Claude Skills by tmj-90

Fixture quality lens — deliver the smallest correct change.

Fixture stack skill — build a React component.

Fixture language skill — follow the repo's TypeScript conventions.

Internal skill for onboard's file-card emission pass. Defines how to write one file card from a mechanical structure summary (imports, top-level symbols) plus an optional bounded head snippet — NEVER the whole file. Drives the per-file (or batched) model turn in onboard-analyze.mjs with a versioned prompt_version hash. Not for the ticket delivery flow.

Internal skill for onboard's semantic review gate. After the deterministic validation gate (which catches invented symbols / hash drift / secrets), this skill drives a sampled `claude -p` pass that checks whether the TLDR and role are DIRECTIONALLY ACCURATE given the file's structure and head snippet. The deterministic gate is the FLOOR; this skill is the ceiling check for plausible- but-wrong summaries (e.g. "handles auth middleware" when the file only renders auth *errors*). Used by onboard...

Use this skill when the user types `/memory-onboard` (or asks "set up memory for this repo" / "onboard this repo to memory" / "what should be in lore for this repo?"). It runs a repo-aware onboarding interview that produces DRAFT lore records grounded in concrete repo signals (README, ADRs, recent commits, deprecation markers, in-flight migrations). Requires the memory-mcp MCP server to be configured. Uses these MCP tools: search_lore / get_lore / suggest_lore (core), and optionally report_co...

Use when a ticket asks to add or extend an HTTP/API endpoint — a new route, handler, or RPC method — with request validation and a defined response. Invoke for "add a POST /things endpoint", "expose a list API", or "add a field to the X response".

Use when a ticket requires a database schema change — a new table/column, an index, a constraint, or a backfill. Invoke for "add a migration for X", "alter the schema", or any change to the persisted data model. Schema changes are high-risk; treat them carefully.

Use when a ticket asks for integration or end-to-end coverage across components — an API route hitting a database, a service-to-service call, a multi-step flow — rather than a single unit. Invoke for "test the endpoint end to end", "cover the checkout flow", or "verify the migration + query together".

Use when a ticket asks for new unit tests, or when an acceptance criterion requires test coverage for a function/module/component and none exists. Invoke for "add tests for X", "cover the Y edge case", or raising coverage on a specific unit.

Use when you want a genuinely critical review of recent changes — before merging a PR, after a sprint, or when you suspect the review is being too agreeable. Forces perspective shifts through three hostile reviewer personas that catch blind spots the author's mental model shares with the reviewer. Triggers on "adversarial review", "break my code", "what could go wrong", "devil's advocate review", or "pre-merge review".

Use when optimising content to be cited by AI language models (ChatGPT, Perplexity, Claude, Gemini) as an authoritative source — distinct from SEO. Triggers on "AEO audit", "optimize for ChatGPT", "get cited by Perplexity", "LLM citation strategy", "answer engine optimization", "content for AI search", or "E-E-A-T audit". For click-through SEO, use `seo-audit`. For structured data, use `schema-markup`.

Use when reviewing a PR that adds or changes API endpoints, auditing an existing API for v2 migration, or establishing REST API standards. Triggers on "API review", "REST design review", "breaking change check", "OpenAPI audit", "endpoint review", or "API consistency".

Use when a ticket asks for backend business logic that isn't itself an endpoint or a migration — a service/use-case, a domain operation, a background job, or orchestration across repositories. Invoke for "add a service to do X", "implement the use-case", or "extract the business logic out of the handler".

Use as an INDEPENDENT tester agent to test another agent's `in_testing` ticket from the OUTSIDE — never your own, and never from the implementation diff. You test from the operational test contract + acceptance criteria only (never HOW it was built), writing automated tests that invoke the changed surfaces and recording a PASS/FAIL verdict via the scoped Dispatch MCP. The testing analog of the review gate — catches "the implementation passes its own tests but doesn't satisfy the acceptance cr...

Use to establish or audit a product's brand so the factory's output looks intentional, not template — when a ticket asks to "create a brand", "define the design system / visual identity / palette / typography", or when delivered UI looks generic and needs a deliberate direction. Detects existing brand and extends it in its own idiom, or commits to one specific direction (palette, type pairing, voice) and writes a BRAND.md. Invoke whenever the factory needs a design foundation before building UI.

Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when the user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Adapted from Matt Pocock's caveman skill (MIT — https://github.com/mattpocock/skills).

Use when producing release notes from Conventional Commits, computing the next semantic version from a commit stream, generating CHANGELOG.md, or automating release notes in CI. Triggers on "generate the changelog", "what version bump do these commits require", "release notes", "CHANGELOG", or "semantic version".

Use when setting up CI for a new project, refactoring existing pipelines, migrating between platforms, or standardising deployment workflows. Triggers on "set up CI/CD", "GitHub Actions", "GitLab CI", "pipeline for this repo", "deployment workflow", or "why is CI slow".

