claudops

Internal reference skill — coding standards and patterns for developer agents. Not user-invocable.

Close out work by committing local changes, pushing, waiting for green CI, and merging the PR. Universal — works on any branch with an open PR; no task structure required. Use when asked to 'merge the PR', 'ship it', 'merge and close', 'commit push merge', 'finalize the PR', 'land it on main', 'we're done — close it out', or whenever the user signals end-of-work and the next step is to merge. If (and only if) the current work is one phase of a multi-phase task in `tasks/**/phase-N-*/`, also make upcoming phase tech-decomposition documents accurate for the implementation that just landed by adding handoff notes or updating stale assumptions before merging — otherwise this step is silently skipped. Make sure to use this skill whenever the user signals end-of-implementation and wants the changes merged — even if they don't say the word "skill". NOT for opening a new PR (use plain `gh pr create`). NOT for addressing review comments (use /prc). NOT for preparing a session handoff to a fresh context (use /ph).

Use when a plan, design, or discovery document needs stress-testing for hidden assumptions, scope gaps, unresolved branches, or ambiguous wording; also when the user explicitly says "grill me".

Internal reference skill — shared conventions for all code review agents. Not user-invocable.

Implements a feature from a technical decomposition using TDD, keeping the task document updated and handing off cleanly to review. Use when starting, continuing, or resuming implementation from a tech-decomposition or task directory. Trigger: 'implement this task', 'start implementation', 'continue/resume implementation', 'build from the tech decomposition', or after /ct produces a decomposition. NOT for creating the plan (/ct), feature discovery (/nf), small untracked changes (/si-quick or /quick), or code review (/sr).

Use when asked to review code before merge or review a PR, branch, commit range, task path, or current working tree. Trigger on requests like 'review PR', 'review my changes', 'review this branch', 'is this ready to merge', or other pre-merge review requests. Supports task/spec-aware review when task docs exist. NOT for addressing review comments (use /prc).

Test-driven development with red-green-refactor loop using vertical slices. Use when building features or fixing bugs with TDD, when /si or /si-quick needs canonical TDD discipline, when user mentions "red-green-refactor", "tracer bullets", "test-first", or asks for integration-style tests. Forbids horizontal slicing (all tests then all implementation).

Run Google Antigravity CLI (agy) for web-grounded research, cross-AI review, or validation. Use when asked for 'ask antigravity', 'antigravity review', 'agy search', 'use antigravity', or when you need Google Search grounding or a different AI perspective. NOT for interactive conversations (driven one-shot only).

Run OpenAI Codex CLI for one-shot cross-AI code review or approach validation. Invoke ONLY when the user explicitly asks ('second opinion', 'codex review', 'ask codex', 'run codex', 'cross-AI check'), or when another skill passes an explicit instruction to delegate to codex. Do not invoke proactively on general review requests — the primary review skills handle those. Not for interactive conversations (codex is one-shot only).

Use when a feature/scoped task is clear enough for technical planning — produces an implementation-ready technical decomposition before coding. Trigger: 'create task', 'technical decomposition', 'plan implementation', 'break into implementation steps', or after /nf or /product when ready to plan the build. NOT for feature discovery (/nf), product docs (/product), brainstorming (/brainstorm), or implementation (/si).

Run Cursor CLI (Composer 2, a Kimi-K2.5 lineage) for one-shot cross-AI code review when a non-OpenAI/non-Anthropic perspective is specifically wanted. Invoke ONLY when the user explicitly asks ('cursor review', 'ask cursor', 'run cursor'), or when another skill passes an explicit instruction to delegate to cursor. For generic 'cross-AI check' requests, the caller skill should pick the specific CLI; do not invoke both cursor and codex implicitly. Not for interactive conversations (cursor is one-shot only).

Runs an in-depth feature-discovery interview that explores, challenges, and documents a new feature before planning. Use when asked to 'detail a feature', 'explore a new feature', 'feature discovery', 'interview about feature', 'spec out a feature', 'design a feature', 'think through a feature', 'deep dive on a feature', 'discover [feature-name]', or 'what should we consider for [feature]'. NOT for quick brainstorming (/brainstorm), PRD/JTBD docs (/product), or implementation tasks (/ct).

Create JTBD or PRD product documentation through an interactive interview process. Use when asked to 'create JTBD', 'write a PRD', 'product requirements', 'jobs to be done', 'product documentation', 'product spec', or when a feature needs formal product-level documentation before technical planning. Conducts research, interviews, and pressure-tests the product thinking before writing. NOT for technical decomposition (use /ct), NOT for feature discovery (use /nf).

Configure workflow for your codebase. Run after cloning .claude/ into your repo. Use when asked to 'setup', 'configure workflow', 'initialize .claude', 'setup wizard', 'configure for my project', or when the codebase has unconfigured {{PLACEHOLDER}} variables.

Inspect, install, customize, or troubleshoot the harness-level git safety hook that blocks dangerous git operations (push, branch -D, checkout .) before they execute. Use when the user wants to change which git commands are blocked, verify the guard is wired up, or set it up after a fresh clone.

