| name | execute |
| description | Use when running a spec's execution tail — presents the 执行方式 selector, dispatches the chosen engine (task-swarm / superpowers / specode-native TDD), then runs acceptance and the distill prompt. Trigger /specode:execute <slug> manually at any time once tasks.md exists, or invoked by name (specode:execute) via the Skill tool by the spec / continue skills. |
/specode:execute — run a spec's execution tail (selector → execution → acceptance)
This skill owns everything from "tasks.md is ready" to "acceptance written": the 「执行方式」 selector, engine dispatch (including the task-swarm handoff), implementation-log.md appending, acceptance, and the distill prompt. It never generates requirements / design / tasks — earlier phases belong to the sibling spec / intake skills. Extracted from ../spec/SKILL.md as a pure relocation: the semantics below are unchanged from the pre-6.3.0 inline pipeline.
Entry contract (three callers, one behavior)
- Pipeline entry: the spec orchestration shell (
../spec/SKILL.md Flow step 5) invokes this skill by name (specode:execute) via the Skill tool right after tasks.md is confirmed — slug and specsRoot are already in the conversation context; don't re-ask, but still run §Preflight to ground on on-disk state.
- Manual entry: the user types
/specode:execute <slug> at any time (typically after a session break, or after /specode:continue <slug> reported an executing/complete phase). slug is required — missing → report an error and suggest /specode:list.
- continue handoff: when
/specode:continue <slug> infers phase ∈ {executing, complete, legacy 5.x} and the user gives the go-ahead, the continue skill invokes this skill via the Skill tool instead of re-deriving execution rules from prose.
All three entries converge on the same flow: §Preflight → §执行方式 selector → §Execution dispatch → §Acceptance.
Shared rules (inherited, cross-referenced — do not re-derive)
-
CLI resolver: every specode CLI goes through the run.sh wrapper — relative to this skill that is ../../scripts/; use this skill's base directory to make it absolute (no env-var resolution, no cache find, never bare python3):
sh ../../scripts/run.sh ../../scripts/resolve_root.py <verb> <args...>
-
Core invariant (4 fixed docs): unchanged — see ../spec/SKILL.md §Core invariant. This skill only appends to implementation-log.md and checks off tasks.md checkboxes; it never creates or renames artifacts.
-
Output language: user-facing output (selector, progress, acceptance summary, errors) in Chinese (中文); technical names / paths / code identifiers verbatim. Document output brevity: never reprint document bodies in chat (path + a few bullets only).
Preflight (always run, all entries)
resolve_root.py get-root (exit 3 → first-time setup; exit 4 → specsRoot configured but unreachable — external drive not mounted / path gone → surface the cause and re-prompt the user for a path, do not treat it as "slug not found"; both per ../spec/SKILL.md §specsRoot resolution) → on exit 0, locate <specsRoot>/<slug>/; directory missing → report an error and suggest /specode:list.
- Read the fixed docs present and branch on plan state:
| On-disk state | Action |
|---|
tasks.md has unchecked - [ ] | Normal path: §执行方式 selector → §Execution dispatch → §Acceptance. |
no tasks.md, but design.md contains ## Task + - [ ] | Legacy 5.x spec: treat design.md as the plan (pre-6.0.0 semantics) and proceed on the normal path. |
no tasks.md (and not legacy) | Stop: report the spec hasn't reached the execution phase yet; suggest /specode:continue <slug> to finish requirements / design / tasks first. Never generate tasks.md here. |
all tasks.md checkboxes checked | Skip selector + execution; go straight to §Acceptance (if implementation-log.md already carries an acceptance summary, report already complete instead). |
执行方式 selector (the single fixed per-spec selector)
Call AskUserQuestion to present adaptive 4 options — show an option only if its engine is installed. Pass the option label/description text below verbatim (they are user-facing selections and stay in Chinese):
- 委托 task-swarm(多 agent 并发) — requires task-swarm.
- superpowers subagent-driven(每 Task 派全新 subagent + 两阶段评审,推荐) — requires superpowers.
- superpowers executing-plans(当前会话顺序批量 + checkpoint) — requires superpowers.
- specode 自执行(顺序单 agent) — native fallback, the only option when nothing is installed.
Options 2/3 are both superpowers skills (built on Claude Code's native Agent/subagent capabilities), not Claude built-in workflows; their ergonomics differ (the former: clean context + per-Task review; the latter: single-session continuous batch).
When presenting, pass question / header / options verbatim per the references/selectors.md example — do not invent and do not collapse into a shorter option set. This is a single-user scenario with the PreToolUse hard-check removed, so "verbatim per the example" is enforced by this rule alone.
Execution dispatch (branches by selector choice, all TDD)
- Delegate to task-swarm (installed) → see §task-swarm handoff below.
- superpowers subagent-driven (installed) → call
superpowers:subagent-driven-development.
- superpowers executing-plans (installed) → call
superpowers:executing-plans.
- specode self-execute (fallback) → the host agent runs TDD in
tasks.md Task order (write failing test → run red → implement → run green), checking off each - [ ].
- Append to
implementation-log.md during execution.
Availability check: attempt to invoke the superpowers skill via the Skill tool first; if unavailable, take the native branch — same logic for task-swarm (/task-swarm:swarm invocation fails → fall back). Do not stall or tell the user to install something; pick up natively right away. Per-phase mapping details: ../spec/references/superpowers-wiring.md.
task-swarm handoff (zero hard dependency)
task-swarm is a standalone plugin; specode has zero imports of it and does not know its install path — all calls go through task-swarm's own /task-swarm:swarm skill (which self-locates its scripts via its own base directory). After the user picks "delegate":
- Read this spec's
tasks.md Task list + each Task's **Files:** + (needs:) → mechanically derive <specsRoot>/<slug>/pipeline.yml (merge Tasks into task groups by writes-conflict + needs topology / @writes files / needs topology).
- Show the yml summary to the user (number of task groups / same-file conflicts / topology); init only after the user confirms.
- Invoke task-swarm's own
/task-swarm:swarm command to drive its plan → fork → advance → writeback → resolve orchestration until done.
- Append to
implementation-log.md throughout; run acceptance after done.
task-swarm not installed (/task-swarm:swarm unavailable) → fall back on the spot to "specode self-execute" or the superpowers execution path, so the user is never stuck. pipeline.yml is a transient artifact only — not one of the 4 fixed products.
Acceptance (coding complete)
- superpowers installed → call
superpowers:verification-before-completion (optionally also superpowers:requesting-code-review).
- not installed → specode-native: the host agent verifies item by item against the
AC-N in requirements.md / design.md's test strategy (测试策略) / all tasks.md checkboxes checked.
- Say "请验收" in prose and write an acceptance summary in
implementation-log.md. There is no formal acceptance-gate selector.
- distill is manual — leave a one-line reminder, do not prompt: after acceptance is written, add a single passive line to the report, e.g.「如需把本次定位经验沉淀进项目 knowledge-base,可手动运行
/specode:distill <slug>」. Do not AskUserQuestion and do not auto-run distill — it stays a fully separate user-triggered command (../distill/SKILL.md). This keeps execute and distill decoupled (no gate, no config).
References
references/selectors.md — verbatim AskUserQuestion example for the 「执行方式」 selector (moved here from the spec skill in 6.3.0).
../spec/SKILL.md — the pipeline that hands off to this skill (Core invariant, specsRoot resolution, Iron rules).
../spec/references/superpowers-wiring.md — phase ↔ superpowers skill mapping and availability checks.
../spec/references/obsidian.md — the full resolve_root.py verb table.