القائمة
SpecForge 内部实现技能。用于 spec_review 已批准后，根据 tasks 的边界、依赖、验证方式和批准设计执行实现，并记录 implementation plan、report 与 changed files。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | implementation |
| description | SpecForge 内部实现技能。用于 spec_review 已批准后，根据 tasks 的边界、依赖、验证方式和批准设计执行实现，并记录 implementation plan、report 与 changed files。 |
本技能在 spec review 批准后执行实现。实现必须服从已批准 tasks 和写入边界，不借机做无关重构。实现阶段的核心产出不是“代码改完”，而是“代码、任务状态、验证证据、真实 diff 四者一致”。
spec_review gate 为 APPROVED。01-spec/tasks.md 存在且任务边界明确。node .specforge/core/scripts/instructions.mjs -- apply 显示 apply ready。work.yaml01-spec/requirements.md（存在时）01-spec/gap-report.md（bugfix / issue）01-spec/ui-design.md（存在时）01-spec/technical-design.md（存在时）01-spec/tasks.md02-spec-review/spec-review-v1.md.specforge/wiki/00-index.md 和 tasks / technical design 引用的相关 wikicore/profiles/README.md 以及 technical-design.md 选中的技术选择卡.specforge/core/standards/engineering.md.specforge/core/standards/workflow.md.specforge/core/standards/ai-toolkit.md.specforge/core/skills/README.md（存在浏览器实现或验证辅助时）.specforge/core/skills/code-intelligence/SKILL.md（tasks / technical design 包含 Graph Facts、关键符号、调用关系或受影响测试时）03-implementation/plan.md03-implementation/report.md03-implementation/changed-files.md01-spec/tasks.md 中完成的任务。行为变更默认先写或定位一个会失败的单元 / 集成 / 契约 / Playwright 用例，再写生产代码使其通过。确实无法失败优先时，必须在 03-implementation/report.md 写明原因、风险和替代证据。
允许先做结构性准备的场景包括：官方脚手架 / 模板初始化、依赖安装、测试框架配置、纯文档、纯配置登记、删除无引用死文件、为测试可运行而做的最小 harness。这些场景仍要记录安装、构建、启动、diff 对账或人工检查证据。
DONE，但验证命令、证据或可信 N/A 缺失。_Boundary:_ 之外的文件，且没有 approved spec 依据。[NEEDS TECH DECISION]、[NEEDS DEPENDENCY DECISION] 或关键 unknown 还在继续实现。no 的影响面。spec_review gate 必须为 APPROVED。node .specforge/core/scripts/instructions.mjs apply 必须显示 ready。git status --short --untracked-files=all，识别本次工作前已有改动；不要覆盖或回滚无关改动。_Impact:_、_Files:_、_Boundary:_、_Verification:_、_Rollback:_、风险和预计变更文件。任务图与执行策略，必须按其中依赖、可并行边界、主要写入边界和交接证据执行。sf-tasking。technical-design.md#0. 影响面与读取计划、#7.1 Architecture Contract、#Implementation Handoff、#12. Operability & Maintenance 以及相关 wiki 提取 yes / no / unknown、入口路径、关键符号 / 路由、上游 / 下游、测试位置、运行命令、change slices、files/modules、test seams、rollout、rollback、owner 和 revisit trigger，形成实现影响面对账计划。GF-*、Graph Facts、关键符号或受影响测试，先运行 node .specforge/core/scripts/graph-freshness.mjs --json；fresh / ready 时按图事实定位，stale / unavailable 时只作为低置信线索并回到 wiki / tasks / technical design 的明确边界。sf-tasking 或 sf-spec-review。technical-design.md 仍有 [NEEDS TECH DECISION] 或 [NEEDS DEPENDENCY DECISION]，停止回到 sf-tech-design 确认技术选型或新增依赖。unknown，停止回到 sf-tech-design 或 sf-spec-review。technical-design.md 的 Tech Profile Selection 和项目 wiki 选择脚手架命令。ui-design.md 中批准的 UI 产物：
ui-design.md 声明采用 PC 端业务系统规范，必须同时读取 .specforge/core/standards/pc-ui-design-spec.md；生成 HTML/CSS 或组件样式时严格使用该规范 token，不得使用 UI 库默认主题或临时改值。ui-design.md 中的页面/状态矩阵，以原型为布局和交互参照实现。data-testid。不能为了测试绕过真实用户路径。technical-design.md，按其中的前后端边界、API、数据、权限、配置、NFR、Architecture Contract、Implementation Handoff、Operability & Maintenance 和验证策略执行。
yes 影响面：必须落到代码 / 配置 / 文档变更、关联任务和快速验证。no 影响面：不得出现未经批准的真实 diff；发现必须修改时停止退回 spec。unknown 影响面：不得以实现代替澄清。[NEEDS TECH DECISION] / [NEEDS DEPENDENCY DECISION]：不得以实现代替用户确认。Implementation Handoff：必须承接 change slices、files/modules、sequence、test seams、rollout、rollback seam、do-not-touch 和 open assumptions。Operability & Maintenance：必须承接 owner、extension point、deprecation path、wiki target、technical debt 和 revisit trigger。_Boundary:_ 允许的文件；确需越界时停止并回到 spec。DONE、DONE_WITH_CONCERNS、BLOCKED、NEEDS_SPEC。03-implementation/report.md 记录 task 状态、验证、偏离、风险和 code review 提示。03-implementation/report.md 必须记录 technical_design 影响面实现对账：yes 的落地与验证、no 的未越界确认、unknown 的退回处理。03-implementation/changed-files.md 记录每个真实变更文件、任务、批准边界来源、风险和验证。git status --short --untracked-files=all、git diff --name-only、git diff --stat 反查，发现未登记变更、未追踪文件或登记但无 diff 的项必须补齐或说明。sf-verify。_Files:_、_Boundary:_、_Verification:_ 或 _Rollback:_ 不足以指导实现。unknown，或实现需要修改被批准为 no 的影响面。[NEEDS TECH DECISION] 或 [NEEDS DEPENDENCY DECISION]。ui-design.md 或 technical-design.md 的范围。SpecForge requirements 主能力包。用于把 brief、brainstorm、PRD、research、gap report、wiki 当前事实和用户确认转成可测试、可追踪、可交给 UI / technical design / tasking / verification 的 REQ / AC / NFR / 边界 / handoff 行为契约。
生成或更新 SpecForge 工作项的需求规格；用于活跃工作项的 ready artifact 为 requirements，或需要把产品需求文档 / 简报转成可测试行为、边界、用户故事、验收标准和影响面标记时。
SpecForge 内部需求技能。用于为 work item 生成清晰、可测试的功能需求、非功能需求、范围边界、不在范围内和验收标准。
SpecForge 跨阶段代码智能能力包。用于任何阶段需要 Wiki-first 定位现有代码范围、选择 CodeGraph / MCP / SCIP / Repomix / rg、检查 provider freshness、归一 graph_facts、分析影响面 / affected tests 或生成 Wiki 回写候选时必读；不要只在 sf-steering 中使用。
为存量项目或大型代码库建立 SpecForge 项目画像；用于新需求或 bugfix 前理解现有架构、刷新 wiki、生成后续 work item 的上下文基线。
SpecForge 测试工程主能力包。用于 sf-verify 在验证前把 requirements、tasks、UI、technical design 和 code review 风险转成可解析 TC/PW 用例、runtime runbook、auth strategy、自动化计划和可归档 evidence。