jwogrady

audit

Audit a whole project directly in-session with a small dispatched crew, in one of two modes — assess produces an evidence-cited health report across documentation, architecture, code quality, testing/reliability, security/config, and product readiness; purge removes what is proven dead or false (stale code, untrue docs, stale branches, unused dependencies) behind a human approval gate. Use when preparing for a release or external review, assessing overall project health, or purging dead code, doc drift, and stale branches. Not for a single diff or PR — use the native /code-review and /security-review, or `validate` to orchestrate them on one branch.

connect

Bootstrap a project's external service connectivity and secrets — capture API keys, load them into 1Password, verify each connection, and shred the plaintext. Use when setting up GitHub/Google Cloud/Vultr/Linode access, wiring API keys, configuring 1Password (op), or connecting a new project to its providers. Not for scaffolding the project runtime — use `bootstrap` for that.

docit

Generate or refresh a repo's public-facing docs (README, philosophy/motivation, positioning, launch copy) by writing through a small crew of author personas, then assembling them with an Editor-in-Chief. Use when the user wants to "glow up" a repo to attract GitHub stars, write or rewrite the README, articulate the project's philosophy, or produce launch/marketing copy aimed at developers. Not for internal knowledge — the Spark core's knowledge skill owns that.

AI & Automation Listed

agents-md

Create, maintain, and audit a repo's AI-agent contract — one canonical AGENTS.md body plus a CLAUDE.md pointer stub that imports it. Use to write, update, audit, or drift-check AGENTS.md or CLAUDE.md, or to collapse a dual-body pair into the single-body model. Defers net-new repo scanning to native /init. Not for prose docs — use `docit` (public) or `knowledge` (internal).

bootstrap

Scaffold a new project's runtime — choose frontend/backend and framework, run the canonical scaffolder (Bun or uv defaults), and wire it into the lifecycle. Use when starting a new project or setting up a frontend/backend stack. Not for wiring services or secrets (`spark-connect`), nor framing/planning (`ideate`/`plan`).

codify

Implement one planned GitHub issue on a feature branch as focused conventional commits, scoped to that issue's acceptance criteria. Use to start coding an issue or a planned feature. Not for reviewing/hardening the result (`validate`) or publishing the branch as a PR (`ship`).

ideate

Frame a problem in writing before any code — a sharp problem statement with success criteria, constraints, and a prior-art survey. Use when starting something new, when scope is still fuzzy, or when re-planning a rewrite. Not for breaking work into issues (`plan`) or writing code (`codify`).

knowledge

Turn messy notes, findings, and decisions into clean, durable internal docs — ADRs, system docs, product specs, SOPs/runbooks, glossary entries — via a three-role crew (intake → author → librarian-editor). Also the deliberate promotion path — glossary terms to the operator store, and durable cross-project learning to the project's configured memory hub, evidence-cited and human-approved (ADR-0028). Use to record a decision, document a system or process, or promote a durable cross-project lesson. Not for outward-facing marketing or README glow-ups — that's `docit` (public docs).

onboard

Guide a repository's first run as one narrative — orient, choose a setup profile, seed hooks + permissions + standards docs, and close with a brief. Stops at each human decision. Use when arming a repo for the first time or when a brief reports it unclassified/unarmed. Not for scaffolding a new runtime (`bootstrap`) and not the mechanical seed itself (`spark setup`, the one-command carry-in).

plan

Turn a framed problem into an implementation approach (stack/architecture as ADRs), a feature breakdown, and GitHub issues plus a milestone. Use to decide the stack, break work into issues, or scope a milestone after `ideate`. Not for framing the problem (`ideate`) or implementing it (`codify`).

ship

Publish reviewed work — verify the branch's commit series, push it, and open one focused pull request. Use to push, open a PR, or land finished work. Not for writing the code or its commits (`codify`), or running the reviews (`validate`); it assumes an already-reviewed, already-committed branch.

validate

Review and harden one change — run the built-in /code-review and /security-review on the branch diff, triage findings, and fix until acceptance criteria hold. Use to harden a single change/branch/PR or resolve review findings after `codify`. For a whole-codebase audit rather than one diff, use `audit`.