Dev Loop

2. Test

• Run the relevant automated checks.
• If the change is not covered, add or update tests.
• Do not move on with broken tests.

Tests answer: "Does it do what I intended?"

3. Vibe-check

Experience the change like a user or consumer would. This catches unspecified but obvious problems.

Examples:

• Frontend: open the flow, click through, resize, try keyboard navigation.
• Backend/API: hit real endpoints, inspect response shapes, try malformed input.
• CLI: run real commands with both valid and invalid inputs.
• Library: write a small consumer example and judge ergonomics.
• Docs/paper: read it cold and check flow and clarity.
• Data pipeline: run sample data and inspect outputs.

Guidance:

• In metric-driven mode, self-verify where possible and ask for human spot checks periodically.
• In human-in-the-loop mode, explicitly tell the user what to check once tests pass.

4. AI review

Do an objective alignment pass, not just a style review.

Check:

• Consistency: naming, patterns, structure, style
• Scope: minimal change, no speculative abstractions
• Trade-offs: does the change improve or preserve the project's key goals?
• Simplicity: all else equal, prefer the simpler implementation

5. Measure

Run the project's observations and compare against a baseline or the previous successful iteration.

Typical observation types:

• Script observations: run every iteration when cheap and deterministic
• Agent observations: run periodically for qualitative aspects
• Human observations: use at milestones or when uncertainty remains

Possible outcomes:

• Keep: indicators improved or held steady and no stage found blocking issues
• Discard: indicators regressed without a stronger compensating gain
• Investigate: mixed results or the signal is too weak to call

If you discard, revert to the pre-change snapshot and try a different approach instead of patching blindly.

Intensity guide

Adjust how heavy the loop is based on the change:

• Trivial change: test and measure only
• Bug fix: full loop
• New feature: full loop, usually human-in-the-loop
• Refactor: test, AI review, and measure; lighter vibe-check unless UX changes
• Performance work: full loop plus benchmark-style measurement
• Docs/paper section: vibe-check, AI review, and whatever quality measurement exists

Loop-back rules

• Test failure -> go back to testing after the fix
• Cosmetic vibe issue -> fix and re-check vibe
• Structural issue -> return to implementation and then re-test
• AI review concern -> fix and re-review
• Metric regression -> usually discard and rethink the approach
• Too many iterations on the same problem -> step back and reconsider the strategy

Logging and tracking

When the project uses iteration tracking, keep a simple progress log such as progress.tsv with:

• date
• commit or snapshot id
• status (baseline, keep, discard, investigate)
• key indicators
• short description

Use a human-readable location in the repo root unless the project specifies another path.

If your environment includes telemetry tooling such as skill-evolve, log the keep/discard result as a best-effort step after measurement. Do not let telemetry block the actual work.

How this skill connects to others

• north-star: defines the goals or indicators that measurement should check
• long-horizon: governs how to make autonomous decisions during extended loops
• notify: can report flagged decisions or iteration outcomes without blocking the work

Migration notes

This Codex version keeps the procedural guidance from the Claude skill but removes Claude-specific frontmatter fields such as category. Any project-specific commands should live in the repo's own instructions or adjacent references, not hard-coded into this skill.