devkit

Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.

Generate documentation for code — use when asked to document a module, generate API docs, create a README for code, or write reference documentation. Triggers the deterministic doc-gen workflow (analyze → generate via documenter agent → write).

Check devkit health — which external CLIs (codex, gemini, gh, rtk, sg, gcli) are installed, which agents are available, which skills are ready to use. Use when asked about devkit health, devkit status, "is devkit working?", "what's installed?", "what devkit capabilities do I have?", diagnosing devkit setup issues, or running /devkit:health. Read-only diagnostic, safe to auto-invoke.

Fan-out PR review that runs BOTH `/devkit:tri-review` AND `/pr-review-toolkit:review-pr` in parallel for maximum coverage, then presents unified results — this skill does not compete with its sub-skills, it delegates to both simultaneously. Use when the user asks for "mega PR review", "mega-pr", "mega review", "full PR review with everything", "both review tools", "maximum coverage review", or explicitly wants every available reviewer looking at a change at once (Claude + Codex + Gemini model diversity PLUS specialized aspect reviewers like silent-failure-hunter, type-design-analyzer, test-analyzer, code-reviewer). Worth the extra cost when: the PR is high-stakes and the user wants every angle covered, or before merging a critical or hard-to-revert change. Do NOT use when the user only wants one review system (use tri-review or pr-review-toolkit:review-pr directly). Do NOT use for routine code review where a single reviewer suffices. This is deliberate overkill for when you want absolutely everything.

Generate a codebase onboarding guide — use when asked to explain this codebase, help understand the architecture, give a tour of the repo, or onboard a new contributor. Triggers the deterministic onboard workflow (analyze structure → architect via researcher agent → write guide).

Full end-to-end PR pipeline — validate → necessity-check → lint (loop) → test (loop) → security scan → doc-check → changelog → create-pr → monitor reviews (loop). Takes a branch from "code done" to "merged" with every gate enforced. Use when the user asks to "submit a PR", "open a pull request", "ship this", "make this PR-ready", "finalize this branch", or wants the full pipeline run end-to-end with CI monitoring and reviewer-comment handling automated. Worth the ceremony when: lint and test gates must pass before the PR opens, docs need syncing alongside code (README, ROADMAP, SKILL.md, workflows), security scan is required, or the user wants reviewer comments automatically classified and responded to. Do NOT use for a quick commit+push+PR without gates — use `/commit-commands:commit-push-pr` for that lighter path. Do NOT use when already mid-PR and just handling existing review comments in isolation. Do NOT use on the main branch or with uncommitted changes — the validate step will block you. This is devkit

Install devkit coding rules to ~/.claude/rules/ for Claude Code language-specific auto-activation. Use when the user explicitly asks to set up devkit rules, install language rules, or run /devkit:setup-rules. One-shot installer with side effects (writes to ~/.claude/rules/) — user-only invocation, never auto-triggered. Under non-Claude hosts, use AGENTS.md and resources/rules/ as reference instead of installing Claude rules.

Three independent code reviews (smart + general + fast model tiers running Claude, Codex, and Gemini) with consolidated findings — use when the user asks for tri-review, triple code review, three-way code review, multi-model code review, consensus code review, or says "get three opinions on this diff/PR/change before I ship". Worth the extra cost when the change is high-stakes, the user doesn't trust a single-model review, or they want breadth of perspectives over depth. Do NOT use for bug diagnosis (use tri-debug), security audits (use tri-security), or comparing implementation approaches on greenfield work (use tri-dispatch). Do NOT use for routine "can you review this PR" requests where a single-model pass is fine.

Scrape a URL to clean Markdown — use when asked to scrape, fetch, extract content from, or read a webpage and convert it to Markdown. Uses Jina Reader, Playwright, Camoufox (TLS-spoofing Firefox), Scweet (X/Twitter), Firecrawl, or WebFetch.

Audit the agent harness itself — CLAUDE.md, hooks, MCP configs, agent definitions, and permissions — for misconfigurations, injection risks, and security gaps. Use when the user asks to "audit my setup", "check my harness config", "is my agent config secure", "review my hooks", "check my MCP setup", or before trusting a new project's harness with autonomous work. Worth using on first clone of an unfamiliar repo, after adding new hooks or MCP servers, or when onboarding a new team member. Do NOT use for auditing project source code (use audit or tri-security), debugging workflow failures (use tri-debug or bugfix), or reviewing code changes (use tri-review).

External-scanner-driven project health check — runs the actual ecosystem tools (npm audit, eslint, govulncheck, semgrep, pip-audit, etc.) to surface what the standard scanners flag — outdated or vulnerable dependencies, lint violations, known CVEs, and config drift. Use when the user asks to "audit this project", "check project health", "run a project audit", "check deps/lint/security state", "is this repo up to date", or wants a stateless rundown of what the standard tools report. Worth using when kicking off work on an unfamiliar project, before a release, after a dependency bump, or when triaging a long-neglected repo. Do NOT use for introspective "what's wrong with this repo and what should I fix first" questions (use self-audit — that ranks issues by evidence), security-focused review of a specific code change (use tri-security), or debugging specific failures (use tri-debug or bugfix). This skill reports what scanners say, not what a human should prioritize.

