前端页面接口索引（frontend-index）

概述

目的：把「前端页面 ↔ 后端接口」的双向定位，从"每次 grep 试探 + 逐条读文件收敛"变成"查表直达 file:line"。后端要改接口时先知道哪些页面在调（防漏改），接页面任务时先知道它用了哪些接口与组件（省搜索）。

功能：

扫描本地前端源码，提取路由（页面）→ 接口调用 → 定义处的完整链路（含 file:line 证据）
产出双向映射：页面 → 接口/组件 与 接口 → 页面（直接调用 / 间接候选）
一键重建：重建由脚本完成（零依赖），AI 只做语义标注，成本不随项目规模线性上涨
新鲜度闸门：索引记录生成时的 commit，查询前比对，过期先提示重建（代码映射失效是静默的，必须显式校验）
证据分级：🟢 页面自身调用｜ 🟡 直接依赖｜ 🔵 间接候选（深度 ≥2）｜ [待确认] 动态 URL
约定探测 + 声明文件：内置主流框架约定探测，探测结果可固化为 .fe-index/config.json，之后重建零猜测
双模式：消费模式（查已有索引，不跑脚本）与建造模式（采集建库）分离

使用场景：

后端要改 / 删某个接口，需要知道"哪些前端页面会受影响"
接到某个页面的任务，需要知道"这个页面调了哪些接口、依赖哪些组件、在哪看代码"
新会话接手前端项目，需要一份"页面地图"快速建立认知
用户说"给前端建个索引"、"页面接口映射"、"改这个接口影响哪些页面"、"哪个页面调了这个接口"、"前端索引"时
之前建过索引的项目再次被问起——先查 .fe-index/INDEX.md 进消费模式，而不是重跑扫描

定位

本地前端源码 → frontend-index（本 skill）→ .fe-index/（页面 ↔ 接口 双向路由表）
                                   ↓
              改接口前：查"接口 → 页面" → 知道要改/要回归哪些页面
              接页面任务：查"页面 → 接口/组件" → 直达 file:line

