Claude Skills by AaravChadha

Fixes issues in your repo, wiring Fixes #N into the PR body. Use when asked.

Checks one thing and reports it: a verdict, then evidence. Use when the user asks to check the thing.

Seeded user-level skill. Present only to be leaked into a run that failed to isolate.

Audit one of six targets. code - defect hunt producing a report with safety checks and adversarial verification evidence; docs - drift check of README/PLAN/JOURNAL against the actual tree, counts, and checkbox reality; eval - failure classification with the never-inflate rule; tests - finds tests that pass without catching, including a mutation spot-check; skills - SKILL.md hygiene; readme - whether the front door works on a stranger, measured against comparator projects. Use when the user as...

Interrogate a BRIEF before committing to it - premise attacks with steelmans, a narrower-wedge proposal, cost/hours/blast-radius reality checks, forcing questions, and a proceed / narrow-first / rethink verdict. Use when the user asks to challenge, stress-test, or poke holes in a brief, an idea, or a product premise.

Breaking-change pre-flight for the surface callers depend on - function signatures, API response shapes, public exports, config keys. Classifies every change in a diff additive vs destructive, names the add-new-then-deprecate alternative for each destructive one, and opens with a written GO or NO-GO verdict. Never fixes anything - it blocks and explains. Use before merging or releasing a change that touches a public interface, or when the user asks to check for breaking changes.

Dependency hygiene review - for each declared package, whether it is imported at all, whether the standard library or an existing dependency already does its job, whether it is still maintained, and whether its license fits the project's. Reports findings against the manifest line, ordered by how decidable each one is, and never edits the manifest. The upgrade mode pre-flights a version bump against this repo's call sites and ends GO/NO-GO. Use when the user asks to review dependencies, check...

Static UI convention check - off-palette colors and wrong product-name casing, dishonest data labels (AI-generated or mock data shown as real), AI-slop (lorem remnants, hedge copy, emoji headings, uniform gradient grids), and client-facing language leaks. Reports file:line findings with fixes; conventions come from config layered over pack defaults. Use when the user asks to design-audit or check UI conventions, polish, or copy.

Generate production-grade UI, not a mockup. Token system first (DTCG), wireframe before code, then an eight-item production-readiness set every interactive surface must answer - all states, real content, responsive, accessibility, interaction feel, theming, performance, UX writing - with any unanswered item reported as a named gap. Style is the user's call via dials; production-readiness is not optional. Use when the user asks to design, build, or restyle a UI, a screen, a component, or a des...

