SpecForge requirements 主能力包。用于把 brief、brainstorm、PRD、research、gap report、wiki 当前事实和用户确认转成可测试、可追踪、可交给 UI / technical design / tasking / verification 的 REQ / AC / NFR / 边界 / handoff 行为契约。

2026-06-222

sf-requirements

huangrx6/SpecForge

生成或更新 SpecForge 工作项的需求规格；用于活跃工作项的 ready artifact 为 requirements，或需要把产品需求文档 / 简报转成可测试行为、边界、用户故事、验收标准和影响面标记时。

2026-06-222

requirements

huangrx6/SpecForge

SpecForge 内部需求技能。用于为 work item 生成清晰、可测试的功能需求、非功能需求、范围边界、不在范围内和验收标准。

2026-06-222

code-intelligence

huangrx6/SpecForge

SpecForge 跨阶段代码智能能力包。用于任何阶段需要 Wiki-first 定位现有代码范围、选择 CodeGraph / MCP / SCIP / Repomix / rg、检查 provider freshness、归一 graph_facts、分析影响面 / affected tests 或生成 Wiki 回写候选时必读；不要只在 sf-steering 中使用。

2026-06-222

sf-steering

huangrx6/SpecForge

为存量项目或大型代码库建立 SpecForge 项目画像；用于新需求或 bugfix 前理解现有架构、刷新 wiki、生成后续 work item 的上下文基线。

2026-06-222

test-engineering

huangrx6/SpecForge

SpecForge 测试工程主能力包。用于 sf-verify 在验证前把 requirements、tasks、UI、technical design 和 code review 风险转成可解析 TC/PW 用例、runtime runbook、auth strategy、自动化计划和可归档 evidence。

2026-06-222

name	wiki-sync
description	SpecForge 内部 Wiki 同步技能。用于 closure 前判断 work item 是否影响 .specforge/wiki 长期项目知识，并更新或说明不更新原因。

Wiki 同步技能

本技能在 closure 前判断 work item 是否影响长期项目知识，并更新 .specforge/wiki/ 或说明不需要更新。它是防止“代码已变、知识库过期”的收口步骤。Wiki 只保存当前事实，不保存过程流水账。

读取

01-spec/requirements.md
00-intake/prd.md（存在时）
01-spec/ui-design.md（存在时）
01-spec/technical-design.md（存在时）
02-spec-review/spec-review-v1.md（存在时）
03-implementation/report.md
04-code-review/code-review-v1.md
05-verification/report.md
.specforge/wiki/
.specforge/core/standards/wiki.md
.specforge/core/standards/engineering.md
.specforge/core/standards/workflow.md
.specforge/core/standards/ai-toolkit.md
.specforge/core/standards/pc-ui-design-spec.md（本次确认或落地 PC 端业务系统 UI 规范时）
node .specforge/core/scripts/wiki-update-plan.mjs --json 输出

写入

06-close/wiki-sync.md
必要时更新 .specforge/wiki/01-project-overview.md
必要时更新 .specforge/wiki/02-product-rules.md
必要时更新 .specforge/wiki/03-architecture.md
必要时更新 .specforge/wiki/module-<name>.md
必要时更新 .specforge/wiki/api-<domain>.md
必要时更新 .specforge/wiki/external-interfaces.md
必要时更新 .specforge/wiki/integration-<system>.md
必要时更新 .specforge/wiki/config-env.md
必要时更新 .specforge/wiki/security-auth.md
必要时更新 .specforge/wiki/jobs-events.md
必要时更新 .specforge/wiki/design-system.md
必要时更新 .specforge/wiki/04-data-model.md
必要时更新 .specforge/wiki/05-operations.md
必要时更新 .specforge/wiki/06-decisions.md
必要时更新 .specforge/wiki/07-glossary.md
必要时更新 .specforge/wiki/08-risks.md
每次更新后同步 .specforge/wiki/00-index.md

判断维度

变化类型	目标文件
项目目标、用户、整体状态	`01-project-overview.md`
产品规则、角色、权限、审批、状态机	`02-product-rules.md`
架构、模块边界、技术栈、关键数据流	`03-architecture.md` 或 `module-<name>.md`
API、事件、Webhook、SDK 契约	`api-<domain>.md`
对外接口总览、第三方集成、CLI、文件导入导出、公开前端入口	`external-interfaces.md` / `integration-<system>.md`
核心实体、表、关系、状态、迁移注意事项	`04-data-model.md`
环境、配置、启动、任务、发布、回滚、观测	`05-operations.md`
环境变量、secret、feature flag、配置源	`config-env.md`
认证、授权、权限、敏感数据边界	`security-auth.md`
后台任务、队列、事件、定时任务、消息契约	`jobs-events.md`
稳定 UI 组件、token、设计系统、风格规则、PC 端业务系统规范落地规则	`design-system.md`
长期架构 / 产品 / 技术决策	`06-decisions.md`
术语、缩写、领域语言	`07-glossary.md`
已知风险、技术债、后续事项	`08-risks.md`

