frontend-page-discovery

Frontend page inventory reverse engineering (evidenced)

Overview

Goal: generate a page inventory and single-page documentation based on code evidence (written to disk at docs/）。

When to use / When not to use

When to use (trigger signals)

• You need to derive from frontend codetraceablepage inventory, and continue to distill processes/rules
• Complex project routing entry points: multiple SPAs/micro-frontends/multiple frameworks coexisting, runtime-injected routes, backend-delivered menus
• Common team problems: missed pages, duplicate pages, permissions/dynamic routes that cannot be written to disk, rule summaries lacking evidence

When not to use

• You only need to write a PRD/prototype (this is not code reverse engineering)
• You are asked to "give the real page inventory/rule conclusions of your project even without code" (in this case you can only deliver templates/examples, and cannot output facts)

Default deliverables of this skill (written to disk at .aisdlc/project/frontend/)

• .aisdlc/project/frontend/pages/index.md
• .aisdlc/project/frontend/pages/<page_id>.md
• .aisdlc/project/frontend/flows/index.md
• .aisdlc/project/frontend/conflicts.md

On-disk templates (minimal usable, ready to copy)

The output templates for this skill have been migrated to assets/ directory, to reduce the length of the skill body and keep the templates reusable.

Template mapping:

• .aisdlc/project/frontend/pages/index.md ← <本SKILL.md目录>/assets/pages-index-template.md
• .aisdlc/project/frontend/pages/<page_id>.md ← <本SKILL.md目录>/assets/page-template.md
• .aisdlc/project/frontend/flows/index.md ← <本SKILL.md目录>/assets/flows-index-template.md
• .aisdlc/project/frontend/conflicts.md ← <本SKILL.md目录>/assets/conflicts-template.md

Hard rules (if any one occurs: stop and correct)

1. No filling in gaps
   • Any "page/process/rule" must be able to point to evidence (see the evidence format below); otherwise write it into Evidence Gaps, and do not write speculative conclusions.
2. Facts and examples must be physically separated
   • If the user asks to "assume boldly, no evidence needed", you may only output the EXAMPLE（示例） section or template; you must not write examples as project facts, and must not mix them into fact tables.
3. Output fields must be complete
   • The page index must include module_name page_id page_name。
   • A single page must include page_name breadcrumb ascii_wireframe 核心任务 关键规则摘要。

Page wireframe (ASCII) evidence gate (mandatory)

Goal: the wireframe may only "restate UI that already exists in the code", and must not "fill in a backend page you think should exist".

Hard gate (if any is not satisfied: the wireframe must not be drawn, and only Evidence Gaps may be written)

• Item-by-item mapping: every visible element appearing in the wireframe (title/button/field name/column header/Tab/copy/menu item/action) must map to at least 1 piece of frontend code evidence (file + lines + excerpt）。
• "Common-sense completion" is not allowed: you must not add filter conditions, export, bulk actions, sidebar menu, statistics cards, invoice download, timeline, or other controls just because "common backend systems are like this", "it looks more complete", or "the owner is pressing for delivery/does not allow saying information is missing".
• Unknowns must be explicit: when evidence is insufficient, use the placeholder UNKNOWN(...) to express the unknown, rather than writing a "reasonable guess" of a specific field/copy; and write unknown items one by one into Evidence Gaps。
  • Important limitation：UNKNOWN(...) can only be used for elements that are "evidenced to exist, but whose details are incomplete" (for example: a button exists in the code but its copy is an unresolved i18n key).It is forbidden to use UNKNOWN(...) to disguise newly added controls/areas(for example: drawing UNKNOWN(Export) / UNKNOWN(侧边栏菜单)）。

Recommended output structure (evidence first, diagram after)

• Control/area checklist (required): First list the UI elements (for example: title, primary action button, search box, filter items, table columns, row actions, modal fields, status copy), with evidence for each line.
• Then generate ascii_wireframe: Only elements that have been evidenced in the checklist may be used; areas without evidence may only be written as UNKNOWN(...)。

Evidence extraction priority (suggested order)

• Routes and page entry points: route table/route injection points/backend menu adapter → locate the page component file
• Page title and breadcrumb: page header component,<h1>、document.title/useTitle, breadcrumb component props, i18n key
• Primary actions and toolbar: button copy (including i18n), icon+aria-label, call sites for onClick navigation/opening modals
• Filters/forms: form schema,name/label/placeholder, validation rules, default values
• Lists/tables: columns definition (title/key/render), row action menu, pagination parameters
• Status copy: empty/loading/error/403 components and copy; if only generic components are seen but it cannot be confirmed whether this page uses them, treat as UNKNOWN

Common excuses → how they must be handled (anti-hallucination)

Excuse/pressure phrasing	Correct approach (mandatory)
"Just fill it in based on experience / make it look more like a real product"	Only output EXAMPLE（示例）; the factual wireframe still follows the evidence gate.
"You can't say information is missing, you must deliver"	Deliver UNKNOWN(...) + Evidence Gaps ; do not write unknowns as specific fields/buttons. UNKNOWN(...) + Evidence Gaps; do not write unknowns as specific fields/buttons.
"The template has a filter area/export/bulk actions"	The template is only a skeleton; controls not covered by code evidence must remain as UNKNOWN(...) or be deleted.
"At least write in the empty/loading/error states"	Only write them when they can be located in code/components/copy; otherwise mark as UNKNOWN(state) and add to Evidence Gaps.

Red flag checklist (stop and correct immediately when it appears)

• "I'll draw a complete one first, then go back and find evidence to fill it in"
• "This type of page usually has... (export/bulk/time filter/role department/stat cards)"
• "The code doesn't say it, but the product should have..."
• "It's okay, just write something rough first"
• "I'll use UNKNOWN(...) as a placeholder first and draw the page completely"

Evidence format (uniform and reviewable)

Each conclusion must include at least 1 piece of evidence:

• type：page_title | route_decl | file_convention | menu_static | menu_backend | nav_call | guard | api_call | state_machine | form_validation | other
• file: relative path
• lines：start-end
• excerpt: 1–3 lines of key excerpt (original text)

When evidence is missing, you must write:

• gap: what evidence is missing
• candidate_locations: where it might be found (directory/file type/keywords)
• impact: impact on the conclusion (for example, "cannot confirm whether there is a hidden page caused by a backend-delivered menu")

Output fields (must appear in the final result)

• Page index:module_name page_id page_name
• Single page: page_name breadcrumb ascii_wireframe core task key rules summarypage_name breadcrumb ascii_wireframe 核心任务 关键规则摘要