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 during strict issue planning or on a feature branch before/during PR creation to detect drift against the authoritative SDD Acceptance and constraints. Planned-intent mode emits hash-bound local evidence; branch mode can optionally post the report as a PR comment.

write-checklist

Use during strict issue planning or when a feature approaches QA/PR review to derive a per-spec acceptance checklist. It preserves source AC ids, writes an open checklist, and never treats checklist generation as human feature acceptance.

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". Commits an existing staged selection, or stages dirty changes automatically while preserving any explicit file scope. 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. Drafts from branch history and, after confirmation, publishes the branch before creating the PR. 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 48 bundled skills

create-issue

Use to create a single Linear Issue with a strict SDD-formatted description or resume a legacy partially committed create-project cascade. Adaptive cascades resume only through create-project. Standalone mode drafts and previews via issue-drafter; legacy resume mode reuses the exact pre-approved issue packet and dependency metadata from chain-state, then updates progress and recommends the next issue.

create-milestone

Use to add a single Milestone to an existing Linear Project (standalone add-on) or to resume a legacy partially-committed create-project cascade. Adaptive cascades resume only through create-project. Reads chain-state to detect legacy 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.

create-project

Use when creating a Linear Project end-to-end from an Acid Prophet artifact set, a spec file, or vibe-mode Q&A. Drafts the project plus complete traceable issue packets and their dependency graph before one approval gate, then batch-creates everything on Linear and recommends the first startable issue. Supports idempotent resume after partial failure.

greet

Use only at fresh session start when a Linear issue identifier is detected from the current branch or explicitly provided in the user's first prompt, and no Linear issue context is already available. Never use on resume or compaction, from an existing conversation summary, or on main/master/staging without an issue identifier. Delegates issue context to issue-context, binds the workflow decision and source authorities, writes greet context, then hands off to plan. Never writes implementation code.

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.

plan

Use when planning implementation for a Linear issue after greet or from an issue id. Loads the authoritative issue-delivery decision and source artifacts, creates the profile-appropriate issue plan, audits it, and emits a named hash-bound implementation handoff. Never writes implementation code.

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 or merged and the autopilot relay must move on — auto-invoked by git-gremlin:pr in autopilot, or "issue suivante", "continue le relais", "next movement". Reviews an open PR and records the human acceptance, then waits for that exact PR to be merged into its base branch. Only a verified merged PR can resolve and spawn the next issue. Does not merge. Does not use local relay-state as queue authority.

halt

Use when the user wants to stop an autopilot relay — "arrête l'autopilote", "baton down", "stop the relay", "autopilote off", "coupe le relais". Disarms one Linear project's control flag so no further worktrees spawn. With several projects armed in one repo, infer the current branch's project or require an explicit issue/project; `--all` is the explicit all-projects escape hatch. `--legacy` disarms the old pre-project-scoping relay once during migration. It does not maintain or edit a local issue queue; Linear and GitHub remain the authority.

orchestrate

Use when the user wants Monkey Maestro to run an active Linear project. Loads Linear once, creates branch-idempotent Superset workspaces in parallel, launches only missing agents, and returns immediately.

DevOps & Infrastructure Listed

reconcile

Use when the user explicitly asks Monkey Maestro to audit or repair Superset runtime correlation and best-effort execution records. It is optional, candidate-scoped, GitHub-free, never adopts the Linear graph, never gates orchestration, and never dispatches work.

run

Use when the user wants to start the autopilot relay over a Linear project — "lance l'autopilote", "enchaîne mes issues", "run the relay", "autopilote on", "conduct my backlog". Resolves the project from a starting issue, atomically arms that project's control flag, and spawns its first worktree. Several Linear projects can run concurrently in one Git repo; one project cannot have two relays. Linear remains the source of truth; no local relay queue is maintained. Do not use to stop the relay (monkey-maestro:halt) or to advance after acceptance (monkey-maestro:advance).

spawn

Use when the user or branch guard explicitly wants one Linear issue in one task-linked Superset workspace. Applies the same live Linear planner, issue-scoped force rules, exact runtime idempotence, and short lock as project orchestration; active controls supply configuration instead of blocking spawn.

start

Use when the user wants to activate Monkey Maestro for a Linear project. Writes one minimal control v2 after a single approval and enters Linear-first orchestration; graph receipts, GitHub, and Superset availability are not activation prerequisites.

status

Use automatically when the user supplies a Linear project URL or asks to inspect one project's Maestro state. Reads only the minimal control plus live Linear statuses and blockedBy links, reports the deterministic frontier, and never inspects Superset or requires reconciliation.

stop

Use when the user wants to stop future Monkey Maestro dispatches for a Linear project. Performs one Linear-only minimal-control update to active:false; Superset availability can never prevent stop and existing workers remain untouched.

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, before commit or PR, to verify an issue-delivery packet. Uses Moon's affected graph when present and documented repository-native commands otherwise; returns hash-bound evidence and loops back on failure.

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 TypeScript — named exports, declarative entry points, one responsibility per file, explicit package boundaries, and reuse before writing. Applies whenever editing or creating TypeScript files.

API & Backend Listed

form-rules

Form discipline for TypeScript — the schema is the only converter, input and output are different types, a required field is seeded blank not absent, submit is never gated on validity, and each failure names itself.

hono-pipeline

Implementation discipline for Hono with a typed RPC/contract stack — discover local conventions, then move contract → resource error → pure service Result → exhaustive unwrap → thin router → wiring.

Web & Frontend Listed

react-rules

React implementation discipline — one component per file, folders mirror JSX ownership, children receive stable IDs/primitives, state lives at the highest durable layer, and styling ownership stays explicit.

DevOps & Infrastructure Listed

result-pattern

Result/error discipline for backend domain and service code — expected outcomes return Result variants, infrastructure failures stay exceptional, and one exhaustive unwrap translates at the transport edge.

state-machine

State-machine discipline for TypeScript lifecycle, workflow, reducer, and state-machine files — make illegal states unrepresentable, keep transitions pure and exhaustive, and design for replay and concurrency.

Testing & QA Listed

testing-discipline

Testing discipline for TypeScript test files — reproduce regressions first, test observable behavior and typed failures, keep doubles at owned boundaries, and preserve unexpected rejections.

type-safety

Type-safety discipline for all TypeScript work — prove unknown values, avoid any/as/non-null assertions, prefer inference and exhaustive unions. Applies whenever editing or creating TypeScript files.

validation

Validation discipline for TypeScript — one schema source of truth, parse data once at each trust boundary, and derive static types 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.