メニュー
Turn a development goal into a dense sddx spec — binary success criteria, a mandatory oracle, stop rules — and register it as a task. Use when the user wants to plan or spec out a task before executing it.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Flagship sddx flow — decompose a goal into oracle-backed task specs and run them through TDD loops in parallel git worktrees, each ending in a verified, hash-chained receipt. Use for multi-task goals or any task that should run isolated from the current checkout.
Run a single sddx task through the PLAN → RED → GREEN → REFACTOR → VERIFY loop. Use when the user asks to execute one small, well-scoped task with spec-driven TDD.
Execute a task's oracle and, on pass, produce the hash-chained receipt and atomic commit. Use when an sddx task reaches VERIFY or the user asks to verify a task.
Ship a done goal as one PR of cherry-picked commits. Use when asked to open a PR for /sddx:run goals.
Verify the receipt hash chain, commit bindings, and (optionally) commit signatures. Use when the user asks to audit sddx receipts or check the integrity of completed work.
Regenerate .sddx/BOARD.md and show task status across the repo and its worktrees. Use when the user asks for sddx status, the board, or task progress.
| name | plan |
| description | Turn a development goal into a dense sddx spec — binary success criteria, a mandatory oracle, stop rules — and register it as a task. Use when the user wants to plan or spec out a task before executing it. |
CLI: "${CLAUDE_PLUGIN_ROOT}/bin/sddx-run" "${CLAUDE_PLUGIN_ROOT}/dist/cli.mjs" (run from the repo root).
Hunt the gaps. Interrogate the goal until nothing is vague: exact inputs and outputs, edge cases, what is explicitly out of scope, and — above all — the observable signal that proves success. Ask the user; do not guess.
Every criterion binary. Rewrite each success criterion until it is pass/fail with no judgment call. "Fast" is not a criterion; "p95 < 100ms in bench output" is.
Draft the spec (YAML, this shape):
task: <one sentence>
context: <links/paths, not prose>
success_criteria:
- "<binary check>"
scope: # optional — write globs this task's lane covers
- "<glob>"
oracle: # mandatory — no oracle, no goal
type: command # command | test-suite | browser | manual
run: "<command that proves success>"
expect: exit 0
stop_rules:
- max_iterations: 5
out_of_scope:
- "<explicitly not doing>"
on_dependency_failure: skip # optional — skip (default) | block
retry: # optional — bounded automatic retry before ABANDONED
max_attempts: 1 # default 1 = no automatic retry, today's behavior
workspace: fresh # fresh (default) | reuse
Declare scope when the task will run alongside others: it's the write-lane
the graph gate checks for conflicts and the gate enforces at run time. A
dependent task (one that needs another's committed result — possibly
several, for a fan-in task) is expressed in the graph with depends_on,
not in this spec — see /sddx:run. Leave on_dependency_failure/retry
unset unless this task specifically needs to block on (rather than skip
past) a failed ancestor, or needs more than one automatic attempt.
Register it. Save the YAML to .sddx/drafts/<date>-<slug>.yaml (dated
so same-wording plans on different days never collide) and run:
... task create --spec .sddx/drafts/<date>-<slug>.yaml --workspace branch
(in-session flow; /sddx:run uses --workspace auto for worktrees instead).
The CLI rejects any spec without a valid oracle — fix the spec, never work
around the rejection. On success it prints the task id and switches to the
sddx/<id> branch.
Hand off to /sddx:quick to execute.