18 skills
Every skill ships in the plugin — the Related Skills graph is closed, nothing dangles. One-line enforcement contracts below; full frontmatter descriptions and bundled materials in the detail cards further down. Hands-on invocation examples for every skill live in the usage guide.
What each skill actually does
Structured solution brainstorming with trade-off analysis and brutal honesty: scans the codebase BEFORE asking questions, pins exact requirements (expected output, acceptance criteria, scope boundary constraints, touchpoints), presents 2-3 approaches with pros/cons in visible text, and writes no code until the user approves a design. Use when exploring ideas, weighing architecture or technology options technical debates, feasibility assessment, design discussions problem-first inversion ('user already picked a solution — find the real problem'), or whenever the path forward is unclear — 'let's brainstorm' 'explore ideas', 'what are my options', 'which approach is best'. Not for executing an approved plan (use implement), end-to-end orchestrated builds (use implement), or auditing finished work (use full-functional-audit).
Single-file skill — doctrine loaded on demand from shared references.
Conduct an evidence-backed, end-to-end audit and safe remediation of any software repository. Reconstructs change intent from history, verifies code, configuration, documentation, runtime behavior, dependencies, and production readiness; identifies drift, dead code, stale docs, cleanup risks, and remediation options; pauses for explicit approval before behavior or destructive changes; then executes approved remediation with validation. Use when asked to audit a codebase, compare implementation with intent or docs, plan a refactor, clean a repository safely, close documentation drift, or prepare a repo for production. Not for greenfield planning (use validation-plan), feature builds (use implement), or mining session transcripts (use session-intent).
Bundled — 1 references: output-contract.md · 1 scripts: init_audit_workspace.py
The proof standard for end-user testing: every completion claim is proven by driving the real system as the end user, with run-scoped fresh evidence (timestamped, sequential, non-empty, never reused across runs), full-path citations describing what is SEEN, personally examined proof before any task is marked done, cache-clearing before final passes, and refusal to PASS without cited artifacts. Includes the fresh_evidence.py helper enforcing init-run / next-step / seal / validate. Use when a verdict is about to be written, when capturing end-user test evidence, when marking tasks complete, or when the user says 'end-user test this', 'capture evidence', 'fresh screenshot', 'produce a verdict', or 'prove it's done'. Not for writing test suites (use stack-testing) or visual/UX review (use visual-inspection or ui-experience-audit).
Bundled — 1 scripts: fresh_evidence.py · 1 assets: verdict-template.md
App-wide functional audit of a live site or app that inventories EVERY user interaction — every screen, page, button, form, link, endpoint, and flow — then clicks through everything and validates each one against the real running system, remediates failures immediately, and revalidates until clean. Five phases: Explore (interaction inventory), Plan, Execute (fresh evidence per interaction), Remediate (fix the real system, never defer FAILs), Verdict (coverage statement). Use when asked to 'audit the whole app', 'click through everything', 'find bugs on this site/URL' 'test everything', 'full QA sweep', or for pre-release hardening. Not for single-feature checks (drive the real system per the shared runbooks), per-screen UX review (use ui-experience-audit), or one known bug (use root-cause-debugging).
Single-file skill — doctrine loaded on demand from shared references.
The single write path: scouts the real codebase (mandatory, subagents) distills TRUE success criteria, mines past sessions (session-intent) forges the build prompt (prompt-forge), decomposes into a task graph where every task carries a proof obligation, then runs the execution loop — implement a task, drive the finished feature as the end user immediately record the proof — until every criterion is proven. End-user validation is an inline phase of every task, not an optional skill: the real runtime gets driven as the end user, always, with fresh run-scoped evidence. Never writes test files; validation is the completed user job. Flags: --parallel (executable lane contracts), --auto (never stops until proven), --mine --fast. Use when asked to 'implement X', 'build X end to end', 'ship X' 'make X work', 'use all the skills to ship this', or to execute a plan against a real codebase. Not for planning without building (use validation-plan) or ideation (use brainstorm).
Single-file skill — doctrine loaded on demand from shared references.
Drive and validate iOS apps end-to-end on real simulators — five-phase SETUP, RECORD, ACT, COLLECT, VERIFY protocol with video recording, log streaming, and screenshot evidence; three-facet validation checkpoints (simulator + backend + log analysis); xcrun simctl device control; XC-MCP accessibility-first UI automation; Expo/React Native simulator workflows; preflight environment checks. Use when validating an iOS or Expo feature marking any mobile task complete, booting/controlling simulators capturing mobile UI evidence, or debugging Metro/simulator issues. Unexecuted mobile validation is UNVERIFIED, never done. Not for web, desktop, or API validation (the shared runbooks) or non-iOS test suites (use stack-testing).
Bundled — 22 references: expo-e2e-testing-workflow.md, expo-testing-workflow.md, ios-simulator-control.md, ios-validation-gate.md, ios-validation-runner.md, preflight.md, simctl-command-reference.md, xc-mcp-accessibility-patterns.md +14 more · 4 scripts: example.sh, simulator.sh, validate.sh, xc_mcp_wrapper.sh
Second-pass plan strengthening: red-teams a draft plan through multiple adversarial lenses, scores confidence gaps, researches weak sections injects or strengthens proof obligations, and surgically remediates findings while preserving the original intent. Also converts arbitrary prompts or plans into proof-carrying versions using the standard proof block. Use when a plan exists but may be shallow, overconfident, missing failure modes, or lacking proof obligations — 'harden this plan', 'deepen this plan', 'red-team my plan', 'stress-test this design', 'add proof obligations to this prompt' — or before executing any high-stakes multi-phase plan. Not for authoring a plan from scratch (use validation-plan) or executing one (use implement).
Single-file skill — doctrine loaded on demand from shared references.
Take a codebase from 'works on my machine' to shippable — systematic 8-phase production-readiness audit (risk-based cleanup waves, dead code documentation drift, zero-regression enforcement), spec-vs-implementation compliance audits that find COVERED/INCOMPLETE/MISSING gaps, and dependency supply-chain health (CVEs, CVSS, lockfile hygiene, license compliance). Use when preparing a first release, open-sourcing, doing a major version bump, auditing whether a spec was fully implemented reviewing dependency risk, or after rapid prototyping leaves the repo in unknown shape. Not for runtime feature QA (drive the real system per the shared runbooks), screenshot review (use visual-inspection), or intent provenance (use session-intent).
Bundled — 3 references: dependency-health.md, production-readiness-audit.md, spec-compliance.md
Prompt engineering, rating, and pipeline design: authors high-quality prompts on the canonical XML tag skeleton, rates any prompt against a quantitative rubric with test cases and metrics, optimizes weak prompts against real failure evidence, and builds multi-stage meta-prompt pipelines (.prompts/ directories, dependency-aware stages, each with a SUMMARY.md). Always-on workflow: sequential thinking, todo tracking authorization engine, file-output contract; flags --in-place --report-only, --ship-below-threshold, --out, --evidence, --depth, --dir; unknown flags rejected. Use when writing, rating, improving, or debugging a prompt; designing a system prompt; forcing structured output; managing long context; or when model output is unreliable and the prompt is the suspect. Not for executing build plans (use implement) or adversarial plan review (use plan-hardening/red-team-eval).
Bundled — 7 references: context-management.md, evaluation-frameworks.md, prompt-optimization.md, prompt-patterns.md, remediation-sample.md, structured-outputs.md, system-prompts.md
Router and entry point for the proofpunk plugin's 17 delivery skills — reads a request, names the single best-fit skill (or short ordered chain for compound asks), and hands off without repeating that skill's own doctrine. Covers the full arc: brainstorm a design, plan or harden a multi-phase build, implement it end to end, audit a repo or a running app, chase a bug to its root, red-team an artifact, and prove any of it against the real system (web, API, CLI, iOS, TUI). Use when unsure which proofpunk skill applies, when a request spans more than one skill's scope, or when you want a map of the whole plugin before picking a skill yourself. Not a substitute for any listed skill's own workflow — it only routes.
Single-file skill — doctrine loaded on demand from shared references.
Attack your own plans, prompts, and outputs before reality does — 4-lens hostile review (security, scope-creep, evidence-rigor, failure-modes) against plans/prompts/artifacts, formal eval-driven development (EDD) scoring agent sessions against rubrics, QA cycling loops (test, verify fix, repeat until goal met), and agent evaluation with scoring rubrics and benchmarks. Use when a plan or prompt needs adversarial stress beyond a friendly review, when you want measurable quality scores for agent output across runs, when a fix-verify loop must not stop at 'looks done', or when regression-testing prompt changes against real failure cases. Not for finding a bug's root cause (use root-cause-debugging) or pre-execution plan strengthening (use plan-hardening).
Bundled — 4 references: agent-eval-strands.md, eval-harness.md, red-team.md, ultraqa.md · 2 assets: evals.json, trigger-eval.json
Find and fix the real cause of bugs, never the symptom — disciplined reproduce-minimize-hypothesize-instrument loops for hard bugs and performance regressions, backward call-stack tracing to the original trigger, test-pollution bisection with a find-polluter script, expert investigation protocols, and competing-hypothesis tracing lanes. Use when a bug's cause is unclear, errors surface far from their origin, fixes keep not sticking, tests pollute each other, or you're tempted to patch a symptom or add a retry. Iron Rule: no fix without reproduction, no claim without evidence. Not for full-site bug hunts (use full-functional-audit) flaky-test discipline (use stack-testing), or pre-release audits (use production-readiness).
Bundled — 9 references: debug-like-expert.md, diagnose.md, expert-debugging-mindset.md, expert-hypothesis-testing.md, expert-investigation-techniques.md, expert-verification-patterns.md, expert-when-to-research.md, root-cause-tracing.md +1 more · 2 scripts: find-polluter.sh, hitl-loop.template.sh
Reconstruct what was actually ASKED from the sessions themselves — parses Claude Code JSONL transcripts into a per-session intent matrix (first user prompt = stated intent, subsequent prompts = steering, tool calls, files touched, commits made), aligns sessions to git history, and builds intent-vs-implementation matrices where every row cites its session intent source or is marked intent-unrecoverable. Use when auditing what a codebase was supposed to become versus what it became; when session summaries, CLAUDE.md, or commit messages are the only stated rationale; when building commit-to-intent provenance; or when asked 'why was this change made' and the answer must come from evidence, not memory. Not for live repo audits (use codebase-truth-audit) or planning future work (use validation-plan).
Bundled — 5 references: claude-code-analyzer.md, analyze-claude-md.sh, analyze.sh, fetch-features.sh, github-discovery.sh · 1 scripts: session_intent.py
Real-system test discipline per stack — pytest/Go/C++/Django/Spring Boot gotchas that cause flaky CI, FastAPI HTTP/SSE testing with curl Playwright browser automation with server lifecycle management, and condition-based waiting to kill timing flakes. Use when writing debugging, or deflaking test suites in Python, Go, C++, Django, Spring Boot, or FastAPI projects; when tests pass locally but fail in CI; when browser e2e needs a dev server managed; or when any test uses sleep()/arbitrary timeouts. Iron Rule: mocks chapters in references are for understanding existing suites only; new tests run against the real system. Not for end-user proof of a finished feature (use end-user-testing) or single-bug root causes (use root-cause-debugging).
Bundled — 10 references: condition-based-waiting.md, cpp-testing-gtest.md, django-testing-gotchas.md, fastapi-backend-testing.md, go-testing-gotchas.md, playwright-api-reference.md, playwright-browser-automation.md, pytest-gotchas.md +2 more · 4 scripts: helpers.js, package.json, run.js, with_server.py
End-user proof for terminal UIs (Ink, blessed, textual, ratatui, curses): drive the real TUI in a real PTY as the end user with observe-then-act discipline, matched-assertion waits, three-facet evidence (screen + disk + logs), and pixel proof for visual claims. Codifies the measured lessons of driving agent-tty against a live Ink application: TTY guards, runtime floors, daemon PATH inheritance, cold-boot budgets, key-mount races transport-envelope traps, and per-run secret scans. Use when validating a TUI/CLI-interactive feature, when a gate drives a terminal app, or when 'prove the TUI works' is the ask. Not for web UIs (use web-validation via the implement validation phase) or non-interactive CLIs (use `references/cli-validation.md`).
Single-file skill — doctrine loaded on demand from shared references.
Deep end-to-end audit of any UI screen across four dimensions — visual defects, interactive elements, content quality, and UX heuristics — ending in one severity-classified report. Inventories every action item (button link, field, gesture), verifies each is discoverable and reachable, audits prose / code-block / diagram / data-viz rendering, and evaluates against Nielsen's 10 heuristics plus affordance theory. Modes: identify-and-delegate (screenshot only) or drive-interaction (drive the live system as an end user — preferred). Use when reviewing a UI screen page, or flow — 'review this screen', 'audit this page', 'QA this view' 'is this UI good' — iOS, web, or cross-platform. Not for pixel-checklist screenshot QA (use visual-inspection) or app-wide functional sweeps (use full-functional-audit).
Bundled — 4 references: content-quality-checklist.md, interactive-element-audit.md, responsive-audit.md, ux-heuristics-checklist.md · 1 assets: audit-report-template.md
Authors multi-phase project plans where every phase carries blocking cumulative proof obligations — BRIEF, ROADMAP, per-phase PLAN, SUMMARY + VALIDATION with run-scoped evidence. Proofs are cumulative: phase N's validation re-verifies phases 1..N-1, so a regression in earlier work blocks advancement. Use when asked to plan a multi-phase build, create a validation plan, structure a project roadmap, break a feature into proven phases, write a BRIEF/ROADMAP, or when an autonomous runner needs phases it cannot advance past without proof. Not for executing the plan (use implement or implement) or hardening an existing draft (use plan-hardening).
Bundled — 1 references: task-file-format.md
Mandatory visual QA protocol for UI screenshots — iOS (Apple HIG), web (WCAG 2.2), and cross-platform. Evaluates layout, overflow, spacing typography, contrast, touch targets, dark mode, and visual hierarchy against universal and platform-specific checklists, with severity classification and a defect-pattern database. Use when reviewing simulator captures, browser screenshots, or design-implementation evidence, and before marking ANY screenshot as PASS — even when the user just says 'check this screenshot', 'does this look right', or attaches a UI image. Not for interactive UX flow audits (use ui-experience-audit) or driving running features (the shared runbooks).
Single-file skill — doctrine loaded on demand from shared references.