vc-execute

Vector Cadence Execute

Purpose

Implement approved work safely. This skill assumes the target is clear enough to code; if not, route back to alignment, planning, triage, or debugging.

Operating model

Use branch/worktree safety, task tracking, one-behavior-at-a-time TDD for behavior changes, continuous validation, and scoped subagents only when their file access is safe.

When to use

Use for:

• implementing a reviewed plan,
• executing a ready-for-agent issue,
• completing an agent brief,
• running a bounded AFK implementation loop.

When to skip

Skip when:

• scope is vague (vc-align or vc-plan),
• a bug lacks root cause (vc-debug),
• a human design/security/privacy decision is unresolved,
• workspace safety cannot be established.

Inputs

Accept:

• plan path,
• issue reference,
• agent brief,
• small direct task.

Workflow

1. Triage input

Classify:

2. Check workspace safety

Before editing:

• check branch and uncommitted changes,
• avoid overwriting user work,
• avoid committing to default branch unless policy/user permits,
• prefer feature branch or isolated worktree for non-trivial work.

3. Build task list

Preserve source trace:

• U-IDs,
• requirements,
• dependencies,
• execution notes,
• likely files,
• test scenarios,
• verification criteria.

Track progress in the task tracker or summary, not by editing the plan body.

4. Choose execution strategy

If the harness does not provide subagents, execute inline or serially yourself.

Never let shared-checkout subagents stage, commit, or run whole-suite tests concurrently.

5. Implement behavior with TDD

For behavior-bearing work:

choose one behavior
→ write one failing public-interface test
→ verify it fails for the right reason
→ implement minimal code
→ verify green
→ repeat
→ refactor only while green

Test observable behavior through public interfaces. Avoid tests coupled to private implementation. Add integration coverage for callbacks, persistence, permissions, retries, multi-interface parity, and external contract behavior when relevant.

Skip strict test-first for pure styling, mechanical renames, config-only changes, or cases where characterization-first is safer.

6. Verify continuously

Before marking a task complete, check:

• what callbacks/middleware/jobs/events fire,
• whether tests exercise the real chain,
• whether failure can leave orphaned state,
• whether other interfaces expose the behavior,
• whether auth, privacy, payments, or external contracts are touched.

Run focused tests first, then broader affected checks as confidence grows.

7. Commit only if allowed

If user/project/harness policy permits commits, commit complete logical units only when tests pass and the message describes real value. Do not create WIP commits or stage unrelated files.

8. Apply review gate

Stop conditions

Stop when:

• acceptance criteria are ambiguous,
• three fix attempts fail,
• tests fail for unknown reasons after focused diagnosis,
• implementation reveals an unplanned product/architecture decision,
• subagent outputs conflict or risk lost work,
• high-risk behavior differs from the plan.

Output

## Execution Summary

**Implemented:** ...
**Source:** ...
**Tests run:** ...
**Review gate:** ...
**Commits:** ...
**Open risks / follow-ups:** ...
**Recommended next skill:** vc-review | vc-learn

Guardrails

• Do not code from vague intent.
• Do not refactor while tests are red.
• Do not let subagents write overlapping files in one checkout.
• Do not leave debug/prototype artifacts unmarked.
• Do not claim validation passed unless it did.