Shipshitdev Skills

File a GitHub issue of type Bug from a description — structures a clear bug report (summary, steps to reproduce, expected vs actual, environment), previews it, then on confirmation creates the issue with the Bug issue type (falling back to a bug label when the repo has no issue types). Use when the user asks to file a bug, open a bug report, create a GitHub bug issue, log a bug, or runs /bug.

Walk through how a subsystem works. Use for "how does X work", code walkthroughs before changing something, and placement or ownership questions. Explains architecture, runtime flow, and onboarding mental models. Can critique architecture. Use why for motivation.

Discover and document a product's Ideal Customer Profile as a durable .agents/memory/icp.md — segments ranked by revenue potential, each with acute pain, willingness-to-pay, buying trigger, and churn reasons. Use when a user says "define our ICP", "who is our customer", "who are we selling to", "document our ideal customer", or before roadmap-analyzer / roadmap-to-milestones need a customer to prioritize against.

Test-driven development workflow for feature work and bug fixes. Use when the user asks for TDD, red-green-refactor, test-first implementation, regression-first bug fixes, or vertical-slice delivery. For bugs, require a cheap local test path; skip a new test when the path is unclear, expensive, or integration-heavy.

Investigate why code is shaped the way it is. Use for design rationale, regressions, postmortems, or data-backed thresholds. Queries available evidence categories in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.

Creates clear, concise technical documentation for software projects, runbooks, and developer guides. Use when writing or updating a README, guide, runbook, API reference, setup instructions, or troubleshooting notes.

Spawn N parallel candidates at the same task, pick a base, and graft the strongest parts of the losers into it. Use for arena this, throw it in the arena, or when one attempt at a non-trivial artifact would lock in the wrong shape.

Sweeps implemented frontend code across five dimensions at once — accessibility, performance, theming, responsive design, and anti-patterns — scoring each 0-4 and emitting a single P0-P3 report with a prioritized plan. Reports only; it changes no code. Reach for it as the broad first pass when no one dimension has been named. For a deep WCAG conformance pass, use `accessibility`; for design-token drift, use `design-consistency-auditor`.

Front door for a freshly reported failure: build a deterministic feedback loop, reproduce the symptom, rank falsifiable hypotheses, and instrument the narrowest point that separates them. Carries the lookup library — 54 rules across 10 categories covering observation technique, common bug patterns, and triage priority. Use on first contact with a bug, crash, wrong output, or performance regression before any fix has been attempted, and to look up a debugging technique or bug pattern by name. Hands off to `systematic-debugging` when a fix attempt has already failed or the cause survives the loop.

Plan the UX and UI for a feature before writing code. Produces a design brief that guides implementation.

Fan out N parallel workers, drain them, and return one report. Use for swarm this, or parallel coverage, races, gauntlets, and exploration partitions.

Explain a body of work so a person actually understands it. Runs how and why and weaves what they find into one plain explanation, built up diagram by diagram. Use for teach me this, help me really understand X, or explain this change or subsystem.

Run deployment workflows for web applications (staging, production). Use when user says 'deploy', 'push to staging', 'release', 'ship it', or 'go live'.

Strip AI-generated slop from a codebase, product, and prose. Code slop — console statements, `any` types, unused imports, commented-out code, redundant comments, needless defensive try-catch on trusted paths, over-nesting. Product slop (with --product) — marketing-filler copy, generic AI phrasing, default-shadcn look, unstyled loading/error states, dead buttons and half-wired flows. UI slop (`ui`) runs a project-derived design-system primitive pass. Prose slop (`prose`) cuts AI tells from writing. Can scope to the current branch's diff or sweep the whole tree. Use when asked to clean up AI-generated code, unslop writing, remove slop, or make an app feel finished before shipping to customers.

Reworks the structure underneath a UI — spacing scale, visual hierarchy, grid and composition, rhythm, and density — turning monotonous or crowded arrangements into intentional ones. Applies while the composition itself is still wrong, ahead of any detail pass. Use when the user says the layout feels off, every section looks the same, the UI is crowded or too sparse, hierarchy is unclear, or nothing guides the eye. For the last-mile pass on a finished feature, use `polish`.

Runs the last pass over a functionally complete feature — pixel alignment, interaction and loading states, empty and error states, copy consistency, transition smoothness, and micro-details measured against the design system. Requires the work to be finished first; it refines, it never restructures. Use when the user asks for polish, finishing touches, a pre-launch review, or wants to go from good to great. To fix the underlying composition instead, use `layout`.

Playbook orchestrator for verified, unslopped engineering work. Matches a task to a named playbook, applies the principles index, and routes to how, why, architect, arena, swarm, interrogate, tdd, and related skills. Use for pstack, poteto-mode, /pstack, or requests to work in this style.

