Claude Skills by chrislacey89

Invoked helper skill for higher-risk API contract decisions, usually called from /research or /write-a-prd. Use when the unresolved question is API shape, compatibility, auth, webhook design, or paradigm choice. Not a default top-level workflow step or a substitute for ordinary implementation work.

Primary pipeline tail step after /pre-merge, when a reviewed PR is ready to land and you want the workspace back to a clean base. Use to merge, switch off the worktree before removing it, prune the merged branch, pull base, and verify a clean end state. Triggers on 'close out', 'merge and clean up', 'get back to a clean main/base', 'tear down the worktree'. Not for capturing lessons (that's /compound) or closing PRD/slice issues and research-artifact hygiene (that's the cleanup prose in SYSTE...

Primary pipeline knowledge-capture step that closes the compounding loop. Capture a durable lesson in docs/solutions/ onto the open PR before /closeout merges (the default), or post-merge when the lesson only surfaces during/after merge. Use so future /research and /write-a-prd runs improve. Not for trivial edits with no reusable project-level learning, and not for the merge/teardown itself (that's /closeout).

Side-route skill for explicit backtracking when an upstream artifact becomes untrustworthy. Use when research, PRD, or slice decomposition has been invalidated by new information and you need to clean up stale artifacts before re-running an earlier pipeline step. Not for forward progress, fresh shaping, or routine bug fixes.

Primary planning branch after /shape for major-tranche work that requires multiple independent PRDs. Use to create a GitHub milestone plus sequenced feature issues that will later mature from roadmap bet to research-ready to prd. Not for single-feature shaping, single-PRD big-batch work (which gets a container milestone from /write-a-prd), decomposition of a finished PRD, or implementation-ready work.

Invoked helper skill for unresolved module boundaries, usually called from /write-a-prd. Use to compare multiple interface shapes for a module or component when caller ergonomics and surface area are still unclear. Not for API contract review or already-settled designs.

Primary pipeline execution step after /prd-to-issues or for clearly scoped implementation work. Use to build, verify, and commit a concrete slice, delegating to /tdd for backend work and behavior-heavy frontend logic when red-green-refactor will reduce risk. Not for shaping or pre-merge review.

Invoked helper skill for fixing the /pre-merge findings a human has already chosen, with a fresh sub-agent writing each fix and a second fresh sub-agent trying to break it. User-invoked only — type /fix-findings <numbers> after picking findings from a review. Not for choosing which findings to act on, not for stamping review currency, and not for merging.

Infrastructure safety skill for blocking dangerous git commands in Claude-driven workflows. Use when the repo or user environment needs guardrails against destructive git operations. Not a delivery-pipeline step; it makes later work safer.

Side-route skill for compacting the current session into a transient handoff doc when no pipeline compression artifact fits — mid-skill, exploratory, side-route, or non-pipeline work. Not for routine inter-skill handoffs; use the calling skill's closing summary + **Next session:** line instead.

Side-route orientation skill. Use when the user asks 'what's next', 'where am I', or is returning to a repo mid-pipeline and wants to know which skill to run next. Reads repo state (branch, PRs, issues, research archive, milestones) and recommends one next step with a one-line reason. Not for executing work — only for routing.

Side-route skill for architecture exploration and deepening opportunities. Use when the user wants to find structural improvements, shallow-module pain, or refactor opportunities that may flow into /request-refactor-plan or /execute. Not for already-scoped implementation tasks.

Optional meta-skill for improving `chrislacey89/skills` from real-world friction or breakdowns discovered while using the pipeline in another repo. Use when the main lesson is about the pipeline itself, not the downstream project. Grounds proposals in established software-engineering guidance from `/library`. Produces a GitHub issue in `chrislacey89/skills` and only moves to implementation after review.

Infrastructure skill for scaffolding pipeline enforcement into a project. Sets up Claude Code hooks (TDD classification gate, git guardrails, optional quality gate), pre-commit hooks (detects existing tools, defaults to Lefthook + Biome + pnpm if none found). Run when setting up a project for pipeline work, and again to re-scaffold a hook that predates the post-review edit lock; /execute Step 0 auto-invokes it when the hook is missing or pre-lock.

Side-route utility skill for generating Mermaid diagram code from a description. Use when the user wants a flowchart, sequence diagram, class diagram, ER diagram, state machine, Gantt chart, mindmap, C4 architecture, user journey, or any of 23 supported Mermaid diagram types — often during /shape, /research, /write-a-prd, or /prd-to-issues when a visual would clarify scope, flow, or structure. Not for free-form ASCII sketches, hand-drawn whiteboards (use /excalidraw-diagram for that), or rend...

Primary pipeline decomposition step after /write-a-prd. Use when a shaped PRD is ready to become implementation-ready slices with boundary maps and dependency order. Not for unresolved scope, appetite, or solution direction.

Primary pipeline review step after verified implementation. Use to create a PR with lineage and run architectural review before merge. Not for QA intake, planning, or implementation work.

Build a throwaway prototype to flush out a question before committing to it. Routes between three branches — a runnable terminal app for state/business-logic questions (LOGIC), several radically different UI variations toggleable from one route (UI), or a focused spike that gives a binary verdict on whether a technical assumption holds (FEASIBILITY). Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, verify an `Uncertain` as...

Side-route skill and single entry point for bug conversations. Use when the user is reporting observed failures and wants durable GitHub issues filed in project language. Delegates per-issue to /triage-issue for bugs that need root-cause diagnosis, then returns to the loop. Not for already-scoped implementation work (use /execute).

Side-route skill for when an explanation did not land. Use when the user says 'wait, what', 'I don't follow', 'say that again', or 'in plain English' — it diagnoses which kind of confusion occurred and re-states the same answer in controlled technical English with every domain term glossed on first use. Not for producing new work, retracting a wrong answer, or trimming a long answer the reader already understood.

Side-route skill for planning refactors as safe, tiny-commit RFCs. Use when the user wants a structured refactor plan before implementation. Feeds approved refactor work back into /execute. Not for new-feature shaping or already-concrete implementation tasks.

Primary pipeline step after /shape and before /write-a-prd. Use to verify current docs, versions, repo patterns, and key unknowns before shaping. Invokes /api-design-review when API contract risk is high. Not for underdefined problems or implementation-ready work.

Infrastructure skill for setting up commit-time quality gates. Use when a repo needs Lefthook-based pre-commit hooks for formatting, linting, type checking, and tests. Supports downstream /execute and /pre-merge, but is not part of the normal feature-delivery pipeline.

Infrastructure skill for setting up Ralph loop scripts for Claude-driven AFK execution. Use when a repo wants a HITL-to-AFK runner around /execute with bounded iterations, GitHub-native durable state, and explicit feedback loops. Not a normal feature-delivery stage; it prepares the repo for safer autonomous execution.

Primary pipeline entry for structured requirements discovery. Use first when the problem, scope, or user needs are still fuzzy and you need shared understanding before /research. Not for already-shaped PRDs or implementation-ready work.

Invoked helper skill for strict red-green-refactor implementation, usually delegated from /execute or bug-fix work shaped by /triage-issue. Use when backend behavior or behavior-heavy frontend logic should be built test-first through public interfaces. Not for shaping, decomposition, vague implementation tasks, or primarily visual frontend work.

Invoked helper skill for deep bug diagnosis, usually delegated from /qa when a reported issue needs root-cause analysis and a TDD fix plan before implementation. Use when the cause is unclear, the bug is a regression, or the user explicitly wants diagnosis. Not for lightweight QA intake (use /qa) or already-clear implementation tasks (use /execute).

Audit TypeScript and React code against expert-level best practices from 9 TypeScript library references. Use when the user wants to review, audit, check, or improve TypeScript code quality — including requests like "audit this file", "review my types", "check my TypeScript", "what's wrong with this code", "improve my TS", "type review", or any request to evaluate TypeScript code against modern patterns. Also use when the user mentions type safety, generics review, or React TypeScript pattern...

Side-route skill for hardening domain vocabulary. Use when terminology is fuzzy, competing terms are causing confusion, or a glossary would improve shaping, QA, and refactor conversations. Produces UBIQUITOUS_LANGUAGE.md, then returns to the workflow that needed sharper language.

Side-route skill that renders a change as a single self-contained interactive HTML artifact — a finished diff, PR, or branch, or a plan's decisions and architecture before any of it is built. Three block sets: a scrolling recap for auditing a change (file-tree + change flags, annotated split diffs with line-anchored callouts, schema/API contract cards, UI wireframes, before/after columns, a per-unit series when one root cause repeats across four or more near-identical sites), a paged walkthro...

Side-route skill for an interactive, commit-by-commit comprehension walkthrough of a finished branch before merge. Use when the person about to merge didn't author the diff — or hasn't internalized it — and needs to understand each commit's intent, riskiest line, deliberate oddities, and what's absent by design, with per-commit sign-off. Not a defect finder (that's /pre-merge), not a behavioral check (that's /verify), not an acceptance-criteria checklist (that's /execute Step 5). Optional and...

Primary pipeline shaping step after /research and before /prd-to-issues. Use when the problem is understood well enough to turn into a bounded PRD issue. May invoke /design-an-interface or /api-design-review when interface or contract uncertainty remains. Not for discovery, decomposition, or implementation-ready work.