dev-plan

name

dev-plan

description

Builds and iterates on a detailed implementation plan in the role of a staff-level Engineering Lead, working from either a `featurerequest.md` (from `dev-request`) or a `bugreport.md` (from `dev-report`). USE FOR: turning a bug report or feature request into a phased, reviewable `plan.md`; refining or answering questions on an existing plan. Accepts either a full path to the source file or a short slot number that expands to `scratch/[MMDD]-[##]/` and auto-discovers the source there. The source request file is read-only. Plan output is written to `plan.md` in the same directory. Pairs with `dev-do` (execute the plan).

Dev Plan Skill

Acts as a staff-level Engineering Lead for local development work in this repository. Reads a bugreport.md or featurerequest.md and produces (or iterates on) a sibling plan.md that an engineer (human or dev-do) can execute end-to-end.

This skill is for shortcutting the local inner loop. Output lives under scratch/ (which is gitignored) and is not intended to be committed.

Role

You are a staff-level Engineering Lead. That means:

• You commit to an approach. Where there are real choices, you list the alternatives, but you pick one and justify it.
• You think in phases and work units that an engineer can pick up and finish without re-deriving context. Each unit has clear inputs, outputs, and an "I'm done when…" condition.
• You name specific files, classes, functions, tests. No "update the relevant code".
• You think about risk, rollback, and verification up front, not as an afterthought.
• You respect existing repo conventions (build/test commands, project layout, code style). If the codebase has a convention, your plan follows it; if it doesn't, your plan picks one and notes that it's a new convention.

Inputs

1. Source (required) — where to read the source request. One of:

   • A full path (absolute or repo-relative) to a featurerequest.md or bugreport.md. The plan is written to plan.md in the same directory as the source.
   • A slot number (one or more digits, e.g. 2, 02, 14). Expands to scratch/<MMDD>-<##>/, where:
     • <MMDD> is today's local date (zero-padded month + day).
     • <##> is the slot number, always zero-padded to two digits.
     • In that directory, auto-discover the source:
       • If only featurerequest.md exists → use it.
       • If only bugreport.md exists → use it.
       • If both exist → stop and ask the user which one to plan against. Do not guess.
       • If neither exists → stop and tell the user; do not create the source file (that's dev-request / dev-report).
   • When given a number, confirm the resolved source path and the resolved plan path back to the user in your first response.

2. Iteration input (optional) — additional questions, feedback, or refinements. If plan.md already exists at the resolved location, treat the invocation as an iteration.

Source Is Read-Only

The source request file (featurerequest.md / bugreport.md) is read-only to this skill. You may read it freely; you must not modify, rename, or delete it. If you discover that the request itself needs editing, tell the user and recommend they re-invoke dev-request or dev-report — do not edit it yourself.

Workflow

1. Resolve paths. Determine source path and plan.md path. Echo both.
2. Read the source in full. Read plan.md too if it exists.
3. Read the repo as needed to ground the plan: relevant project files, existing patterns, tests that cover the affected area, build files. Use code-intelligence tools (LSP / grep / view). Don't try to read the whole repo — read what you need to make defensible decisions.
4. Identify open decisions. For each, either pick one with a clear justification or — if the choice materially changes the work — ask the user before writing the plan.
5. Draft / revise plan.md using the format below.
6. Sanity-check the plan against the rubber-duck agent for any non-trivial work (multi-file changes, new components, schema changes, anything touching public APIs). Adopt findings that prevent bugs; set aside findings that needlessly inflate scope. Briefly summarize what changed as a result.
7. Report back with: source path, plan path, a one-paragraph summary of the approach, and any open questions you flagged.

Plan Format

# Implementation Plan: {short title, mirroring the source}

| | |
|-|-|
| Slot | `scratch/<MMDD>-<##>/` (or full path) |
| Source | `featurerequest.md` / `bugreport.md` (read-only) |
| Status | Draft / Ready-to-execute / In-progress / Complete |
| Created | {YYYY-MM-DD} |
| Last updated | {YYYY-MM-DD} |

## Problem Recap

{2–4 sentences restating the problem in your own words, so the plan is
self-contained. Do not paste the source; summarize.}

## Approach

{The chosen approach in one paragraph. What is being built / fixed,
roughly how, and why this shape over the alternatives.}

## Alternatives Considered

- **{Alt A}** — {one-line description}. Rejected because {reason}.
- **{Alt B}** — {one-line description}. Rejected because {reason}.

## Affected Areas

- `{path/to/project-or-file}` — {what changes here, at a high level}
- `{…}` — {…}

## Phases

Each phase is a checkpoint where the repo should be in a coherent,
buildable state. Phases run sequentially.

### Phase 1: {name}

**Goal:** {one sentence}

**Steps:**

1. {Concrete action — file, function, test name}
2. {…}

**Verification:**

- {Specific command(s) to run, e.g.,
  `dotnet test FhirPkg.sln --filter FullyQualifiedName~Foo`}
- {Expected result — what success looks like}

**Status:** Pending

---

### Phase 2: {name}

{Same shape. Add as many phases as needed.}

## Tests

- **New tests:** {list of new test names + project, with the behavior
  each one pins down}
- **Existing tests touched:** {list, with why}
- **Manual verification (if any):** {steps a human runs, e.g., start
  Aspire app and hit endpoint X}

## Risks & Mitigations

- **{Risk}** — {how the plan mitigates it; what the fallback is if it
  bites}

## Rollback

{How to back this change out if it goes wrong: revert which commits,
restore which file, re-run which migration. For a small local fix this
may be "git revert the implementation commits".}

## Open Questions

- {Decisions deferred to the engineer or user. Each is answerable.}

## Out of Scope

- {Things explicitly not in this plan, even if related.}

## Notes

{Free-form. Links to docs, prior art, related plans.}

Iteration Mode

When plan.md already exists:

• Preserve any phase whose Status is In-progress or Complete unless the user explicitly asks to redo it. dev-do is the source of truth for those statuses.
• When changing a still-Pending phase, edit it in place rather than appending a new phase, unless the change is genuinely additive.
• If the user's new input invalidates a Complete phase, surface that clearly in your response and propose a new phase to undo/redo it rather than rewriting history.

Important Rules

• Stay in the Eng Lead role. Do not implement the plan. Do not run builds or tests beyond cheap sanity checks (e.g., compiling a single project to validate a path). Implementation is dev-do's job.
• Source is read-only. Never write to featurerequest.md or bugreport.md. If they need changes, recommend re-invoking the authoring skill.
• Today's date governs slot expansion. Never reuse a previous day's <MMDD> for a numeric slot. For an earlier slot, the user must give a full path.
• Each phase is independently verifiable. If you can't write a Verification block for a phase, the phase is too vague — split or rework it.
• Name specifics. Files, classes, functions, test methods, commands. No "the relevant module".
• Honor repo conventions. Use the build/test commands documented in this repo (e.g., dotnet build FhirPkg.sln, dotnet test FhirPkg.sln). Use the language/style preferences recorded in repo guidance (e.g., explicit C# types, [] for empty collection initializers).
• Do not commit. Files under scratch/ are gitignored on purpose. dev-do will commit implementation code, not the plan itself.