Overview

Create dt-rpi-planning-context.instructions.md — a DT-aware instruction file that auto-loads when task-planner operates on DT artifacts. This ensures planning respects DT's iterative nature, lo-fi quality constraints, and human-centered design principles rather than defaulting to traditional linear implementation planning.

When task-planner receives a handoff from the DT coach (via Solution Space or Implementation Space exit), this instruction file helps the planner understand that:

• Planning should preserve iteration affordances (DT may loop back)
• Prototype fidelity constraints apply to planned deliverables
• Implementation phases should include user validation checkpoints
• DT coaching context (stakeholder map, insights, HMW questions) informs planning constraints

Directory context: The .copilot-tracking/dt/ path in applyTo is created per-project by the coach agent (#579 from Phase 2). See #583 for directory structure and handoff contract details.

Target File

.github/instructions/dt-rpi-planning-context.instructions.md

Frontmatter

---
description: 'DT-aware task-planner context — preserves DT iteration, lo-fi constraints, and human-centered planning'
applyTo: '**/.copilot-tracking/dt/**'
---

Required Content

Planning Adjustments

When operating in DT context, task-planner adjusts its approach:

DT-Specific Planning Patterns

• Iteration checkpoints: Plan review points after each major deliverable where the user can choose to continue implementation or return to DT coaching with new evidence
• Fidelity gates: Planned deliverables must not exceed the fidelity level of the originating DT space (Problem Space → research artifacts only; Solution Space → concept specifications, not production code)
• Stakeholder validation steps: Include explicit steps for validating deliverables against the stakeholder map from Method 1
• DT context preservation: Planning documents reference the originating DT project and coaching state, enabling return-to-coaching if needed
• Assumption tracking: Carry forward the validated/assumed/unknown markers from the DT handoff; plan validation activities for "assumed" items

Phase Architecture for DT-Origin Plans

Plans originating from DT handoffs use this phase structure:

1. Phase 1: Context Integration — Read DT coaching context, validate handoff artifact, confirm stakeholder map is current
2. Phase N (implementation phases) — Standard implementation with DT-specific constraints (fidelity, iteration checkpoints)
3. Phase N+1: Stakeholder Validation — Validate deliverables against stakeholder map, measure against human-centered success criteria
4. Phase Final: DT Reconnection — Offer to resume DT coaching with implementation results (feeds into Method 8: Testing or Method 9: Iteration)

Constraint Inheritance

Task-planner inherits these constraints from DT context:

• Lo-fi quality enforcement per originating DT space
• Stakeholder priorities from the DT coaching process
• Evidence quality markers (plans should not assume "unknown" items are resolved)
• Industry context constraints (safety, regulatory, operational)

Token Budget

Target: ~500-700 tokens (ambient tier — auto-loads on all DT artifact paths)

RPI Pipeline Workflow

1. task-researcher: Review existing task-planner agent definition and planning patterns. Understand how applyTo globs modify planner behavior. Gather DT planning adjustments from cumulative research.
2. task-planner: Plan the file — planning adjustments, DT-specific patterns, phase architecture, constraint inheritance.
3. task-implementor: Author following prompt-builder standards. Adjustments should augment (not replace) standard planner behavior.
4. task-reviewer: Validate against DT review context (feat(instructions): Create dt-rpi-review-context.instructions.md #593), confirm planning adjustments, iteration checkpoint design, prompt-builder compliance.

Success Criteria

• Instruction file created at .github/instructions/dt-rpi-planning-context.instructions.md
• Frontmatter has applyTo: '**/.copilot-tracking/dt/**' glob
• Planning adjustments defined (iteration loops, fidelity gates, stakeholder validation)
• DT-specific planning patterns cover iteration checkpoints, fidelity gates, assumption tracking
• Phase architecture for DT-origin plans includes context integration and DT reconnection
• Constraint inheritance carries forward quality markers and industry context
• Token count within ~500-700 target
• Passes task-reviewer validation against prompt-builder standards
• Each prompt, instructions, or agent file registered in collections/design-thinking.collection.yml with path and kind fields
• Each prompt, instructions, or agent file registered in collections/hve-core-all.collection.yml with path and kind fields
• npm run plugin:generate succeeds after collection manifest updates