Rebuild recent working context from chat history, live state, and the shared record, then hand back a tight current-state brief. Use for recall my work on X, catch me up, what have I been working on, or where did I leave off.

Provides shadcn/ui component library best practices and patterns. Triggers when writing, reviewing, or refactoring shadcn/ui components; when working with Radix primitives, Tailwind styling, React Hook Form validation, data tables, theming, or component composition patterns.

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover.

Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.

Runs an interactive localhost QA session that accepts issues, screenshots, routes, and browser evidence; watches app, API, browser, and network errors; reproduces and fixes each defect; verifies the result; and creates one local commit per fix. Use when asked to start QA, QA a local app, fix localhost issues as they arrive, or work through screenshot feedback without leaving the current checkout.

Tones down visually aggressive or overstimulating designs, reducing intensity while preserving quality. Use when the user mentions too bold, too loud, overwhelming, aggressive, garish, or wants a calmer, more refined aesthetic.

Cuts the release itself — derives the next semantic version from commits since the last tag, writes plain-English patch notes, previews the plan, then on confirmation creates an annotated tag plus GitHub release, or dispatches the repo's guarded release workflow where production sits behind a workflow_dispatch promote gate. Trunk-based; no develop or staging branch promotion. Assumes the trunk is already green — to open a release PR or wait on required checks first, use `release-pr-gates`.

Summarize what you personally shipped over a time window from git history — an engineer standup or weekly recap, not a customer changelog. Scopes commits to your git author identity, reads the diffs, and classifies each as a feature, fix, refactor, tech-debt, or docs change. Use when the user asks what did I get done, write my standup, what did I ship this week, weekly recap, or runs /standup.

Evaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, automated anti-pattern detection, and actionable feedback. Use when the user asks to review, critique, evaluate, or give feedback on a design or component.

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, asks to be grilled, or another skill needs the interview primitive.

Generate incremental local code modules following existing codebase patterns. Use for endpoints, components, packages, collections, or modules inside an existing repo; not for full project scaffolds.

Provides Tailwind CSS v4 performance optimization and best practices guidelines. Triggers when writing, reviewing, or refactoring Tailwind CSS v4 code; when working with Tailwind configuration, @theme directive, utility classes, responsive design, dark mode, container queries, or CSS generation optimization.

Create an isolated git worktree from the correct base branch and check it out into a clean, gitignored directory. Use when the user asks to make a worktree, spin up a parallel/isolated workspace, work on something without disturbing the current checkout, branch off the current work, or run multiple agents on the same repo at once. Picks the base branch smartly — the current feature branch when you are on one, otherwise the repository's default/trunk branch — so worktrees continue your in-progress work by default instead of forking from the wrong place.

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for architect this, design this, or non-trivial work where jumping to code would lock in the wrong shape.

Discover the environment variables a codebase actually reads, generate or update a grouped .env.example template, validate that required variables are set, and keep secrets out of git. Use when setting up environment variables for a project, scaffolding .env templates, validating an existing .env file, documenting required configuration, or checking that .gitignore covers env files. Backs the /env command.

Repo-grounded discovery interview that produces a handoff brief for PRD writing, feature intake, or planning.

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Inventories a real codebase and ranks its technical debt into a register scored by interest (how often it hurts) over principal (effort to fix), every item anchored to a file-and-line or a metric. Covers code smells, dependency debt, test gaps, and architectural churn hotspots across frontend and backend. Use when asked what to pay down, where the codebase is rotting, or to turn debt into a tracked backlog. Files the register as GitHub issues on request. For org-level technology strategy and architecture direction, use `cto-advisor`.

Turborepo monorepo build system guidance. Triggers on: `turbo.json`, task pipelines, `dependsOn`, caching, remote cache, the `turbo` CLI, `--filter`, `--affected`, CI optimization, environment variables, internal packages, monorepo structure, and package boundaries. Use when the user configures tasks or workflows, creates packages, sets up a monorepo, shares code between apps, runs changed packages, debugs cache behavior, or works in an `apps/` plus `packages/` workspace.

Re-pitch the last message in plain English using the project's CONTEXT.md vocabulary.

Reconciles a project board with current work and delivery evidence, reports incomplete coverage and metadata gaps, and applies only approved provider-supported field changes. Use when auditing board drift, reviewing blocked work, or assessing upcoming delivery.

Build evaluation frameworks for agent systems. Use when testing agent performance, validating context engineering choices, or measuring improvements over time.

Guards day-to-day git work in an existing repository: blocks secrets from entering a commit, gates destructive git operations before they run, installs ignore rules and pre-commit hooks, and drives the rotate-first response when a credential has already leaked.

Apply opinionated styling to barebones HTML. Use when user has plain/unstyled HTML and wants to apply consistent visual styling. Triggers: style this HTML, apply styling, make this look good, /html-style, or when user shares HTML that needs CSS. Transforms tables, lists, status indicators, buttons, and layouts into a cohesive design system.