输入：本地前端工程（含路由配置或页面目录）
输出：.fe-index/（INDEX.md + {slug}/index.md + pages/*.md + apis/*.md + meta.json）
边界：只索引不改码；只做 HTTP 接口（GraphQL / WebSocket / RPC 不提取）；索引是派生产物，需一键重建

与邻接 skill 的分工（防重叠）

邻接 skill	它回答的问题	本 skill 回答的问题
`web-index`	外部网站的文档该看哪一页（抓 llms.txt / sitemap）	本地前端代码里页面与接口怎么对应（扫源码）
`backend-index`	本地后端的「模块 ↔ 目录/入口/依赖/数据表」（扫后端源码，模块级）	本地前端的「页面 ↔ 接口」（扫前端源码，页面级）。两者同族同根 `.fe-index/`：跨端 join（改后端接口 → 前端哪些页面）用后端 `index.md` 的「模块 → 挂载前缀」匹配本索引 `apis/*.md` 的接口路径，口径见 `backend-index/SKILL.md` 的「被其它 skill 集成」
GitNexus MCP（`impact` / `api_impact` / `context`）	符号级影响面（需要 CLI + 已建索引）	页面级视角、零依赖、产物是人可读的落盘表
`code-survey`	设计前一次性调研代码现状	一次性调研 → 可跨会话复用的落盘资产
`relation-lookup` / `strong-relation`	人工沉淀的跨模块强关联记录	从源码自动提取的页面↔接口映射
`frontend-walkthrough`	页面体验走查（点一遍看有什么问题）	页面与接口的静态对应关系
`frontend-api-guide`	从 API 设计文档生成前端集成指南（设计 → 文档）	从已有代码反推页面与接口关系

何时不使用本 skill：只查一个页面/一个接口的瞬时问题 → 直接 grep；要看符号级调用链影响面且项目已装 GitNexus → 用 GitNexus；要看后端性能 → performance-analysis；要重新设计页面 → ui-designer。

与项目强制规则的关系：后端侧"改 API handler / 路由 / 对外契约前查影响面"仍按项目规则走 GitNexus（如 rules/gitnexus-mcp-rules.md 的强制触发表）；本 skill 只补前端页面级那一层，不替代、也不弱化既有强制规则。

核心原则

路由表，不是链接清单：每条映射必须有任务视角的落点（页面 → file:line、接口 → 调用页面），否则等于没索引。
深度即置信度（本 skill 的诚实性根基）：调用点在页面自身（深度 0，🟢）才是"这个页面在用"；在直接依赖内（深度 1，🟡）是强相关；在依赖的依赖里（深度 ≥2，🔵）只是间接候选。反向表必须分开列，禁止把候选混进"调用页面数"。
不臆造：URL 必须来自源码；动态拼接 / 运行时变量无法静态求值时标 [待确认] 并保留原始表达式，不猜最终路径。
新鲜度必须显式校验：代码每天都在变，过期索引会静默给错答案（比没有索引更糟）。查表前先比对 commit（--check），过期先重建。
机器提取为主，AI 只补语义：映射关系由脚本提取（确定性、可复跑）；AI 只补分区、语义列、处理 [待确认] 与少量抽样。页面/路由名本身自带语义，不要重读每个页面。
一键重建：重建 = 一条命令 + 一次标注。若重建成本高到不愿跑，索引必然腐化。
声明文件兜底通用性：内置约定探测覆盖主流写法；探测不到时用 .fe-index/config.json 显式声明（框架无关靠这层，不靠无限猜测）。
可见性由集成方负责：.fe-index/ 是隐藏目录，本 skill 不擅自往用户的 AGENTS.md / 规则里写钩子；被其它 skill 集成时由调用方在自身流程声明"先查 INDEX.md"。

产物结构

落点一律在【项目根】（git rev-parse --show-toplevel；非 git 仓库则逐级向上找 .git）：即 {项目根}/.fe-index/。 monorepo 里 --root 可以给应用子目录（如 bkmonitor/webpack），但索引属于整个项目——所有应用共用一个 .fe-index/。

{项目根}/.fe-index/
.fe-index/
├── INDEX.md                      # 必存在：全项目登记表（一行一应用）—— 后续会话的发现入口
├── config.json                   # 可选：约定声明文件（AI 在阶段 1 探测后产出、用户确认，重建零猜测）
└── {slug}/
    ├── index.md                  # 必存在：元信息 + 新鲜度状态 + 怎么用 + 分区索引 + 高频直达
    ├── meta.json                 # 必存在：机器可读元信息（commit / 范围 / 统计），--check 依据
    ├── pages/{分区}.md           # 页面 → 路由、文件、接口、组件（≤30 页时直接放 index.md）
    └── apis/{分区}.md            # 接口 → 页面（直接调用 / 间接候选）、定义位置

两类文件，入库策略不同（别一锅端）：

类别	文件	是否入库
声明（人写，AI 探测后固化）	`config.json`	建议入库——它记录"这个项目的约定"，不入库则每个会话/每个协作者都要重新探测
派生产物（脚本+标注生成）	`meta.json` / `index.md` / `pages/` / `apis/`	默认不入库（会随代码过期，入库前请加 `.gitignore` 或按团队约定）

INDEX.md 是这个机制的生命线：隐藏目录不会被自动发现，每次建造都必须同步更新它。

# 索引登记表（.fe-index/）

> 涉及下列应用的问题，先查对应条目所在的分区/映射表，再看代码

| 应用 | 类型 | slug | 根目录 | 规模 | commit | 生成日期 |
|------|------|------|--------|------|--------|----------|
| monitor-pc | frontend | monitor-pc | src/monitor-pc | 页面 116 · 接口 337 | 4f2a9c1 | 2026-10-13 |
| server-ai | backend | server-ai | `/root/xpert` | 模块 125 · 表 122 | 889e265c | 2026-10-13 |

**更新纪律**：只增改本应用那一行，**不动其他行**；同一仓库前后端各占一行（slug 不同，不合并）——`backend-index` 与本 skill 共用这份登记表，列结构一致。
**「根目录」列口径**（消费方按此解析）：绝对路径直用；**相对路径以 `.fe-index/` 的上一级为基准**（便于跨机器与仓库整体搬迁）。查找登记表时若 `{root}` 下没有，逐级向上找 ≤3 层。

meta.json 模板（`--check` 依赖，必写）

{
  "slug": "monitor-pc",
  "root": "/abs/path/to/repo/webpack",
  "scope": "src/monitor-pc",
  "commit": "4f2a9c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6071",
  "generated": "2026-10-13",
  "routes": 124,
  "pages": 116,
  "apis": 337,
  "scanner": "scan_frontend.py v1.0.0"
}

scope 支持字符串或数组；多个范围必须写成数组（["packages/**", "apps/**"]）——拼成一个字符串会让 git 匹配不到文件，--check 会错报"索引可用"（静默假阴性）。

index.md 模板

# {应用名} 前端接口索引

> 根目录：{root} · 范围（scope）：{prefix} · slug：{slug}
> 生成：2026-10-13 @ commit 4f2a9c1 · 页面 116 · 接口 337 · **需一键重建**（快照制 + 新鲜度闸门）

## 怎么用

1. 查「接口 → 页面」定位影响面（直接调用优先，间接候选仅参考）
2. 查「页面 → 接口」拿到该页面要读的文件与依赖
3. 表是快照：`--check` 报过期时重跑脚本并重新标注

## 高频直达

| 我要… | 去哪一页 | 证据 |
|-------|----------|------|
| 改 grafana 面板列表接口，看哪些页面受影响 | [apis/grafana.md](./apis/grafana.md) | `rest/v2/grafana/dashboards` |

## 分区索引

| 分区 | 文件 | 页面数 | 覆盖内容 |
|------|------|--------|----------|
| grafana | [pages/grafana.md](./pages/grafana.md) | 8 | 面板、文件夹、快照 |

pages/{分区}.md 与 apis/{分区}.md 模板

# {分区}（{应用名} · 页面 {N} 个）

| 路由 | 页面文件 | 用到的接口 | 直接依赖 |
|------|----------|------------|----------|
| `/grafana` | `pages/grafana/grafana.tsx` | GET `rest/v2/grafana/dashboards` 🟢 | `components/…`(深度1) |

# {分区} 接口反查（{应用名} · 接口 {N} 个）

| 方法 | 接口 | 直接调用页面 | 间接候选 | 定义位置 |
|------|------|--------------|----------|----------|
| GET | `rest/v2/grafana/dashboards` | `/grafana`、`/grafana/new` | 3 个（见备注） | `monitor-api/modules/grafana.js:12` |

分区规则：页面 ≤30 个不分区（直接放 index.md）；>30 按路由一级段 / 页面目录一级拆分；接口按 URL 首个有意义路径段。分区名以扫描输出的「分区建议」为准，不自造。

工作流

第一步先判模式（必做）：读 .fe-index/INDEX.md（不存在则视为首次建库；被集成时落点以调用方指定为准，见「被其它 skill 集成」）。

情况	模式	路径
目标应用已在册，本次是来问某个接口/页面	消费模式	见下，查到就走——不重跑扫描
未收录，或用户明确要求建 / 重建	建造模式	走阶段 0 → 阶段 5

消费模式（查表 → 读码）

读 .fe-index/INDEX.md → 拿到 slug
新鲜度闸门（轻量校验，只比对 commit，不产出索引）： python3 {skill-dir}/scripts/scan_frontend.py --root {root} --check --index .fe-index/{slug}
- 退出码 0：新鲜（含"提交前进但扫描范围内无变化"）→ 直接查
- 退出码 6：已过期 → 告知用户并给出重建命令（先问是否重建，不擅自重跑）
- 退出码 7：缺 meta.json → 视为"无新鲜度信息"，按待重建处理并告知
- 退出码 3：git 不可用或记录的 commit 不可达 → 告知用户，按"新鲜度不可判"处理（不假装新鲜）
读 .fe-index/{slug}/index.md → 命中分区后再读对应 pages/*.md 或 apis/*.md（只读命中的那一个）
用 Read / grep 打开命中行的 file:line 确认现状（索引是路标，源码是事实）
没命中才现场 grep；确认是常用页面/接口后可手动补一行（重跑会丢失，属可接受损耗）

消费模式不做提取扫描（--check 只比 commit，属轻量校验）；查表命中即止，不"顺便重建一下"。

建造模式总览

阶段 0：准入判断   → 该不该建？（不该建就直说，走正常 grep）
阶段 1：约定探测   → 探测路由/接口层/别名 + 生成声明文件（唯一的用户确认点）
阶段 2：脚本提取   → 一次扫描拿到 路由 / 接口定义 / 调用点 / 正反映射
阶段 3：标注落盘   → 分区 + 语义列 + 处理 [待确认]（成本闸门：读文件 ≤10 个）
阶段 4：写产物     → INDEX.md + index.md + pages/* + apis/* + meta.json
阶段 5：交付       → 输出结算 + 声明后续用法与重建方式

阶段 0：准入判断（AI 自主，不必问用户）

信号	判定
目标应用已在 `INDEX.md` 在册	➡️ 转消费模式（用户要求重建除外）
只问一个页面/一个接口的一次性问题	❌ 不建，直接 grep
代码量极小（单页 demo、<10 个页面且无路由表）	❌ 不建，直接读文件
项目用 GitNexus 且问题只需符号级影响面	⚠️ 告知用户可用 GitNexus；仍要页面级映射则建
同一应用本次已出现 ≥2 次跨文件定位，或用户说"后面会反复改接口"	✅ 建
用户主动要求"建索引"	✅ 建（仍会在阶段 1 确认范围）

判定不建时，一句话说明理由后回到正常查阅流程，不产出任何文件。

阶段 1：约定探测（唯一的用户确认点；阶段 4 遇到同名 slug 时另有一次覆盖重建确认）

先探测（零配置可跑）：
```
timeout 60s python3 {skill-dir}/scripts/scan_frontend.py --root {项目根} --dump-config
```
输出：框架信号、候选路由文件、候选 pagesDirs / apiDirs、别名、工作区包名。

校正并生成声明文件 .fe-index/config.json（探测有遗漏时手改，尤其 apiDirs 与 aliases）：

{
  "apps": [
    {
      "kind": "frontend",
      "slug": "monitor-pc",
      "root": "/root/bk-monitor/bkmonitor/webpack",
      "include": ["src/**"],
      "routes": ["src/**/router/**/*.ts"],
      "pagesDirs": ["src/monitor-pc/pages"],
      "apiDirs": ["src/monitor-api/modules"],
      "aliases": {"@page": "src/monitor-pc/pages", "@api": "src/monitor-api"},
      "requestObjects": [],
      "maxDepth": 2
    }
  ]
}

