Tsh Creating Implementation Plans

Creating Implementation Plans

This skill turns a designed solution into a phased, verifiable implementation plan document.

Persisted approval is valid if and only if Human Decision=APPROVED, Approved Revision=current Plan Revision, and Decision Timestamp is valid ISO 8601 UTC ending in Z. A fresh session accepts persisted approval only under that exact predicate. Material changes before implementation completion increment Plan Revision, set Human Decision=PENDING, clear Approved Revision, and explain the change in Changelog. A material change after an earlier Human approval immediately halts further file-changing delegation and requires renewed Human approval; it does not automatically invoke a reviewer, and a new review event occurs only through an explicitly user-directed new review event. The low-risk exemption applies only to initial preparation before any Human approval. Routine task checkbox/progress/status updates and execution/review recording do not invalidate approval. This is an instruction-level, auditable mechanism, not cryptographic and not platform enforcement. Plans must not be dispatched to an implementor while any executable slot still contains an angle-bracket placeholder or any assumed-default command. Verification fields, DoD command items, and file/spec path arguments must be resolved from Technical Context or the task's app stack before dispatch. This gate is intentionally narrow: it applies only to executable slots, and instructional angle-bracket placeholders elsewhere in the template are allowed. The plan must not contain real implementation code or full implementation bodies/function logic. Pseudo-code is allowed only to explain genuinely complicated algorithms or ideas, and task-boundary seam artifacts such as type definitions, function signatures, DTOs, interfaces, and API shapes are allowed when they clarify the contract without supplying implementation bodies. Diagrams, explanations, and the Technical Context chapter content are allowed and encouraged.

Plan Creation Process

Before drafting, read ./plan.example.md in full first — it is the canonical structure every plan must follow. Knowing the required sections up front tells you which fields you must research, discover, or design (for example Technical Context, Current Implementation Analysis, and Security Considerations) before you begin, so you gather the right information deliberately rather than backfilling it later.

1. Confirm inputs: a designed solution, typically from tsh-architecture-designing, plus task research and context. Do not design the solution here; this skill structures an already-designed solution into a plan.
2. Define the Wildly Important Goal and the plan description.
3. Divide the work into small phases. Each phase must have a Goal, a Description, a **Verification:** field listing the exact fast-running checks to run after the phase completes, and a list of tasks with checkboxes to mark finished tasks later. Keep phase verification reviewer-verifiable and limited to fast checks such as unit tests, integration tests, static code analysis, linters, formatting checks, and project build. Source these checks from the plan's Technical Context → Tech Stack / Testing Patterns rather than assuming Node/npm.
4. Define each task. Each task must have a Description, a **Files:** field, and a Definition of Done as a checkbox list. Phase Description states the broader why for reviewers and implementors. Task Description should use a near-imperative form that names the files and the behavior to change. The **Files:** field must name every file the task will touch and label each one with create, modify, or reuse. If a file was produced or last touched by an earlier task in the same plan, include an inline back-reference such as (modify — created in Task 1.1); if a file is created and consumed within the same task, no back-reference is needed. Tasks may also include an optional **Stop Rule:** sentence near Clues that tells the implementor to stop, report, and avoid improvising if the task cannot proceed safely or an expected seam is missing; do not turn this into a formal dependency graph or a Depends on: field. Optional Clues should still help the implementor with file paths, line ranges, reference patterns, and gotchas.
5. Add the mandatory cross-cutting tasks required by the plan rules.
6. Save the plan as a document following the ./plan.example.md template. Do not add or remove any sections from the template. Follow the structure and naming conventions strictly.

Connected Skills

• tsh-architecture-designing - designs the solution this skill turns into a plan
• tsh-implementation-gap-analysing - verifies what was already implemented before planning new work
• tsh-technical-context-discovering - populates the plan's Technical Context section