Complete one numbered subtask from PLAN.md end-to-end - execute exactly the named subtask, run its acceptance check, tick the exact box, commit with the task reference locally (never pushes - that is /ship's job), report what was edited, and propose subtasks that group naturally with it. Use when the user asks to do or complete a specific numbered task like 3.2.1.

Execute a project's eval and produce a results file - locate the golden set, scaffold a runner for the project's stack when none exists, grade every case by its own rule, and write per-case results plus a headline computed from that file. Reports verdict-first against the spec's target and never edits a golden case to raise a score. Use when the user asks to run the eval, score the golden set, or produce eval results.

Write the eval before the system exists - golden questions with category minimums, refusal cases where declining is the right answer, a grader defined up front, and the acceptable_failure discipline. The score target becomes the plan's exit criterion before any code is written.

Read-only project checkup - three docs present and fresh, CLAUDE.md pointer intact, conduct block current, config valid, secrets clean, attribution honored, learnings alive, tickets-mode prerequisites met. Every failed check comes with its exact fix command, never applied. Use when the user asks for a health check, a project checkup, or whether the project setup is sane.

Root-cause a failure before any fix - the iron law is no fixes without investigation. Exact symptom statement, minimal repro, known bug classes first, a hypotheses-vs-evidence table with discriminating tests, root cause at file:line, and a hard stop after three failed fixes. Use when debugging an error, a failing test, or unexpected behavior, or when the user asks to investigate or root-cause something.

Update JOURNAL.md, the rolling project journal, after a work session. Writes a dated work-log entry with exact names and before/after numbers, classifies eval failures, syncs PLAN.md checkboxes to reality, and commits. Use at the end of a work session or when the user asks to journal, log, or write up what happened.

Capture a lesson as a durable LEARNINGS.md entry - one-line lesson, symptom, cause, fix, context, and a dated trail of sightings; dedups against existing entries and proposes promoting recurring lessons into the pack's known-bug-classes. Use when the user says they learned something, wants to capture a lesson or gotcha, or when an investigation closes with a cause worth keeping.

Pre-flight safety check for Prisma/SQL migrations. MUST be run before creating or applying any migration in a project whose database is shared Postgres. Opens with a written GO or NO-GO verdict, then classifies every SQL statement additive vs destructive, checks migration-history drift and folder reuse, enforces create-only plus deploy discipline, and identifies the backup path first. Never fixes anything - it blocks and explains.

Engineering review that locks PLAN.md before code - end-to-end data-flow trace, failure modes per phase with detection and recovery, the test matrix the plan implies but doesn't state, hidden assumptions with their cheapest probes, and a LOCKED or CHANGES REQUIRED verdict. Use when the user asks to review, lock, or sanity-check the plan before building. For doc-vs-reality drift use /audit docs; for interrogating the brief use /challenge.

Create or evolve project planning docs. Modes - seed (write BRIEF.md, the frozen problem statement, and gate on written architecture pushback), build (write PLAN.md, the living phase plan with runnable exit criteria), replan (supersede decisions with dated verdicts, insert decimal phases). Hackathon shape via config or the hackathon argument.

Exercise the running app through the probe layer - happy-path flows first, then adversarial inputs (garbage, oversized, regex-special, out-of-range) and auth-gate probing, reported with a PASS/FAIL verdict and exact repro commands. The http probe is implemented; browser mode declines honestly until it lands. Use when the user asks to QA, smoke-test, or probe the running app, an endpoint, or a flow.

Behavior-preserving cleanup with proof - the suite runs green BEFORE and green again AFTER with the same test count, because a suite that shrinks during a refactor is the finding, not a detail. Stops when the tree is dirty, the baseline is red, or the suite is too thin to detect a behavior change, naming what to test first. Use when the user asks to refactor, clean up, restructure, or simplify existing code without changing what it does.

Resume a project in five minutes - read BRIEF/PLAN/JOURNAL plus git state, deliver a short where-we-are brief, divergence flags (uncommitted work, unjournaled commits, acceptance drift), and the next three unblocked tasks. Use at session start or when the user asks where were we, what's next, to catch up on a project, or to get oriented in an unfamiliar repo.

Trend review across many sessions - velocity vs planned dates, eval-score trend toward target, failure-category trends from journal triage and investigations, and a status check on every open PLAN risk. Reads JOURNAL/PLAN/eval history, writes a dated retro entry into JOURNAL.md. Use when the user asks for a retro, a weekly review, or a phase-end wrap-up.

Security review with a confidence gate - a finding exists only with a concrete exploit scenario and a high/medium/low confidence rating; everything else goes to a worth-hardening list, never inflated. Sweeps five surfaces: auth gates, secrets hygiene, injection and unsafe sinks, unsafe deserialization/crypto/transport, and LLM tool-use trust boundaries. Reports only, never fixes. Use when the user asks for a security review or to check vulnerabilities, secrets, or auth.

Branch-level release with five gates before the act - clean-state, tests, eval-vs-target, docs drift, and attribution sweep; any failing gate stops the release with its output. Then push, and under push: branch-pr open a report-shaped PR wiring the issue-closing reference in tickets mode or PLAN task IDs in document mode. Use when the user asks to ship, release, cut, or open the PR for a feature or branch.

Capture a brain-dump as a well-formed work item - verb-first title, acceptance criteria, file paths when known, an out-of-scope line. Files a GitHub issue in tickets mode or appends a numbered PLAN.md task in document mode; unknowns are marked TBD, never invented. Use when the user brain-dumps an idea, bug, or task to capture for later, or asks to ticket, file, or note something as work.

Backlog hygiene sweep - stale items, duplicate pairs, missing acceptance criteria, unblocked-but-unassigned work, and milestone burn, delivered as a report first with only user-approved actions applied. Works on GitHub Issues in tickets mode and on PLAN.md checkboxes in document mode. Use when the user asks to triage, groom, or clean up the backlog or the plan's open tasks.

Audit a completion claim made by someone else - another session, agent, or teammate - against the running system rather than the diff. Re-derives what the claim's acceptance demands, runs it, and returns CONFIRMED, OVERSTATED, FALSE or UNVERIFIABLE with the command and its output. Never fixes, never edits the claim or the acceptance. Use when handed a "done", "all green", "merged" or "it works" you did not produce yourself.

Decision archaeology - answers why the code, config, or plan is the way it is by searching the record in a fixed order: BRIEF constraints, dated PLAN decisions, JOURNAL entries, then git history. Stops at the first real answer, cites it with a date, and says no recorded rationale rather than inventing one. Use when someone asks why something is this way, why a choice was made, or where a decision is written down.