config.json 与 backend-index 共用：本 skill 只认 kind=frontend（缺省视为 frontend），后端只认 kind=backend——同仓库前后端各写一条，互不选中对方。

与用户确认一次：

📇 前端索引 · 范围确认
━━━━━━━━━━━━━━━━━━━━
应用：{应用名}（{根目录}）
产出目录：.fe-index/{slug}/
路由来源：{routes}
接口层：{apiDirs}
归属深度：{maxDepth}（0 页面自身 / 1 直接依赖 / 2 含间接候选）

请确认范围？是否需要排除某些目录（如 mock / 旧版页面）？

参数选择要点：

--include 限定扫描范围（monorepo 必须给，如 src/**），避免扫到构建产物
--routes 用 glob（**/ 按 gitignore 语义可匹配零层目录）
--api-dir 指向接口定义所在目录（服务层 / API 模块），它决定"符号 → URL"能否解析
--max-depth：0 只看页面自身调用（最准最窄）；1 加直接依赖；2（默认）再加间接候选
--alias k=v：别名探测遗漏时补（可重复）

阶段 2：脚本提取

timeout 300s python3 {skill-dir}/scripts/scan_frontend.py --root {根目录} \
  --include 'src/**' --routes 'src/**/router/**/*.ts' \
  --api-dir src/monitor-api/modules --pages-dir src/monitor-pc/pages \
  --format json --out temp/fe-index-{slug}-scan.json

