Claude Code Skills · page 137

Pick the next most important open GitHub issue this agent can actually complete, make its done-condition true, land it with witnesses (suite + parity + commit-audit), and priority-tag every issue touched along the way. Use when asked to "work the backlog", "complete the next most important issue", or to fix a specific issue number end-to-end.

Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.

Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/<codename> git tag on the same commit. Does NOT bump versions or build new artifacts.

One automatic plan-class lifecycle tick. Reads the DECLARED class set + transition list from the workspace `[lifecycle]` table (not a hardcoded taxonomy), evaluates each trigger, spawns a read-only JUDGE-rung adjudicator (the `dos.judges` seam — advisory, fail-to-abstain) to approve/defer each candidate transition, applies the gated transitions as plan-meta edits + one commit per cycle, and logs to the run archive. Failsafes (per-cycle cap, per-plan cooldown, a veto class) are `[lifecycle]` data; the judge content is a host `dos.judges` driver. Every path/class comes from `dos doctor --json`. Use to garden a plan portfolio's lifecycle automatically, judge-gated. The DOS lifecycle gardener (SKP Axis 5, docs/207 Phase 5c).

Run /dos-dispatch on a recurring cadence, alternating with /dos-replan when the backlog drains — the dispatch→replan→dispatch cycle. The continue/stop/next-mode decision is the kernel's typed loop decision, not inline prose: each iteration is classified (`dos gate`) into a verdict and the loop's counters (drained-twice, the unclear/dirty-zero breakers, the iteration cap) drive the next step. Several loops on disjoint lanes run concurrently, each taking its own lane lease via `dos arbitrate`. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference loop workflow (SKP Axis 5).

End-to-end plan-and-ship for one lane — snapshot the portfolio with /dos-next-up, take a lane lease via `dos arbitrate` so parallel dispatches don't collide, gate the empty case via `dos gate`, ship the packet, and archive the run under the configured run dir. Driven entirely by `dos` verbs + the workspace's `dos.toml`; names no host path, lane, or commit convention. Use when you want to plan and ship the next batch on one lane in a single command, with concurrency safety. The DOS reference dispatch workflow (SKP Axis 5).

Ground a "keep working until the goal is met" stop condition in a witness the agent did not author, instead of letting the agent self-certify "done". A harness goal/Stop-hook condition is normally checked by the model re-reading its OWN work — consistency, not grounding. This skill turns the operator's goal into checkable EFFECT claims and wires `dos hook stop` so the Stop is refused until git ancestry (a shipped phase) or an effect read-back corroborates the claimed effect. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when you want a self-stopping agent (or a `/loop` worker) to be unable to declare a goal complete on its own say-so. The single-agent self-stop analogue of `dos-witness-claim`.

Snapshot a repo's phased-plan portfolio and produce a parallel-agent dispatch packet, driven entirely by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Walks the configured plans glob, audits each candidate pick against `dos verify` for its true shipped/unshipped status, renders a self-contained packet to the configured output dir, and reports a typed gate verdict via `dos gate`. Use when you want a "where are we / what's next / who-does-what" snapshot of any repo that has a few plan docs and real commits. This is the DOS reference workflow (SKP Axis 5); a host may use it, fork it, or ignore it.

The visibility-inverse of lifecycle-demote. Run `dos pickable` over every declared unit; for each HELD unit, surface it with its typed HoldReason and the derived unblock action (DRAFT_CLASS→promote-to-active, UNPARSEABLE→inspect-the-deriver, OPERATOR_GATED→raise-a-decision, SOAK_OPEN→wait, DEPENDENCY_UNMET→ship-the-prerequisite). The only auto-applied action is a safe mechanical reclassify (gated, one commit); everything else is surfaced for a human via `dos decisions`. Every path/lane/class comes from `dos doctor --json`. Use when units are stuck un-pickable and you want each one's typed reason + the right unblock move. The operator-facing half of the shipped `pickable` gate (SKP Axis 5, docs/207 Phase 5b).

Run /dos-replan on a fixed cadence for a bounded number of iterations, then stop — an unattended planning-refresh sweep. A thin recurring wrapper over /dos-replan plus an optional guarded release; the release guard reads the workspace's trunk from config rather than assuming a branch name. Driven by `dos` verbs + the workspace's `dos.toml`. The DOS reference planning-loop workflow (SKP Axis 5).

