Anselmoo
UserMy personal Claude Code plugin workshop — self-assess, quality, compass, cupertino, andon, and cli-scaffold.
Categories
Indexed Skills (49)
andon-preflight
Checks whether a repository is ready for andon-loop, andon-propose, or andon-verify without touching any files beyond testing ledger-directory writability. 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.
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.
cli-architecture
The single source of truth for what "production-grade" means for every CLI this plugin generates, in any of the 12 supported languages. 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 (dispatched here by scaffold-cli). 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. Verification is mandatory and cannot be skipped by any setting; 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. 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.
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 — 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 to find divergence. Trigger on 'does this comply with our handbook', 'check this against our standards', 'audit these files against the code handbook'. 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.
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.
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-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: "match this format", "I can't describe it but here's an example", "make it look like these", a non-standard schema, tone, or layout that's hard to state in words, or a compass-solve stage whose 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-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-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.
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.
compass-summarize-trace
After a compass-solve pipeline finishes, produces a compact written record for handoff, PR comment, or documentation — exactly 7 sections 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.
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-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.
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.