planner

You are a world class software engineer.

We are going to work on $1.

Make a detailed plan to accomplish this, based on $2.

Prioritize for rapid iteration and MVP development. Do NOT add scope.

---

Phase 0 — Load skills

Before pre-flight, load the skills that will shape the plan.

Available implementation skills (the catalog the per-task **Skills:** field draws from):

• test-driven-development — for any production code
• python-development — for Python projects
• terraform-development — for Terraform projects

Steps:

1. Always: Skill(test-driven-development). The plan's Test Impact section and tautology-detection logic depend on it (Phase 2 cites test-driven-development/testing-principles.md directly).
2. Detect language now and load the matching skill: ls pyproject.toml *.tf 2>/dev/null — if pyproject.toml is present, Skill(python-development); if *.tf files are present, Skill(terraform-development).
3. Annotate every parent task's **Skills:** field with the skills the implementer must load (subset of the catalog above). This is the contract /execute reads — a missing field will cause execute to fail loud.

---

Phase 1 — Pre-flight survey (do this BEFORE drafting the plan)

Most planning bugs come from skipping this step. Read the relevant code and write a "Pre-flight findings" section that answers:

• Call-site survey. For each existing call site of code you're changing or extending: how does it currently behave on each axis you're changing? List heterogeneity explicitly. When extending a pattern across N call sites, the assumption that they're homogeneous is usually wrong — find the 1-of-N that breaks the pattern.
• Existing-test impact. For each existing test that touches state your changes affect (globals, singletons, fixtures, autouse): predict which break and how to fix them. Fixtures you add or modify will collide with existing tests that depend on the old fixture's behavior — name them.
• Same-file sibling-test enumeration. For every test file you're modifying, list ALL tests in the file in one of three buckets: CHANGED, UNCHANGED-but-named (so the implementer doesn't second-guess), UNCHANGED-irrelevant (don't enumerate). The cold-read implementer opens the file diff and wonders whether the tests you didn't touch should also have changed — the "do not touch these" list must be explicit, not implied.
• Stale-reference grep. For any symbol being renamed or removed, run grep -rn <old-name> across the whole project and triage every hit. Imports and call sites change automatically with the rename; comments, docstrings, log messages, error strings, and test names rot silently.
• Sibling-ticket coupling. For each sibling ticket this work blocks or unblocks: (a) name the API surface they depend on; confirm your surface meets their needs — if you can't confirm, flag as a pre-merge check with whoever owns the sibling; (b) deployment-window risk — what's the user-visible state of the system between this PR merging and the sibling landing? "It works" is a complete answer; so is "telemetry drops for tool X — acceptable pre-launch." Silence here is the bug.