dotfiles

XP-style plan review that identifies gaps, hidden assumptions, and critical misses. Triggers on 'review the plan', 'check the plan', 'audit the plan'. Reviews plans for YAGNI violations, missing feedback loops, and over-engineering.

Comprehensive code review for quality, security, performance. Triggers on 'review code', 'code review', 'check this PR', 'audit code'.

TDD Production Code Refactoring Process. Triggers on 'tidy up', 'tidy this', 'clean up code'. Use for refactoring production code with test coverage.

Systematically explore an unfamiliar codebase and build a reusable architecture summary. Use for repo onboarding, understanding legacy or inherited code, mapping architecture before a migration or refactor, tracing a bug or feature path, or answering "what does this project do?". Documentation-first, then data flow — ends in a concise technical architecture summary with file:line evidence, not a raw file dump.

Compile deep repository evidence into artifact-bound correctness doctrine — authority/law/proof maps, owned invariants, failure archaeology, and the strongest durable destination for each piece of knowledge, plus an optional minimal repository-specific skill portfolio. Use when the user wants both deep codebase understanding AND durable doctrine, knowledge routing, or repo-specific skill recommendations. Research discoverable facts before asking. Read-only. Not for quick onboarding, one isolated invariant, ordinary implementation, generic review, or direct skill creation.

Run a targeted fresh-eyes blunder pass over code, specs, plans, reviews, closure gates, or skill edits. Use when asked to reread with fresh eyes, find obvious bugs, catch mistakes/oversights/omissions, check for embarrassing misses, or do a second independent pass before closure. Use it as the final falsification/check pass for another workflow, not as a substitute for implementation or verification.

Mine a codebase for breakthrough, evidence-backed opportunities — features, additions, refactors, simplifications, DX, UX, reliability, performance, or architecture cleanup. Researches project reality first, then forces two escalation gates (reject the merely-adequate idea; expand ambition 10x then collapse to the smallest proof-bearing artifact). Outputs ranked opportunities, an escalation ledger, and one plan seed. Does not implement or create tickets.

Audit over-engineered codebases by factoring layers into live obligations, quotienting redundant distinctions, ablating unearned surface, and normalizing survivors while preserving required behavior. Use when change latency or agent difficulty comes from frameworks, plugins, DI, codegen, task runners, config indirection, ORMs, GraphQL, monorepo/infra tooling, or web stacks, or when asked to remove layers. Produces an evidence-backed Reduction Certificate, cuts, migration phases, proof signals, and rollback. Not for one local readability cleanup (use tw-complexity-mitigator).

Compress review pressure into the right next action instead of more code by default. Classify findings, reject non-liabilities, and choose proof-only vs minimal-fix vs refactor-kernel, preventing one-patch-per-comment churn. Use after a code review — PR comments, reviewer suggestions, or audit findings — and especially when you are about to reflexively patch every comment.

Use when adding a test to an existing codebase for behavior that is already implemented. Ensures the test is meaningful by mutation-verifying it — breaking the production code to confirm the test fails for the expected reason. Triggers when the user says "add a test for existing behavior", "backfill test coverage", "the test passes on first run", or any scenario where a test is written without a corresponding new production change.

Use when implementing a new function, adding a feature, fixing a bug, refactoring with test coverage, or writing a new test. Enforces strict outside-in red-green-refactor TDD with one-failure-per-turn discipline, predict-the-failure-before-every-run checks, hardcode-first minimum changes, triangulation, and property-based testing for large input spaces. Triggers on explicit TDD requests and on any task phrased as "implement", "add", "write a function", "build a feature", or "fix a bug" in a test-capable codebase. Reports red/green validation evidence.

Commit the current changes with quality checks, status review, staged diff inspection, appropriate tests, and a clear commit message. Use when the user says "commit", "c", asks to make a commit, or wants changes saved in git.

Perform comprehensive exploratory testing on a website using browser automation, covering user journeys, forms, errors, accessibility, responsiveness, performance, and security basics. Use when asked to QA a site, explore an app, find bugs, or produce a browser testing report.

Interview the user deeply about a plan, probing technical implementation, UI/UX, risks, tradeoffs, and missing decisions before writing or refining a spec. Use when the user says "interview me" or asks to be questioned about a plan.

Use when modifying, removing, or refactoring code that lacks test coverage. Emphasizes the danger of untested changes and the RGR workflow to add characterization tests before modifications.

Conduct a Marty-Cagan-style opportunity assessment interview and produce a ~2-page Opportunity Brief in Confluence. Covers business objective, customer, problem, success metric, current alternatives, assumptions/risks, and what we don't know yet. Triggers on "opportunity brief", "opportunity assessment", "discovery brief", "who is this for", "why are we building this", "validate this idea", "product discovery", or any request to frame a feature before implementation. One question at a time. Records accepted research gaps as structured Confluence Decision pages with bidirectional links.

Post-launch review of a shipped PRD against the brief's success metrics. Did we move the metric? What did the data actually show? Which assumptions held, which broke? Which accepted-gap decisions resolved (confirmed vs. invalidated)? What would we do differently? Triggers on "outcome review", "did it work", "post-launch review", "did we move the metric", "retro the feature", "was it worth it". Produces a Confluence outcome-review page and updates the brief + linked decisions.

Product-discovery coach for Fishbowl engineers — inspired by Marty Cagan's work (never impersonates him). Stage-routes between opportunity brief, research, PRD, ticket drafting, and outcome review. Triggers on "product coach", "help me with product", "I need to write a PRD", "I want to do discovery", "opportunity assessment", "who is this for", "why are we building this", or when an engineer is starting, resuming, or post-mortem-ing product-adjacent work. Invoke with a short description of what you want to do, or invoke bare to be surveyed and routed.