Use to turn a vague, under-specified draft ticket into well-specified, agent-deliverable work — before any code is written — or to onboard a repo by establishing baseline context. Reads the ticket and Memory, finds the load-bearing ambiguities (the ones whose answer would change the implementation, scope, or acceptance), asks the human only those, and converts each answer into a durable acceptance criterion. Invoke whenever a ticket is ambiguous enough that delivering it now risks the wrong P...

Use when assessing cloud infrastructure for security misconfigurations, IAM privilege-escalation paths, S3 public exposure, open security-group rules, or IaC security gaps. Covers AWS, Azure, and GCP posture. For active cloud compromise, use `incident-response`. For behavioural anomalies, use `threat-detection`.

Use when asked to create a code walkthrough, onboarding tour, architecture tour, PR review tour, or any structured explanation of how a codebase works. Triggers on "create a code tour", "onboarding tour", "how does X work", "explain the codebase", "architecture walkthrough", "PR tour", or "contributor guide". Outputs a CodeTour `.tour` JSON file for the VS Code CodeTour extension, with a plain-markdown fallback for environments without it.

Use when asked to write, rewrite, or improve marketing copy for any page — homepage, landing page, pricing, feature page, about page, or product page. Triggers on "write copy for", "improve this copy", "rewrite this page", "marketing copy", "headline help", or "CTA copy". For full page generation with structure and code, use `landing-page-generator`.

Use at the start of work on any claimed Dispatch ticket, before editing files, to create the working branch with the required prefix. Invoke whenever a ticket needs code changes and you are not yet on a non-protected feature branch.

Use when designing new database tables from requirements, reviewing a schema for normalisation or performance issues, adding multi-tenancy, planning a breaking migration, or generating TypeScript/Python types from a schema. Triggers on "design the schema", "ERD", "table relationships", "schema migration", "normalise this", or "database model".

Use when a ticket needs a *systematic* token + component foundation for a frontend — the three-layer token architecture (primitive → semantic → component), component specs with full state coverage, or a recommendation for which design system a product should have. Invoke for "set up design tokens", "define the component system", "we keep hardcoding colours — fix it", "what design system should this product use", or as the structural backbone that `frontend-design` and `brand` build distinctiv...

Use when optimising a Dockerfile, creating or improving docker-compose configurations, implementing multi-stage builds, auditing container security, or reducing image size. Triggers on "Dockerfile", "docker-compose", "container", "image size", "build cache", or "Docker best practices".

Use on every code delivery to hold the structural-quality bar — reusability where repetition is real, clear boundaries, explicit error handling, focused units, honest names, and tests for real logic. Invoke whenever you implement a claimed ticket and want the change to read like production code the repo's maintainers would approve, not a quick hack that merely passes. A cross-cutting lens that composes with `minimalism` (least code) and whatever build skill the ticket needs. For "make this re...

Use when a ticket reports an intermittently failing test — passes sometimes, fails others, or fails in CI but not locally. Invoke for "this test is flaky", "fix the intermittent failure in X", or "the suite is non-deterministic". Fix the root cause, never paper over it with a retry.

Use when a ticket requires accessibility work or when delivering UI that must be usable by everyone — keyboard navigation, screen-reader labelling, focus management, colour contrast, or reduced-motion support. Invoke for "make X accessible", "fix the a11y issues", "add keyboard support", or as a companion check on any new component.

Use when a ticket asks to add or change a UI component — a new widget, a reusable element, a page section, or a state/variant of one — in a frontend stack. Invoke for "add a Card component", "build the settings panel", or "add a loading state to X". Match the repo's component conventions; do not introduce a new UI framework.

Use when a ticket builds or reworks a user-facing frontend surface — a hero, landing page, dashboard, marketing section, or any screen where the *visual quality* matters, not just the markup. Produces distinctive, intentional, production-grade UI that avoids generic template aesthetics. Invoke for "build the landing page", "make this look premium / less templatey", "design the X section", or as the design pack for any high-visibility frontend work.

Use on any frontend delivery to hold the surface-specific quality floor that `engineering-craft` doesn't cover — intentional visual hierarchy over template defaults, accessible-by-default markup, design tokens instead of hardcoded values, reusable components matching the repo, and compositor-friendly motion. Invoke whenever the change touches UI (a component, screen, page, or style), as the always-on companion to the deeper `frontend-design`, `frontend-component`, `frontend-a11y`, and `fronte...

Use when a ticket requires a layout to work across screen sizes — mobile/tablet/desktop, fluid typography, breakpoint behaviour, or fixing overflow and touch-target issues. Invoke for "make X responsive", "fix the mobile layout", "support tablet", or when adding any layout that must adapt.

Use when a ticket adds or changes Go code and it must follow the repo's Go conventions — idiomatic Go, explicit error handling and wrapping, small interfaces, correct pointer-receiver rules, and table-driven tests run with the race detector. Invoke for "add this in Go", "fix the go vet/build issues", "add the handler/service", or as the language pack for any Go change.

