caspar

Use when modifying the Codex CASPAR install flow, project skill syncing, learn/recall registry files, or Codex-specific runtime files. TRIGGER when: codex, caspar, codex install, project skills, registry, caspar-learn, caspar-recall, config.toml, doctor

Run an independent adversarial code review of completed work using a pinned high-effort opposing runtime, with a same-contract native fallback. Finds bugs, correctness and security failures, regressions, performance landmines, overengineering, and missing behavioral tests. Review only; never edits code.

Build the planned feature from a compact execute.md index and sliceable tasks.json detail, dispatching parallel task waves through deterministic checks, lightweight sentinel review, and final adversarial review/validation. Trigger after execute.md/tasks.json exist or to resume a partially-built wave plan. Do NOT trigger for scoping/planning, unplanned bug-fixing, or dead-code cleanup (caspar-prune).

Use when rendering the Next Steps footer at the end of any caspar command, suggesting which caspar command to run next, or answering "what command should I run?" / "how does the workflow work?". Do NOT use mid-task or for executing a phase — this only renders guidance and the footer.

Independent adversarial review of plan.md before task generation. Use a pinned high-effort opposite-runtime reviewer; fall back to one native reviewer with the same contract when unavailable. Trigger after create_plan and before create_tasks. Do NOT review generated tasks, finished code, or apply scope changes.

Adversarial review of generated execute.md + tasks.json against a reviewed plan using a pinned high-effort opposite runtime, with a same-contract native fallback. Checks translation, criteria, RED pairing, dependencies, waves, and alignment. Do NOT review plan quality, finished code, or change scope.

Run an independent adversarial code review of completed work using a pinned high-effort opposing runtime, with a same-contract native fallback. Finds bugs, correctness and security failures, regressions, performance landmines, overengineering, and missing behavioral tests. Review only; never edits code.

Build the planned feature from a compact execute.md index and sliceable tasks.json detail, dispatching parallel task waves through deterministic checks, lightweight sentinel review, and final adversarial review/validation. Trigger after execute.md/tasks.json exist or to resume a partially-built wave plan. Do NOT trigger for scoping/planning, unplanned bug-fixing, or dead-code cleanup (caspar-prune).

Use when rendering the Next Steps footer at the end of any caspar command, suggesting which caspar command to run next, or answering "what command should I run?" / "how does the workflow work?". Do NOT use mid-task or for executing a phase — this only renders guidance and the footer.

Independent adversarial review of plan.md before task generation. Use a pinned high-effort opposite-runtime reviewer; fall back to one native reviewer with the same contract when unavailable. Trigger after create_plan and before create_tasks. Do NOT review generated tasks, finished code, or apply scope changes.

Adversarial review of generated execute.md + tasks.json against a reviewed plan using a pinned high-effort opposite runtime, with a same-contract native fallback. Checks translation, criteria, RED pairing, dependencies, waves, and alignment. Do NOT review plan quality, finished code, or change scope.

Break requirements into executable task artifacts: a compact execute.md index plus sliceable tasks.json detail with typed acceptance criteria, RED-test pairing, and dependency waves. Trigger after scope/plan when you need concrete build tasks before execute. Do NOT trigger to set scope, design architecture, or run implementation.

Unified planning entry point: classify tier, run tier-sized research, then route to the smallest safe plan→task-artifacts→review workflow. Use after scope or for "plan this/how build this" requests. Do NOT trigger for scope, specific bug diagnosis, or direct task breakdown.

Break requirements into executable task artifacts: a compact execute.md index plus sliceable tasks.json detail with typed acceptance criteria, RED-test pairing, and dependency waves. Trigger after scope/plan when you need concrete build tasks before execute. Do NOT trigger to set scope, design architecture, or run implementation.

Unified planning entry point: classify tier, run tier-sized research, then route to the smallest safe plan→task-artifacts→review workflow. Use after scope or for "plan this/how build this" requests. Do NOT trigger for scope, specific bug diagnosis, or direct task breakdown.

Run the lightweight Caspar release flow: commit pending Caspar changes, sync Codex assets, run tests, bump marketplace/plugin/package versions, commit and push, refresh the user-level Codex install, and print the Claude Code marketplace update command. Use when the user asks to release, ship a Caspar version, bump Caspar, or update local installs after Caspar prompt/plugin changes.

Meta cleanup workflow: orchestrate prune, risk-based automated tests, and sweep/commit through focused subagents. Use after execute/validate or when asked to clean up a finished branch end-to-end. Do NOT trigger for dead-code-only cleanup (caspar-prune), test-only work (caspar-test), commit-only hygiene (caspar-sweep), bug fixes (caspar-fix), or scoping/planning.

