phase-execution
Your bulletproof guide to executing implementation phases! Handles commits, detects when phases are too big, and knows when to bail cleanly. Load this whenever you're implementing a phase - it provides clean commit protocol and signals the orchestrator when things go sideways.
Installation
Suivez les instructions du dépôt pour votre agent. Consultez les fichiers et dépendances avant l’installation.
Voir la source ↗GuidesInstructions
Phase Execution
Overview
Execute a single phase from an implementation plan with disciplined commit protocol and automatic detection of phases that are too large.
When to Use
- When executing a phase from an implementation plan
- When the orchestrator (Planner) hands off a specific phase for implementation
- When working within the RPIV orchestration system
Inputs
The orchestrator provides:
| Input | Description | Example |
|---|---|---|
| Plan path | Location of the implementation plan | thoughts/shared/plans/2026-01-03_core-graph.md |
| Phase number | Which phase to execute | Phase 2 |
| Worktree path | Working directory (if using worktrees) | .trees/plan-1-core-graph |
| Branch name | Git branch for commits | implement/plan-1-core-graph |
Execution Protocol
Step 1: Read Phase Requirements
- Read the full implementation plan
- Locate the specific phase
- Extract:
- What changes are required (files, code patterns)
- Success criteria (automated and manual)
- Dependencies on previous phases
- Verify previous phases are complete (check git log or plan checkboxes)
Step 2: Execute Implementation
For each change in the phase:
- Make the code change
- Run relevant tests incrementally (don't wait until end)
- If a test fails, fix immediately before proceeding
- Track context consumption mentally
Step 3: Escape Hatch Detection
Trigger conditions (any of these):
- Context threshold message received: "STOP IMMEDIATELY. Context threshold..."
- Significant scope creep detected (implementing things not in phase spec)
- Phase requires more than 3-4 significant file changes beyond what was specified
Escape hatch protocol:
1. STOP immediately
2. Discard uncommitted changes: git checkout .
3. Return to orchestrator with signal: "NEEDS_DECOMPOSITION"
4. Include: what was completed, what remains, estimated sub-phases
Step 4: Commit Protocol
When phase is complete:
- Stage all changes:
git add -A - Create commit with structured message:
Phase N: [Phase Title] - [Key change 1] - [Key change 2] Plan: thoughts/shared/plans/[plan-file].md - Push to branch:
git push origin [branch-name]
Step 5: Verification
Before returning to orchestrator:
- Run ALL success criteria commands from the plan
- Document results:
- ✓ for passing checks
- ✗ for failing checks (should abort, not return success)
- Note any manual verification items for later
Return Protocol
On successful completion:
PHASE_COMPLETE
Commit: [SHA]
Checks:
- tests: ✓
- types: ✓
- lint: ✓
Manual verification needed:
- [item 1]
- [item 2]
On escape hatch trigger:
NEEDS_DECOMPOSITION
Completed:
- [what was done]
Remaining:
- [what remains]
- [what remains]
Suggested sub-phases:
- [sub-phase 1 description]
- [sub-phase 2 description]
Anti-Patterns
- Don't batch all tests to the end - Run tests incrementally
- Don't commit partial work - Either complete the phase or escape hatch
- Don't ignore scope creep - If you're doing more than specified, escape hatch
- Don't continue after context warning - The plugin message is authoritative
- Don't update the plan file - Return PHASE_COMPLETE and let the orchestrator handle progress tracking
-
Don't skip the push - Always
git pushafter committing; the orchestrator and validator need your commits on the remote
Exemples
Consultez les exemples du dépôt source.
Voir la source ↗Historique source
- Date d’indexation
- 2026-01-20
- Mise à jour de l’index
- 2026-02-03
- Branch
- main
Les dates concernent ce répertoire. Consultez le dépôt pour l’historique du code.
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!