Claude Skills by hectorcanaimero

Use when an accepted PRD under docs/prd/ needs a technical architecture before specs are written (step 2 of orch-plan). Reads the code and the PRD, writes docs/arch/NNN-<slug>.md with components, contracts, decisions and the phase/package split orch-spec turns into tasks. Never writes code, specs or tasks.json.

Use when the user describes a feature or product idea and wants it planned end to end for orch ("plan this", "/orch-plan <idea>"). Drives the pipeline PRD → ARCH → SPEC → TASKS through orch-prd, orch-arch, orch-spec and orch-tasks, stopping for the user at each gate and resuming from whatever artifact already exists.

Use when the user wants to turn a product or feature idea into a PRD for an orch-managed project (step 1 of orch-plan). Interviews for the missing facts, then writes docs/prd/NNN-<slug>.md with numbered, testable requirements that orch-arch and orch-spec can trace. Never writes code, specs or tasks.json.

Use when an architecture under docs/arch/ needs to become dispatchable work for orch (step 3 of orch-plan). Writes specs/fN-<slug>.md in the exact markdown format orch atomize parses — phase, package and task headers with Model, Estimate, Reason, Dependencies and Files — one agent-sized task per header. Never edits tasks.json.

Use when specs under specs/ are ready to become tasks in an orch project (step 4 of orch-plan, or on its own after editing a spec). Runs orch atomize as a dry-run, shows the diff, applies it only after the user confirms, then makes the DAG valid with orch router and orch validate and explains how to promote tasks out of backlog.

Use when the user's cwd contains .orchestrator/ or tasks.json (a project managed by the orch CLI). Explains the task DAG model, where runtime state lives (SQLite), how to inspect it without editing tasks.json, how to legally move a task between states, and which commands are safe from an agent session. Load on demand — no need to keep in system prompt.