← ai-atoms

Skills (19)

Bounded, invocable units of AI capability. Each skill declares a system_prompt_fragment — the instruction text injected into the agent when the skill loads — plus inputs, outputs, and applicable domains.

Amendment Author

stable

Guided workflow for authoring and publishing governance amendments against the four canonical files (Constitution, Common, Code, Writing). Walks the full lifecycle: identify the violation or gap, draft the amendment stub, review it against the governance model, apply it to the governance file, and optionally publish it as a versioned amendment atom. Triggers on: /amendment-author, 'author an amendment', 'create an amendment', 'propose a governance change'.

/amendment-author
System prompt fragment
Guide the user through authoring a governance amendment. Step 1 IDENTIFY: ask 'What rule was violated or what gap needs addressing?' Accept a violation file path, free-text description, or override audit log reference. Step 2 LOCATE: find the relevant section in the governance file (Constitution/Common/Code/Writing). Step 3 DRAFT: write the amendment using the strengthen-only rule (amendments may never weaken a parent rule). Step 4 REVIEW: apply the amendment to a local copy and verify no conflicts. Step 5 APPLY: edit the governance file, bump its version, add a changelog entry tagged with the date. Step 6 PUBLISH (optional): create a versioned amendment atom in amendment-atoms. End each step with Did/Next/Blocked/Artifact.

Inputs

violation_or_gap Violation file path, audit log reference, or free-text description of what needs addressing.
target_file ? Which governance file to amend (Constitution/Common/Code/Writing). Inferred if not provided.

Outputs

amendment_text The drafted amendment text ready to apply.
amended_file Path to the updated governance file.
governancemetaatoms amendmentconstitutionlifecycle
skill/amendment-author · v1.0.0

Atom Fleet Status

stable

Full fleet snapshot of all *-atoms.com catalog sites — deploy health, DNS, HTTPS reachability, atom_types per catalog with item counts, schema compliance, /ai/index.json, Terraform backend, sidenav, brand asset uniformity, builder script, federation field, and registry presence. Use when the user asks about the state of the atoms fleet, wants to verify deployments, asks for a fleet snapshot or schema compliance report, or before starting any cross-fleet work.

/atom-status /atom-status tree/atom-status tree <catalog-name>
System prompt fragment
Run the atom fleet status check. For each *-atoms.com catalog site check: (1) deploy status from latest CI run, (2) DNS resolution (LIVE/NONE/STALE), (3) HTTPS apex response code, (4) /ai/index.json reachability, (5) schema spec_version compliance, (6) Terraform vs Wrangler backend, (7) deploy-after-merge gate, (8) open PR count, (9) Classes/Atoms counts. Report as a table grouped by catalog. Flag: Apex 000 but green deploy (DNS gap), /ai/ unreachable on live site, schema below v1.1.0, wrangler.toml present without Terraform, federation not convergent-systems.co.

Inputs

catalog ? Optional: check a single catalog by name (e.g. brand-atoms). Omit for full fleet.

Outputs

fleet_table ASCII table showing status of each catalog across all checks.
needs_attention List of catalogs with actionable issues.
atomsdevopsfleet statusdeploydnscompliance
skill/atom-state · v1.0.0

Atom Publisher

stable

Guided 5-step workflow for drafting, canonicalizing, verifying, and publishing a new atom to the appropriate *-atoms catalog. Supports skill, hook, persona, profile, plugin, amendment, and action atom types. Routes to the correct catalog based on type. Triggers on: /atom-publisher, 'publish an atom', 'create an atom', 'contribute an atom'.

/atom-publisher /atom-publisher skill/atom-publisher hook/atom-publisher persona
System prompt fragment
Guide the user through publishing an atom. Step 1 IDENTIFY: ask what type of atom (skill/hook/persona/profile/amendment/plugin/action) and which catalog it belongs to. Step 2 DRAFT: produce the JSON payload conforming to the catalog's atom-v1.json schema. Required fields: schema, type, id, version, name, description. Step 3 CANONICALIZE: run the catalog's build-exports.py to validate the atom against its schema. Fix any errors. Step 4 VERIFY: confirm the atom is reachable at its canonical URL after building. Step 5 PR: open a PR against the catalog repo with the new atom file. End each step with Did/Next/Blocked/Artifact.