Find and remove confirmed-safe dead code and artifacts from a scoped working set — orphaned imports/exports, unused code, commented-out blocks, debug/temp logging, duplication, AI slop — while surfacing uncertain items for manual review. Use for dead-code/artifact cleanup only, standalone or as the prune phase inside caspar-clean. Do NOT trigger for adding tests (caspar-test), final commit hygiene (caspar-sweep), bug fixes (caspar-fix), or broad behavior-changing refactors.

Light pre-commit cleanup pass — diff sanity, log/dead-code hygiene on changed files, strict lint, run related + broad tests, then conventional-commit. Use when wrapping up uncommitted or just-finished work before check-in ("sweep", "clean up and commit", "tidy this diff"), standalone or as the final phase of caspar-clean. Do NOT use for forensic dead-code removal across the codebase (use caspar-prune), for authoring new tests (use caspar-test), or as a full validation gate — this is a fast hygiene+commit pass, not deep review.

Triage a working set into risk tiers (P0–P3) and add risk-appropriate behavioral tests — thorough coverage where bugs hurt users (auth/payment/security/PII), light or none on low-risk code — fixing lint and committing per passing batch. Trigger after a feature is built or when asked to add/strengthen tests for recent changes; when invoked by caspar-clean, consume the primary's risk plan and execute the assigned test batch. Do NOT trigger for brute-force 100%-line-coverage demands, dead-code cleanup (caspar-prune), bug fixes (caspar-fix), final commit hygiene (caspar-sweep), or scoping/planning.

Validate that completed implementation actually delivers the scope/tasks requirements — chunks the work into areas, dispatches parallel @caspar:analyst validators that trace each requirement from user action to render, and writes one actionable validation_gaps.md ranking what's Delivered / Partial / Dead Code / Missing. Trigger after execute (or any build) when you need to confirm requirements are met before clean/test/ship. Do NOT trigger to fix the gaps (caspar-fix), to run the test suite (caspar-test), or to remove dead code (caspar-prune).

Meta cleanup workflow: orchestrate prune, risk-based automated tests, and sweep/commit through focused subagents. Use after execute/validate or when asked to clean up a finished branch end-to-end. Do NOT trigger for dead-code-only cleanup (caspar-prune), test-only work (caspar-test), commit-only hygiene (caspar-sweep), bug fixes (caspar-fix), or scoping/planning.

Find and remove confirmed-safe dead code and artifacts from a scoped working set — orphaned imports/exports, unused code, commented-out blocks, debug/temp logging, duplication, AI slop — while surfacing uncertain items for manual review. Use for dead-code/artifact cleanup only, standalone or as the prune phase inside caspar-clean. Do NOT trigger for adding tests (caspar-test), final commit hygiene (caspar-sweep), bug fixes (caspar-fix), or broad behavior-changing refactors.

Light pre-commit cleanup pass — diff sanity, log/dead-code hygiene on changed files, strict lint, run related + broad tests, then conventional-commit. Use when wrapping up uncommitted or just-finished work before check-in ("sweep", "clean up and commit", "tidy this diff"), standalone or as the final phase of caspar-clean. Do NOT use for forensic dead-code removal across the codebase (use caspar-prune), for authoring new tests (use caspar-test), or as a full validation gate — this is a fast hygiene+commit pass, not deep review.

Triage a working set into risk tiers (P0–P3) and add risk-appropriate behavioral tests — thorough coverage where bugs hurt users (auth/payment/security/PII), light or none on low-risk code — fixing lint and committing per passing batch. Trigger after a feature is built or when asked to add/strengthen tests for recent changes; when invoked by caspar-clean, consume the primary's risk plan and execute the assigned test batch. Do NOT trigger for brute-force 100%-line-coverage demands, dead-code cleanup (caspar-prune), bug fixes (caspar-fix), final commit hygiene (caspar-sweep), or scoping/planning.

Validate that completed implementation actually delivers the scope/tasks requirements — chunks the work into areas, dispatches parallel @caspar:analyst validators that trace each requirement from user action to render, and writes one actionable validation_gaps.md ranking what's Delivered / Partial / Dead Code / Missing. Trigger after execute (or any build) when you need to confirm requirements are met before clean/test/ship. Do NOT trigger to fix the gaps (caspar-fix), to run the test suite (caspar-test), or to remove dead code (caspar-prune).