Garden a repo's plan portfolio from accumulated evidence — detect closures (a queue item whose phases now `dos verify` as shipped is done), track cooldown state, and surface the 0-2 items the operator must actually decide via the `dos decisions` queue. Read-only on code/data; writes only its queue + cooldown state. Driven by `dos` verbs + the workspace's `dos.toml`; names no host path or convention. Use after a burst of dispatches, when the backlog looks drained, or when recurring findings start hurting throughput. The DOS reference planning-sweep workflow (SKP Axis 5).

Run a self-improving work loop where the kernel — not the agent's say-so — decides whether each candidate change actually improved the codebase. The propose→verify→measure→keep-or-revert cycle with one rule no prior auto-improver enforced: a candidate is KEPT only if a witness the candidate's author did not write CONFIRMS it improved (the test suite green on a clean worktree, the truth syscall clean, and a strictly-measured metric gain). Otherwise it is REVERTED. The keep/revert/escalate decision is the kernel's typed `improve` verdict (`dos improve`), not inline prose; a run of non-keeps trips a breaker that ESCALATEs to a human. Each candidate is applied in an ISOLATED git worktree so the kernel adjudicating it is never the kernel being rewritten. Driven entirely by `dos` verbs + the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. The DOS reference recursive-self-improvement loop (SKP Axis 5, docs/280).

One-time check that the DOS kernel plugin is ready to use — confirm the `dos-kernel` Python package is importable (the hooks and MCP server need it), report what the plugin bundled (hooks, the `dos` MCP tools, the generic skill pack), and point at the next skill to run. Use right after installing the dos-kernel plugin, or when `/mcp` shows the `dos` server failing to start or a `dos hook` command erroring. Read-only: it runs `dos doctor` to confirm wiring; it installs nothing and changes no config.

Show what the bundled DOS hook binary has been doing — fold its per-call observation log into an at-a-glance report (how many tool calls it adjudicated, how many it DENIED / WARNED / passed through, which reason classes fired, how often verify-on-stop blocked a false \"done\", the wait-marker budget, and per-verb latency). Use when you want to see the trust substrate's OWN activity on this project, confirm the native fast-path is actually serving calls (not silently delegating to Python), or check how fast the hooks run. Read-only: it folds a log the hooks already wrote; it takes no lease, launches nothing, and changes nothing.

Keep a target population of worker dispatch-loops alive across a workspace's lane roster — the supervisor cadence (the init/PID-1 analogy for a fleet). Each tick reads the active lane taxonomy from `dos doctor --json`, asks the kernel for a spawn/reap/flag plan via `dos loop --target N --json`, launches one `/dos-dispatch-loop` per SPAWN, scavenges only STALLED leases, and SURFACES (never kills) a SPINNING worker. The spawn/reap/flag decision is the kernel's typed `supervise()` verdict, not inline prose — the supervisor only carries out the plan. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference supervisor workflow (SKP Axis 5).

Sweep the run-archive trail of BLOCKED/DRAIN verdicts, normalize each to a canonical cause via the recurring-wedge fold, cluster by recurrence × stall-cost, and propose ONE structural fix per recurring cause — a contract/oracle/preflight change, never a one-off unblock. Read-only on code; surfaces via `dos decisions`. The cause taxonomy is `[reasons]` data; every path/lane comes from `dos doctor --json`. Use when a fleet keeps stalling on the same thing across runs and you want the structural fix, not another manual unblock. The DOS operator remediation sweep (SKP Axis 5, docs/207 Phase 5a).

Route a subagent's actionable claims through the witness rung instead of folding its return string. For any worker whose deliverable is a CHECKABLE EFFECT — a shipped git phase, a created file, a DB row, a sent message — do NOT believe what the worker said it did; extract the claim at the boundary, gather an independently-authored read-back, and fold ONLY the confirmed effects. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use at a `parallel()`/`pipeline()` barrier, a synthesis step, or any fold site where one agent's output becomes another's input. This is the DOS reference pattern for the docs/197 §7(2) witness-routing stage; the seam below is honest about which steps have a CLI verb and which are Python-API-only today.

Before accepting an agent's 'done / shipped / fixed' claim, verify it against ground truth (git ancestry + the commit's own diff) using the DOS kernel's `dos verify` and `dos commit-audit` — never the agent's own narration.

Run the DOS enforcement-policy self-tuning loop. Use when Codex should tune `[intervention_policy]`, `[intervention]`, or `[improve]` knobs from observed false-deny vs held-catch outcomes with `dos enforce-tune`, measuring candidates in an isolated worktree and keeping only kernel-witnessed improvements: suite green, truth clean, strict net_task_delta gain, and no runtime-logic edits. Driven by `dos` verbs and workspace `dos.toml`; escalate after repeated non-keeps. (docs/365).

