Stats
Actions
Tags
From proto-analyzer
Analyzes prototype page URLs to generate backend development documentation: PRD (business requirements), System Design (architecture), and API Specification (integration contracts). Use whenever the user provides a prototype page link (Figma, Axure, online demo, deployed HTML) and wants backend documentation, API specs, data models, or any phrase like "analyze this prototype", "generate backend docs from this page", "extract requirements from this URL".
How this skill is triggered — by the user, by Claude, or both
Slash command
/proto-analyzer:proto-analyzerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transform a prototype URL into three backend development documents:
Transform a prototype URL into three backend development documents:
Explore the prototype to understand its content.
Multiple URLs: The user may provide multiple prototype URLs (e.g., separate pages for list, form, detail). If multiple URLs are provided, process each URL through Steps 1.1-1.5 individually, then aggregate all results into a single page-analysis.json. For each URL, limit navigation depth to 2 levels from that URL.
Use whatever browser automation tool is available:
browser_navigate, browser_snapshot, browser_take_screenshot, browser_click, browser_type)puppeteer_navigate, puppeteer_screenshot, puppeteer_evaluate, puppeteer_click, puppeteer_fill)Strategy: Start with the most capable tool. If one fails (e.g., page doesn't render, auth blocked), try another or ask the user for access.
Fallback chain: If browser automation fails entirely (page won't load, iframe blocked, anti-scraping prevents rendering):
Different prototype platforms behave differently in a browser. Adjust your extraction approach accordingly:
| Platform | DOM Reality | Extraction Approach |
|---|---|---|
| Figma embed | Static SVG/canvas layers; no real HTML form elements | Read visual labels, infer field structure from layout; look for design annotations |
| Axure viewer | Simulated interactions via JavaScript; notes in sidebar panels | Use both visual inspection AND notes panel (highest authority); interact with dynamic panels to reveal hidden states |
| CoDesign/墨刀 | May have real HTML inputs mixed with static previews | Check if elements are actual <input> tags or just styled divs; prefer actual inputs |
| Deployed HTML demo | Real HTML/CSS/JS; actual form elements | Standard DOM inspection; extract from <form>, <input>, <select>, etc. |
| 无法渲染 (iframe blocked / auth wall / anti-scraping) | Empty page, login redirect, or blank iframe | Do NOT proceed with browser tools. Fall back to: (1) ask user for screenshots, (2) ask user for field list directly, (3) use provided URL metadata (page title, URL path segments) to make educated guesses with low confidence |
Key principle: When in doubt about whether a visual element represents a real field or mock data, check the prototype's annotation/notes system first, then ask the user for clarification.
Before extracting any fields, classify each page:
| Page Type | Characteristics | Extraction Strategy |
|---|---|---|
| 表单页 (Form) | Input boxes, textareas, selects, file uploads, editors with labels | Extract label-input pairs as backend fields |
| 列表页 (List) | Table/grid with column headers, filter bar, pagination | Extract column headers as list fields; extract filter items; do NOT extract individual row data values |
| 详情页 (Detail) | Read-only display of a record | Extract displayed fields; note whether there's an associated edit/create form |
| 导航/面板 (Dashboard) | Cards/links to other pages | Extract navigation structure only; typically no backend fields |
| 登录/注册 (Auth) | Auth forms | Extract auth fields; note auth method |
The central challenge: distinguishing field definitions from data instances and mock content. Use this decision tree:
Is this element part of a form control or data display?
├── Form control (input, select, textarea, upload zone, editor)
│ └── Has a visible label nearby? → YES = real field, NO = investigate further
│
├── Data display (static text, table cell, card content)
│ ├── Is it inside a "list" or "table" row? → YES = data instance (extract structure, not values)
│ ├── Is it inside a "form" with other input fields? → YES = could be pre-filled value (check if editable)
│ └── Is it standalone display content? → Evaluate context (see 1.6)
│
└── Navigation/UI chrome (menus, breadcrumbs, buttons, logos)
└── NOT a field
Apply these filtering rules:
Rule 1: Label-Input Pairing (primary signal for form pages) A real form field has:
* if requiredRule 2: Data Instance vs. Field Definition
Rule 3: Context-Based Mock Data Detection A text block is likely mock/sample data (not a backend field) when:
Rule 4: Aggregated/Computed Displays Text that summarizes or aggregates other data is typically NOT a field:
Rule 5: Designer Notes Authority If the prototype has a notes/annotations/specification system:
Rule 6: When Ambiguous — Ask or Flag If you cannot confidently determine whether content is a field definition or mock data:
confidence: "low" in the outputexcluded_items with reason "uncertain — requires clarification"Produce a page-analysis.json with this EXACT structure:
{
"project_name": "string",
"platform_type": "string — Figma/Axure/CoDesign/墨刀/deployed HTML/etc.",
"prototype_url": "string",
"total_pages": number,
"pages": [
{
"page_name": "string",
"page_type": "form | list | detail | dashboard | auth | other",
"navigation_path": "string — e.g., 后台 > 课程管理 > 创建课程",
"confidence": number,
"sections": [
{
"section_name": "string",
"fields": [
{
"label": "string",
"field_key": "string — suggested snake_case key",
"control_type": "text | number | textarea | select | radio | checkbox | date | file | rich_text | switch | custom",
"required": boolean,
"max_length": "number | null",
"placeholder": "string | null",
"validation_rules": ["string array"],
"confidence": "high | medium | low",
"notes": "string | null — designer annotations if available"
}
],
"actions": [
{
"label": "string",
"type": "submit | reset | navigate | dialog_trigger | delete | other",
"requires_confirmation": boolean,
"target_page": "string | null"
}
]
}
],
"excluded_items": [
{
"text": "string — brief description of excluded content",
"reason": "string — why excluded (data_instance, mock_content, aggregated_display, uncertain, navigation_chrome, etc.)",
"rule_applied": "string — which extraction rule triggered the exclusion"
}
]
}
],
"navigation_tree": ["array of reachable page paths"],
"confirmed_workflow": [
{
"page_name": "string",
"entry_path": "string — navigation path to reach this page",
"core_flow": ["string array — step-by-step flow: A → B → C"],
"available_actions": ["string array — operations user can perform"],
"post_action_behavior": [
{
"action": "string",
"behavior": "string — navigate/dialog/refresh/etc."
}
],
"exception_branches": [
{
"scenario": "string — e.g., permission denied, network timeout",
"handling": "string — system response"
}
]
}
],
"auth_required": boolean,
"analysis_notes": "string — observations about prototype completeness, ambiguities, or limitations"
}
Key principles for the output:
excluded_items documents what was filtered and why — this is auditable and debuggableconfidence on each field and page lets downstream agents know what to trustexcluded_items[].rule_applied links each exclusion to a specific rule, making the reasoning transparentfields arraysBased on page-analysis.json, ask the user to provide business context. Do NOT infer business background from page content alone — the UI only shows what fields exist, not why they are needed.
Ask the user three questions:
请提供以下业务背景信息（如果某些项暂不确定，可以跳过或说"用你的推断"）：
**1. 业务背景与痛点：** 当前业务面临什么问题？为什么需要开发这个功能？
**2. 目标用户角色：** 谁会使用这个页面/功能？（如运营人员、C端用户、管理员等）
**3. 预期目标：** 这个功能上线后希望达到什么效果？
请逐一回答，或回复"先跳过"让我基于原型内容做初步推断。
If the user says "先跳过" or asks you to infer, draft the three items with a clear disclaimer that they are preliminary and need verification:
（以下为用户未提供时的初步推断，需要后续确认）
**业务背景与痛点：** [基于原型字段的推断]
**目标用户：** [基于页面结构的推断]
**预期目标：** [基于功能集的推断]
After the user provides or confirms the business context, present any low-confidence fields or ambiguous items from excluded_items that need user clarification:
以下字段/内容我拿不准，请确认：
- [模糊项 1] — 原因：...
- [模糊项 2] — 原因：...
Wait for user confirmation or edits before proceeding.
基于 page-analysis.json 中的 navigation_graph 和 actions，梳理出完整的业务流程图，向用户展示并要求确认。这是生成文档前的最后一道闸门。
呈现格式：
以下是我基于原型梳理的业务流程，请逐项确认：
**页面：[页面名称]**
- 入口路径：[导航路径]
- 核心流程：[步骤A] → [步骤B] → [步骤C]
- 可执行操作：[操作1]、[操作2]、[操作3]
- 操作后的行为：[操作1]→跳转到XX页 / 弹出确认对话框 / 刷新当前列表
- 异常分支：[如权限不足时跳转 / 网络超时时提示]
---
（多个页面依次列出）
---
请确认以上流程是否准确。如有遗漏或错误，请指出需要调整的部分。
回复"确认"继续，或告诉我具体要修改的地方。
关键规则：
page-analysis.json 中的 navigation_tree、sections[].actions、pages[].page_type，不可凭空捏造[推断] 并提醒用户确认[推断—需确认]用户确认后：
page-analysis.json 的 confirmed_workflow 字段page-analysis.json 后再次展示，直到用户确认Ask the user to choose a backend tech stack. If they haven't specified one, present options:
请选择后端技术栈：
1. Java + Spring Boot + MyBatis Plus
2. Python + FastAPI + SQLAlchemy
3. Go + Gin + GORM
4. Node.js + NestJS + TypeORM
5. 其他（请说明）
6. 框架无关的描述即可
Do NOT proceed to document generation until tech stack is confirmed.
Once tech stack is confirmed:
mcp__context7__* tools to query the framework's official documentation for latest conventions and best practices. Then use WebSearch to supplement with recent community guidance (e.g., GitHub issues, Stack Overflow, blog posts from the past 12 months).Only proceed after Step 1 is complete (page-analysis.json available) AND Steps 2-4 confirmed by user.
Document generation follows a sequential dependency to ensure consistency:
Step 6a (Agent A: PRD) ──completed──▶ Step 6b (Agent B: System Design + Agent C: API Spec, in parallel)
Each agent receives:
page-analysis.json (complete field/interaction data)confirmed_workflow (user-confirmed business workflows from Step 3)Spawn Agent A to generate PRD.md. This agent must complete before Step 6b begins, as both Agent B and Agent C will read the generated PRD.
Agent A must include:
confirmed_workflow; if not confirmed, derive from the navigation graphREMINDER: No database terminology, no API paths, no JSON structures.
CRITICAL: Only include fields from page-analysis.json that are in the fields arrays. Cross-check excluded_items to ensure excluded content was not inadvertently included.
Once PRD.md is written and available, spawn Agent B and Agent C in parallel. Both agents receive the same inputs plus the completed PRD.md.
Agent B: System Design Writer
Generate SYSTEM-DESIGN.md using the template at templates/system-design-template.md. Must include:
REMINDER: No API endpoint definitions, no request/response JSON examples. Reference PRD for business rules.
Agent C: API Spec Writer
Generate API-SPEC.md applying the tech stack conventions from Step 5. Must include:
Non-CRUD operations: For actions that are not simple CRUD (batch operations, state transitions, file uploads, exports), define them as custom endpoints with clear request/response contracts. Example: POST /api/v1/orders/{id}/approve for order approval, POST /api/v1/users/import for file upload with multipart/form-data.
REMINDER: No database table definitions, no business background. Reference SYSTEM-DESIGN for entity types, PRD for validation rules.
After all three documents are generated, run verification in three sequential passes:
Spawn a verification sub-agent that performs independent verification against the original prototype, not just page-analysis.json:
page-analysis.json? Is it in the generated documents?page-analysis.json: does it correspond to a real visual element on the prototype?page-analysis.json AND a visible prototype element?page-analysis.json that don't actually exist on the prototype (over-extraction, mock data misclassified as fields)page-analysis.json (under-extraction, real fields misclassified as mock data)excluded_items arrays:
page-analysis.json that shouldn't be therepage-analysis.jsonKey principle: The prototype is the ground truth. Both page-analysis.json and the generated documents are derived artifacts that may contain errors. Always verify against the source.
Spawn a verification sub-agent that:
page-analysis.json, AND the Step 7a backtrack reportpage-analysis.json) as the baseline for coverage checksexcluded_items arrays (that were correctly excluded per Step 7a) appears as a field in any documentSpawn a second verification sub-agent (or continue with the same agent) that:
Merge all three reports into a single VERIFICATION.md with:
If Step 7a finds significant errors in page-analysis.json (more than 2 false positives or false negatives):
page-analysis.json with the corrected field listIf Step 7a finds minor errors (1-2 discrepancies):
If 7b or 7c finds gaps or boundary violations (after 7a has stabilized the field list), re-spawn the relevant document agent with the gap report and regenerate only the affected sections. Retry at most once per document. If gaps remain after one retry, output the remaining gap list for manual review.
All documents are written to a docs/ directory at the project root. If docs/ does not exist, create it. If a file with the same name already exists, append a timestamp suffix (e.g., PRD_20260415_1430.md).
docs/
├── PRD.md
├── SYSTEM-DESIGN.md
├── API-SPEC.md
└── VERIFICATION.md
templates/prd-template.mdtemplates/system-design-template.mdtemplates/api-spec-template.mdnpx claudepluginhub fectivnfy112357/proto-analyzer --plugin proto-analyzerProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.