
This skill should be used when the user asks to "execute the spec", "run the plan", "implement the issue", "run all steps", or "run spec". Implements all steps from a GitHub issue spec.
Create a named branch and git worktree, then open it in a color-coded VSCode window. Use when: 'branch worktree', 'new worktree', 'worktree for', 'start a worktree', 'create worktree'.
This skill should be used when the user asks to "review a spec", "review an issue", "check the plan", "review the implementation plan", "find gaps in the spec", or "review spec". Reviews a GitHub issue spec for gaps and viability, then directly edits the issue if improvements are needed.
This skill should be used when the user asks to "run the full workflow", "spec and implement", "dev workflow", "build this end to end", or "spec, branch, implement, and PR". Chains spec → branch → run-spec → PR into a single orchestrated flow.
This skill should be used when the user asks to "write a spec", "create a spec", "spec this out", "plan this feature", or "write an implementation plan" for a feature or change. Creates a structured implementation spec and writes it to a GitHub issue.
Act as the first architecture stage in the spec-driven workflow: given a problem or feature request, review the current system architecture and write .specs/<slug>/proposal.md with a compatible solution, or explain why the request does not fit. Use when the user says 'architect this', 'design a solution for', 'how should I implement', 'how would this fit into the codebase', 'propose an approach for', 'is this feasible in our architecture', or 'plan this feature'.
Audit migrated code by re-running the SpecOps analysis on the new target folder, comparing it against the original analysis spec, and generating corrective specs for each behavioral divergence so the next code-generation iteration converges toward the original behavior. Use this skill whenever the user mentions checking whether migrated code preserves original behavior, comparing migrated code against the original analysis, finding drift between legacy and migrated implementations, post-implementation verification, generating correction specs from a code analysis diff, closing the loop on a code-gen iteration, or reanalyzing a migrated module. Also trigger when the user describes "does the new code do what the old code does," "find where the migration drifted," "diff the migrated implementation against the spec," or "generate corrective specs based on a code diff." Run this after any round of code generation in a SpecOps migration, then iterate until corrections converge.
Analyze a git merge commit for PR complexity. Use when: 'analyze this PR', 'how complex is this commit', 'PR complexity for', 'score this merge'.
Act as a software architect: given a problem or feature request, review the current system architecture and propose a solution that is compatible with it — or explain clearly why it isn't compatible and what alternative approach to take instead. Use this skill when the user says 'architect this', 'design a solution for', 'how should I implement', 'how would this fit into the codebase', 'propose an approach for', 'is this feasible in our architecture', or 'plan this feature'. Also trigger when someone describes a problem and asks how to solve it within an existing project, asks whether a technology or pattern will work with their stack, or wants a technical design document or implementation plan before writing code. If the user is asking 'where should this go' or 'what's the right way to build this' in the context of an existing repo, use this skill.
Fix a test file to comply with Bun test rules from AGENTS.md. Use when: 'fix this test', 'make this test compliant', 'bun test fix', 'audit this test file'.
This skill should be used when the user asks to "review this PR", "review PR", "review the pull request", "code review PR", "give PR feedback", or "check this PR". Reviews a PR's code changes, submits review comments, and commits any fixes.
This skill should be used when the user asks to "commit", "commit changes", "commit staged files", "conventional commit", or "commit this". Creates a conventional commit of staged files, using the GitHub issue for context.
Analyze one controller file, determine which handlers are no longer wired from routes, and assess whether controller responsibilities have grown beyond validation/response orchestration. Produce analysis only (no implementation plan). Use this when the user says 'analyze this controller', 'is this controller still used', 'find dead controller handlers', or 'does this controller do too much'.
Audit a React component tree against the FirstWho design system and recommend Tailwind CSS corrections. Use when asked to 'align to design system', 'design system audit', 'check design tokens', or 'fix styling to match design system'.
This skill should be used when the user asks for an inventory of features a codebase provides, grouped logically into capability areas. Produces an implementation-language-agnostic catalog of user-facing and operator-facing features, their entry points, and their supporting modules. Uses sub-agents to shard discovery across the repository so the top-level context stays small.
Modernize an existing form through multi-phase analysis, redesign, TypeScript typing, and visual verification. Use when: 'modernize this form', 'redesign this form', 'form audit', 'improve this form'.
This skill should be used when the user asks to "open a PR", "create a PR", "submit a PR", "push and open PR", or "send a pull request". Commits staged files, pushes the branch, and opens a PR referencing a GitHub issue.
This skill should be used when the user asks to "run a step", "implement the step", "execute the spec", "run the plan", or "implement step N". Implements specific steps from a GitHub issue spec.
Create a new reusable skill by analyzing the current codebase to find how a task is already done, extracting the repeatable pattern, and producing a SKILL.md grounded in actual conventions. Use this skill when the user says 'create a skill for', 'make a skill that', 'I want a skill to', 'generate a skill', 'new skill for', 'skill for setting up', 'skill for adding', or 'skill for creating'. Also trigger when someone wants to codify a repeatable workflow into a reusable automation — scaffolding a module, wiring a route, adding a service, setting up a new package in a monorepo, or any task they find themselves explaining the same way each time.
Audit a SpecOps analysis specification for ambiguities that would force an implementer to make undocumented judgment calls, then resolve them by spawning parallel subagents to research the legacy source code and patching the spec with concrete answers. Use this skill whenever the user mentions auditing, hardening, reviewing, or finding gaps in an analysis spec, an analysis.md file, a spec document, a SpecOps spec, or any specification derived from legacy code. Also trigger when the user asks to find unclear statements, vague behaviors, judgment calls, underspecified behavior, or implementation gaps in a spec, even if they don't use the word "ambiguity" explicitly. Trigger before generating code from a spec, after a spec-driven implementation drifted from expected behavior, or as a pre-verification pass before marking a spec verified.
Generate framework-agnostic contract tests from a SpecOps analysis file. Use when: 'generate contract tests', 'spec-to-gate tests', 'create tests from analysis', 'contract tests for this analysis', 'test this spec', 'generate tests from specops'.
This skill should be used when the user asks to create an initial SpecOps plan or to extract a comprehensive implementation-language-agnostic specification from an existing codebase, module, subsystem, service, or workflow.
Generate integration tests for normative application runs in a SpecOps migration — pathways the system exercises in normal use that cross multiple modules and traverse real seams between them. The skill discovers significant pathways from both the analysis specs (intended integration points) and the migrated code (actual call graph), generates tests that reuse the project's existing unit-test mocks, and places them where the target platform stores integration tests. Use this skill whenever the user mentions integration tests, end-to-end tests, normative runs, cross-module test coverage, testing the migration as a system, generating tests that exercise multiple modules together, or verifying the migration's seams. Also trigger when the user asks "what should I integration test," "test the system end-to-end," or describes wanting tests beyond what unit tests cover. Run this after at least one round of code generation has produced runnable migrated code with passing unit tests, and re-run as the migration evolves to add tests for newly-completed pathways.
This skill should be used when the user asks to convert a SpecOps analysis into a deterministic implementation specification for a specific project, stack, and engineering standards.
This skill should be used when the user asks to orchestrate SpecOps analysis from an initial plan output across all targets using sequential subagents.
This skill should be used when the user asks to generate specs for multiple analysis files by orchestrating sequential subagents that apply the specops-make-spec workflow per file.
This skill should be used when the user asks to create a refactor-focused SpecOps plan for a specific source folder and explicit refactor goal.
This skill should be used when the user asks to "run the spec", "implement the spec", or "execute the spec". Implements every step in a SpecOps implementation spec by delegating each step (or logical group of adjacent steps) to a sequential subagent, conventional-committing each one independently, and — when `roborev` is on the path — running `roborev check` on every commit and `roborev fix` (with spec context, so the fix cannot silently drift the implementation away from the spec) on any commit that fails.
Audit a set of SpecOps analysis specs for cross-spec coherence — establish a dependency-ordered implementation sequence, then verify pairwise integration contracts at module boundaries plus three cross-cutting consistency dimensions (shared data models, side-effect ownership, terminology) — and patch the affected specs to resolve gaps. Use this skill whenever the user mentions cross-spec consistency, integration gaps between specs, conflicts between specs, duplicate work across specs, implementation order, dependency order for migration, building an implementation-order checklist, ensuring specs interoperate, terminology drift across specs, or shared data model conflicts. Also trigger when the user describes "do my specs agree with each other," "what order should I implement these in," "find inconsistencies across all my specs," or asks to audit a folder of analysis specs as a set rather than individually. Run this once after generating a full set of analysis specs, before deriving implementation specs.
Audit a SpecOps implementation spec against its source analysis spec to find requirements, policies, contracts, edge cases, error modes, invariants, defaults, side effects, or implementation steps that the implementation has dropped, weakened, contradicted, or silently changed — then patch the implementation spec to restore them. Use this skill whenever the user mentions auditing, comparing, conforming, reconciling, or checking an implementation spec against an analysis spec, finding gaps between two specs, ensuring an implementation spec preserves analysis behavior, or verifying spec derivation or traceability. Also trigger when the user describes "did the implementation spec lose anything from the analysis," "does the implementation match the analysis," "verify the implementation spec covers everything," or asks to confirm one spec is faithful to another. Run this before generating code from an implementation spec and after either spec is edited.
Exhaustively audit a top-level UI implementation component against an HTML prototype and produce a grouped markdown checklist of corrections. Use when a user asks for UI parity review, visual QA, design implementation audit, pixel-level drift detection, or behavior/style mismatch analysis between prototype HTML and shipped component code.
This skill should be used when the user asks to "address PR feedback", "handle PR comments", "review PR feedback", "fix PR comments", or "respond to PR reviews". Retrieves PR review comments, addresses them one at a time, and leaves responses.
This skill should be used when the user asks for a SpecOps analysis of existing systems, modules, services, or workflows to produce a comprehensive implementation-language-agnostic specification, including explicit and implicit business rules, decision logic, defaults, thresholds, workflow constraints, and user-visible policies enforced by the system.
This skill should be used when the user asks to "execute the spec", "run the plan", "implement the issue", or "run all steps". Implements all steps from a GitHub issue spec.
This skill should be used when the user asks to "create a branch", "make a branch", "start a branch", or "branch from issue". Creates a new local branch based on a GitHub issue topic.
Critique a proposed architecture or implementation plan by selecting two real-world practitioners with deep, relevant expertise and evaluating the proposal through their known perspectives. Use this skill when the user says 'critique this architecture', 'review this proposal', 'what would an expert think of this', 'poke holes in this design', 'stress-test this approach', 'what am I missing', or 'is this a good architecture'. Also trigger when someone has an implementation proposal (especially one from the architect-initial skill) and wants it challenged before committing to it. If the user asks 'what could go wrong', 'where are the weak points', 'would this scale', or 'is this the right approach', use this skill. This skill is about rigorous critique, not validation — its job is to find what's wrong before code gets written.
This skill should be used when the user asks to "write a spec", "create a spec", "spec this out", "plan this feature", or "write an implementation plan" for a feature or change. Creates a structured implementation spec in .specs/<slug>/spec.md and mirrors it to GitHub only when the current repository is hosted on GitHub.
Inspect a top-level file for a component or feature, then analyze and describe the current architecture around it (boundaries, dependencies, data flow, and risks). Use this when the user says 'inspect this architecture', 'analyze this component architecture', 'explain how this feature is structured', or 'how does this module fit into the system'.
This skill should be used when the user asks to "compile review criteria", "generate spec criteria", "compile the conformance checklist", "build guardrails from the spec", or "spec criteria". Compiles a frozen spec's normative prose into an executable conformance checklist at .specs/<slug>/criteria/, blind to any implementation of that spec, and accumulates cross-phase ownership invariants in .specs/<slug>/invariants.md.
This skill should be used when the user asks to "create a spec branch", "make a spec branch", "start a branch", or "branch from spec". Creates a local branch from a spec, description, or issue/ticket reference without requiring GitHub.
Analyze a code repository's architecture and produce (or update) an AGENTS.md file that gives LLM coding agents a map of the project. Use this skill whenever the user says 'generate AGENTS.md', 'create AGENTS.md', 'update AGENTS.md', 'map this repo', 'document this project for agents', 'analyze the architecture', or any variation of 'help an LLM understand this codebase'. Also trigger when the user asks to onboard an AI agent onto a project, describe a repo's structure for Claude/Copilot/Cursor, or identify the architectural pattern of a codebase. If someone says 'what pattern does this project use' or 'where is everything in this repo', use this skill.
This skill should be used when the user asks to "execute the spec", "run the plan", "implement the spec", "implement the issue", "run all steps", or "run spec". Implements all steps from .specs/<slug>/spec.md, using a subagent per step when the harness supports subagents.
This skill should be used when the user asks to "audit the implementation against the spec", "run the spec audit", "check spec conformance", "verify the branch against the criteria", or "spec audit". Executes the frozen conformance checklist from .specs/<slug>/criteria/ against the implementation diff and reports PASS/VIOLATION/UNVERIFIABLE per criterion with file:line evidence. Report-only; never edits production code.
This skill should be used when the user asks to "review a spec", "review an issue", "check the plan", "review the implementation plan", "find gaps in the spec", or "review spec". Reviews .specs/<slug>/spec.md for gaps and viability, edits it when needed, and mirrors changes to GitHub only when a GitHub mirror exists.
Critique a spec-driven architecture proposal by selecting two real-world practitioners with deep, relevant expertise and evaluating the proposal through their known perspectives. Use when the user says 'critique this architecture', 'review this proposal', 'what would an expert think of this', 'poke holes in this design', 'stress-test this approach', 'what am I missing', or 'is this a good architecture', especially after spec-architect-initial writes .specs/<slug>/proposal.md.
Identify where a plain-language feature or behavior lives in the current codebase and return the top-level file(s) to inspect first. Use this when the user says 'where is X implemented', 'find where this logic lives', 'which file handles Y', 'locate this feature', or 'what file should I read first for Z'. Also trigger when someone describes behavior in prose and wants likely owning files.
This skill should be used when the user asks to "remediate the audit findings", "fix the spec violations", "close the audit findings", "fix conformance violations", or "spec remediate". Reads a spec-audit report, drives one smart subagent per VIOLATION to converge the code back to the frozen spec, and re-audits until clean. Edits production code; never rewrites the spec.
Create a named branch and git worktree for spec-driven work, then open it in a color-coded VSCode window. Use when: 'spec branch worktree', 'new spec worktree', 'worktree for', 'start a worktree', 'create worktree'.
This skill should be used when the user asks to "review a spec", "review an issue", "check the plan", "review the implementation plan", or "find gaps in the spec". Reviews a GitHub issue spec for gaps and viability, then directly edits the issue if improvements are needed.