Generate a high-quality pull request from the actual diff and open it via gh — derives What from the diff, Why from commits/linked issue/branch, Testing from real test changes, scales the template to PR size, self-verifies every claim against a diff hunk, then runs gh pr create. Use when wrapping up a branch and asked to open a PR or write a PR description. Do NOT use to commit/clean the diff first (caspar-sweep), to rebase history (caspar-rebase), or for the full autonomous brain-dump→PR flow (caspar-ship).

👻 | Autonomous end-to-end delivery — brain dump → scope → TDD → sweep → rebase → PR, zero confirmation gates. Use when you want a reviewable PR produced hands-off from an informal description. Do NOT use when you want approval checkpoints (use the staged scope/plan/execute flow), or for non-code/non-git work.

Generate a high-quality pull request from the actual diff and open it via gh — derives What from the diff, Why from commits/linked issue/branch, Testing from real test changes, scales the template to PR size, self-verifies every claim against a diff hunk, then runs gh pr create. Use when wrapping up a branch and asked to open a PR or write a PR description. Do NOT use to commit/clean the diff first (caspar-sweep), to rebase history (caspar-rebase), or for the full autonomous brain-dump→PR flow (caspar-ship).

👻 | Autonomous end-to-end delivery — brain dump → scope → TDD → sweep → rebase → PR, zero confirmation gates. Use when you want a reviewable PR produced hands-off from an informal description. Do NOT use when you want approval checkpoints (use the staged scope/plan/execute flow), or for non-code/non-git work.

Use when user wants to search for existing knowledge, recall a specific learning, or discover what knowledge is available.

Rewrite a verbose SPECTRE skill into a compact, contract-form Caspar skill proposal — clear on WHAT, silent on HOW — grounded in the caspar-light distillation and freedom-tier budget. Use when compressing or forking a `spectre-*` skill into `caspar-*`, when the user says "rewrite/compress this skill" or "run the Caspar light-rewrite", or to QC a draft skill against the budget and load-bearing checklist. Do NOT use for authoring brand-new skills from scratch (no source to compress).

Rewrite Caspar subagent definitions into compact, contract-driven agents with clear routing, least-privilege tools, output schemas, and an auditable rewrite trail. Use when reviewing or rewriting `plugins/caspar/agents/*.md`, when the user asks to improve subagents/agent definitions, or when checking generated `plugins/caspar-codex/agents/*.toml`. Do not use for rewriting workflow skills; use `caspar-rewrite-skill` for `SKILL.md` compression.

Run the Caspar release workflow, including version bumps, Codex sync, global Codex install verification, GitHub release, manual npm publish handoff, npm verification, and final global Codex refresh.

Turn a PRD/scope into a technical implementation plan (`plan.md`) — codebase research, clarifications, then a verification-spine plan ready for task breakdown. Use when planning HOW to build an already-scoped feature, or when `plan` routes here with a depth tier. Do NOT trigger to define WHAT/why (that's `scope`), to break a plan into tasks (`create_tasks`), or for design/UX flows (`ux`).

Generate a right-sized manual test guide for completed work — feature-based checklists scaled to change size, focused on risk. Use after execute/validate when you need a human-runnable QA pass before clean/test. Do NOT use to write automated tests (that's the test phase) or to validate wiring (that's validate).

Investigate a reported bug, pin the root cause, and implement a verified fix. Use when given an error, stack trace, failing behavior, or repro steps and asked to diagnose and fix it — the diagnose-then-fix loop. Do NOT use for greenfield feature work (use plan/execute) or for fixes already root-caused with an approved approach (go straight to execute).

Project kickoff — deep codebase + external research producing an evidence-backed kickoff doc, gap analysis, and MVP path before scoping. Use to start a fresh feature/project from an unclear problem, when the user wants research/options/an MVP recommendation before committing to scope or a plan. Do not trigger once scope is already defined (use /caspar:scope) or for a single targeted code question (use an analyst agent directly).

Use when the user invokes /learn or asks to remember, save, or capture a pattern, decision, gotcha, procedure, or feature dossier from this session for later re-use ("please remember", "what did we learn?"). Captures durable project knowledge as an on-demand Skill. Do NOT trigger for simple personal preferences (those go to CLAUDE.md) or for recalling existing knowledge (that is /caspar:recall).

Generate a single self-contained, clickable HTML prototype to make a feature visible before planning — resolving ambiguity pre-scope, validating flows pre-plan, or rendering an approved UX spec for stakeholder review. Triggers on "prototype this", "mock up the UI", "make a clickable preview", or a mid-flow `ux` Stage 1→2 transition. Do NOT trigger to write production app code, build a multi-file frontend, or plan/scope the work itself — this produces one throwaway HTML file only.