lens-sandbox

Red-test-first fix loop for bugs and behavior changes — state the defect as a claim, write the failing test before any production code, watch it fail for the stated reason, then make the smallest change that turns it green. Includes follow-up sweeps (coverage of new properties, side-effect accounting, fixture reality checks), mutation proofs for green-on-arrival tests, and a strictly bounded, optional end-to-end phase used only when a contract crosses a component boundary. Use this whenever the user reports a bug, asks to fix an issue, asks whether a finding is real and then wants it fixed, asks to verify a fix with tests, or asks to harden tests against regressions — even if they don't say "TDD" or "red test".

Handle PR review comments interactively — fetch, triage, present, fix, reply, and resolve. Use this skill whenever the user wants to address PR review comments, fix review feedback, handle reviewer suggestions, respond to code review, resolve review threads, or work through pull request feedback. Triggers on 'fix review comments', 'address review comments', 'handle review feedback', 'resolve review threads', 'review comments', 'what comments are on my PR', 'fix pr feedback', or any mention of working through pull request review feedback.

Run the repo verification gates and auto-repair failures until green, an escalation, or the attempt cap. Use when the user runs `/green`, asks to run the gates or make them pass, or closes out an implemented slice. Do not auto-invoke during UI iteration.

Drive the problem-first pipeline forward — detect the current phase (intake, plan, implement, review, PR) from observable state and invoke the right skill, pausing at every human gate. Use only when the user runs `/ship`, optionally with an issue number or a one-line idea.

Create a pull request for the current branch. Use when user asks to: (1) create a PR, (2) open a pull request, (3) submit changes for review. Handles branch pushing, PR creation with gh CLI, and conventional title formatting.

Continuation of `/problem-first`. Confirms scope against product docs and existing specs, writes the agreed Gherkin scenarios to a `.feature` file in the target crate's test-layer directory, and enters technical planning mode. Use when the user explicitly runs `/problem-first-impl`, or when they ask to proceed to implementation after a `/problem-first` session. Do NOT auto-invoke.

Continuation of `/problem-first`. Creates a GitHub issue (open, unassigned) capturing the agreed problem statement and Gherkin scenarios as acceptance criteria. Use when the user explicitly runs `/problem-first-issue`, or when they ask to file an issue for a problem they've just worked through via `/problem-first`. Do NOT auto-invoke.

Problem-first planning that reads product docs, challenges assumptions, iterates behavior via Gherkin, agrees on a solution direction, and confirms doc-level alignment. Ends with an agreed problem statement, scenario set, chosen approach, and explicit confirmation that no doc conflicts remain; then suggests a continuation (`/problem-first-issue` to file a GitHub issue, `/problem-first-impl` to proceed to technical planning). Do NOT auto-invoke this skill. Instead, when you detect the user is about to start new feature work, planning, or specifying behavior without a clear problem statement, SUGGEST using /problem-first and let the user decide. Only invoke after the user explicitly opts in.

Thorough, opinionated code review. Two modes: (1) Self-review — no arguments — reviews your current branch against origin/main before creating a PR. (2) PR review — pass a GitHub PR URL or owner/repo#number — reviews someone else's PR and posts findings as a draft review on GitHub. Triggers on 'review my code', 'review this PR', 'code review', 'self-review', 'pre-PR review'.