Authors the PRD document itself — problem, scope boundaries, EARS acceptance criteria, and verification plan — as one self-contained contract a planning agent consumes without re-elicitation. Ends at the written PRD; slicing it into tracked issues is `prd-task-creator`.

Generates minimal HTML pages to review structured data in a browser with maximum readability. Triggers on: "show me", "view this", "make reviewable", "open as webpage", or any request to review lists, tables, drafts, or summaries that are hard to read in the terminal.

Enforces a spec → plan → execute → verify loop before writing code, preventing "looks right" failures. Activates on "build X", "implement...", "add a feature that...", or any multi-file/unclear-requirements request. Creates spec.md, todo.md, and decisions.md as durable artifacts.

Correctness, security, and spec-fidelity gate for incoming pull requests. Auto-invoked when reviewing a diff, evaluating a PR, running /code-review at any effort level, or asked "is this safe to merge?" Covers bugs, TypeScript hygiene, security, database safety, test existence, devex regressions, feature-flag leaks, and whether the diff matches the originating issue/spec. Multi-PR report-only review routes through review-dispatch; non-serial queue draining is exposed only through exact /merge force.

Advises engineering leadership on direction — architecture decisions recorded as ADRs, technology and vendor evaluation, team scaling ratios, and DORA/engineering-metric targets. Reasons from org-level indicators and frameworks, never from a repository scan. Use when the user asks which technology to adopt, how to structure or scale the engineering team, whether to write an ADR, what DORA targets to hold, or mentions CTO, technical leadership, technology strategy, vendor selection, or engineering metrics. To inventory and rank the debt already sitting in a codebase, use `tech-debt`.

Verifies immutable branch history against trunk before planning or removing merged branches and worktrees. Defaults to a read-only cleanup plan.

Independent second-opinion code review through the Grok CLI. Builds a self-contained review prompt from the exact diff, runs one headless Grok invocation on the CLI's own default model and effort, then verifies every returned finding against the code before reporting. Use when asked to review with Grok, get a second opinion on a branch, worktree, or PR from another CLI, or cross-check a review with an independent engine.

Adversarial multi-reviewer pass over a diff. Use for interrogate, adversarial review, multi-model review, challenge this, stress test this code, find blind spots, or tear this apart. Several independent reviewers challenge the change. The lead synthesizes a verdict and does not auto-apply fixes.

Creates MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Activates on: "build an MCP server", "create MCP tools", "integrate API via MCP", "write a FastMCP server", "add an MCP server to an agent", or any request to wrap an external API as LLM-callable tools in Python or Node/TypeScript.

Review comments on a diff, delete narration and workaround sermons, fix accepted findings, and offer encodings for claimed constraints. Use before review or when asked to strip comments.

Reads a pull request's review threads and returns a digest — grouped by thread, severity-tagged, priority-ordered, with the open questions called out. Strictly read-only: no code edits, no replies, no thread resolution. Reach for it to triage feedback before deciding what to fix; implementing those fixes is `github-address-comments`.

Runs a structured multi-phase verification pass on completed AI agent work — catching bugs, missed requirements, and incorrect assumptions before changes are committed. Triggers on: "check your work", "review this", after complex multi-step implementations, before committing major refactors, or proactively after any task longer than five steps.

Search local, marketplace, repository, package, GitHub, and web sources before creating a new skill or custom implementation. Use when asked to create, fork, import, or evaluate a skill, or before writing code for functionality that likely already exists.

Run a project's tests at the right scope — changed-only, focused, full, type-check, or e2e — then report failures with evidence. Repair and rerun only when fixing failures is explicitly authorized. Detects the test runner in a Bun-managed repo. Use when the user asks to run tests, run the suite, run smoke/e2e tests, type-check, check the build compiles, fix failing tests, or runs /test run.

Design tools that agents can use effectively, including when to reduce tool complexity. Use when creating, optimizing, or reducing the set of tools available to an agent.

Ask which Dev Loop skill or flow fits the current situation. A router over the flagship idea-to-ship path.

Find what a small-looking change could break somewhere else, and prove the one fact it is safe because of by running real code. Use for blast radius of X, what could this break, or reviewing a small diff you do not trust.

Granular feedback on drafts without rewriting. Generates highlighted HTML with click-to-reveal inline comments. Use when user says "comment on this", "leave comments on", "give feedback on", or asks for feedback on a draft. Supports multiple lenses—editor feedback, POV simulation ("as brian would react"), or focused angles ("word choice only", "weak arguments"). A granular alternative to rewrites that lets users review feedback incrementally without losing their voice.

Collect and triage a GitHub work inbox from assigned issues, review requests, mentions, authored PRs with failing checks, and optional project filters. Use when checking what needs attention across GitHub or prioritizing GitHub tasks.