--format json 便于 AI 结构化处理；md 供人读、tsv 供管道
中间产物落 temp/（不存在则先创建），只增不删，完成后告知用户位置
Python 运行方式：项目有 venv 按其命令；否则优先 uv run python；uv 不存在时不擅自安装，退回 python3（本脚本零依赖）

退出码处置（完整表见 reference.md）：

码	含义	处置
0	成功	进入阶段 3
2	未识别到路由 / 接口约定	回到阶段 1 校正声明文件（显式给 `--routes` / `--api-dir` / `--alias`）
3	环境或 IO 错误（路径不存在、git 不可用）	报告用户，修正路径后重跑
4	提取结果为空	检查 `--include` 是否过窄、深度是否为 0
5	入参非法（config 不是合法 JSON、`--max` 超上限、缺 `--index`）	修正参数后重跑，重试同一命令没有意义
6	`--check` 判定索引过期	告知用户 + 给重建命令
7	`--check` 时 `meta.json` 缺失	按"无新鲜度信息"处理，建议重建

退出码非 0 不得进入阶段 3（尤其别把失败当"没条目"处理，否则会产出一份空索引却看起来正常）。 截断必须处理：输出里出现 stats.truncated（如 page_apis 2024→1000）说明撞到了 --max 上限——反向表会静默少列页面/接口。此时必须提高 --max（硬上限 5000）或收窄 --include 后重跑，不得直接进入阶段 3。

