菜单
Use when raw intent must be turned into a reviewed spec before implementation, including OpenSpec adapter, pack-backed spec generation, lightweight spec generation, acceptance criteria, non-goals, and evidence plan. 当用户要求先写 spec、意图还没变成目标/边界/验收/测试，或 adaptive-dev-workflow 路由到 SpecFlow 时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Classify a new or materially changed software-development goal and submit its route decision to workflow-control-plane. Use at task intake when risk, strategy, SpecFlow/OpenSpec, context grounding, handoff, harness, or downstream skill selection must be decided; do not use for ordinary continuation when an active workflow manifest already selects the current stage skill. 当新开发目标进入、范围或风险实质变化、需要选择开发策略/Spec/上下文/交付流程时使用；已有 active workflow 的普通续作直接恢复当前 stage，不重复触发本 skill。
Coordinate role-based AI agents through agent rosters, work orders, context packets, artifact refs, and structured result contracts. Use when a software workflow needs multiple roles such as context researcher, spec writer, spec reviewer, technical designer, implementer, code reviewer, tester, verifier, or when the user wants an orchestrator to manage progress without manually copying context between sessions. 当需要多 Agent 协作、角色隔离、上下文投影、work order、artifact 驱动交接、进度监管或避免人工搬运上下文时使用。
Select and run changed-file-aware tests for software development loops, checkpoints, and completion gates. Use when a task should avoid repeatedly running the full unit suite, needs diff-based test impact selection, test cadence decisions, or must escalate from focused tests to broader verification. 当开发任务需要按 diff 跑增量测试、选择受影响单测、控制测试频率、避免每个 task 全量测试或判断何时升级为模块/全量验证时使用。
Owns workflow runtime state for adaptive AI coding tasks. Use when resolving route decisions, selecting versioned strategies, creating/updating workflow_manifest.json, validating artifact graphs, resuming interrupted workflows, applying specialist skill transition results, or enforcing strategy/stage/claim/state contracts. 当需要策略解析、workflow_manifest 单点写入、状态迁移、resume、artifact graph、stale 传播、claim ceiling 或工作流状态检查时使用。
Use when validating evidence manifests, deciding dev_done/integration_done/handoff_done claims, issuing verifier attestations, preventing completion overclaim, or requiring fresh consumer / real external verification. 当任务需要证据矩阵、交付验收、claim attestation、fresh consumer、real external、E2E/integration/system 证据或防止假完成时使用。
Initialize or repair a project AI coding harness: AGENTS.md, OpenSpec-first or Superpowers-fallback spec/design/plan routing, docs/evidence, Goal Loop Mode prompt, agent team roles, project-local skill, learning candidates, and delivery verification templates. Use when starting a new repo/product area, first MVP vertical slice, Large feature lacking current-truth docs, repeated user explanations, weak project agents, missing spec/technical-design/plan/evidence contracts, or when adaptive-dev-workflow routes to project harness initialization. 当需要项目初始化、目标模式、OpenSpec 优先或 Superpowers fallback 的 spec/technical design/plan/evidence、项目 agent 团队、项目 skill、AGENTS.md、交付验证或 Loop Engineering 基座时使用。
| name | specflow |
| description | Use when raw intent must be turned into a reviewed spec before implementation, including OpenSpec adapter, pack-backed spec generation, lightweight spec generation, acceptance criteria, non-goals, and evidence plan. 当用户要求先写 spec、意图还没变成目标/边界/验收/测试，或 adaptive-dev-workflow 路由到 SpecFlow 时使用。 |
SpecFlow 是 spec 生成过程，不是整个项目执行过程。它把 intent 或 Analysis Pack 转换成可审阅的 spec artifact。
pack-backed-specflow: L2/L3 或 current truth 不清；输入为 approved Analysis Pack + Context Manifest。lightweight-specflow: L1/L2 且上下文清楚；允许直接从 intent 写轻量 spec。openspec-adapter: repo 使用 OpenSpec 时，输出到 OpenSpec proposal/spec/tasks，不生成第二套 product spec。产出一个 spec artifact，通常包含：
L2/L3 SpecFlow 不允许主 agent 自写自批。当 spec 会改变 runtime architecture、delivery contract、public API、data/auth/security model、project priority、implementation engine，或会成为后续 plan/implementation 的主依据时，使用 maker/checker：
spec-writer pass：把 intent / Analysis Pack 转成 draft spec。spec-reviewer pass：独立检查目标、非目标、边界、兼容性、验收标准、Evidence Plan、Stop/Continue 条件和实现可执行性。如果没有启动 isolated spec-writer / spec-reviewer，只能把 spec 标记为 draft 或 ready_for_user_review。只有用户确认或 isolated reviewer 通过后，才能标记为 ready；approved 必须来自用户或项目既有 spec approval 流程。
SpecFlow 不写生产代码，不请求 dev_done。它只能把 spec 标记为 draft/ready/approved，然后回到 adaptive strategy 的 plan 或 implementation stage。