vince-implement

Files (7)

• SKILL.md
• completion-and-review.md · reference/
• contract-and-recon.md · reference/
• dod-gates.md · reference/
• hygiene.md · reference/
• remediation.md · reference/
• tdd-and-wire-proof.md · reference/

SKILL.md (first lines)

# Vince — Implement

Before the final user-facing response, apply `reference/brief.md`.

An implementation is failing until reproducible evidence proves otherwise.

## Core rules

1. No implementation before a test fails for the expected reason.
2. No completion claim before `vince-review` writes a PASS verdict.
3. No claim such as “verified” or “tests pass” without the command and observed result.
4. Never weaken RED, GREEN, TAMPER, regression, wire proof, or independent review to save tokens.
5. Never write to shared dev, test, or production infrastructure without explicit authority.

Conversation is direct and plain. Artifacts remain professional. Load `reference/voice.md` only
when tone needs clarification or a user-facing report is difficult to phrase.
Load `reference/token-discipline.md` only at a checkpoint with context pressure, repeated reads, large
outputs, or a configured compact/clear policy. The compact efficiency rules are: read ranges, not
whole files; bound output; prefer deterministic scripts; use one fresh reviewer; keep the ledger
current.

## Intake and routing

Invoke `vince-intake` first. Continue only on `READY`; for an ad-hoc request, the user must confirm
the restated contract. Do not continue on `CLARIFY` or `BOUNCE`.

Invoke `vince-route` after intake is `READY`, before implementation planning, and at boundaries
between mechanical work, implementation, high-risk judgment, and review. Use the resolver’s exact
profile mapping. `ASK` stops work. A `SWITCH` model switch is a recommendation unless the harness
confirms it.

## Tier

| Tier | Applies to | Evidence shape |
|------|------------|----------------|
| T1 | Non-behavioral copy, formatting, or dependency-free configuration | Ledger stub, baseline, proof, and five-point self-review |
| T2 | Ordinary behavior, fixes, features, and refactors | Full workflow and fresh review |
| T3 | Multiple repos, public contracts, auth/isolation, migrations, or concurrency | Full workflow, confirmed plan, and one requirements-scoped review |

Take the highest applicable tier. Never downgrade without the user. Anything user-observable is
at least T2.

For T1, perform and record all five checks explicitly:

1. The diff contains only the intended change.
2. The suite is no worse than baseline.
3. Nothing user-observable changed.
4. No secret, debug artifact, or stray file is present.
5. The commit message and version change follow the profile.

## Phase 0 — Contract extraction

Resolve the profile and task paths; never assume `.vince/` is inside the repository:

```bash
python <toolkit>/scripts/install.py where --repo <repo>
```

If no profile exists, invoke `vince-setup` before continuing. Read the resolved profile and
lessons. Create the task directory and copy `templates/verification-ledger.template.md`. Record
the verbatim contract, one acceptance criterion per row, its proof level, tier, routing decision,
and session resources. No acceptance criteria, contradictory criteria, or missing authority is a
STOP.

Load `reference/contract-and-recon.md` now. It defines contract sources, profile inheritance,
proof levels, memory checks, and the required ledger fields.

## Phase 1 — Recon and baseline

Work in a dedicated worktree from the verified integration branch. Record it immediately. Inspect
only the owning code and relevant project instructions. Run the profile’s exact test command before
editing and record pass/fail/skip counts per repository. A suite that cannot run is a STOP.

Follow the recon and first-touch profile-promotion procedure in
`reference/contract-and-recon.md`.

## Phase 2 — Plan and confirm

Map each criterion to its test, changed files, and proof level. T3 plans require explicit user
confirmation. T2 plans may proceed when the confirmed contract and repository conventions settle
the implementation choices.

## Phase 3 — RED / GREEN / TAMPER / SUITE

For each criterion, in order:

1. **RED:** add the test and observe the expected failure.
2. **GREEN:** make the smallest implementation and observe the pass.
3. **TAMPER:** preserve the green implementation, deliberately break it, prove the test notices,
   restore it, and prove green again.
4. **SUITE:** run the full suite and compare it with baseline; no new failure or skip may pass.

Never edit, skip, quarantine, or delete a test merely to reach green. Never mock the behavior being
proved. Load `reference/tdd-and-wire-proof.md` before the first RED; it contains mutation safety,
restore rules, forbidden shortcuts, and evidence requirements.

## Phase 4 — End-to-end wire proof

Prove the headline behavior through the real user-facing interface. Unit-only evidence cannot
prove observable behavior. Use the profile’s rig and reach `E2E-WIRE` for at least one criterion.
If required infrastructure, credentials, or data is missing, record BLOCKED and stop rather than
inventing a substitute. Follow `reference/tdd-and-wire-proof.md`.

## Checkpoints

At every phase boundary, update statuses, evidence, the Resume block, and Session resources. Run:

```bash
python <toolkit>/scripts/resume.py --task <task-dir> --check
```

Only suggest `/compact` or `/clear` when the profile requests it and the command reports
`SAFE TO CLEAR`.

## Phase 5 — Definition of done

Load `reference/dod-gates.md`. Mark every applicable catalog and profile `dod_extras` gate PASS
with evidence, FAIL, or N/A with a reason. A checked box without a command is FAIL.

From elroykanye/vince-gate, MIT.

More from elroykanye/vince-gate