thiientv Implementation Planning
Write for a capable engineer who does not know this repository or the hidden assumptions behind the request. A plan is useful only when another agent can execute it without reconstructing the design from hints.
Plan structure
Before listing tasks, record:
- goal and user-visible outcome;
- architecture and ownership boundaries;
- constraints, compatibility promises, and non-goals;
- files to create, modify, or delete;
- test and evidence strategy;
- rollback and migration safety.
Use plan-template.md for the complete skeleton.
Task rules
Break the work into thin, independently testable slices. Each task names:
- exact files and responsibilities;
- inputs, outputs, and interfaces consumed or produced;
- the failing or observable check first;
- the smallest implementation step;
- the focused command and expected result;
- the next checkpoint or integration dependency.
Prefer one behavior per task. Keep setup with the first deliverable that needs it. Do not create a task for speculative cleanup.
Plan quality gate
Before handing off:
- trace every design requirement to a task;
- search for placeholders such as
TBD,TODO, or “add appropriate…”; - check names and types across task boundaries;
- confirm commands exist in the repository;
- identify what the plan cannot prove locally.
Hand the completed plan to plan-execution or
subagent-driven-development. Do not claim the feature is implemented because
the plan is complete.