Menu
Turn a design spec into an explicit tx task graph with `tx decompose`, then refine the graph using normal tx task and dependency primitives.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Generate a detailed design document via `tx doc add design`. Covers architecture, interfaces, data model, invariants, failure modes, verification, and testing strategy. References plan via file path instead of embedding. Plan lives in ~/.claude/plans/<name>.md. Reads companion PRD automatically to map EARS requirements to invariants. Output lands in specs/design/<name>.md.
Generate a system overview spec via `tx doc add overview`. Produces an architectural overview covering problem, scope, components, data flows, and non-goals. References plan via file path instead of embedding. Plan lives in ~/.claude/plans/<name>.md. Output lands in specs/<name>.md with tx-managed frontmatter.
Generate a detailed Product Requirements Document via `tx doc add prd`. Uses EARS requirement syntax with traceable IDs, acceptance criteria, and non-functional requirements. References plan via file path instead of embedding. Plan lives in ~/.claude/plans/<name>.md. Designed to be created alongside a companion `/design-doc`. Output lands in specs/prd/<name>.md.
Internal closed-loop skill: drive CLI/API/MCP to 100% shape parity (same service methods) AND behaviour parity (same response shapes). Uses ESLint rules tx/require-surface-parity + tx/interface-parity. NOT shipped to tx users.
Generate a system-level design document via `tx doc add design`. Covers cross-cutting architecture, service boundaries, data flows, scalability, and deployment topology. References plan via file path instead of embedding. Plan lives in ~/.claude/plans/<name>.md. Use for system-wide or multi-domain designs rather than feature-scoped subsystem docs.
Create, patch, lint, discover, trace, and complete docs-first specs. Use when working in Claude Code and the user needs tx commands from this area.
| name | decompose-spec |
| description | Turn a design spec into an explicit tx task graph with `tx decompose`, then refine the graph using normal tx task and dependency primitives. |
| argument-hint | <design-doc-ref> [--parent <task-id>] [--runtime <auto|claude|codex>] [--dry-run] |
Use this skill when the user already has a design spec and wants an explicit tx task graph created from that spec.
tx doc show <design-doc-ref>
tx decompose <design-doc-ref> --dry-run --json
tx decompose <design-doc-ref>
tx decompose <design-doc-ref> --runtime claude
tx decompose <design-doc-ref> --runtime codex
tx decompose <design-doc-ref> --parent <task-id>
tx decompose over manually creating a large first-pass task graph.--parent <task-id> when the spec should decompose under an existing task.--dry-run when you need to inspect or compare graph options before writes.--max-tasks unless the user explicitly requests a cap. Artificial
limits produce weak decompositions that miss important slices. Let the LLM
produce as many tasks as the design doc warrants.tx decompose makes LLM calls and can take 60–120 seconds.
If you launched it, wait for it to finish. Never re-run it because output
appears empty — that wastes API credits and risks duplicate subtasks. If it
was launched in the background, poll the output file at long intervals (30s+).tx add "Follow-up task"
tx add "Nested subtask" --parent <task-id>
tx dep block <task-id> <blocker-id>
tx dep unblock <task-id> <blocker-id>
tx doc attach <task-id> <doc-name>
tx update <task-id> --status blocked
tx decompose --dry-run first
and repair the existing graph explicitly instead of creating duplicate work.tx show <task-id> on the generated root task to inspect linked-doc and
blocker state after decomposition.--max-tasks.POST /api/decomposetx_decomposeawait tx.decompose.run({
docRef: "<design-doc-ref>",
runtime: "auto",
dryRun: true,
})