Inputs

atom_type The class of atom to publish (skill, hook, persona, profile, amendment, etc.).
atom_data ? The atom payload fields. Can be partial — the skill will prompt for missing required fields.

Outputs

atom_json The validated atom JSON ready to commit.
pr_url URL of the opened PR against the catalog repo.
atomsmetapublishing workflowcatalog
skill/atom-publisher · v1.0.0

Brainstorm Before Building

stable

Explore user intent, requirements, and design space before writing any code. Surfaces constraints, alternatives, and tradeoffs. Must run before any creative work — features, components, new functionality, or behavior modifications. Prevents building the wrong thing.

System prompt fragment
Before writing any code or UI, run a brainstorming session. Ask: (1) What is the user actually trying to accomplish (not just what they asked for)? (2) What constraints exist (performance, compatibility, existing patterns)? (3) What are 2-3 distinct approaches? For each: pros, cons, implementation complexity, reversibility. (4) What could go wrong? (5) What's out of scope? Surface answers before proposing an approach. Let the user redirect before any implementation begins.
codedesignplanning brainstormrequirements
skill/brainstorming · v1.0.0

Debug

stable

Five-phase systematic debugging (reproduce → isolate → root cause → fix-with-regression-test → verify). Use when the user reports a bug, hits an error or failing test, or wants methodical investigation. Invocable as /debug, /debug "<symptom>", /debug --error <log>, /debug --test <test-name>.

/debug /debug "<symptom>"/debug --error <log-or-file>/debug --test <test-name>
System prompt fragment
Debug using five phases — do not skip or reorder. Phase 1 REPRODUCE: if you cannot reproduce, the bug report is the deliverable; do not guess. Phase 2 ISOLATE: narrow to the smallest surface. Phase 3 ROOT CAUSE: name the root cause before proposing any fix. Phase 4 FIX + REGRESSION TEST: write a failing test first, then the minimal fix that makes it green. Phase 5 VERIFY: run the suite and cite the output. After fixing: 'Why was this not caught?' — name the gap. Apply the 3-cycle cap: after three failed attempts with the same approach, stop, name what is not working, propose an alternative, ask before continuing.

Inputs

symptom Description of the bug, error message, or unexpected behavior.
error_log ? Error log or stack trace (--error mode).
test_name ? Name of the failing test (--test mode).

Outputs

reproduction Confirmed minimal reproduction case.
root_cause Named root cause with evidence.
fix Minimal fix addressing the root cause.
regression_test Test that would have caught this bug.
gap_analysis Why this was not caught and what closes the gap.
codedebugtesting tddroot-causeregressionfive-phase
skill/debug · v1.0.0

Dispatch Parallel Agents

stable

Decompose a multi-task problem into independent units and dispatch subagents in parallel. Use when facing 2+ independent tasks with no shared state or sequential dependencies. Each agent gets a self-contained prompt with full context.

System prompt fragment
Decompose the work into independent tasks. For each task: (1) confirm it has no dependency on another task's output, (2) write a self-contained agent prompt with full context (the agent has no memory of this conversation), (3) specify what files to read/write and what to return. Dispatch all independent tasks in a single message as parallel tool calls. Wait for all to complete. Synthesize results — do not just concatenate agent outputs; identify conflicts and inconsistencies. Tasks with dependencies must be serialized; tasks without can be parallelized.
codeagentsparallelism parallelsubagentdispatch
skill/dispatching-parallel-agents · v1.0.0

Hook Author

stable

Guided workflow for authoring and installing governance hooks to the ~/.ai/hooks/ enforcement plane. Covers the full lifecycle: describe the behavior → write the script → validate → install → test. Supported events: PreToolUse, PostToolUse, Stop, SubagentStop, PreCompact, UserPromptSubmit. Triggers on: /hook-author, 'author a hook', 'create a hook', 'write a governance hook'.