Parallelize implementation across isolated git worktrees. Use when /si identifies parallelizable work, the user says 'run in parallel', 'implement simultaneously', 'parallelize these steps', or when a task has 2+ independent acceptance criteria touching different files/modules. NOT for single-threaded implementation (use /si).

Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to product-docs/UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, or mentions "domain model" or "DDD". Also invoked from /nf, /product, /ct as Step 0 (load) and after grill (update). NOT for architectural vocabulary (use /architecture-language).

Canonical architectural vocabulary — module, interface, seam, adapter, depth, leverage, locality. Use when reviewing architecture, deepening shallow modules, designing interfaces, or evaluating refactor candidates. NOT a domain glossary (use /ubiquitous-language for that).

Find deepening opportunities in a codebase — refactors that turn shallow modules into deep ones for better testability and AI-navigability. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable. NOT for code review before merge (use /sr). NOT for spec/requirement gaps (use /ct). Reads but does not write code.

Interactive QA session where the user reports bugs conversationally and the agent files them as tracker issues (GitHub or Linear) one by one or as a dependency-linked breakdown. Explores the codebase in the background for context and domain language. Use when user wants to "do QA", "report bugs", "file issues from a QA pass", or runs through multiple problems at once. NOT for single-bug triage (use /triage-issue) or interactive debug (/dbg).

Use when handling a small, untracked change with clear scope or a bugfix with a known root cause, and there is no tech-decomposition or task directory to follow. Trigger on requests like 'quick fix', 'just do it', 'small change', or 'quick task'. NOT for new features, tracked task work, or changes needing formal implementation/review flow (use /si).

Investigate a reported bug, find its root cause, and file a tracker issue (GitHub or Linear) with a TDD-based fix plan. Mostly hands-off — minimize questions to the user. Does NOT apply the fix. Use when user reports a bug and wants it tracked, mentions "triage", "file an issue", or "investigate and plan a fix". NOT for interactive debugging (use /dbg) or batch QA sessions (use /qa).

Pull upstream workflow changes from claudops into a local .claude/ folder. Uses a deterministic scan/report/apply engine, asks for approval before writes, and only touches upstream-tracked workflow files. Use when asked to update setup, pull workflow changes, sync claude config, update workflows, update skills, check for updates, or update-setup.

Step up one layer of abstraction and produce a map of the relevant modules and their callers — used when you (or the agent) are stuck in one file and losing the bigger picture. Use when user says "zoom out", "give me a map", "I'm lost in this code", or "what calls this".

Start any project's dev server and monitor it for errors in real-time. Universal — works with Node.js (Next.js, Vite, Remix, Astro, SvelteKit, Nuxt, Angular, Gatsby, Expo), Python (Django, Flask, FastAPI, Uvicorn), Ruby (Rails, Sinatra), Go, Rust (Cargo), Java (Spring Boot, Gradle, Maven), PHP (Laravel, Symfony), Elixir (Phoenix), and Docker Compose. Auto-detects the stack and package manager from project files. Uses the Monitor tool to stream only errors, warnings, and crashes — not routine request logs. Use this skill whenever the user says "start dev server", "run dev", "start the app", "launch the server", "npm run dev", "cargo run", "python manage.py runserver", "rails server", "go run", or anything that implies starting a local development server. Also trigger when the user asks to "monitor the server", "watch the build", "check for errors while I work", or simply "dev".

Cross-artifact consistency check between spec documents and tech decomposition. Use when asked to 'analyze consistency', 'check alignment', 'verify spec matches plan', 'traceability check', 'spec drift', 'are my docs aligned', or after /ct completes to verify the tech decomposition covers all requirements. Also invoked automatically as GATE 4 in /ct. NOT for code review (use /sr), NOT for code analysis (use /code-analysis), NOT for debugging (use /dbg).

Turn a one-line objective into a multi-session implementation plan with cold-start briefs. Use when asked to 'blueprint', 'multi-session plan', 'long-term plan', 'construction plan', 'break into sessions', 'plan across sessions', 'multi-step project plan', 'session plan', or when a feature is too large for a single Claude session. Produces a plan where each step can be executed independently by a fresh agent with no prior context.

Collaborative brainstorming session on any topic — project-related or general. Use when asked to 'brainstorm', 'let's brainstorm', 'explore ideas', 'think through', 'brainstorm about [topic]', 'what are our options for', 'let's think about', 'pros and cons of', 'help me decide', or 'weigh the options'. NOT for feature discovery (use /nf), NOT for PRD/JTBD docs (use /product), NOT for deep research (use /deep-research), NOT for pre-implementation design (auto-triggered by design-exploration skill).

