claude-code-orchestra: Skill for Claude Code

Create Implementation Plan

Create an implementation plan for $ARGUMENTS.

A plan is a file, not a transcript. The plan produced here is written to a resolved path, validated against a document contract, reviewed by Codex, and approved by the user — in that order, and all four. A plan that lives only in the conversation cannot be handed to /team-execute, cannot survive a /checkpointing compaction, and cannot be re-read next session.

Planning Process

0. Resolve the Workspace (always first)

Resolve this plan's slug and output path once. The title becomes the file name, so give it a short English descriptor — not the user's raw wording, which the Language Protocol keeps out of paths:

python3 .claude/skills/_shared/workspace.py \
  --skill plan --title "<short English title>" --create

The JSON on stdout carries slug and paths.plan_doc (.claude/docs/plans/{slug}.md). Every {slug} and every output path below — and the /team-execute handoff in step 6 — MUST come from this JSON verbatim, never be re-derived by hand: two hand-derived slugs are exactly how a plan and its executor's work logs drift apart. Exit codes: 0 resolved (and created); 1 bad arguments.

If .claude/docs/plans/{slug}.md already exists, the plan is a revision of that document — read it first and say so, rather than silently overwriting it.

1. Requirements Analysis

First clarify with the user:

• Purpose: What to achieve
• Scope: What to include, what to exclude
• Constraints: Technical, time, dependencies

Ask, do not assume. Unresolved items belong in ### Open Questions, not in a guessed step.

2. Current State Investigation

Reading the codebase for a plan is broad-context work: delegate it rather than consuming orchestrator context.

Task tool:
  subagent_type: "general-purpose-opus"
  prompt: |
    Investigate this codebase for a planned change: {purpose from step 1}

    Report, with file:line evidence for every claim:
    1. Related existing code — which modules already do something similar
    2. Files that will need to change, and why each one
    3. Libraries and patterns the change should reuse (project conventions)
    4. Existing tests that cover the affected area, and gaps in that coverage
    5. Constraints or invariants the change must not break

    Use Glob, Grep, and Read. Do not implement anything.
    Return the findings; do not summarize away the file paths.