Refactor code to remove dead code, useless comments, unused variables, and unused imports. Use when asked to declutter a class, clean up noisy code, remove cruft, or run `/refactor:declutter`.

Refactor duplicated code by extracting helpers, shared abstractions, or clearer reusable structure. Use when asked to apply DRY, remove duplication, consolidate repeated logic, or run `/refactor:dry`.

Refactor Swift code toward declarative functional programming with immutability, value types, pure functions, transformations, and closure-based APIs. Use when asked for functional refactoring or `/refactor:functional`.

Refactor long methods or large code blocks by extracting small, focused helper methods with clear names and narrow responsibilities. Use when asked to extract methods or run `/refactor:methods`.

Refactor code by renaming variables, methods, classes, and concepts for clearer intent. Use when asked to improve names, clarify naming, perform a naming pass, or run `/refactor:names`.

Analyze a class or module for code smells and produce a prioritized refactoring plan. Use when the user asks for code smell analysis, says `/smells`, or runs `/refactor:smells`.

Refactor a class toward the Single Responsibility Principle by identifying responsibilities, grouping cohesive behavior, and extracting focused classes. Use when the user says `/srp`, asks for SRP refactoring, or runs `/refactor:srp`.

Refactor test files to improve behavioral coverage, clarity, structure, assertions, fixture setup, mocking strategy, and remove implementation-detail or low-value tests. Use when asked to clean up, declutter, consolidate, or improve tests.

Analyze code for primitive obsession and plan value object extractions around domain concepts, validation, and grouped primitive fields. Use when the user says `/value-objects`, asks for value object refactoring, or runs `/refactor:value-objects`.

Compile up to five durable insights from the current conversation for possible addition to CLAUDE.md. Use before clearing context, when asked to remember lessons, or when the user wants project conventions and preferences preserved.

Load Remotion best practices for React video creation, including animations, composition setup, assets, audio, captions, sequencing, transitions, media metadata, Three.js, Tailwind, and rendering patterns. Use when creating, editing, debugging, or reviewing Remotion code.

Brutally honest AGENTS.md/CLAUDE.md review backed by real A/B test evidence. Not just opinions — actual proof that your rules are dead weight. Roasts instruction files for bloat, slop, and redundancy, then proves it by running evals. Use when user says "roast my agents.md", "roast my CLAUDE.md", "prove my rules are useless", "eval roast", or wants entertaining evidence-based feedback on their AI config files. Also triggers on "audit my instructions" or "are my rules helping".

Save the latest learning as a numbered markdown file under ~/.claude/learnings and update the learnings index with title and tags. Use when the user says "save", asks to record a learning, or wants the current insight stored for later.

Apply Steven's Bash script style rules: strict mode, minimal validation, concise logic, executable scripts, and no unnecessary comments or echoes. Use when creating, reviewing, or refactoring shell scripts.

Break an application or feature into thin vertical user-story slices with clear acceptance criteria and user-observable value. Use when planning a backlog, decomposing a feature, writing implementation-ready stories, or turning requirements into deliverable slices.

Two-phase code quality skill: (1) review codebase for structural smells — file LOC, method LOC, accidental complexity, test readability — producing a structured report, then (2) fix all smells via provable refactorings with ACN micro commits and green-bar-at-all-times discipline. Use this skill when the user says 'sweep', 'code review', 'find code smells', 'check method lengths', 'review for complexity', 'tidy up the codebase', 'refactor smells', or asks about long methods, test readability, or accidental complexity. Also trigger when users ask to 'clean up' or 'improve code quality' across multiple files.

Acceptance-test newly added features using browser automation, happy-path flows, screenshots, UX notes, and a written report. Use when asked to test a feature, verify a recent UI change, or check whether an app workflow works.

Create a language-agnostic ghost package (spec + portable tests) from an existing repo by extracting SPEC.md, exhaustive tests.yaml (operations and/or scenarios), INSTALL.md, README.md, VERIFY.md, and upstream LICENSE files with provenance and regeneration instructions. Use when prompts say "/tw-ghost", "ghostify this repo", "spec-ify/spec-package this library", "ghost library", or ask to extract portable spec/tests for libraries or tool-using agent loops (scenario testing); do not use for implementation work or editing skills.

Comprehensive, measurement-driven performance optimization for latency, throughput, memory/GC, and tail behavior. Use when the user asks to optimize/speed up, reduce latency (p95/p99), increase throughput/QPS, lower CPU/memory/allocations/GC pauses, profile hot paths, or run a benchmarked perf pass (including JSONL/query-heavy code). Requires before/after measurement on a runnable workload (or an explicit `UNMEASURED` plan) plus a correctness gate.

Analyze a local codebase and infer the architecture it is actually using, including repo kind, best-fit dominant architecture, directly evidenced coexisting patterns, major subsystem exceptions, confidence, docs-vs-code drift, and repo-fit hints for downstream agents. Use when prompts ask what architecture a repo uses, whether it is really hexagonal or just layered, what subtle patterns shape a repo or slice, how a target slice fits a hybrid monorepo, whether documented architecture matches implementation, or when `/tw-tk` needs a repo-dialect preflight before making a minimal change.

Set up and manage a UI redesign experiment with three git worktree branches for modern minimal, bold creative, and classic refined design directions. Use when asked to run a UI redesign experiment, compare design approaches, or prototype multiple visual directions in parallel branches.

Mutation testing patterns for verifying test effectiveness. Use when analyzing branch code to find weak or missing tests.