阶段 3：标注（本 skill 的核心增值）

对扫描结果补齐语义层。成本闸门：本阶段读文件不超过 10 个。

分区：按输出的「分区建议」拆 pages/{分区}.md / apis/{分区}.md；≤30 页不分（直接进 index.md）
接口列：URL 保留源码形态（rest/v2/report/report_list/、/api/membership/plans/:param）；动态部分标 [待确认]
页面列：用页面名/路由名直接写"我要…"（如"改 grafana 面板列表 → 看 /grafana 页"），不重读页面文件
组件列：取扫描输出的「页面 → 直接依赖」（深度 1），只列有导航价值的（页面级组件 / 工具模块），不列类型文件
[待确认] 分诊（三类，逐条给结论，不许留在原地）：
- 常量可解析（${this.apiUrl} 随实例变化）→ 在表内写明"前缀来自实例配置，需看运行环境"
- 动态拼接（`/api/${type}/list`）→ 拆成"模板 + 变量来源"，必要时读那一个文件确认
- 真不确定 → 如实保留 [待确认]，并在交付说明里列出条数
反向表：直接调用页面（🟢🟡）内联列出；间接候选（🔵）只写条数，不展开（避免"一张表 300 个页面"）

本阶段禁止：为了填满表格逐页读代码；把 🔵 候选写成"调用页面"；把动态 URL 猜成确定路径。

阶段 4：落盘