/hook-author
System prompt fragment
Guide the user through authoring a governance hook. Step 1 DESCRIBE: ask what behavior the hook should enforce. Which event (PreToolUse/PostToolUse/Stop/etc.)? Blocking or non-blocking? What trigger pattern? Step 2 WRITE: implement the hook in Python following the _lib.py conventions in ~/.ai/hooks/. For blocking hooks: emit JSON {hookSpecificOutput: {permissionDecision: 'deny', permissionDecisionReason: '...'}}. For non-blocking: emit modified payload or nothing. Always exit 0. Step 3 VALIDATE: run --self-check to verify the hook loads without errors. Step 4 INSTALL: add to ~/.claude/settings.json hooks array. Step 5 TEST: trigger the hook manually and verify it behaves correctly. Also publish as a hook atom to ai-atoms. End each step with Did/Next/Blocked/Artifact.

Inputs

behavior_description What the hook should enforce or observe.
event ? The Claude Code event to hook into (PreToolUse, PostToolUse, Stop, etc.).
blocking ? Whether the hook should block execution on violation.

Outputs

hook_script The Python hook script ready to install at ~/.ai/hooks/.
settings_entry The settings.json hooks entry to wire the hook.
governancemetahooksclaude-code lifecycle
skill/hook-author · v1.0.0

Make — Unified Dispatcher

stable

Dispatcher for the make skill suite. Reads the subcommand and invokes the matching skill immediately. Subcommands: work/sprint (PM + delivery team), clean (purge merged branches), build (commit+push+PR+merge), test (run test suite), status (sprint snapshot), sync (pull all repos), review (code reviewer sweep), doctor (governance health check), atoms (atom ecosystem ops).

/make work /make sprint/make clean/make build/make test/make status/make sync/make review/make doctor/make atoms
System prompt fragment
Read the first word after /make and dispatch to the matching skill immediately. Do not summarize, plan, or ask clarifying questions — just dispatch. Dispatch table: work / sprint → make-work clean → make-clean build → make-build test → make-test status → make-status sync → make-sync review → make-review doctor → make-doctor atoms → make-atoms If the subcommand is unknown or missing, print the usage table and stop.
codedeliverygitproject makedispatcherworkflow
skill/make · v1.0.0

Make Atoms

stable

Discover, fetch, or scaffold skill atoms via the atoms-discover skill. Routes to the atoms binary for ecosystem operations: finding atoms in convergent-systems-co catalogs, fetching atom JSON schemas, scaffolding new atom files, or checking whether an atom exists for a given capability.

/make atoms /make atoms discover/make atoms fetch <slug>/make atoms scaffold <type>
System prompt fragment
Delegate to the atoms-discover skill for all atom ecosystem operations. For discovery: fetch the catalog from the relevant *-atoms.com/ai/index.json and search by type or name. For scaffolding: generate a compliant atom JSON using the catalog's schema. For checking: look up the atom at its canonical URL. Use the atoms binary (ai atoms ...) when available. Never confuse atom management with the ai CLI or ~/.ai/ directory.

Inputs

subcommand ? discover | fetch | scaffold
target ? Atom slug or type for fetch/scaffold.

Outputs

result Atom data, catalog listing, or scaffolded JSON.
atomsmeta discoveryscaffolding
skill/make-atoms · v1.0.0

Make Build

stable

Commit staged changes, push the current branch, open a pull request, and merge after CI passes. Never pushes to main directly. Never squash-merges on non-release branches.

/make build
System prompt fragment
Run the build pipeline: (1) Stage and commit any uncommitted changes using Conventional Commits. (2) Push the branch to origin. (3) Open a GitHub PR with body generated from the branch commit log including 'Closes #<n>' links for any issues referenced. (4) Wait for CI to pass. (5) Merge with a merge commit — no squash on non-release branches. Report: PR URL, CI status, merge SHA.

Outputs

pr_url URL of the opened PR.
merge_sha SHA of the merge commit after CI passes.
codegitdelivery prcimerge
skill/make-build · v1.0.0

Make Doctor

stable

Health check for the AI governance stack and per-repo CI. Runs 'ai doctor', checks hook permissions, verifies CLAUDE.md constitution includes, confirms ~/.ai/memory/ and audit/ exist, and reports CI status on open PRs. Read-only unless --fix is explicitly requested.

/make doctor /make doctor --fix
System prompt fragment
Run the doctor pipeline: (1) Run 'ai doctor' and surface warnings or failures. (2) Verify hook files in ~/.ai/hooks/ are executable (0755). (3) Check ~/.claude/CLAUDE.md contains @~/.ai/Constitution.md (not stale four-file includes). (4) Verify ~/.ai/memory/ and ~/.ai/audit/ directories exist. (5) Check CI status on all open PRs in the current repo. Report each check as PASS/WARN/FAIL with remediation steps. Read-only except when --fix is explicitly requested.

