feat(instructions): Create dt-rpi-implement-context.instructions.md #596
Description
Overview
Create dt-rpi-implement-context.instructions.md — a DT-aware instruction file that auto-loads when task-implementor operates on DT artifacts. This ensures implementation respects DT fidelity constraints, stakeholder validation requirements, and iteration support rather than defaulting to production-grade output.
When task-implementor receives a handoff from the DT coach (via Solution Space or Implementation Space exit), this instruction file helps the implementor understand that:
- Output fidelity must match the originating DT space (lo-fi early, hi-fi late)
- Implementation should preserve DT context for potential coaching return
- Stakeholder validation steps are explicit deliverables, not optional
- Iteration is expected — implementations may feed back into DT coaching
Directory context: The
.copilot-tracking/dt/path inapplyTois 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-implement-context.instructions.md
Frontmatter
---
description: 'DT-aware task-implementor context — fidelity constraints, stakeholder validation, and iteration support for DT artifacts'
applyTo: '**/.copilot-tracking/dt/**'
---Required Content
Implementation Adjustments
When operating in DT context, task-implementor adjusts its approach:
| Standard Implementation | DT-Informed Implementation |
|---|---|
| Production-quality output | Fidelity-appropriate output matching DT space |
| Complete implementation | Progressive implementation with validation gates |
| Technical acceptance criteria | Human-centered acceptance criteria (stakeholder validated) |
| Forward-only execution | Implementation may trigger return to DT coaching |
| Self-contained deliverables | Deliverables reference DT context and coaching state |
DT-Specific Implementation Patterns
- Fidelity-appropriate output: Problem Space artifacts are research-grade (notes, maps, summaries); Solution Space artifacts are concept-grade (wireframes, mockups, specifications); Implementation Space artifacts are production-grade
- Stakeholder validation steps: Each implementation phase includes an explicit step to validate output against the stakeholder map from Method 1
- DT context preservation: Implementation files include references to the originating DT project and coaching state, enabling return-to-coaching if results need DT iteration
- Assumption tracking: Carry forward validated/assumed/unknown markers from the DT handoff; flag when implementation decisions depend on "assumed" items
- Iteration support: Implementations are structured to support revision — avoid premature optimization or irreversible architectural decisions in early DT spaces
Fidelity Constraints by DT Space
| DT Space | Fidelity Level | Implementation Guidance |
|---|---|---|
| Problem Space (Methods 1-3) | Research-grade | Create research artifacts, stakeholder maps, problem statements — no code or prototypes |
| Solution Space (Methods 4-6) | Concept-grade | Create wireframes, concept specifications, lo-fi prototypes — functional proof only, not production code |
| Implementation Space (Methods 7-9) | Production-grade | Create production implementations with full quality standards — test coverage, documentation, deployment readiness |
DT Coach Return Triggers
Task-implementor should recommend returning to DT coaching when:
- Implementation reveals that the problem statement needs revision
- Stakeholder validation surfaces new requirements not in the original DT synthesis
- Technical constraints invalidate the selected solution concept
- Implementation results suggest a different DT method would yield better outcomes
Token Budget
Target: ~500-700 tokens (ambient tier — auto-loads on all DT artifact paths)
RPI Pipeline Workflow
- task-researcher: Review existing task-implementor agent definition and implementation patterns. Understand how
applyToglobs modify implementor behavior. Gather DT implementation adjustments from cumulative research. - task-planner: Plan the file — implementation adjustments, fidelity constraints, stakeholder validation, DT coach return triggers.
- task-implementor: Author following prompt-builder standards. Adjustments should augment (not replace) standard implementor behavior.
- task-reviewer: Validate against DT review context (feat(instructions): Create dt-rpi-review-context.instructions.md #593), confirm fidelity constraints, iteration support, prompt-builder compliance.
Success Criteria
- Instruction file created at
.github/instructions/dt-rpi-implement-context.instructions.md - Frontmatter has
applyTo: '**/.copilot-tracking/dt/**'glob - Implementation adjustments defined (fidelity-appropriate, stakeholder validation, DT context preservation)
- Fidelity constraints specified per DT space (research-grade, concept-grade, production-grade)
- DT coach return triggers defined (problem revision, new requirements, constraint invalidation)
- 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.ymlwithpathandkindfields - Each prompt, instructions, or agent file registered in
collections/hve-core-all.collection.ymlwithpathandkindfields -
npm run plugin:generatesucceeds after collection manifest updates