VC Phase Loop
Outcome
Complete the requested work within the user's scope and authority, then support the completion claim
with executed checks and concrete evidence.
1. Scope and risk
- Read applicable repository instructions before editing.
- Separate requirements from assumptions.
- Identify destructive, costly, credential-sensitive, public, or externally consequential actions.
- Proceed with reversible in-scope choices. Ask when an unanswered choice materially changes the
result or requires authority the user has not granted.
2. Choose task depth
- Small: execute directly, then verify.
- Multi-step: keep a short plan with one active step.
- Long-running or resumable: create
.vc/work-{timestamp}.md with requirements, decisions, status,
blockers, and completion evidence. Update it at decision or phase boundaries, not after every command.
Do not inflate a task to reach a fixed phase count.
3. Execute
- Follow existing project patterns.
- Keep changes minimal and reviewable.
- Use built-in Codex subagents only for independent work that benefits from separate context, such as
exploration, test execution, or review.
- Avoid parallel write-heavy work unless file ownership is clearly separated.
- Preserve user changes and stay within the approved roots.
4. Recover intelligently
Use the Two-Strike rule:
- Diagnose the first failure and try a targeted correction.
- If the same failure repeats, stop using the same approach.
- Re-check assumptions, inspect the root cause, and choose a materially different strategy.
- If progress requires missing authority, credentials, money, user input, or external state, report
the blocker instead of pretending to continue.
Retries are bounded by new information. Never promise guaranteed success or an infinite loop.
5. Verify proportionally
Prefer the project's own checks in this order when available:
- focused tests for changed behavior;
- lint, type, or syntax checks;
- broader tests or build for higher-risk changes;
- a real user-path exercise when practical.
Do not claim a check passed unless it ran successfully. If a check could not run, state why.
6. Report
Lead with the outcome. Include:
- what changed;
- commands or user paths actually verified;
- important assumptions or tradeoffs;
- remaining blockers or follow-up work.
1---2name: vc-phase-loop3description: Run a bounded evidence-first plan, execute, and verify workflow for multi-step implementation or repair tasks. Use when the user wants end-to-end completion; do not use for a simple answer or when a required decision needs user authority.4---56# VC Phase Loop78## Outcome910Complete the requested work within the user's scope and authority, then support the completion claim11with executed checks and concrete evidence.1213## 1. Scope and risk1415- Read applicable repository instructions before editing.16- Separate requirements from assumptions.17- Identify destructive, costly, credential-sensitive, public, or externally consequential actions.18- Proceed with reversible in-scope choices. Ask when an unanswered choice materially changes the19 result or requires authority the user has not granted.2021## 2. Choose task depth2223- Small: execute directly, then verify.24- Multi-step: keep a short plan with one active step.25- Long-running or resumable: create `.vc/work-{timestamp}.md` with requirements, decisions, status,26 blockers, and completion evidence. Update it at decision or phase boundaries, not after every command.2728Do not inflate a task to reach a fixed phase count.2930## 3. Execute3132- Follow existing project patterns.33- Keep changes minimal and reviewable.34- Use built-in Codex subagents only for independent work that benefits from separate context, such as35 exploration, test execution, or review.36- Avoid parallel write-heavy work unless file ownership is clearly separated.37- Preserve user changes and stay within the approved roots.3839## 4. Recover intelligently4041Use the Two-Strike rule:42431. Diagnose the first failure and try a targeted correction.442. If the same failure repeats, stop using the same approach.453. Re-check assumptions, inspect the root cause, and choose a materially different strategy.464. If progress requires missing authority, credentials, money, user input, or external state, report47 the blocker instead of pretending to continue.4849Retries are bounded by new information. Never promise guaranteed success or an infinite loop.5051## 5. Verify proportionally5253Prefer the project's own checks in this order when available:54551. focused tests for changed behavior;562. lint, type, or syntax checks;573. broader tests or build for higher-risk changes;584. a real user-path exercise when practical.5960Do not claim a check passed unless it ran successfully. If a check could not run, state why.6162## 6. Report6364Lead with the outcome. Include:6566- what changed;67- commands or user paths actually verified;68- important assumptions or tradeoffs;69- remaining blockers or follow-up work.
kks0488