nuthouse

audit

Scan all skills, agents, personas, and banner prompts in this nuthouse repo against the _templates/ source of truth. Reports missing

Use when the user wants to review the quality of existing nuthouse skills — runs a structural audit then queues selected skills for testing and description optimization via skill-creator. Use when the user says "are my skills good?", "review all skills", "check my skills", "audit quality".

scaffold-agent

Use when adding a new dedicated subagent to an existing plugin in this `nuthouse` marketplace. Asks for parent plugin, agent name (descriptive role, no vague names like "agent" / "helper"), description, model (`haiku` for parsing/fetch+summary vs default for reasoning), explicit tools allowlist, input format spec, output format spec (SDD vs structured report vs custom). Generates `<plugin>/agents/<name>.md` with the right frontmatter (name, description, model, tools list) and the standard Mission / Input / Output / Hard rules sections. Encodes the subagent and SDD conventions from the legacy CLAUDE.md.

check-drift

Use on a feature branch before or during PR creation — detects drift between the PR diff and the SDD Acceptance/Constraints of the linked project. Prefers the repo spec markdown as primary truth, falls back to Linear project context only when no spec markdown is found, generates a structured drift report, and optionally posts it as a PR comment.

write-checklist

Use when a feature is approaching QA or PR review and the team needs a derived, per-spec acceptance checklist — reads an approved spec, generates a concrete `- [ ]` checklist of verifications drawn from its Acceptance / Constraints / Non-goals sections, writes it to docs/acid-prophet/checklists/<slug>.md, and optionally posts it as a PR comment. Complements `check-drift` (drift = spec↔code mismatch · checklist = did we actually validate the AC).

write-constitution

Use when a project needs immutable governing principles that every spec / audit / drift check is held against — runs a one-question-at-a-time interview to extract project-specific articles (test-first, anti-abstraction, library boundaries, etc.), writes them to docs/acid-prophet/constitution.md, and commits. The spec-auditor reads this file on every audit and treats each article as an extra gate.

write-plan