检查 {项目根}/.fe-index/{slug}/ 是否已存在：存在则先告知用户"将整应用覆盖重建"（快照制无增量合并），确认再写
写 meta.json（必须：commit 用 git -C {root} rev-parse HEAD；scope 填扫描范围）+ index.md + pages/*.md + apis/*.md
同步更新 .fe-index/INDEX.md（新增或覆盖该应用那一行）——缺这步，后续会话发现不了这份索引
写入后自检：所有 URL / file:line 均来自阶段 2/3 的实际产出，无凭空拼写的路径

阶段 5：交付

✅ 前端接口索引已生成

位置：.fe-index/{slug}/        （默认隐藏目录，不入库）
应用：{应用名}（{根目录}）
范围：{scope} · 页面 {N} · 接口 {M} · 生成于 commit {xxx}

| 文件 | 内容 |
|------|------|
| index.md | 高频直达 + 分区索引 |
| pages/{A}.md | {A 覆盖内容}（{n} 页） |
| apis/{A}.md | {A 覆盖接口}（{m} 个） |

⚠️ 派生产物：代码变了要重建（一条命令）
   timeout 300s python3 {skill-dir}/scripts/scan_frontend.py --root {root} --out temp/fe-index-{slug}-scan.json
   重建后重跑阶段 3-4（脚本负责映射，你只需补标注）
⚠️ 新鲜度自检：python3 {skill-dir}/scripts/scan_frontend.py --root {root} --check --index .fe-index/{slug}
   （0 新鲜 / 6 过期 / 7 缺 meta.json）
⚠️ 隐藏目录不会被自动发现：独立使用时需项目在 AGENTS.md / 规则里加一行
   "改前端接口相关代码前，先查 .fe-index/INDEX.md"（加不加由你决定，本 skill 不代劳）；
   被其它 skill 集成时，钩子由调用方在其流程中声明。

后续用法：先查索引定位页面/接口，再读源码确认；索引是路标，源码是事实。

抽样校验（可选，建议首次建造时做）：随机抽 5-10 条 🟢 行回源码核对（via 为 import: 的看调用点是否有该符号调用；inject: 的看是否有 this.#svc.method(）——抽样不通过时不要交付，先修正声明文件重跑。浏览器可运行时，还可用 use_skill("agent-browser") 实测 2-3 个高频页面，比对实际网络请求与索引条目。

反模式

❌ 把源码读一遍来"理解页面用途"：映射由脚本提取，AI 只补语义列；逐页阅读会让成本爆炸且得不到更准的表
❌ 把间接候选写成"调用页面"：🔵 是"经依赖链相关"，不是"这个页面在用"——混写会让反向表不可信
❌ 动态 URL 猜成确定路径：/api/${type}/list 不许写成 /api/order/list；拿不准就 [待确认]
❌ 不写 meta.json 就交付：没有 commit 就无法判断新鲜度，索引会静默过期
❌ 过期索引照用：--check 报 6 还继续查表，等于用旧代码回答新问题
❌ 每次提问都重跑扫描：建造成本 > 收益；消费模式就是为省这一步存在的
❌ 漏更新 .fe-index/INDEX.md：索引藏在隐藏目录里，没有登记表谁也找不到它
❌ 把多个应用塞进同一个 slug：monorepo 里 apm / monitor-pc 混在一起，反向表会互相污染
❌ 只索引不重建：写完全量索引就当一劳永逸——代码一变，索引就从资产变成负债

行为边界

只索引，不改码：不修改被扫描项目的任何文件；不提交、不写 .gitignore（是否入库由用户决定）
快照制 + 新鲜度闸门：不生成自动刷新计划、不做增量合并；重建 = 重跑脚本 + 重标注（脚本重建成本为秒级）
只做 HTTP 接口：fetch / axios / http.* / 自定义 request 工厂 / inject 服务方法；GraphQL、WebSocket、RPC 不提取（在报告里说明"未覆盖"）
不猜运行时：动态 URL、feature flag 条件调用、运行时菜单驱动路由 → 标 [待确认]，不推断
不改用户环境：不装依赖、不改配置、不注册到任何需求管理系统
不替代源码阅读：索引给"去哪看"，最终结论必须落到源码确认
与 web-index 分工：web-index 管外部网站的页面路由（.web-index/），本 skill 管本地前端代码的页面↔接口（.fe-index/）——两者产物互不冲突，落点不同

被其它 skill 集成（调用契约 · SSOT）

需要"页面 ↔ 接口"映射的 skill 按本节判定，不要无脑建索引：

情况	怎么用
已在 `.fe-index/INDEX.md` 在册	消费模式：先 `--check` 验新鲜度 → 查表 → 读源码。不跑扫描
未收录且会反复用（跨阶段 / 跨会话）	建造模式（阶段 0-5），落点默认 `.fe-index/`
只问一次	什么都不建，直接 grep

判定规则本身不复制——规则改了只改本文件。已知集成点（新增时在此加一行）：

集成方	建议用法	状态
`index-lookup`（统一查询入口）	消费方先调它按代码路径判定该查前端还是后端索引（读同一张 `.fe-index/INDEX.md`），再按本 skill 的查询口径查表	推荐接入：不要让每个消费方自己实现"选哪端"（口径会漂移）。已接入：`code-review` / `debug` / `product-manager` / `code-survey` / `bug-impact-analysis` / `expert-team`
`frontend-walkthrough`	阶段 1「入口穷举」先查索引拿页面清单与接口，省一次全站搜索	已接入（阶段 1 第 1 项）
`code-review` / `bug-impact-analysis`	改到前端接口调用时，用反向表确认影响页面	已接入（code-review 阶段 2 / bug-impact-analysis 3.0，经 `index-lookup`）
`e2e-testing`	设计端到端旅程时用页面→接口表选关键路径	已接入（阶段 1 选路径与终态校验点）

上表不声明"已接入"：本 skill 的落盘映射需要目标项目先建一次索引，集成方需自行降级（无索引时按原流程 grep）。

frontend-index

SKILL.mdskills/frontend-index/SKILL.md

前端页面接口索引（frontend-index）

概述

定位

与邻接 skill 的分工（防重叠）

核心原则

产物结构

meta.json 模板（`--check` 依赖，必写）

index.md 模板

pages/{分区}.md 与 apis/{分区}.md 模板

工作流

消费模式（查表 → 读码）

建造模式总览

阶段 0：准入判断（AI 自主，不必问用户）

阶段 1：约定探测（唯一的用户确认点；阶段 4 遇到同名 slug 时另有一次覆盖重建确认）

阶段 2：脚本提取

阶段 3：标注（本 skill 的核心增值）

阶段 4：落盘

阶段 5：交付

反模式

行为边界

被其它 skill 集成（调用契约 · SSOT）

更多资源

Похожие навыки: design

add-uint-support

skill-writer

frontend-design

frontend-index

SKILL.mdskills/frontend-index/SKILL.md

前端页面接口索引（frontend-index）

概述

定位

与邻接 skill 的分工（防重叠）

核心原则

产物结构

meta.json 模板（--check 依赖，必写）

index.md 模板

pages/{分区}.md 与 apis/{分区}.md 模板

工作流

消费模式（查表 → 读码）

建造模式总览

阶段 0：准入判断（AI 自主，不必问用户）

阶段 1：约定探测（唯一的用户确认点；阶段 4 遇到同名 slug 时另有一次覆盖重建确认）

阶段 2：脚本提取

阶段 3：标注（本 skill 的核心增值）

阶段 4：落盘

阶段 5：交付

反模式

行为边界

被其它 skill 集成（调用契约 · SSOT）

更多资源

Похожие навыки: design

add-uint-support

skill-writer

frontend-design

meta.json 模板（`--check` 依赖，必写）