← ai-atoms

Skills (12)

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

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