Launch N independent headless worker instances in account-balanced waves, each armed with ONE goal whose "done" is gated on a witness the worker did not author — not on its own say-so. Each objective becomes one self-stopping child wired to `dos hook stop` (the `dos-goal-gate` discipline), co-launch safety comes from `dos arbitrate` over each child's file-tree, and every claimed ship is confirmed by `dos verify` / `dos commit-audit`, never by a transcript line. Driven by `dos` verbs and the workspace's own `dos.toml` — names no host path, runtime, model, or account mechanism. Use when an operator hands a context with several independent objectives and says "launch a worker per goal", "fire a wave of goal agents", or "run these N goals in parallel". The fan-OUT analogue of `dos-goal-gate` (one self-stopping leaf) and `dos-witness-claim` (the fold).

Price a PROPOSED multi-agent fan-out BEFORE any worker launches — from the kernel's own agent-blind file-tree geometry, not a self-report. Given the partition a fan-out is about to hand its workers (N agents x declared trees), compute the collision graph, the true collision-free maximum concurrency, the safe set to run now, and the cheapest disjoint re-partition — so a colliding plan is refused with zero agents launched instead of discovered after the Kth acquire already raced. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use before a `dos-goal-fleet` wave, before dispatching a `dos-next-up` packet, or any time an operator says "fan these N agents out over these trees" and you want the price before the launch. The PREDICTIVE complement to `dos arbitrate` (EXAMPLES.md R2), which is the reactive floor that refuses one colliding acquire at a time.

Convert any agent skill into a trust-grounded variant — read the skill, find every place it believes a worker's word (a self-certified "done", an ungrounded "it shipped", a blind file-edit, a filter(Boolean) fan-out fold), and emit an ADDITIVE new-copy variant whose trust seams shell a `dos` verb and read the verdict, plus a re-derivable conversion report. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when an operator hands you a skill and says "make this DOS-aware", "ground this skill's self-checks", or "what would DOS add to this skill". The converter is itself a judged agent — it abstains on an unwitnessable claim and its output is admitted by witness, never by its own say-so.

>

Version bump and optional PyPI release for goodeye-cli. Use when bumping the version, cutting a release, or pushing a git tag to trigger PyPI publish.

Use when creating, editing, inspecting, exporting, or troubleshooting Flato designs through Flato Design MCP tools such as flato_whoami, flato_get_design_context, flato_create_pages, flato_update_pages, flato_update_canvas, and flato_export_to_png.

>

>

>

>

Print and physically mail documents and postcards to US postal addresses via the PostAgent API, send certified/registered mail with proof of delivery, verify postal addresses for deliverability, and (KYC-verified senders only) run bulk mail campaigns. Use when the user wants to send real, physical mail — a letter, notice, invoice, or postcard — to a US recipient, or to check whether a postal address is deliverable. Each send is paid per-call in USDC on Base using the x402 protocol, so it spends real money and is irreversible once submitted.

Professional frontend standards for building, scaffolding, extending, or reviewing any UI or frontend project — new or existing — even when standards aren't explicitly asked for. Keeps generated code consistent, reusable, secure, and production-quality. Framework-agnostic: React, Vue, Angular, Svelte, plain JS.

Access your Vibo (vibodj.com) event music planning via MCP. Use when the user asks about their Vibo events, wedding/event timeline, song requests, playlists, or "do not play" list, or wants to add or like songs, join an event from a share link, or export songs to Spotify/Apple Music. Triggers on phrases like "what's on my Vibo timeline", "add this song to the first dance", "what songs did guests request", "join this Vibo event", or "export our playlist to Spotify". Requires vibo-mcp installed and the vibo server registered (see Setup below).

Agile product ownership toolkit for Senior Product Owner including INVEST-compliant user story generation, sprint planning, backlog management, and velocity tracking. Use for story writing, sprint planning, stakeholder communication, and agile ceremonies.

Executive leadership guidance for strategic decision-making, organizational development, and stakeholder management. Includes strategy analyzer, financial scenario modeling, board governance frameworks, and investor relations playbooks. Use when planning strategy, preparing board presentations, managing investors, developing organizational culture, making executive decisions, or when user mentions CEO, strategic planning, board meetings, investor updates, organizational leadership, or executive strategy.

Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Includes tech debt analyzer, team scaling calculator, engineering metrics frameworks, technology evaluation tools, and ADR templates. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.