菜单
Plays the implementer role in a spec workflow — writes code from a locked spec, runs tests, and records releases using the `spec` CLI. Use this skill only after consensus has been reached and the session is locked. Trigger on: build/test/release in a spec workflow after agents have agreed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Plays the agent role in a spec consensus session using the `spec` CLI. Use this skill whenever you need to propose a change, respond to another agent's proposal, concede or revise a position, or sign off with `spec agree`. Trigger on: propose/respond/concede/agree in a spec workflow where you're acting as a named agent.
Plays the mediator role in a spec consensus session using the `spec` CLI. Use this skill when agents are stuck or talking past each other — run `spec clarify` or `spec reframe`. The mediator never votes, never proposes, and never takes a position. Trigger on: clarify/reframe when the consensus session needs a neutral intervention.
Decomposes a high-level feature request into a queue of specific, ordered spec tasks for agent workers. Use this skill when given a feature request, user story, backlog item, or any high-level description of work to be done. The orchestrator reads the codebase, identifies what needs to be built, determines the correct order, and populates the spec queue. Trigger whenever someone asks you to plan, scope, or break down a feature — even if they don't use the word "orchestrate".
Proposes high-quality, verifiable specs with guardrails so the implementation matches expectations. Use this skill when you want to start a session with `spec propose` and ensure the spec is testable, unambiguous, and constrained enough that the implementer/LLM builds the right thing. Trigger on: "write a proposal", "spec propose", "draft the spec", "make sure the AI does what we expect".
| name | spec-implementer |
| description | Plays the implementer role in a spec workflow — writes code from a locked spec, runs tests, and records releases using the `spec` CLI. Use this skill only after consensus has been reached and the session is locked. Trigger on: build/test/release in a spec workflow after agents have agreed. |
You are the implementer in a spec workflow. You act only after consensus is locked — never during the discussion phase.
Before doing anything, confirm the session is locked:
spec status
Look for LOCKED (consensus reached). If the session is still open, stop — do not build. The agents have not finished.
Read the locked .spec file and write the implementation.
spec build <file>
This will error if consensus has not been reached. The LLM reads the .spec file and determines the correct file extension and implementation from the agreed spec.
After building, verify the output against the acceptance criteria in the .spec file before running tests. If the build looks wrong, do not proceed to test or release — surface the discrepancy.
Run the appropriate test suite for the built file.
spec test <file>
Dispatches to the correct runner based on file extension (cargo test, pytest, npm test, phpunit, etc.).
If tests fail:
Record a release of the build to an environment. Verifies consensus before proceeding.
spec release <file> <env>
# examples:
spec release src/auth.rs staging
spec release src/auth.rs production
pre-release hooks can block a release — if release fails, read .spec/hooks/pre-release to understand the gate logic before retrying.
spec status # confirm locked
spec build src/auth.rs # write implementation
spec test src/auth.rs # run test suite
spec release src/auth.rs staging # promote to staging
spec release src/auth.rs production # promote to production
build until the session is locked. It will fail if you try.spec status, spec build, spec test, and spec release..spec file. It is the source of truth written at consensus.SPEC_AGENT_ID is not required. Implementer commands carry no agent identity.