Execute Linear operations via direct GraphQL API — create issues, update status/priority/title, add comments, search tasks, manage labels, assign work, and link PRs. Use this skill when the user mentions Linear explicitly, or references a Linear-style identifier (uppercase team prefix + dash + number, e.g. ENG-123, OPS-7; the project's team key is in $LINEAR_TEAM_KEY). Trigger on phrases like "create a Linear ticket/issue", "move TEAM-X to done/in progress/review", "update the Linear task status", "close the Linear issue", "what's in our Linear backlog", "assign this Linear issue to", "my Linear issues", or any project management operation targeting Linear. Also trigger when other skills (ct, si, sr) need to sync state with Linear. Do not trigger on ambiguous "create an issue" when the user clearly means a GitHub Issue (repo context, `gh issue` commands, issues.md), unless they also reference Linear.

Deep code analysis with metrics, patterns, and recommendations. Use when asked to 'analyze this code', 'explore the codebase', 'code audit', 'tech debt assessment', 'architecture review', 'codebase overview', 'show me the project structure', 'where are the hotspots', 'code metrics', 'what patterns are used', 'how is this organized', 'code quality check', 'find complexity', 'module dependencies', or any request to understand, assess, or explore code quality and structure. Also triggers for pre-implementation codebase exploration and dependency analysis. NOT for code review before merge (use /sr). NOT for debugging (use /dbg). NOT for research on external technologies (use /deep-research).

Debug mode with runtime evidence and instrumentation. Use when asked to 'debug this', 'find the bug', 'troubleshoot', 'why is this broken', 'investigate runtime issue', 'it's not working', 'getting an error', 'this crashes', 'unexpected behavior', or when the user pastes an error message or stack trace and wants to find the root cause. Also trigger when the user describes behavior that differs from expectations in a running app. NOT for static code analysis without reproduction (use /code-analysis). NOT for CI pipeline failures (use /fci).

In-depth research on technical topics using web search, documentation, and codebase analysis. Use when asked to 'research', 'investigate', 'find out about', 'look into', 'dig into', 'compare X vs Y', 'what's the best library for', 'how does X work', 'should we use', 'find alternatives to', 'evaluate options for', 'what are others doing for', or explore unfamiliar technologies, libraries, or architectural patterns. Also triggers for technology evaluation, migration research, and dependency decisions. NOT for quick brainstorming (use /brainstorm), NOT for feature discovery (use /nf), NOT for static code analysis (use /code-analysis).

Explore codebase and design approaches before implementation. Use when asked 'explore the design', 'how would this fit', 'design exploration', 'what patterns exist for', 'how is X implemented', or when another skill (brainstorm, nf) needs codebase context to ground a design proposal. NOT for code review (use /sr), NOT for static analysis (use /code-analysis).

Fix CI pipeline failures blocking PR merge. Use when CI checks fail, 'pipeline broken', 'build failing', 'fix CI', or 'checks not passing'. NOT for debugging runtime bugs (use /dbg), NOT for code review (use /sr).

Prepare session handoff for continuation in a new conversation. Use when 'prepare handoff', 'save progress', 'session handoff', 'I need to stop', 'prepare for next session', 'hand off', 'write handoff', or when the user wants to pause mid-implementation and resume later in a fresh context window.

Review and address code review comments on PR. Use when asked to 'address review comments', 'fix PR feedback', 'handle review comments', 'respond to PR comments', or 'address CR comments'. NOT for initiating code review (use /sr), NOT for task-based implementation with CR mode (use /si).

Review implementation plan for business value alignment. Use when asked to 'review my plan', 'walk through implementation', 'check plan against PRD', 'review technical decomposition', or 'is my plan aligned with requirements'. NOT for code review (use /sr), NOT for creating tasks (use /ct), NOT for static code analysis (use /code-analysis).

Interactive teaching guide for learning while working. Use when asked to 'teach me', 'walk me through', 'explain step by step', 'guide me through', 'show me how', 'learn while doing', 'I want to understand', 'help me learn', 'can you explain how', 'what does this do and why', or when the user expresses desire to understand a topic deeply rather than just get a quick answer. Also trigger when the user wants to learn a new tool, library, pattern, or workflow hands-on — even if they don't use the word "teach". NOT for open-ended brainstorming (use /brainstorm), NOT for quick one-off explanations (just answer directly), NOT for debugging (use /dbg).

Update documentation and generate changelog after task implementation. Use when asked to 'update docs', 'generate changelog', 'sync documentation with code', or when a task is complete and docs need updating. NOT for creating new product docs (use /product).

Create interactive visual prototype playground for user approval before technical decomposition. Use when asked to 'create prototype', 'visual mockup', 'preview design', 'design playground', 'show me the feature', 'what would this look like', 'mockup the UI', 'visualize the architecture', 'preview before building', 'let me see the design', or anytime the user wants to see or approve a visual representation of a feature before coding begins. Also trigger when /nf discovery is complete and the user says 'looks good, let's see it', 'now show me', or 'visualize this'. NOT for brainstorming (use /brainstorm), NOT for feature discovery (use /nf), NOT for implementation tasks (use /ct), NOT for quick one-off diagrams (use /generate-web-diagram).