Menu
Survey observable paths, run the real system, capture evidence, and surface gaps. TRIGGER when asked to prove a change works or write a QA plan.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Voice guide for writing PR descriptions. Use this skill for ALL PR creation and updates (via gh CLI or editing existing PRs). Contains your specific voice rules, anti-patterns, examples, and workflow. Never write PR descriptions without invoking this skill first.
Commit the changes in the working tree. Only invoke when the user explicitly signals to commit ("commit", "/commit", etc.). Never invoke this skill on your own initiative — implementation approval is not a commit signal.
Standalone code review for any scope — PR number, branch, file paths, or current changes. Synthesizes intent, runs 10 parallel specialized agents, and presents actionable findings with a verdict. For PR scope, optionally posts the review to GitHub with inline comments.
Tell the next agent everything they need to know to continue your work.
Voice guide for writing issue/ticket/task/epic descriptions. Use this skill for ALL issue creation — GitHub issues, Jira tasks, Monday tasks, Linear tasks, and epics. Contains section structure, voice rules, and anti-patterns. Never write ticket descriptions without invoking this skill first.
Design the type progression and test plan for approved work. Invoke after agreeing on the high-level approach and before writing any implementation.
| name | prove-it-works |
| description | Survey observable paths, run the real system, capture evidence, and surface gaps. TRIGGER when asked to prove a change works or write a QA plan. |
| argument-hint | Scope to check (e.g. "current branch", "the /login endpoint", "the retry logic in src/queue.ts") [optional] |
Scope: $ARGUMENTS (if empty, assume the current change).
Before running anything, produce a short report:
This is a planning artifact, not prose — use a list.
Pick the real entry point. Real inputs. Real outputs. Not a test runner.
If you find yourself reaching for a test file, stop and ask: how would I observe this behaviour if I had no test suite at all? That's the question to answer.
Cover every branch from Step 1 that you can reach. For each run, record:
❌ "The tests pass and the logic looks correct."
✅ "I ran npm run dev, navigated to /settings, toggled the feature, and saw the config update in the network response."
After running, answer two questions:
Don't let this section distract from Steps 1–2. The primary goal is live evidence, not test design. Surface the gap, name the test type, move on.
Before writing the report, decide what you'll recommend. Ask yourself:
Produce a private prioritized list (3–5 bullets). Use these categories:
Hold this list. Output nothing yet.
Now output the summary table followed immediately by the recommendations from Step 4:
| Path | Observed? | Evidence | Notes |
|---|---|---|---|
| Happy path | ✅ | npm run dev → navigated to /settings → saw config update in network response | |
| Invalid input | ✅ | curl -X POST /api/foo -d '{}' → 400 response with expected error body | |
| DB unreachable | ❌ | Can't simulate locally without stopping the DB container | Missing integration test |
Recommended next steps:
What would you like to do?
