0xdeafcafe
UserSixteen Claude Code skills for the parts of shipping I'd rather not do myself: ADRs, specs, audits, PR composition, review iteration.
Categories
Indexed Skills (12)
drive-code
Use when the user says "drive the code", "/drive-code", "clean up the code in this PR", "make sure the touched files follow best practices", or asks Claude to do a code-quality pass on the files a PR (or working tree) touches. Evaluates each touched file for single-responsibility, modularity, service/repository pattern compliance, utility placement, naming, length, and runs the project's linter + formatter. Applies mechanical fixes automatically; proposes (with diff) any structural refactor before changing it. Does NOT verify the feature's behaviour (use /drive-feature) or its UX (use /drive-ux).
drive-feature
Use when the user says "drive the feature", "/drive-feature", "audit the feature logic", "is this feature complete", "check edge cases", or asks Claude to verify that a feature (typically the one in the current PR) is well built end-to-end. Reads any ADRs and specs that exist for the feature, traces the data flow from entry to exit, and checks edge cases, error handling, loading states, and side effects against the spec. Does NOT pass judgment on code style (use /drive-code) or click through the UX (use /drive-ux) - focuses on logic and completeness.
drive-pr
Use when the user says "drive this PR", "/drive-pr", asks to resolve all PR comments, get a PR green, address review feedback, or otherwise wants Claude to iterate on an open pull request until every trusted comment is resolved, CI is passing, and the PR description matches the code. Operates only on the current branch's PR or an explicitly passed PR number/URL.
drive-security
Use when the user says "drive the security", "/drive-security", "security review", "is this safe", "check for vulnerabilities", or asks Claude to do a security-focused audit of the files a PR (or working tree) touches. Audits authn/authz on touched routes, scans for hardcoded secrets, checks input validation and output encoding at trust boundaries, runs dependency-vulnerability tools (npm audit / pip-audit / cargo audit / govulncheck) where available, and flags OWASP-top-10 smells. Applies safe mechanical fixes inline; surfaces judgment calls. Companion to /drive-code (code shape), /drive-feature (logic), /drive-test (tests).
drive-test
Use when the user says "drive the tests", "/drive-test", "review the tests", "are the tests any good", "check test coverage", or asks Claude to audit test quality across the files a PR (or working tree) touches. Evaluates each touched file's tests for level (unit vs integration vs e2e), assertion quality, mock health, coverage of new code paths, and the classic smells (mocking the unit under test, snapshot churn, tests-that-can't-fail, etc.). Runs the test suite to confirm green, fixes mechanical issues, surfaces judgment calls. Companion to /drive-code (which checks code shape) and /drive-feature (which checks logic).
drive-ux
Use when the user says "drive the UX", "/drive-ux", "walk through the feature", "check the UX", "test the flow in a browser", or asks Claude to launch the app and click around to verify a feature's UX. Drives the application in a real browser (via the chrome-devtools MCP if available, otherwise Playwright), exercises the golden path and edge cases for the feature in the current PR, captures screenshots, and audits against UX best practices. Does NOT do code-quality checks (use /drive-code) or feature-logic audits (use /drive-feature).
plan-feature
Use when the user says "plan a feature", "/plan-feature", "let's discuss this feature", "let's design X", "kick off feature Y", or wants Claude to drive a discussion that produces both an ADR (architecture decision record) and a Gherkin spec (.feature file) for a feature about to be built. Discovers the repo's ADR and specs conventions, holds an interactive discussion to extract scope + architecture + scenarios + edge cases, then writes both files cross-linked together. Composes /write-adr and /write-spec into the natural "I'm starting something" entry point.
review-spec
Use when the user says "review this spec", "/review-spec", "check for overlap", "is this spec consistent with our ADRs", or asks to validate a new Gherkin spec or ADR against the existing corpus before it lands. Searches all .feature files and ADRs in the repo, flags duplicate scenarios, conflicting decisions, overlapping feature areas, missing ADR cross-links, and contradictions with the base architecture. Read-only - produces a report, never modifies files.
tone-of-voice
Use when writing prose that will go out under Alex Forbes-Reed's name - blog posts, marketing copy, launch announcements, release notes, PR descriptions, internal slack messages, customer emails, X/LinkedIn posts, conference abstracts, anything ghost-written. Triggers on "write a blog post", "draft this for me", "in my voice", "polish this", "make this sound like me", "rewrite as me", "/tone-of-voice", or any explicit request to produce text Alex will publish. Does NOT apply to Claude's own conversational replies, code comments, neutral technical docs, or PR comments Claude posts as itself.
write-adr
Use when the user says "write an ADR", "/write-adr", "let's document this decision", "add an architecture decision record", or asks to capture a design/architecture decision in writing. Discovers the repo's existing ADR convention (location, numbering, format), discusses the decision interactively to draw out the context, alternatives, and consequences, then writes the ADR file matching the local style. Standalone counterpart to /plan-feature, which writes an ADR + a Gherkin spec together.
write-pr
Use when the user says "open a PR", "/write-pr", "draft a PR", "create the PR", "write a PR description", or wants Claude to compose a pull request from the current branch and open it on GitHub. Drafts the title and body from commits + diffstat + linked ADR/spec/ticket, runs the repo's pre-push checks (tests, lint, type-check, build), shows the user the proposed PR for confirmation, then pushes and creates via `gh pr create`. Bookend to /drive-pr - write-pr opens, drive-pr iterates.
write-spec
Use when the user says "write a spec", "/write-spec", "add a feature file", "write a Gherkin spec", "specs for this feature", or asks to capture a feature's behaviour as a Gherkin .feature file (Cucumber/SpecFlow/Behave/pytest-bdd style). Discovers the repo's existing specs folder and conventions, discusses the feature interactively to extract scenarios (golden path, edges, errors), then writes the .feature file matching local style. Pulls context from a related ADR if one exists. Standalone counterpart to /plan-feature, which writes ADR + spec together.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.