SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsfrontend-page-discovery

frontend-page-discovery

Frontend & websites

View repository

Updated 10-16 08:49

About this skill

Frontend page inventory reverse engineering (evidence-based)

Overview

Goal: Generate a page inventory and per-page documentation based on code evidence (persisted to docs/）。

When to use / when not to use

When to use (trigger signals)

  • You need to derive from frontend code atraceablepage inventory, and continue to refine processes/rules
  • Project route entry points are complex: multiple SPAs/micro-frontends/multiple frameworks coexist, runtime-injected routes, backend-delivered menus
  • Common team problems: missing pages, duplicate pages, permissions/dynamic routes cannot be persisted, rule summaries lack 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 for your project even without code" (in this case you can only deliver templates/examples, and cannot output facts)

Default deliverables of this skill (persisted to .aidlc/project/frontend/)

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

Persistence templates (minimal usable, can be copied directly)

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

Template mapping:

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

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

  1. No imagining
    • 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 requests "bold assumptions, no evidence needed", you may only output the EXAMPLE（示例） block or template; you must not write examples as project facts, nor mix them with 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: A wireframe can only "restate UI that already exists in the code", and cannot "fill in a backend page that you think should exist".

Hard gate (if any one 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 be able to 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, batch operations, sidebar menus, statistic cards, invoice downloads, timelines, or other controls just because "common backend systems are like this", "it looks more complete", or "the person in charge 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 the unknown items one by one into Evidence Gaps。
    • Important limitation：UNKNOWN(...) can only be used for elements that "already exist with evidence, but whose details are incomplete" (for example: the code has a button but its copy is an unresolved i18n key).It is forbidden to use UNKNOWN(...) to disguise newly added controls/areas(for example: drawing without evidence UNKNOWN(Export) / UNKNOWN(侧边栏菜单)）。

Recommended output structure (evidence first, diagram after)

  • Control/region inventory (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 are already evidenced in the inventory may be used; regions without evidence may only be written as UNKNOWN(...)。

Evidence extraction priority (recommended 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 parameters, 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.
"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 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 any appears)

  • "I'll draw a complete one first, then go back and find evidence to fill it in"
  • "This kind of page usually has... (export/bulk/time filter/role department/stat cards)"
  • "The code doesn't say it, but the product should have it..."
  • "It's fine, 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 are hidden pages caused by backend-delivered menus")

Output fields (must appear in the final result)

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