Use after a spec has been ratified and before any code is written — turns an approved spec into a concrete implementation plan with file-level architecture decisions, typed API/data contracts, and a quickstart validation scenario. Produces docs/acid-prophet/plans/<slug>/{plan.md, contracts/*.md, quickstart.md, codebase-map.md} and is consumed downstream by the main implementation turn or linear-devotee:create-issue.

Testing & QA Listed

write-spec

Use when starting any project or feature that needs a structured spec before development — asks clarifying questions one at a time, proposes approaches, validates a written spec, then optionally hands off to linear-devotee:create-project for Linear project creation

commit

Use automatically when the user asks to commit changes, create a commit, write a commit message, commit staged changes, commit everything, run git commit, "fais le commit", "commit mes changements", or "crée un commit". Handles staged changes first and stages dirty changes only when the user explicitly asks to commit all/everything or stage changes. Do not use for plain git status, diff, log, push, rebase, or PR creation.

pr

Use automatically when the user asks to create, open, draft, or publish a GitHub PR, pull request, review request, "ouvre une PR", "fais la PR", "crée une pull request", or says the branch is ready for review. Delegates git log/diff reading and PR description writing to a subagent. Do not use for commits, plain git status, diff, log, push-only, rebase, or non-GitHub merge requests.

review-passes

Portable review pass contract for git-gremlin:review — shared input packet, candidate finding schema, the read-only passes (correctness, convention, tests, risk), and aggregation rules. Background knowledge preloaded into the reviewer host agent; not a user-facing workflow.

review

Use automatically when the user asks to review code, review the current diff, inspect a PR/branch/commit range, run a contextual code review, "review la PR", "review ce diff", or "fais une review". Loads repo instructions such as AGENTS.md, CLAUDE.md, Copilot instructions, path-scoped rules, and PR/spec context before producing severity-ranked findings. Do not use for commit creation, PR creation, branch creation, or implementing fixes unless the user explicitly asks to address findings.

Show all 36 bundled skills

spawn

Use when a new branch is needed — to create a branch, start work on a new branch, "crée une branche", "nouvelle branche", "bosse sur X dans une nouvelle branche", "spawn a workspace", "nouveau workspace", or when the PreToolUse hook blocked an in-place `git checkout -b` / `git switch -c` / `git branch <new>`. Creates a dedicated Superset workspace (one git worktree per branch) and spawns a fresh agent on the task instead of branching in place. Do not use for switching to an existing branch, deleting/renaming branches, commits, or PRs.

create-issue

Use to create a single Linear Issue with a strict SDD-formatted description (standalone add-on) or to resume a partially-committed create-project cascade. Reads chain-state to detect resume mode and pick the next issue whose `id` is still null, dispatches issue-drafter, previews, creates on approval, updates chain state, and recommends the next issue to work on.

create-milestone

Use to add a single Milestone to an existing Linear Project (standalone add-on) or to resume a partially-committed create-project cascade. Reads chain-state to detect resume mode and pick the next milestone whose `id` is still null. Drafts via milestone-drafter when needed, clarifies, previews, creates on approval, updates chain state.

Web & Frontend Listed

next-issue

Use when the user says a Linear issue is finished/done/complete and wants the next issue to work on, or asks which Linear issue to take next in the same project. Resolves the current issue, reads project issues, respects completed/canceled states and blockers, and recommends the next startable issue without auto-starting greet or mutating Linear.

research

Use automatically when the user wants a researched, fact-checked, or cited answer from the web — "fais une recherche", "creuse le sujet", "vérifie cette info", "trouve-moi des sources sur", "research X", "fact-check X", "find sources on X", "dig into X", or any question whose answer needs several cross-checked web sources. Prefer this over a bare WebSearch whenever the answer should be sourced rather than answered from memory. Fan-out web search → fetch + summarize → adversarial verification → cited synthesis. Zero parametric knowledge — answers only from verified sources.

advance

Use when a feature is implemented, verified, and its PR is open and the autopilot relay must move on — auto-invoked by git-gremlin:pr in autopilot, or "issue suivante", "continue le relais", "next movement". Holds the per-feature acceptance gate ("tested, it's good?"); on approval resolves and spawns the next startable issue's worktree, then stops. Does not merge (the patron merges PRs). Do not use to start the relay (monkey-maestro:run) or to stop it (monkey-maestro:halt).

halt

Use when the user wants to stop the autopilot relay — "arrête l'autopilote", "baton down", "stop the relay", "autopilote off", "coupe le relais". Disarms the repo-scoped autopilot flag and marks the relay-state stopped so no further worktrees are spawned. The already-open PRs and worktrees stay — the patron merges and cleans those up. Do not use to start the relay (monkey-maestro:run) or to accept a feature and advance (monkey-maestro:advance).

affected-scope

The scope map JSON contract moon-moth skills and agents exchange — schema and field rules for the affected project set (ids, layers, stacks, tasks, downstream blast radius) computed from `moon query`. Background knowledge contract, preloaded into moon-moth agents; not a user-facing workflow.

init

Use to wire a moon TypeScript monorepo for a moon-aware agentic dev loop — generates path-scoped `.claude/rules/`, a moon-command allowlist and plan-default in settings, a cache Read-deny, and a short moon-loop section in the repo's agent contract (AGENTS.md/CLAUDE.md). Idempotent and confirmation-gated; merges into existing config instead of clobbering. Run once per repo to make Claude Code + Codex fast and precise in that monorepo.

moon-commands

Canonical `moon` CLI invocations for scoping and running tasks in a moon monorepo — the single source of truth every moon-moth skill and agent uses for `moon query` and `moon run`. Background knowledge contract, preloaded into moon-moth agents; not a user-facing workflow.

scope

Use at the start of any task in a moon monorepo to scope work to the affected project graph — runs `moon query changed-files`/`affected`, dispatches the affected-scout subagent, and returns a structured scope map (affected projects, layers, tasks, downstream blast radius). Prefer this over blindly scanning the repo when working in a repo with a `.moon/` workspace.

verify

Use after editing code in a moon monorepo, before commit or PR, to verify the change — runs affected :typecheck/:lint/:test via the verify-runner subagent, dispatches change-auditor for an adversarial review of the diff against scope, reports evidence (not assertion), and loops back on a torn wing (failing check). Prefer this over a blind repo-wide test run.

saucy

debug-local

Use when the user reports a runtime error, a service not starting, an auth/OIDC failure, or missing env vars in local dev on the notom platform. Investigate proactively with available tools before asking the user to run anything.

drive-scaleway

Use when working with any Scaleway resource — IAM, instances, databases, registry, observability, networking. Drives the `scw` CLI directly to inspect and modify resources instead of suggesting manual console actions.

API & Backend Listed

observe-platform

Use when investigating a service issue, checking logs, querying metrics, or verifying the health of any notom-platform resource on Scaleway staging or prod. Queries Loki logs and Prometheus metrics directly via the cockpit API — never punts to Grafana.

sync-insomnia

Use when adding, modifying, or removing API endpoints and the corresponding Insomnia collection needs to be updated. Edits the Git-Synced YAML collection directly, commits, and tells the user to Pull in Insomnia.

code-organisation

Code-organisation discipline for all TypeScript work — named exports only, declarative index.ts, one-file-one-responsibility, reuse before writing. Applies whenever editing or creating TypeScript files.

hono-pipeline

Layered backend pipeline discipline for Hono + typed-RPC monorepos — contract → error union → pure service → unwrap → thin router. Applies when working on Hono backend code.

Web & Frontend Listed

react-rules

React component discipline — one component per file, folder mirrors the JSX tree, IDs-only props, state hierarchy. Applies when working on React components and hooks.

result-pattern

Result/error discipline for domain and service logic — business outcomes return `Result<T,E>`, never throw; one unwrap at the transport boundary. Applies when working on backend/domain TypeScript code.

type-safety

Type-safety discipline for all TypeScript work — no `any`/`as`/`!`, string-literal unions over enums, exhaustive matching. Applies whenever editing or creating TypeScript files.

validation

Validation discipline for all TypeScript work — Zod as the single validation library, parse at trust boundaries, types inferred from schemas. Applies whenever editing or creating TypeScript files.

voice

Use when toggling nuthouse fun messages on or off globally — /warden:voice [on|off|status]. Controls the shared flag read by warden:voice agent before emitting any decorative persona line.