不进入 wiki 的内容：一次性调试记录、命令长日志、截图、未批准草稿、只对本 work item 有意义的实现备注。

回写流程

生成机器回写计划：运行 node .specforge/core/scripts/wiki-update-plan.mjs --json。
- 必须把 wiki_state、long_term_fact_candidates、required_targets、can_write_na、blocking_gaps 写入 06-close/wiki-sync.md。
- 若 can_write_na=false，不得写 N/A - 无长期事实。
- 若当前 work item verification 已批准且 wiki 仍为 missing / bootstrap，先运行 node .specforge/core/scripts/wiki-hydrate.mjs --mode close --write，再补充人工可确认事实。
生成 diff 级 Wiki 刷新计划：implementation / verification 后运行 node .specforge/core/scripts/wiki-refresh-plan.mjs --from-diff --json；若返回 wiki_update_needed=true，把 targets 写入 wiki-sync.md#2-必须更新的-wiki-目标。
收集候选事实：从 PRD / requirements / ui_design / technical_design / implementation report / verification report 提取长期有效事实。
- 从 technical-design.md#7.1 Architecture Contract、#Implementation Handoff、#12. Operability & Maintenance 提取 owner、boundary、interface、operability、extension point、deprecation path、wiki target、technical debt 和 revisit trigger。
判断复用价值：至少沉淀一个未来 work item 会复用的事实；只有 can_write_na=true 且 wiki refresh plan 没有必须更新目标时，才允许写 N/A - 无长期事实，不要把过程流水账塞进 wiki。
判定写入目标：使用“判断维度”表选择唯一目标文件；一个知识项只维护一个 current 文件。
对照现有 wiki：读取目标文件和 00-index.md，判断是更新当前事实、补充新章节，还是写 N/A。
检查最低完整度：按 .specforge/core/standards/wiki.md#最低完整度 检查目标文件。架构、API、数据、运维文件缺少关键事实时，先补扫相关代码 / 配置 / 测试；仍缺失时写 未确认，并同步到 08-risks.md 或本次 wiki-sync 的缺口表。
- SQL / DDL / dump 文件默认不是当前事实。只有被 migration/runtime/CI/tests 引用或用户确认时，才能写进“当前数据权威”或“当前实体 / 表”；否则写入 04-data-model.md#历史--未受信-sql-产物 或 08-risks.md。
处理冲突：如果 artifact 与现有 wiki 冲突，以已批准并验证的最新 work item 为准；同时在 06-decisions.md 或目标文件中保留必要决策理由。
刷新元数据：每个更新文件都刷新 frontmatter 的 last_updated、source_work 和 status: current。
同步索引：新增或重命名 wiki 文件后更新 00-index.md；不得产生重复 current 条目。
严格质量检查：运行 node .specforge/core/scripts/wiki-quality.mjs --mode close。FAIL 必须修复；WARN 必须写接受理由、影响和补证路径。

输出要求

明确“影响”或“不影响”。
写明 wiki-update-plan 的 can_write_na、required_targets 和 blocking_gaps。
列出更新文件。
每个更新的 wiki 文件必须保持 status: current，除非被明确替代。
同一知识项不得存在多个 current 文件；不得创建日期版、work item 版或 v2 版 wiki。
说明没有更新的理由。
写明契约变化、下游重新验证要求和来源证据。
写明 Architecture Contract、Implementation Handoff、Operability & Maintenance 中哪些事实已回写，哪些 N/A，以及对应 wiki target。
写明未确认缺口：缺失的 API、数据模型、架构链路、运行配置或证据不足项。
本次若确认或实现了 PC 端业务系统 UI 规范，写明是否更新 design-system.md；不更新时说明该规范是否只是一次性页面约束。
更新 .specforge/wiki/00-index.md 的当前知识项、摘要和最后同步时间。
写明 wiki-quality.mjs --mode close 的结果。

停止条件

verification 未批准。
无法判断长期影响。
需要更新 wiki 但缺少事实证据。
wiki-update-plan 输出 can_write_na=false 但未更新 required targets。
wiki-quality.mjs --mode close 仍有 FAIL。
发现 wiki 与代码 / 验证证据冲突，且无法判断哪个为准。
会产生重复 current wiki 文件，或无法把新事实合并到唯一目标文件。

完成标准

wiki-sync.md 存在。
wiki 更新与 work item 证据一致。
00-index.md 已列出所有 current 知识项和最后同步时间。
目标 wiki 文件达到最低完整度；未达到的部分已标注 未确认 并进入风险 / 缺口记录。
wiki-update-plan 与实际更新文件一致；wiki-quality.mjs --mode close 无 FAIL。
wiki_sync gate 可以被批准或有明确阻断原因。