Fix missing format fields and create implementation-plan format

formats/implementation-plan.md

@@ -0,0 +1,97 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) PromptKit Contributors -->
+
+---
+name: implementation-plan
+type: format
+description: >
+  Output format for implementation and refactoring plans. Defines
+  section structure for task breakdown, dependency ordering, risk
+  assessment, and verification strategy.
+produces: implementation-plan
+---
+
+# Format: Implementation Plan
+
+The output MUST be a structured implementation plan with the following
+sections in this exact order. Do not omit sections — if a section has no
+content, state "None identified" with a brief justification.
+
+## Document Structure
+
+```markdown
+# <Plan Title> — Implementation Plan
+
+## 1. Overview
+<1–3 paragraphs: what is being implemented or refactored, why,
+and what the end state looks like. Include the goal, scope, and
+any driving requirements or design documents.>
+
+## 2. Current State
+<Description of the starting point:
+- What exists today (code, infrastructure, processes)
+- What works and what doesn't
+- Key assumptions about the current state
+
+For greenfield projects, state "Greenfield — no existing implementation."
+For refactoring, provide a behavioral summary of the current code.>
+
+## 3. Prerequisites
+<What must be true before work begins:
+- Required documents (requirements, design)
+- Environment setup
+- Dependencies on other teams or systems
+- Decisions that must be made first>
+
+## 4. Plan
+
+### Phase <N>: <Phase Name>
+
+#### TASK-<NNN>: <Task Title>
+- **Description**: <what to implement or change>
+- **Requirements**: <REQ-IDs addressed, if available>
+- **Dependencies**: <TASK-IDs that must complete first, or "None">
+- **Acceptance Criteria**: <how to verify completion>
+- **Complexity**: Small / Medium / Large
+- **Risks**: <what could go wrong with this task>
+- **Verification**: <how to confirm correctness after this task>
+- **Rollback**: <how to undo this change if needed>
+
+<Repeat for each task. Group tasks into phases representing
+logical milestones or deliverables.>
+
+## 5. Dependency Graph
+<Text-based diagram (Mermaid, ASCII, or structured list) showing
+task dependencies and the critical path. Identify which sequence
+of dependent tasks determines the minimum time to completion.>
+
+## 6. Risk Assessment
+| Risk ID | Description | Likelihood | Impact | Mitigation |
+|---------|-------------|-----------|--------|------------|
+| RISK-001 | ... | High/Med/Low | High/Med/Low | ... |
+
+## 7. Verification Strategy
+<How to confirm the plan is complete and correct:
+- What tests should pass at each phase boundary
+- Integration or end-to-end verification approach
+- How to validate the final state matches the target>
+
+## 8. Open Questions
+<Decisions that need to be made before or during implementation.
+For each: what is unknown, why it matters, and who can resolve it.>
+
+## 9. Revision History
+<Table: | Version | Date | Author | Changes |>
+```
+
+## Formatting Rules
+
+- Tasks MUST be ordered by dependency, not by perceived importance.
+- Every task MUST have acceptance criteria (how to know it is done).
+- Every task MUST have a complexity estimate (Small / Medium / Large).
+- The critical path MUST be identified in the dependency graph.
+- Tasks MUST use stable identifiers: `TASK-<NNN>` with sequential numbering.
+- Cross-references between tasks use the task ID
+  (e.g., "depends on TASK-003").
+- Phases represent logical milestones — each phase should be
+  independently demonstrable or deployable where possible.

manifest.yaml

@@ -213,6 +213,14 @@ formats:
       .github/instructions/*.instructions.md with applyTo targeting.
       Also supports Claude Code (CLAUDE.md) and Cursor (.cursorrules).
 
+  - name: implementation-plan
+    path: formats/implementation-plan.md
+    produces: implementation-plan
+    description: >
+      Output format for implementation and refactoring plans. Task
+      breakdown, dependency ordering, risk assessment, and verification
+      strategy.
+
 taxonomies:
   - name: stack-lifetime-hazards
     path: taxonomies/stack-lifetime-hazards.md
@@ -312,6 +320,7 @@ templates:
         with tasks, dependencies, and risk assessment.
       persona: software-architect
       protocols: [anti-hallucination, self-verification]
+      format: implementation-plan
 
     - name: plan-refactoring
       path: templates/plan-refactoring.md
@@ -320,6 +329,7 @@ templates:
         changes that maintain correctness at each step.
       persona: software-architect
       protocols: [anti-hallucination, self-verification]
+      format: implementation-plan
 
   agent-authoring:
     - name: author-agent-instructions

templates/plan-implementation.md

@@ -10,6 +10,7 @@ persona: software-architect
 protocols:
   - guardrails/anti-hallucination
   - guardrails/self-verification
+format: implementation-plan
 params:
   project_name: "Name of the project or feature"
   requirements_doc: "Requirements document (if available)"

templates/plan-refactoring.md

@@ -11,6 +11,7 @@ persona: software-architect
 protocols:
   - guardrails/anti-hallucination
   - guardrails/self-verification
+format: implementation-plan
 params:
   goal: "What the refactoring should achieve"
   current_code: "The code to refactor"

templates/review-code.md

@@ -12,6 +12,7 @@ protocols:
   - guardrails/anti-hallucination
   - guardrails/self-verification
   - guardrails/operational-constraints
+format: investigation-report
 params:
   code: "The code to review"
   review_focus: "What to focus on — e.g., correctness, security, performance, all"