Deterministic full-lifecycle bugfix workflow — triage → reproduce → diagnose → fix → regression-test → run-tests, with a reproduction gate that must fail before the fix and pass after. Use when the user asks to "fix a bug", "debug this issue", "resolve this error", "patch a defect", "this is broken, fix it", or reports a specific failure they want systematically fixed with a regression test added. Worth the ceremony when — the bug is non-trivial, reproduction isn't obvious, a regression test would prevent recurrence, or the fix needs the full test suite to verify nothing else broke. Do NOT use for one-line typos, missing imports, or obvious null-checks (just fix them directly — the workflow has a fast path but the lookup is still overhead). Do NOT use for hard bugs where the user wants divergent hypotheses before committing to one (use tri-debug). Do NOT use for "something's slow" performance work (use self-perf) or for fixing failing tests specifically (use self-test).

High-stakes research with Analysis of Competing Hypotheses, disconfirmation testing, evidence matrices, and sensitivity checks (~400k token budget) — use when the user needs to be SURE, not just well-informed. Trigger phrases include "deep research", "deeply investigate", "validate that X", "prove/disprove", "we're making a big decision", "correctness is critical", "I need to trust this answer", or "actively try to disprove this". Worth the extra cost when — the wrong answer has real consequences (architecture commitment, vendor choice, security claim, compliance question, public-facing claim), the user has already seen shallow answers and doesn't trust them, they explicitly ask for rigor or disconfirmation, or they're defending a position to stakeholders. Do NOT use for exploratory "what's out there" questions (use research), routine library comparisons where a single good answer suffices (use research), or quick factual lookups. This is the bias-catching, evidence-calibrating tier — overkill for casual expl

Deterministic full-lifecycle feature workflow (engine-driven, gated, looped) — triage → brainstorm → plan → implement → gen-tests → run-tests → lint → review → final-report. Use when the user asks to "add a feature", "build X", "implement Y", "ship a new capability", "new feature X", or wants an end-to-end pass from rough spec to PR-ready implementation with lint and test gates enforced. Worth the ceremony when — the feature is non-trivial (touches multiple files, needs tests, needs a plan), the user wants a structured walk from idea to working code, or wants gated iteration instead of free-form building. Do NOT use for the separate `/feature-dev:feature-dev` plugin — that is an agent-guided collaborative workflow; if the user explicitly invokes that command, respect it. Do NOT use for one-file quick additions (just write the code), bug fixes (use bugfix), or pure refactoring of existing behavior (use refactor). Includes a fast path for trivial changes so the workflow self-adjusts to scale.

