plan-feature

name	plan-feature
description	Second stage of the LAD feature workflow. Turns the kickoff context into a test-driven task plan, reviews that plan critically for gaps and risks, and splits it into sub-plans when it is too large to hold in one pass. Use after feature-kickoff, or when asked to plan an implementation before writing code.
argument-hint	["feature slug"]

Plan feature

Read <docs>/<slug>/context.md first. If it does not exist, run /lad:feature-kickoff instead — planning without knowing what already exists is how duplicate implementations get built.

Three things happen here, in order: draft the plan, review it critically, then decide whether it is too big. Do not skip the review because you wrote the plan yourself; the point is to catch what the drafting pass assumed.

1. Draft the task breakdown

Every task names the test that proves it. A task without a test is a task without a definition of done.

Structure tasks so each one is independently completable and verifiable:

- [ ] 1. <task> ║ `tests/<slug>/test_<n>.py` ║ <what it delivers> ║ S/M/L
  - [ ] 1.1 <specific implementation step>
  - [ ] 1.2 <specific implementation step>

Sizing: S = under an hour, M = a focused session, L = should probably be two tasks.

Carry forward from context:

• Integration strategy — if kickoff decided Enhance, the tasks extend named existing components (by path:line); if Build new, there is a task for coexistence and one for the deprecation path.
• Documentation — the doc surface kickoff located becomes real tasks: setup/install changes, user-facing behaviour, breaking changes, new public APIs. Documentation written at the end is documentation that does not get written.
• References — tasks point at path:line or qualified names, not descriptions. The implementation stage should never have to re-find what kickoff already found.

Mark tasks needing a decision from the user with [USER_INPUT] and say what the decision is.

Register the tasks with TaskCreate so progress survives across sessions, and write the same breakdown to <docs>/<slug>/plan.md — the file is what you check off and read later; the task list is what keeps the current session honest.

2. Review the plan critically

Answer these plainly. "Yes" to everything on a first draft usually means the review was not real.

• Completeness — does every acceptance criterion map to at least one task? What behaviour is described in the request but not covered by any task?
• Sequencing — does anything depend on something scheduled after it?
• Testing strategy — is each component tested the right way (integration for APIs, unit for logic — see lad-standards)? Which tests would still pass if the implementation were wrong?
• Test data — for each test, do you actually know what realistic input looks like? Where you do not, that is a [USER_INPUT] task asking for a sample, not a licence to invent a fixture.
• Risk — concurrency, security, performance, data loss. What is the worst outcome of each task and is it reversible?
• Feasibility — are the resources, dependencies and interfaces the plan assumes actually present? Verify the ones you are unsure of rather than assuming.

Record what the review changed in the plan itself, under a ## Review notes heading — including issues you considered and deliberately accepted, with the reason. A reviewed plan that looks identical to the draft is indistinguishable from an unreviewed one.

3. Decide whether to split

Split when more than ~6–8 tasks, more than ~25–30 sub-tasks, or the work spans clearly separate domains. Below that, splitting adds ceremony without benefit.

Split along architectural boundaries, not by counting to six:

• Foundation (models, schema, core services) → Domain logic → Interface (API, CLI, UI) → Hardening (security, performance, deployment)
• Each sub-plan should produce something the next one consumes
• Cross-dependencies between sub-plans should be few and one-directional

When splitting, create <docs>/<slug>/plan_<n>_<name>.md per sub-plan plus <docs>/<slug>/split.md recording the sequence, the rationale, and what each phase hands the next.

Context evolution matters more than the split itself. As each sub-plan completes, the next one's context is updated with what was actually built — real interfaces, working import paths, tested usage — not what was planned. That update is what makes a later sub-plan able to build on an earlier one instead of guessing at it.

Output

Report: the task count, the split decision and why, any [USER_INPUT] items needing an answer before implementation starts, and anything the review changed.

Then hand off to /lad:implement-feature. If there are unresolved [USER_INPUT] items, raise them now — a decision made mid-implementation costs more than one made here.