Inputs

fix ? If true, auto-remediate WARN findings where safe to do so.

Outputs

health_report Per-check PASS/WARN/FAIL report with remediation steps.
governancecodedevops healthhooksauditci
skill/make-doctor · v1.0.0

Make Review

stable

Adversarial code reviewer sweep on the current branch diff against main. Hunts for stubs, placeholders, dead imports, unwired exports, and TODO/FIXME in production paths. Returns HIGH/MEDIUM/LOW findings with file:line citations. HIGH blocks merge.

/make review
System prompt fragment
Run the code reviewer sweep on the current branch diff (git diff main...HEAD --name-only). Hunt for: stubs (panic/not-implemented/empty bodies) — HIGH; placeholder values (REPLACE_ME, <YOUR_VALUE>) — HIGH; TODO/FIXME in non-test production files — MEDIUM; unwired exports (zero non-test callers) — MEDIUM; dead imports — LOW; commented-out code blocks — LOW. Every MEDIUM or HIGH finding MUST include a file:line citation and a quoted code snippet. Return verdict: PASS | WARN | BLOCK.

Outputs

findings List of severity-tagged findings with file:line citations.
verdict PASS | WARN | BLOCK
codereview code-qualitystubsadversarial
skill/make-review · v1.0.0

Make Status

stable

Sprint status snapshot: open PRs and their CI state, stale branches, sync gap between local and origin, and any uncommitted work. Read-only — does not modify any files.

/make status
System prompt fragment
Report sprint status across the repo set. (1) List all open PRs with CI status (green/red/pending) and draft state. (2) List local branches ahead of main with commit counts. (3) Show the sync gap — commits on origin/main not yet in local main. (4) Show uncommitted changes and stale worktrees. Format as a status board: Done / In-flight / Blocked / Next-up. Read-only.

Outputs

status_board ASCII status board showing PRs, branches, and uncommitted work.
codegitproject statussprintciread-only
skill/make-status · v1.0.0

Make Sync

stable

Pull all repos in the workspace (primary + submodules) to their default branch heads. Fast-forward only — never rebases, never force-pulls, never touches non-default branches. Reports any repos where fast-forward failed due to divergence.

/make sync
System prompt fragment
Sync all repos to their remote default branch. (1) Discover primary repo and all git submodules. (2) For each repo: git fetch --prune, then pull the default branch (main/master) with --ff-only. (3) Report any repos where --ff-only failed (diverged) without force-pulling. (4) Update submodule pointers in the parent repo if any changed. Never rebase, never force-pull, never touch non-default branches.

Outputs

sync_report List of repos synced successfully and any that diverged.
codegit syncsubmodulespull
skill/make-sync · v1.0.0

Memory Curator

stable

Guided workflow for reviewing, curating, and archiving AI memory entries at ~/.ai/memory/. Identifies stale entries, spots patterns that warrant governance amendments, and archives obsolete memories. Triggers on: /memory-curator, 'curate memory', 'review memory', 'clean up memory', 'audit my memories'.

/memory-curator
System prompt fragment
Curate the memory store at ~/.ai/memory/. Step 1 INVENTORY: run 'ai memory list' and group by type (user, feedback, project, reference). Report total counts. Step 2 REVIEW: for each memory, check: is it still accurate? Is it still relevant? Is it duplicated? Does it contain secrets (violates Common.md §4)? Step 3 IDENTIFY STALE: flag memories older than 90 days for project/reference types; flag feedback memories that contradict current observed behavior. Step 4 IDENTIFY PATTERNS: if 3+ overrides or violations share a root cause, propose a governance amendment. Step 5 CURATE: archive stale entries (move to ~/.ai/memory/archive/), remove duplicates, add missing entries. End each step with Did/Next/Blocked/Artifact.

Inputs

filter_type ? Optional: filter to a specific memory type (user/feedback/project/reference).

Outputs

inventory Summary of memory entries by type with counts.
stale_list Memory entries flagged for archiving.
amendment_proposals Governance amendments warranted by patterns found.
metagovernancememory curationmaintenance
skill/memory-curator · v1.0.0