Use when a production incident has been declared and needs classification, triage, escalation, and post-mortem. Covers SEV1-SEV4 severity, false-positive filtering, NIST SP 800-61 lifecycle, and blameless post-mortem facilitation. For proactive threat hunting before an incident fires, use `threat-detection`. For cloud misconfigs, use `cloud-security`.

Use when a ticket adds or changes Java code and it must follow the repo's Java conventions — modern Java (records, sealed types, pattern matching, switch expressions), Optional discipline, immutability, Spring Boot constructor injection, and JUnit 5 + Mockito tests. Invoke for "add this in Java", "fix the Java build", "add a Spring endpoint/service", or as the language pack for any Java change.

Use when building a Kubernetes Operator — custom controllers that reconcile CRD state. Triggers on "build an operator", "CRD design", "reconcile loop", "controller-runtime", "kubebuilder", "operator-sdk", "custom resource", or "operator capability levels". NOT a generic k8s skill — specifically the Operator pattern.

Use when asked to create a landing page, marketing page, homepage, lead-capture page, campaign page, or conversion-optimised web page. Outputs complete Next.js/React (TSX) + Tailwind CSS components with proven copy frameworks (PAS/AIDA/BAB), SEO meta tags, and Core Web Vitals targets. Triggers on "create a landing page", "marketing page", "homepage", "lead gen page", or "conversion page".

Use when converting long-form markdown (specs, RFCs, reports, plans, explainers) into a readable, well-structured single-file HTML document with sticky TOC, search, and code-copy. Triggers on "convert this spec to HTML", "markdown to doc", "make this RFC readable", "publish this as a document", or "md to HTML". For slide decks, use `slides-deck`. Input must be ≥ 100 lines to warrant HTML rendering.

Use to deliver the simplest, shortest solution that fully satisfies the ticket — fewer tokens and less code per delivery, without ever weakening a safety guard. Invoke whenever you are about to implement a claimed ticket and want to resist over-engineering, or for "keep it minimal", "don't over-build this", "smallest change that works". A cross-cutting lens that composes with any implementation skill; supports intensity lite | full | ultra (default full).

Use when a ticket builds or reworks UI in a React Native / Expo (or React + Capacitor) mobile app and it must feel like a real, store-credible native app — not a wrapped mobile website. Covers the native-feel bar, safe-area/gesture/haptics, store-readiness, and mobile performance. Invoke for "make this screen feel native", "build the mobile X screen", "this feels like a website", "would this get approved", or as the mobile pack for any app-UI change.

Use when adding observability to a new service, refactoring noisy alerting, or designing a monitoring strategy. Covers the three pillars (metrics/logs/traces), golden-signal dashboards, and alert-noise reduction. For SLO/error-budget math specifically, route to `slo-architect` instead.

Use when asked to optimise or improve conversions on a marketing page — homepage, landing page, pricing page, feature page. Triggers on "CRO", "conversion rate optimization", "this page isn't converting", "improve conversions", "why isn't this page working", or "increase sign-ups". For new page generation, use `landing-page-generator` instead.

Use to turn a one-line brief into a phased, dependency-ordered epic of small, well-specified, deliverable tickets — covering BOTH "build me an app that does X from scratch" (greenfield) and "change/extend/redesign an existing app X" (brownfield, when a target repo is supplied). Clarify genuine ambiguity first, draft concise requirements, then decompose into ordered phases. Invoke whenever someone describes an app or feature set to build from scratch, or an existing app to change/extend, and w...

Use after claiming a ticket and understanding it, before editing any files, to commit to a concrete change plan that keeps the work minimal and on-target. Restates each acceptance criterion as the exact files to touch, the edits to make, the test that will prove it, and what is explicitly out of scope — consulting memory so the plan respects existing conventions. Invoke whenever you are about to start implementing a claimed ticket and have not yet written down what you will change and how you...

Use when writing a Product Requirements Document — to define what to build and why, with evidence-gated drafting. Refuses to draft without a real problem, user, and metric. Triggers on "write a PRD", "product requirements", "spec for this feature", "what should we build for X", or "requirements document".

Use right after a ticket is implemented and evidenced — while you still hold the diff in context — to PREPARE the Repo Digest delta and the feature note as a recorded evidence row, so the merge step can apply them deterministically WITHOUT spending a fresh agent call. Invoke once your change is committed and its ACs are evidenced, as the last thing you do before you stop (the runner submits for review). It only PREPARES (records inert evidence); the merge APPLIES it post-review, so a rejected...

Use when validating product opportunities, mapping assumptions, planning discovery sprints, or testing problem-solution fit before committing delivery resources. Triggers on "product discovery", "validate this idea", "opportunity solution tree", "discovery sprint", "assumption mapping", or "de-risk this bet".

Use to propose the next product work for a repo — on an idle factory tick (nothing ready to deliver) or when a human asks "what should we build next", for product ideas, a backlog, or PO mode. Consults Memory for product direction, inspects the repo, and files 3–5 high-leverage, anti-slop candidates into the Dispatch backlog as draft tickets with real acceptance criteria. Invoke whenever the factory needs new work proposed rather than delivered.