메뉴
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.