Review Panel

stable

Guided multi-panel review workflow. Selects review perspectives, runs each pass, aggregates scores, and writes a structured report artifact. Use when you need more than a single-pass review: governance files, PRs, prose drafts, or any artifact that benefits from multiple independent evaluation perspectives (architecture, correctness, documentation quality, adversarial edge cases, security).

/review-panel /review-panel --pr=<number>/review-panel <file-path>
System prompt fragment
Run a multi-panel review. Step 1 SELECT TARGET: confirm the artifact — a PR diff, a file path, or a governance document. Step 2 SELECT PANELS: choose 2-5 review perspectives appropriate to the artifact (e.g. architecture, security, correctness, documentation, adversarial). Step 3 RUN PASSES: for each panel, run an independent review pass and collect findings. Each finding must cite file:line evidence. Step 4 AGGREGATE: compile findings across panels, remove duplicates, rank by severity (HIGH blocks, MEDIUM warns, LOW informs). Step 5 REPORT: write a structured report artifact with panel summaries, consolidated findings table, and verdict (PASS/WARN/BLOCK).

Inputs

target PR number, file path, or governance document to review.
panels ? Optional list of review perspectives. Defaults to [architecture, correctness, security, documentation].

Outputs

report Structured review report with panel summaries and consolidated findings.
verdict PASS | WARN | BLOCK
codegovernancereview multi-panelqualityadversarial
skill/review-panel · v1.0.0

Session Checkpoint

stable

Capture a complete, resumable snapshot of in-flight work to ~/.ai/checkpoints/<owner>__<repo>/CHECKPOINT.md. Records branch, HEAD SHA, dirty files, active goal, decisions made, files in flight, last green state, next step, open questions, and a verify-on-resume list. Use before /clear, at context limits, or at phase boundaries.

/checkpoint /checkpoint auto/checkpoint show/checkpoint resume/checkpoint resume <UTC>/checkpoint list
System prompt fragment
Save a session checkpoint to ~/.ai/checkpoints/<owner>__<repo>/CHECKPOINT.md. Gather: (1) branch + HEAD SHA, (2) dirty files, (3) active goal from issue/plan, (4) decisions made this session with rationale, (5) files in flight with line ranges, (6) last green test/build command, (7) next step (one imperative sentence), (8) open questions blocking progress, (9) verify-on-resume list of assertions that must be re-checked against live state. MUST NOT contain secrets. Write timestamp file and update CHECKPOINT.md pointer.
codesessioncontinuity checkpointhandoff
skill/checkpoint · v1.0.0

Systematic Debugging

stable

Five-phase debugging protocol: reproduce → isolate → root cause → fix with regression test → verify. Use when encountering any bug, test failure, or unexpected behavior. Never proposes a fix before root cause is confirmed. Enforces the 3-cycle local cap and 5-cycle total cap to prevent thrashing.

System prompt fragment
Debug using five phases in order — no skipping. Phase 1 REPRODUCE: establish a reliable reproduction; if you cannot, the bug report is the deliverable. Phase 2 ISOLATE: narrow to the smallest surface. Phase 3 ROOT CAUSE: name the root cause explicitly before proposing any fix. Phase 4 FIX + REGRESSION TEST: write a failing test first, then the minimal fix. Phase 5 VERIFY: run the suite and cite the output. After fixing: 'Why was this not caught?' — name the gap. Cap: after 3 failed attempts with the same approach, stop and propose an alternative. After 5 total attempts, escalate.
codedebug root-causetddregression
skill/systematic-debugging · v1.0.0

Verify Before Claiming Done

stable

Run verification commands and confirm output before claiming any work is complete, fixed, or passing. Evidence before assertions always. Use before committing, opening PRs, or reporting success. Never cite your own reasoning as proof.

System prompt fragment
Before claiming work is complete: (1) Run the relevant verification command (test suite, build, type-check, lint). (2) Cite the actual output — not a summary, the output. (3) For 'tests pass': cite the test runner output with pass count. (4) For 'build succeeds': cite the build tool output and exit code. (5) For 'fix works': run it and cite the run. If you cannot produce the independent source, downgrade the claim to 'I believe X but did not verify' and surface the gap.
codetestingquality verificationevidenceci
skill/verification-before-completion · v1.0.0