Plan Implementation

Advanced Features

• Search the current artifact root for upstream question, research, design, and structure documents before treating the plan request as artifact-free.
• Use direct code inspection to refresh stale file:line references without restarting broad codebase research.
• Include short code snippets only when they materially improve precision.
• Carry forward explicit non-goals so scope does not expand during planning.
• Treat the approved phase skeleton as binding input and route real sequencing conflicts back upstream instead of silently fixing them in the plan.

Workflow

1. Normalize the inputs.

   • If the user started from Jira, load the ticket through managing-jira.
   • Use artifact-management to find the current workflow root and any existing QRDSPI artifacts for the same topic.

2. Validate prerequisites.

   • Confirm that approved design and structure artifacts exist.
   • Confirm the design decisions are settled enough to expand directly.
   • Use supporting research notes when available, but do not let them replace the design or structure prerequisites.
   • Stop if unresolved questions remain or if the structure artifact is too unstable to expand safely.

3. Refresh the code references.

   • Re-open the important source files cited by the artifacts.
   • Update stale file:line references before relying on them.
   • Gather only the surrounding code needed to ground concrete phase details and snippets.

4. Expand the approved phases.

   • Preserve the approved phase names and ordering.
   • Add concrete changes, completion criteria, automated checks, and manual verification per phase.
   • Keep each phase ready for later execution checkpoints so implement-plan can append Execution Status, Automated Verification, Review And Simplification, Manual Verification Result, and Blockers Or Follow-Up Notes without inventing a new artifact.
   • Keep each phase grounded in verified references and explicit scope boundaries from the approved artifacts.
   • Do not reopen research, redesign the solution, or turn the phase descriptions back into open-ended discovery.

5. Validate completeness.

   • Confirm every phase has concrete implementation detail, not just summary prose.
   • Confirm every phase has both automated checks and a human manual verification checkpoint.
   • Confirm approved sequencing, scope boundaries, and non-goals are preserved.
   • Confirm the final plan contains no unresolved questions.

6. Persist the result.

   • In a staged workflow, update or create the plan artifact through artifact-management.
   • In staged QRDSPI work, set the plan artifact to Status: approved only when the human explicitly approves it.
   • For casual one-off planning, inline output is enough unless the user asked for a file.

Examples

Input: "Use this design doc and structure outline to create the implementation plan for billing retries."

Output:

# Billing Retries Implementation Plan

## Overview

Implement the approved billing retry flow in the existing server-side billing system, following the agreed retry scope and the approved rollout.

## References

- Design: `docs/billing-retries-design.md`
- Structure: `docs/billing-retries-structure.md`
- Research: `docs/billing-retries-research.md`

## Phase 1: Centralize Retry Policy Inputs

### Overview

Create one source of truth for retry classification and scheduling inputs.

### Changes Required

- Update the shared billing retry policy module to accept the approved retry inputs.
- Adjust the existing billing configuration surface to provide policy values without duplicating retry rules.

### Done When

- Retry policy behavior matches the approved design.
- Automated checks covering the billing policy and dependent flows pass.

### Manual Verification

- Trigger a retryable and a non-retryable failure and confirm they diverge at the expected policy boundary before implementation proceeds to the next phase.

Reference Files

• references/plan-template.md - Detailed workflow, required phase content, validation checklist, and plan template.

Guidelines

• Keep SKILL.md concise; put durable templates and detailed structure in reference files.
• Prefer precision over verbosity.
• Do not silently broaden scope beyond the approved design.
• Preserve the approved phase names and sequencing unless you find and call out a concrete conflict.
• No open questions in the final plan. Stop and resolve them before finalizing.
• Do not turn the plan into implementation work.
• Jira can supply context, but it does not waive the requirement for approved local design and structure artifacts.