Deterministic refactor workflow with tests as the safety net — analyze → plan → refactor → run-tests → fix-tests → comparison. The workflow will not exit until tests pass, guaranteeing behavior preservation. Use when the user asks to "refactor", "restructure", "reorganize", "clean up", "extract", "rename across files", or "modernize" existing code that has test coverage. Worth the ceremony when — the refactor spans multiple files, behavior must be preserved exactly, test coverage exists to prove nothing broke, or the user explicitly wants a safety-netted transformation. Do NOT use for renaming a single variable or function in one file (just do it — the workflow overhead isn't worth it). Do NOT use for adding new behavior (use feature) or fixing broken behavior (use bugfix). Do NOT use when there are no tests — the safety net is the entire point; without tests, do the refactor manually with careful review. If the user wants refactoring advice or a discussion (not the transformation), answer directly instead of

Three independent root-cause analyses of a hard bug or failure — smart + general + fast model tiers diagnose in parallel, then theories are compared and reconciled. Use when the user asks for tri-debug, triple debug, three-way debugging, multi-model diagnosis, parallel debug, consensus root-cause analysis, or is stuck on a hard bug and wants divergent hypotheses. Worth the extra cost when — the bug is hard (heisenbug, intermittent, cross-system), logs are ambiguous, the obvious fixes have already failed, or the user explicitly wants three independent theories before committing to one. Do NOT use for code review (use tri-review), security audits (use tri-security), or comparing greenfield implementation approaches (use tri-dispatch). Do NOT use for simple "what does this error mean" or routine null-check / typo bugs — a single pass is faster.

Three model tiers (smart + general + fast) each tackle the SAME open-ended task independently, then their divergent approaches are compared — this is the GENERAL-PURPOSE tri-* skill for tasks that don't fit the specialized siblings. Use when the user asks for tri-dispatch, triple dispatch, three-way comparison of model approaches, says "send this to three models and show me their takes", or wants to see divergent solutions before picking one. Worth the extra cost when — the task is exploratory or greenfield (design, architecture, new implementation, optimization), the user wants to compare model strengths on a novel problem, or is deliberately seeking diversity of approach before committing. Do NOT use for code review of existing code (use tri-review), debugging a specific failure (use tri-debug), or security audits (use tri-security). Do NOT use when the user already knows which approach they want — tri-dispatch is for exploration, not execution.

Three-tier parallel security audit (injection + auth + config, each examined by a different model tier) with severity-ranked consolidation — use when the user asks for tri-security, triple security audit, three-way security review, multi-model vulnerability scan, or parallel security audit of a code change, branch, module, or endpoint. Worth the extra cost when — touching auth/payments/user-uploads/admin surfaces, before prod deploy of security-sensitive code, after a security incident, or when the user is paranoid about a specific attack class. Do NOT use for general code quality review (use tri-review), bug diagnosis (use tri-debug), or approach comparison on greenfield work (use tri-dispatch). Do NOT use for a single-line "is this XSS safe" question, or for running pre-existing scanners like npm audit / gosec / semgrep — those are single-tool tasks, not a tri workflow.

Evidence-ranked codebase self-assessment (karpathy-style) — measures quality, security, and git signals in parallel then produces a prioritized list of what's actually wrong here, ranked by how much evidence supports each finding, with an actionable improvement plan. Use when the user asks to "self-audit", "audit the codebase against its own metrics", "run a karpathy-style audit", "what's wrong with this repo and what should I fix first", "rank issues by evidence", or wants a synthesized improvement plan rather than a scanner dump. Worth using when the user wants judgment and prioritization (where should I invest effort?), not raw warnings; when they're choosing the next big refactor; or when they want the biggest issues surfaced first with evidence showing why. Do NOT use for a plain scanner rundown of deps/lint/CVEs (use audit — that just runs the tools), security review of a specific code change (use tri-security), or debugging a specific failure (use tri-debug or bugfix). This skill is about ranking and j

Fast, standard research workflow (clarify → decompose → parallel search → summarize → synthesize) for exploratory questions where the user wants a good answer quickly. Use when the user asks to research a topic, investigate options, compare libraries/tools/approaches, find the best solution to a technical question, scope out a space they don't know yet, or get a grounded starting point before deciding. Worth using when the user is gathering context or narrowing down options — not when they've already committed and need validation. Do NOT use for high-stakes decisions where a wrong answer is expensive (use deep-research), validating specific claims under scrutiny (use deep-research), or simple factual lookups that don't need web searches (answer directly). Default to this over deep-research unless the user explicitly signals stakes with phrases like "we're making a big bet", "need to be sure", "validate", "deeply investigate", or "correctness is critical".

REFERENCE ONLY — schema documentation for authoring devkit workflow YAML files (step types, variable interpolation, loops, parallel groups, examples). NOT a runnable workflow. Load this only when asked to write or modify a workflow YAML, never on natural-language task requests.

Metric-gated improvement loop — use when asked to self-improve, run an improvement loop, fix issues until a metric passes, or "keep fixing until X is green". Triggers the deterministic self-improve workflow (baseline → improve → verify → loop until passing).

Run linter and fix violations until clean — use when asked to self-lint, lint and fix, fix lint errors, "make lint pass", or "fix all the lint issues". Triggers the deterministic self-lint workflow (baseline → fix → verify → loop until clean).

Incremental migration loop — use when asked to migrate, port, upgrade, convert, or modernize a codebase incrementally with tests as a safety gate. Triggers the deterministic self-migrate workflow (baseline → migrate one piece → verify → loop).

Profile and optimize performance — use when asked to self-perf, optimize performance, profile hot paths, speed this up, or "make it faster". Triggers the deterministic self-perf workflow (baseline → profile → optimize → verify improvement).

Run tests and fix failures until green — use when asked to self-test, fix tests, "make tests pass", "fix the failing tests", or "run tests and fix everything". Triggers the deterministic self-test workflow (baseline → fix → verify → loop until passing).

Generate tests for code — use when asked to write tests, create a test suite, add test coverage, or generate unit/integration tests for a file or module. Triggers the deterministic test-gen workflow (analyze → generate via test-writer agent → run-fix loop → report).

Automate a web browser — use when asked to click buttons, fill forms, navigate multi-step flows, extract data from JS-rendered pages, log into a site, record user interactions, or test a web app in a real browser. Use for anything beyond simple article scraping.

Capture a screenshot or PDF of a web page — use when asked to screenshot a URL, capture a page, take a picture of a website, generate a visual snapshot, or save a page as PDF. Supports full page, element selector, device emulation, and custom viewport.

Autonomous improvement loop inspired by karpathy/autoresearch — use when asked to run an autoloop, auto loop, autonomous improvement, or run experiments overnight on the codebase.

Persistent iteration memory — prevents Groundhog Day loops by recording what was tried, what failed, and what to try next.

Detect when an agent is looping or failing repeatedly, and trigger structured recovery — backtrack, simplify, or escalate.

Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.

Clean code principles — meaningful names, small functions, single responsibility, stepdown rule, flat nesting.

Don't reinvent the wheel — use existing libraries, tools, and stdlib before building custom solutions. Every custom solution is maintenance burden.

Don't Repeat Yourself — Rule of Three, when duplication is fine, extracting the right abstraction.

Execute implementation plans — work through steps methodically, verify each one, keep changes small and reviewable.

Google Workspace CLI (Gmail, Calendar, Drive) via gcli — use --for-ai flag for token-efficient structured output.

You Aren't Gonna Need It — build only what's needed now, no speculative features or premature abstractions.