Anselmoo
UserMy personal Claude Code plugin workshop — self-assess, quality, compass, cupertino, andon, and cli-scaffold.
Categories
Indexed Skills (57)
andon-preflight
Checks whether a repository is ready for andon-loop, andon-propose, or andon-verify. The only files it writes are its own report -- PREFLIGHT.md and preflight_summary.json in the given output_dir -- plus testing ledger-directory writability; nothing else is touched. Use when the user asks if a repo is ready for andon, or before the first run of any andon skill in a new repository.
andon-propose
Proposes a fix for one gap by reading the ledger and codebase first, then grilling the user one question at a time only on genuinely load-bearing forks. Use when andon-loop dispatches it to propose a fix, or when the user directly asks what to fix for a named gap, or asks to be grilled on a decision.
andon-status
Reports the current andon board -- stream table, wire statuses, cycle/pass counters, active constraint, open gap counts, evidence-strategy mix -- without running a new pass. Use when the user asks for the current andon board, wire statuses, cycle or pass counters, the active constraint, or what to do next, without wanting a new pass run (not `andon-loop`, which advances the ledger).
andon-verify
Proves or refutes one wire using whichever of seven evidence-grounded strategies its type calls for -- adversarial tribunal, oracle-gap numerical V&V, an anonymous falsifiability rubric, agentic-reliability dispatch, a structural graph tier check, property/invariant proof, or verify-the-verifier. Use when andon-loop dispatches it to prove a wire, or when the user directly asks to prove a wire, run the tribunal, check if a numeric claim is right, or verify a fix is actually verified. Not for judging whether an existing test suite's assertions would catch mutations -- use confab:confab-assertion-audit for that.
arbeitsplan-backend
Decides whether a compiled arbeitsplan run executes in-session, as a headless matrix of fresh claude -p processes, or inside the Workflow tool, and emits the checked backend object workflow.json requires. Use when the user asks whether to run something as a workflow or a matrix, whether a job should run in parallel agents or in this session, or why a run had to be forced into one. Recommend-only. For which pattern fits, hand off to arbeitsplan-patterns; for which of the four approved workflows applies, to arbeitsplan-start.
arbeitsplan-compile
Turns a stated problem into an executable, budgeted workflow spec plus the takt beats that enforce its order. Use when the user describes a change and wants it run as an agentic workflow, asks to plan or set up a swarm, says the advice they have is too vague to act on, or asks what shape a piece of work should be run in. Refuses and points at compass when the problem turns out to be a question rather than a change. Writes the run's workflow.json under analysis/arbeitsplan/ and, behind an approval gate, .claude/takt.local.md.
arbeitsplan-matrix
Compiles and runs a headless sweep — cases x models x plugin-states x repeats, one fresh `claude -p` process per cell — after proving the environment can authenticate. Use when the user wants genuinely independent candidates, a real per-candidate --model, a plugin-present versus plugin-absent comparison, or asks to benchmark or ablate a plugin. Also use afterwards to read results back. A cell that could not be fairly measured is UNMEASURED, never FAIL.
arbeitsplan-patterns
Says which agentic pattern fits a problem and with what numbers — fan-out width, model tier, stop rule, cost — grounded in a frozen catalog of measured configurations. Use when the user asks what shape work should be run in, how many agents to use, whether to run something in parallel, or whether a named pattern is a good idea. Also use to explain why a pattern is rejected here. Read-only; it proposes, it never compiles.
arbeitsplan-run
Executes a compiled workflow as a redundant swarm — N candidates over the same scope in their own git worktrees, judged blind, exactly one landed. Use after arbeitsplan-compile, or when the user asks to run the workflow, start the swarm, or build several versions and pick one. Halts and surfaces rather than retrying when candidates fail; convergence comes from widening, never from repeating. Writes only inside candidate worktrees until the landing step.
arbeitsplan-start
Names which of four approved workflows fits a stated task, the plugins to install for it, and the permission mode to run it in — and says plainly when none of the four fits. Use when the user asks where to start, which workflow or plugin combination applies, whether to use plan mode or auto mode for something, what to install before beginning, or how to combine werkstoff's plugins for a build, an unfamiliar-repo read, a bug fix, or a UI/plugin review. Recommend-only — it never installs anything, writes workflow.json, or changes permission mode itself.
cli-architecture
The single source of truth for what "production-grade" means for every CLI this plugin generates, in any of the 12 languages plus the POSIX sh dialect. Load this doctrine BEFORE any paradigm skill (cli-scaffold-compiled, cli-scaffold-interpreted, cli-scaffold-shell) generates a scaffold. Defines the five-pillar architecture, the frozen 0/1/2 exit-code contract, and the discoverability, composability, stability, and distribution requirements that the cli-scaffold-verifier checks. Never duplicate this doctrine into paradigm skills — reference it.
cli-scaffold-compiled
Generate a production-grade CLI scaffold in a compiled language — Rust, Go, or .NET. Use when the user requests a CLI in one of those three languages. Not the entry point — scaffold-cli resolves the language and dispatches here; a raw request such as "scaffold a new command-line tool in Rust" should go to scaffold-cli first. Produces a lib+binary split where the core library has zero CLI-framework imports, packaging metadata for the language's idiomatic channel, and a snapshot test for --help. Loads the cli-architecture doctrine first, generates freeform from the per-language reference, then hands the scaffold to the cli-scaffold-verifier before presenting; fixes any fixable gaps and re-verifies.
cli-scaffold-interpreted
Generate a production-grade CLI scaffold in an interpreted language — Python, TypeScript, JavaScript, Ruby, PHP, or Perl. Use when the user requests a CLI in one of those six (dispatched here by scaffold-cli). Produces a core module with zero CLI-framework imports, a thin entry point, packaging metadata for the language's idiomatic channel, and a snapshot test for --help. Loads the cli-architecture doctrine first, generates freeform from the per-language reference, then hands the scaffold to the cli-scaffold-verifier before presenting; fixes any fixable gaps and re-verifies.
cli-scaffold-shell
Generate a production-grade CLI scaffold in a shell dialect — Bash, Zsh, PowerShell, or POSIX sh. Use when the user requests a CLI in one of those (dispatched here by scaffold-cli). Produces a sourced library with zero side effects at source-time plus a thin entry point, packaging metadata for the dialect's idiomatic channel, and a snapshot test for --help. Loads the cli-architecture doctrine first, generates freeform from the per-language reference, then hands the scaffold to the cli-scaffold-verifier before presenting; fixes any fixable gaps and re-verifies. For POSIX sh, the verifier also runs a forbidden-bashisms sweep.
scaffold-cli
Entry point for generating a CLI. Use when the /cli-scaffold command runs or when the user says things like "scaffold a CLI in Rust called foo", "make me a Python command-line tool named bar", or "generate a Bash CLI". Resolves the requested language to its paradigm and dispatches to the matching paradigm skill (cli-scaffold-compiled, cli-scaffold-interpreted, or cli-scaffold-shell) after loading the cli-architecture doctrine. Asks for clarification when the language is ambiguous or missing, and refuses unsupported languages while listing the 12 supported options.
compass-clarify-scope
Scopes an ambiguous task before any work begins — restates it with defaults made explicit, lists known facts (flagging low-confidence ones), and surfaces the interpretation forks that could send the work the wrong way. Use when a task's phrasing supports multiple reasonable interpretations, success criteria aren't stated, or scope is underspecified: "what exactly do you want here", "before I start, let me pin this down", a vague one-line request, or the first phase of compass-solve.
compass-explore-branches
Explores multiple genuinely-distinct approaches to a scoped problem in parallel, scores each on Feasibility/Impact/Risk, and selects a winner — so the work does not anchor on the first idea. Use when a task has more than one viable approach and picking the first that comes to mind would be a mistake: "what are our options here", "don't just do the obvious thing", "weigh a few approaches", "explore alternatives", or the Explore phase of compass-solve.
compass-optimize-instruction
Optimizes the exact wording of an instruction/prompt for a recurring task using APE — generates one candidate per framing, scores them against real test cases, and critiques the winner. Use when a prompt will be reused and its wording matters: "tune this prompt", "find the best wording for this instruction", "optimize this system prompt", "which phrasing works best", with representative test cases available. Not for one-off prompts with no test cases.
compass-reason-verify
Matches reasoning effort to concrete failure-mode signals by climbing a 4-rung ladder — zero-shot, Chain-of-Thought, Self-consistency, or PAL (code offload) — and applies Multimodal-CoT first when the input has an image or diagram. Use when a task shows a real risk of a silent reasoning error: multi-step arithmetic, a single-correct-answer puzzle where a wrong early assumption is costly, a precision-critical calculation, or an image/diagram input. Not for well-trodden single-step questions.
compass-solve
Runs the full compass pipeline — Clarify -> Explore (conditional) -> Decompose -> Execute -> Revise — for a task that is complex/ambiguous AND needs staged decomposition AND carries real ambiguity or multiple viable approaches worth weighing. Use when a request is too big or too underspecified to answer in one shot: "solve this properly", "work through this step by step", "this is complex, break it down and do it", or any multi-faceted task where jumping straight to an answer would anchor on the wrong interpretation or approach. Not for simple, well-specified, single-step tasks.
confab-agentic-reliability
Use when the user asks to audit this plugin repository's own skill, agent, or workflow definitions for agentic-loop reliability defects, wants to check for unbounded retries, missing escalation paths, unwired Find/Verify phases, or excessive tool grants, or asks 'is our own agent design safe'. Verification runs by default and only skips if the user explicitly says skip_verification. Findings fall into exactly four categories.
confab-assertion-audit
Use when the user asks whether their test suite would actually catch bugs, wants a mutation-testing pass over target source and test files, asks to check for weak or tautological assertions, or wants confab's assertion audit run. Not for proving that a specific change, fix, wire, or numeric claim is correct -- use andon:andon-verify for adversarial verification of a change; this skill judges only the tests. Every finding is labeled real-tool or llm-reasoned.
confab-code-change
Use when the user asks for a pre-commit quality check on staged or uncommitted changes, wants a quick confab pass over 'what I just changed' before committing, or asks 'is this diff okay to commit'. Only runs the domains whose file patterns match the changed files, and always produces an advisory verdict that never blocks the commit.
confab-contract-drift
Use when the user asks to audit type signatures, docstrings, or API/OpenAPI/GraphQL schemas against actual call-site or handler usage, wants to check for contract drift after a refactor, or wants confab's contract-drift audit run. Scope is structural, machine-checkable declarations only. Not for prose documentation drift — claims in CLAUDE.md, README.md, ARCHITECTURE.md, DECISIONS.md or ADR files no longer matching the code: use self-assess-docs-drift for that. Verification runs by default and only skips if the user explicitly says skip_verification.
confab-cycle
Use when the user asks for a bounded self-optimization loop that re-runs confab's audits until convergence or a pass cap, wants to 'run the confab cycle', 'keep fixing findings until done', or asks for propose-only vs fix-mode passes. Runs at most max_passes_per_invocation (default 5) passes, applies fixes only in fixable domains, and stops early on convergence — every bound is enforced by scripts/cycle_engine.py, not by this file's instructions.
confab-dependency-audit
Use when the user asks to audit declared dependencies for hallucinated, nonexistent, or typosquat-adjacent packages, wants confab's dependency audit run, or asks whether package.json/requirements.txt/pyproject.toml/Cargo.toml/go.mod/Gemfile entries actually exist. Performs bounded, read-only registry lookups with a mandatory-unless-flagged independent verification pass.
cupertino-backwards
Use FIRST, before cupertino-focus or any other cupertino technique, whenever customer experience and technology choices are both still undecided for a new feature or project scope. This is a pre-architecture gate: it establishes what experience actually matters before any technology direction is chosen, working backwards from experience to technology rather than forwards from the feature request. Trigger on requests like 'design a way for users to...', 'we need a feature that...', or any new scope where nobody has yet named a database, framework, API, or UI element.
cupertino-cannibalize
USER-INVOKED ONLY — never automatic, never run as part of cupertino-review's pipeline or any other automatic stage. Use only when the user explicitly asks, on a deliberate post-ship cadence, whether to replace a currently-successful, load-bearing thing with a better successor built in-house — the iPhone-cannibalizing-the-iPod move. Trigger only on explicit requests like 'should we cannibalize X', 'is it time to replace our own best thing', or a direct ask to run this specific technique by name.
cupertino-council
Use at UI/frontend build-time, before writing any code, whenever a user-facing interface or screen is being designed. Trigger on 'design this screen', 'build this UI', 'make this feel premium', 'this feels generic', or any request to design or implement a user-facing surface. Applies to any stack (HTML, React, Vue, native, etc.). Always run before code, never after — retrofitting the council onto finished code defeats the purpose. Not for a not-yet-scoped new feature where customer experience and technology are both still undecided — run cupertino-backwards first to establish the experience statement. Not for reviewing an interface that already exists: for accessibility, semantic-markup or hardcoded-design-value problems in shipped source use self-assess-ui-audit, and for a full-lifecycle design pass over an existing project use cupertino-review.
cupertino-elevate
Use at build-time, ONLY when a low-status commodity feature already in scope for the current build — error messages, logs, config, settings, onboarding, migrations, loading states, empty states, backups, status output — could be transfigured into something beloved, the way Apple turned boring backup into Time Machine. Trigger on 'this feature is boring', 'nobody uses this', 'make this delightful', 'elevate this'. Never seek out a commodity feature independently or apply this to a brand-new capability not already being worked on — route a brand-new capability to cupertino-backwards instead; if nothing already in scope qualifies, say so and skip.
cupertino-handbook-check
Use when the user wants to compare new or changed work against an existing domain handbook at .cupertino/DOMAIN-handbook.md (one file per domain) to find divergence. Trigger on 'does this comply with our handbook', 'audit these files against the code handbook', 'check this against the code handbook'. Requires a handbook previously produced by cupertino-handbook-draft. Not for repo-wide conventions written in CLAUDE.md or .claude/house-rules.md — use self-assess:self-assess-lint-audit for those. Read-only — never modifies target files. Zero findings is a valid, expected outcome, not something to work around.
cupertino-handbook-draft
Use when the user wants to create and persist a durable handbook for one domain — design, code, testing, or documentation — capturing the project's actual conventions (or honest scaffolded defaults where none exist) as a checkable rule per dimension. Trigger on 'write a code handbook', 'draft our design standards', 'create a testing handbook', or similar requests naming a domain and asking for a persisted, checkable artifact rather than a one-off answer. Not for researching what a stack *should* adopt from external authority, and not for producing the machine-checkable .lehre/ruleset.json a lehre run enforces — use lehre-codify for those. This skill describes one domain as it already is, in a human-readable per-dimension handbook.
cupertino-handbook-fix
Use only when the user has explicitly enabled fix mode for a domain, to apply the mechanical findings from a prior cupertino-handbook-check pass. Trigger only on explicit requests like 'fix the mechanical handbook findings' AFTER the user has turned on fix mode — never infer consent from a check report alone. Never touches mechanical:false findings, never commits or pushes. Not for code-modernization or idiom findings from code_idiom_summary.json — those belong to self-assess-idiom-fix. If no handbook_check_DOMAIN_summary.json exists for the domain, this is not the audit the user means.
cupertino-integrate
Use at architecture-decision time, together with cupertino-longevity, to decide whether one specific seam — a boundary between layers, APIs, or ownership — is worth owning tightly versus delegating to a vendor or framework. Trigger on 'should we build or buy this', 'own vs delegate', 'vendor this piece or not', 'tight integration vs pluggable', or any decision about a single named boundary. Never apply as a blanket policy across a whole system — one seam per invocation.
cupertino-longevity
Use at architecture-decision time, together with cupertino-integrate, to evaluate whether an architecture, API surface, or codebase structure can evolve incrementally or will force a future rewrite. Trigger on 'will this scale', 'future-proof this', 'API versioning strategy', 'will I regret this architecture', 'is this extensible', 'migration path', 'plugin system', or any design discussion where long-term evolvability is genuinely at stake — not on routine feature work with no durability question.
cupertino-prototype
Use at build-time, parallel to cupertino-council, whenever a specific empirical uncertainty needs settling by actually building and running a throwaway version rather than debating it in the abstract. Trigger on 'not sure if this approach will actually work', 'let's spike this', 'will this library even do what we need', or any disagreement that a small runnable experiment would resolve faster than continued discussion. Never use for general feasibility studies — only for one specific, answerable question.
cupertino-review
Use when a project spans multiple lifecycle moments and the user wants the whole cupertino discipline applied end-to-end in one pass — 'give this the full cupertino treatment', 'review this like Apple would', 'run the whole design lifecycle on this'. Composes the plugin's other techniques as fixed, sequenced stages rather than requiring the user to invoke each one by hand. Not for a single lifecycle moment with one obvious technique — use that technique directly instead.
cupertino-unbox
Use at build/finishing-time, after core feature work has produced something worth a new user's first five minutes, to redesign the actual first-run, onboarding, or install flow. Trigger on 'improve onboarding', 'first-run experience', 'unboxing', 'install flow', 'first five minutes'. Scope is strictly the first five minutes of first contact — not the whole onboarding arc, and not to be confused with cupertino-elevate, which transfigures an existing feature's ongoing feel rather than the first-contact sequence.
self-assess-arch-health
This skill should be used when the user asks to "find architecture deficiencies", "find god-objects or god-modules", "detect dependency cycles", "check for layering violations", or as part of self-assess-autopilot's CHECK phase. Reads the full stage_graph.json from self-assess-stage-map and finds god-modules, circular dependencies, and layering violations, verifying each against actual code.
self-assess-autopilot
This skill should be used when the user asks to "run the auto-pilot", "check, plan, fix and validate this repo", or wants the full self-assess value stream run end to end. Conducts CHECK (read-only findings) -> PLAN (modernization brief) -> a hard approval gate -> FIX+VALIDATE (handed to andon-loop), halting on any unproven wire or unmet blocker.
confab-status
Use when the user asks where confab's quality analysis stands, which reports are stale, what to run next, or wants a dashboard of all findings so far. Read-only: never triggers an audit itself, only reports on what has already run.
compass-draft-revise
Scores an already-drafted artifact 1-5 against explicit numbered criteria and selectively revises only the criteria that fall at or below threshold, leaving what already works untouched — then reports exactly what changed. Use when a draft exists and needs targeted iteration rather than a rewrite: "score this against these criteria and fix what's weak", "revise selectively", "which parts fall short", "iterate on this draft", or the Revise phase of compass-solve.
compass-summarize-trace
After a compass-solve pipeline finishes, produces a compact written record for handoff, PR comment, or documentation — 7 sections (6 if Explore did not run) covering what was asked, assumed, weighed, run, produced, revised, and NOT done. Use when a finished multi-stage run needs to be captured: "summarize what we did", "write this up for the PR", "hand this off", "document the run", after compass-solve completes.
compass-verify-assumptions
Checks exactly ONE named assumption against real evidence in at most 3 steps and reports one outcome: confidence raised (>=90), reading changed, or still unresolved. Use to resolve a single load-bearing uncertainty — typically a blocking entry surfaced by compass-clarify-scope: "verify this one assumption", "is it actually true that X", "check this before we rely on it". For multiple uncertainties, invoke once per uncertainty — the step budget is never shared.
cupertino-focus
Use immediately after cupertino-backwards has established the customer experience, to reduce a sprawling portfolio of shipped and planned products, feature lines, modes, or variants down to the smallest focused set before architecture work commits effort. Trigger on requests like 'we have too many modes/plans/tiers/variants', 'help us decide what to cut', or any planning conversation where the honest list of things-in-flight is longer than anyone wants to admit.
arbeitsplan-preflight
Read-only inventory of what a swarm run can and cannot do in this repository before any tokens are spent. Use before arbeitsplan-compile or arbeitsplan-run, when the user asks whether this repo is ready for a swarm, or when a run failed and the cause might be the environment rather than the work. Reports git/worktree support, test commands, other plugins' live guards, and any open run lock. Writes nothing.
arbeitsplan-status
Read-only report on an arbeitsplan run that has already started — phases done, candidates built and refuted, referee verdicts, open doubts, halts with their reasons, dispatch budget used, whether a lock is open, and the single next command. Use when the user asks how the run is going, what the swarm decided, why it stopped, how to resume it, why something was denied, or what is still holding a lock. Advances nothing and writes nothing.
compass-calibrate-format
Pins down an ambiguous output format, style, tone, or schema by anchoring it to 2-5 concrete input/output examples instead of more prose. Use when prose keeps under- or over-specifying the target shape: when the target cannot be described in words, is non-standard, or involves subtle tone or layout choices, or when a compass-solve stage output shape is fuzzy.
compass-decompose-chain
Breaks a scoped problem or selected approach into a 2-5 stage pipeline, each stage with an explicit input contract, output contract, and dependsOn list, and derives the parallel-safe wave grouping from the dependency graph. Use when a task is big enough to need staging with clear hand-offs between steps: "break this into steps", "what's the pipeline here", "map the stages", "what depends on what", or the Decompose phase of compass-solve.
compass-ground-evidence
Checks that every factual claim in an answer or artifact is traceable to a specific source — a file:line, a URL, or explicitly-flagged prior knowledge — and refuses to assert anything beyond what's actually verified. Use whenever an answer, summary, or report makes assertions that need grounding rather than recall: "cite your sources", "don't make this up", "ground this in the actual transcript/code/docs/data", a number or metric that must trace back to where it came from, "verify before asserting", or a factual-claim-heavy stage of compass-solve.
compass-investigate-dynamically
Works a problem whose next action can only be chosen after seeing the last result — a Reasoning / Action / Observation loop where each observation determines the next step. Use when the sequence of tool calls cannot be planned upfront: "figure out why X is happening", "trace this through the system", "I don't know where the problem is, go find it", open-ended debugging or discovery, or an Execute stage of compass-solve whose steps are unknown at the start.
compass-map-relationships
Answers a question that turns on entity/dependency/causal structure by extracting indexed relationship triples and traversing them hop by hop, citing the triple index at every hop. Use when the answer requires following a chain through named entities and relationships: "how does A affect D through the chain", "trace the dependency path", "who reports to whom", "what causes what here", multi-hop "why" questions, or a compass-solve stage that needs graph traversal. Not for deriving a repository's real import/module graph from source — "map this repo's architecture", "show me the real module boundaries", "map stages and wires" belong to self-assess-stage-map, which parses imports per language and writes the stage graph other skills consume. Use this skill only to reason over a relationship graph whose entities are already established, in code or any other domain.
compass-negotiate-tradeoffs
After compass-explore-branches has selected a winner, synthesizes a hybrid that combines strengths from 2-3 branches — but only presents it if it actually beats every source branch on at least one axis. Use when a single winner leaves value on the table and you want the best of several: "can we combine the best of these approaches", "what if we merged A and B", "the winner's good but I liked X from the runner-up". Runs strictly AFTER branch selection, never as a substitute for it.
confab-preflight
Use when the user asks whether this repository is ready for confab audits to run successfully, wants a pre-flight/readiness check before running confab-dependency-audit, confab-assertion-audit, confab-contract-drift, or confab-agentic-reliability, or asks 'is confab set up correctly here'. Runs five independent checks and reports one readiness verdict per domain skill.
cupertino-handbook-apply
Use before starting new work in a domain that already has a drafted handbook, to pull in only the constraints and exceptions relevant to the upcoming task rather than dumping the whole document. Trigger on 'what does our handbook say about this', 'apply our code standards to this task', or naturally at the start of any task in a domain where cupertino-handbook-draft has already run.
cupertino-reveal
Use at ship-time, as the last automatic step for a finished feature, module, tool, or API, to deliver exactly one non-obvious, high-leverage addition in a keynote 'and one more thing' structure. Trigger on 'what's missing here', 'is there anything else this needs before shipping', or automatically as the final stage when cupertino-review runs the full pipeline. Never produces a list — exactly one suggestion, and it must be built, not pitched.
andon-loop
Runs one pass of the andon hardening loop over this project's value stream (its ordered chain of stages, connected by wires/data-contracts). Use when the user asks to harden the pipeline, run a self-optimization loop, close gaps in a multi-stage codebase, or advance the value stream while keeping every handoff between stages proven. Also use for "andon loop", "wire proof", "andon rule", or "run a pass".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.