Executes a pre-written implementation plan in disciplined order, stopping at defined checkpoints to verify assumptions before moving forward. This skill prevents the common pattern of diverging from the plan silently when reality proves it wrong, and it creates natural opportunities to course-correct before small errors compound into large rework.
Use cases
- Following a spec written by an architect or senior engineer who is not available for daily questions
- Implementing a multi-step feature where each phase depends on the output of the previous phase
- Working through a complex refactor with a documented step order that should not be rearranged
- Running a sprint where the team is executing a plan produced during sprint planning
- Teaching an AI agent to implement a feature by providing a plan that the agent then follows
Key features
- Re-read the plan against the current state of the repository before starting, noting any changes since the plan was written
- Implement one step at a time, making small, focused commits that correspond to each plan item
- At each checkpoint, pause to verify the output matches the plan's exit criteria before proceeding to the next step
- Log any deviations from the plan in a brief comment or plan amendment so the record reflects what actually happened
- After the final step, verify the end state against the plan's overall acceptance criteria and surface any gaps
When to Use This Skill
- When executing a plan written by someone else who may not be available for clarification
- When implementing a complex feature where the sequence of changes matters for correctness
- When using an AI agent to implement a feature and providing a plan as the agent's primary guidance
Expected Output
A completed implementation with a traceable commit history that maps to each plan step, plus any plan amendments documenting deviations.
Frequently Asked Questions
- What do I do when the plan is clearly wrong halfway through execution?
- Stop, document the discrepancy, and propose a plan amendment. Do not silently diverge from the plan while continuing to execute it—this creates a situation where the plan and the code no longer match.
- How do I handle a plan step that takes more than a day?
- Split the step into sub-steps with intermediate checkpoints. If the step is blocked on an external dependency, note the block and move to the next independent step if possible.
- Should I update the plan document as I go?
- Yes—when reality diverges from the plan, update the plan to reflect what actually happened and why. This makes the plan useful for future auditors or teammates who need to understand how the final state was reached.
Related
Related
3 Indexed items
Writing implementation plans
Converts vague or frozen requirements into precise, step-by-step implementation plans with file-level touchpoints, decision checkpoints, and verifiable acceptance criteria before any code is written. This bridges the gap between what stakeholders want and what engineers can actually ship, reducing mid-sprint surprises and wasted refactors.
RAG implementation
Builds retrieval-augmented generation pipelines that ground model responses in your own documents rather than generic training knowledge. A RAG implementation covers document ingestion, semantic chunking, embedding, vector storage, hybrid search, reranking, and answer synthesis—so assistants answer from your data with cited sources.
Designing with LLM structured outputs
This skill covers when and how to ask an LLM for machine-readable payloads: define a JSON Schema (or the vendor's equivalent), enable the structured-output feature your provider documents, validate responses in application code, and handle refusals or validation errors explicitly. It applies to tool-calling agents, extraction pipelines, configuration emitters, and any workflow where brittle text parsing creates production risk.