werkstoff

Auto-enforcing loop that walks a project's value stream — its stages and the wires between them — closing one gap per stage and refusing to advance past a broken or unproven wire (the andon rule). Composes andon-propose (pick and design the fix) and andon-verify (prove the wire) over a native OKF ledger. Use this when the user wants to "harden this repo", "run the andon loop", "scan for gaps and fix them in order", "prove this wire is proven", "resume the andon ledger", or any request to iterate a multi-stage codebase closing gaps while keeping each handoff evidence-grounded rather than assumed.

Checks whether the current repository has a legible multi-stage value stream and where the andon ledger should live. Detects stage/wire legibility (directly or via self-assess:stage-mapper if installed), checks for a house-rules.md andon-propose can draw defaults from, and confirms an output/ledger location is writable. Use this when the user asks "is my repo ready for andon", "can andon-loop run here", "check if andon can find my stages", or before running andon-propose, andon-verify, or andon-loop for the first time in a repo.

Runs a complex, ambiguous, or multi-faceted task through compass's full Clarify -> Explore -> Decompose -> Execute -> Revise pipeline, composing the plugin's other 12 skills as pipeline stages instead of requiring the user to invoke them individually. Use when a task is genuinely large enough to need staged decomposition AND carries real ambiguity or multiple viable approaches worth weighing before committing — "solve this end-to-end, I'm not sure of the best approach", "plan this out and carry it out, here are the constraints", or a request that would otherwise mean chaining several compass-* skills by hand. Do not use for a single well-scoped question, a task with one obvious approach and nothing to decompose, or anything answerable directly — most requests do not need this skill; each of compass's other 12 skills stays independently invocable for a narrower job that doesn't warrant the full pipeline.

This skill should be used when the user asks to "check for type signature drift", "verify our API schema matches the handler", "audit our function signatures for drift", "find mismatched function contracts", "check if type hints match how functions are actually called", or "audit our OpenAPI/GraphQL schema against the code". Extracts machine-checkable contracts (type hints, function signatures, docstring parameter/return descriptions, API/OpenAPI/GraphQL schemas) from source files and checks each against actual call-site and handler usage, reporting contradictions with file:line evidence on both sides.

This skill should be used when the user asks to "run a quality self-optimization cycle", "harden the quality findings", "fix what quality found and re-check", "converge the quality audit", or wants the confab plugin's four domain audits run repeatedly with cross-run memory until they stop finding new things — optionally applying and re-verifying fixes for dependency-hallucination, contract-drift, and mechanical agentic-reliability findings, and drafting (never applying) assertion-strength suggestions.

This skill should be used when the user asks to "check for hallucinated dependencies", "verify our packages actually exist", "audit dependencies for AI-generated code", "does this package actually exist on npm/PyPI", or wants declared dependencies in manifest files (package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod, Gemfile) cross-checked against their real public registries for non-existent or typosquat-adjacent packages.

Checks whether the current repository is ready for the confab plugin's audit skills to run well. Detects declared-dependency manifests, probes reachability of each detected language's public package registry, and checks for a real mutation-testing tool on PATH. Use this when the user asks to "run quality preflight", "check if the confab plugin can run here", "is my repo ready for a dependency audit", or before running confab-dependency-audit, confab-assertion-audit, confab-contract-drift, or confab-agentic-reliability for the first time in a repo.

Audits this repository's git remotes, CI configuration, any publish/mirror scripts, and commit-signing consistency for redundant remotes, doc-vs-reality drift about CI, one-directional force-push mirrors with no reverse-sync path, and inconsistent commit signing (the green "Verified" vs grey "Unverified" badge — some commits signed, some not, or `commit.gpgsign` unset). Use this when the user asks to check our git remotes, audit CI setup, find redundant mirrors, verify the docs about CI/CD are accurate, or check commit signing / why some commits show grey/unverified / provenance (CI/git-topology claims only — for broader doc-vs-code drift on other topics, use self-assess-docs-drift).

Parses falsifiable claims out of CLAUDE.md, ADRs, DECISIONS.md, ARCHITECTURE.md, and README, then checks each against the actual code and reports contradictions with file:line evidence on both sides. Use this when the user asks whether the docs are still accurate, to check CLAUDE.md against the code, find stale documentation, audit documentation drift, or verify our ADRs/architecture docs still match reality — general doc-vs-code claims on any topic. For CI/CD-specific doc claims only (git remotes, pipeline config, mirror scripts), use self-assess-ci-topology instead.

Checks whether the current repository is ready for self-assess's analysis skills to run well. Detects the language stack, verifies analysis tooling is present, smoke-parses a real file per detected language, checks for a house-rules.md, and checks git-remote/CI-config readability. Use this when the user asks to run self-assess, check whether self-assess can run here, or before running self-assess-stage-map, self-assess-docs-drift, self-assess-ci-topology, or self-assess-lint-audit for the first time in a repo.

Applies exactly the eligible mechanical:true findings from cupertino-handbook-check's handbook_check_<domain>_summary.json -- single-location, unambiguous handbook-rule fixes -- via the handbook-remediator agent, then immediately checks every fix with a fresh, independent handbook-verifier agent that is blind to the remediator's own rationale (never self-verifies, no exception even for trivial fixes). Use this only when the user explicitly wants to apply cupertino-handbook-check's findings, not just read them, and has set handbook.fix.mode to "fix" in .claude/cupertino.local.md. This is cupertino's only Edit-capable skill -- every other cupertino skill, including cupertino-handbook-check itself, is read-only. Do not use for findings with mechanical:false -- those are never auto-fixed by this or any cupertino skill.

Applies exactly the eligible "modernization"-category findings from self-assess-code-idiom's code_idiom_summary.json -- mechanical, single-location deprecated-idiom rewrites (e.g. Optional[X] to X | None) -- via the idiom-remediator agent, then hands every fix off to andon-verify's adversarial tribunal for proof (never self-verifies, no exception even for trivial rewrites). Use this only when the user explicitly wants to apply code-idiom's modernization findings, not just read them, and has set idiom_fix.mode to "fix" in .claude/self-assess.local.md. This is one of only two skills in self-assess with Edit access to target source (the other is self-assess-transform-execute) -- every other self-assess skill, including self-assess-code-idiom itself, is read-only. Do not use for "smell"-category findings (those are never auto-fixed by this or any self-assess skill), for architectural Merge/Split changes (self-assess-transform-execute), or for house-rules violations (self-assess-lint-audit has no auto-fix path).

This skill should be used when the user asks to "check if our tests actually assert anything", "run a mutation-testing pass", "find assertion-free tests", "check our test suite's assertion strength", or wants to know whether AI-generated tests genuinely catch bugs rather than merely executing code for coverage. Proposes plausible small mutations to a target module's logic and determines — via LLM reasoning or, if a real mutation-testing tool is available, ground-truthed against that tool — whether the existing test suite would actually catch each one.

Analyzes a target project (or scaffolds sensible defaults for an empty/near-empty one) for one of four domains -- design, code, testing, documentation -- and writes a persisted, project-specific handbook artifact of that domain's actual conventions plus a machine-readable summary sidecar. Use when the user asks to draft/create/generate a design handbook, code style handbook, testing conventions handbook, or documentation handbook, or wants a durable "north star" of this project's conventions instead of a one-shot review. This is the first stage of cupertino's handbook lifecycle (draft -> apply -> check -> fix); the artifact it writes is what cupertino-handbook-apply, cupertino-handbook-check, and cupertino-handbook-fix all read. Not for a one-shot design/code review with no persisted artifact -- use cupertino-review or the relevant single-technique cupertino-* skill for that.

Analyzes the real stage/wire graph self-assess-stage-map already built for architecture deficiencies — god-modules (a stage most others depend on, a bottleneck), circular dependencies between stages, and layering violations (a production stage importing a test-only/benchmark/fixture stage). Use this when the user asks to check architecture health, find god-modules or god-objects, detect dependency cycles between modules/packages, find layering or dependency-direction violations, or check whether the module boundaries are healthy. Depends on self-assess-stage-map having run first (it reads that skill's stage_graph.json, never re-deriving the graph). NOT a complexity/size ranking (use self-assess-complexity-score — that never emits pass/fail findings); NOT graph construction (self-assess-stage-map builds the graph, this judges it).

Scans the codebase's own application code for deprecated/legacy idioms in the languages actually present (checked against the version the repo targets, not a fixed list) and for generic code smells that don't need a house-rules entry to exist first — error-swallowing except/catch blocks, magic numbers, overlong functions, deep nesting, missing type coverage in an otherwise-typed module. Use this when the user asks to modernize idioms in place, find legacy/deprecated language patterns, catch code smells, check code idiom quality, or find anti-patterns. NOT for house-rules compliance (use self-assess-lint-audit — that checks only rules the repo already wrote down); NOT for docs-vs-code accuracy (self-assess-docs-drift); NOT for whether AI-authored dependencies/tests/contracts are trustworthy (the confab plugin).

Mines business/domain logic (calculations, validations, eligibility rules, state transitions) out of the current repo's code into testable Rule Cards (Given/When/Then, P0/P1/P2 priority, file:line citation, confidence). Use this when the user asks to extract business rules, document the domain logic hidden in this codebase, find calculation/validation/eligibility logic, or turn tribal knowledge in the code into a testable specification. This mines intent from a live, actively-maintained repo — unlike code-modernization's modernize-extract-rules, which targets a legacy system slated for rewrite.

Checks the codebase against its own repo-authored house-rules.md conventions (or degrades to best-effort against CLAUDE.md if absent) and reports violations with file:line evidence. Use this when the user asks if the code follows our conventions, to check house rules compliance, find places that violate our patterns, or audit convention drift.

Statically audits the codebase's own UI surface — components, templates, and stylesheets (JSX/TSX, Vue/Svelte SFCs, HTML templates, CSS/SCSS) — for accessibility problems (missing alt text, form labels, accessible names; non-interactive elements used as controls; positive tabindex), semantic-markup problems (a clickable div where a button belongs, skipped heading levels, missing landmarks), and hardcoded design values (literal colors/dimensions where a design-token or CSS-variable system is used elsewhere), plus plausibly low-contrast literal color pairs as a static heuristic. Use this when the user asks to audit the UI/UX or accessibility of the code, check a11y, find hardcoded colors/spacing, or catch non-semantic markup. This is a STATIC, read-only source read — it never runs or builds the app, renders a DOM, takes screenshots, or computes a real WCAG contrast ratio. NOT language idioms/smells (self-assess-code-idiom), NOT module architecture (self-assess-arch-health), NOT house-rules compliance (self-asse

Loads an existing design, code, testing, or documentation handbook for a project and produces concrete guidance/constraints for a specific upcoming task before work starts -- an active pre-flight consult, not passive background reading. Use before starting new work in a domain that already has a drafted handbook (see cupertino-handbook-draft) -- "about to build a settings screen, what does our design handbook say", "check the code handbook before I start the billing module", "what are our testing conventions before I write these tests". Stops and suggests cupertino-handbook-draft first if no handbook exists yet for the resolved domain -- this skill never drafts one itself. Independently invocable for any domain, and optionally consulted by cupertino-review before its Council stage when a design handbook already exists.

Compares new or changed work in one domain -- design, code, testing, documentation -- against that domain's existing handbook artifact (see cupertino-handbook-draft) and flags concrete divergence with file:line evidence. Use when the user asks to check code/design/tests/docs against the handbook, verify new work follows our conventions, or find drift from the handbook. Fully self-contained, using its own Workflow-orchestrated Find-then-adversarial-Verify pass -- never invokes self-assess or andon skills even when installed. Stops and suggests cupertino-handbook-draft first if no handbook exists yet for the resolved domain. Its output feeds cupertino-handbook-fix, which applies a gated subset of what this skill finds.

Runs a project through cupertino's full lifecycle pipeline — backwards -> focus -> [longevity & integrate, tension surfaced jointly] -> council -> prototype -> elevate -> unbox -> reveal -> [cannibalize, cadence-triggered, user-invoked only] — composing the plugin's other 10 skills as fixed stages instead of requiring the user to invoke them individually. Use when a project spans multiple lifecycle moments and the user wants the whole Steve-Jobs-grounded discipline applied end-to-end — "give this the full cupertino treatment", "review this project like Apple would", "run the whole design lifecycle on this", "apply cupertino start to finish", or a request that would otherwise mean chaining several cupertino-* skills by hand. Not for a single lifecycle moment with one obvious technique — use that one cupertino-* skill instead. cupertino-cannibalize never runs automatically as part of this pipeline.

Proves or refutes one wire using whichever of seven evidence-grounded proof strategies its type calls for — adversarial tribunal (code/artifact), oracle-gap V&V (numerical/scientific), an anonymous falsifiability rubric (epistemic claims), agentic-reliability dispatch (autonomous-fix reliability), a three-tier structural/connectivity graph check (Kythe/SCIP/LSIF), property/invariant proof (Hypothesis/fast-check/QuickCheck), or verify-the-verifier (contract-drift and mutation-testing the wired test itself). Use this when andon-loop needs to prove a wire green or red, or directly when the user asks "prove this wire", "is this fix actually verified", "run the tribunal on this", "check if my numbers are right", "is this claim falsifiable", "did the autonomous fix stay reliable", "does this structural claim hold", "property test this", or "would this test actually catch a bug".

This skill should be used when the user asks to "audit our own plugin reliability", "check agent escalation paths", "find agents with excessive tool access", find unbounded retry loops in agent or workflow definitions, or verify that a Workflow script's Find phase is actually wired to an adversarial Verify phase. Self-referential — it scans a target plugin repo's own skills/*/SKILL.md, agents/*.md, and workflows/*.js files (including this plugin's, self-assess's, and compass's own definitions when the target is werkstoff itself) for agentic-loop reliability defects, distinct from evaluating whether the agents' conclusions are correct.

One-command auto-pilot over a live repo — runs the whole check then plan then fix then validate value stream by conducting the skills that already exist, without adding a new loop. The CHECK phase (read-only, no fixes) runs stage-map plus the reporting skills (docs-drift, ci-topology, lint-audit, code-idiom, arch-health), the UI audit, extract-rules, and — if the confab plugin is installed — its dependency/assertion/contract/agentic audits. The PLAN phase runs self-assess-transform-brief, which synthesizes every finding into one phased MODERNIZATION_BRIEF with ranked work items plus a behavior contract. The FIX-and-VALIDATE phase runs andon-loop in ingest mode, applying one gated fix per phase and proving each with andon-verify's tribunal. Plan-and-gate throughout — nothing is edited without a human approving the phase. Use this when the user asks to "run the auto-pilot", "check, plan, fix and validate", "harden this repo end to end", "do a full self-assess pass and fix what you find", or "auto-pilot mode". T

Builds a real import/use graph of the current repository and clusters it into stages (packages/crates/modules) and wires (the data-contract boundaries between them), fixing the common bug where two packages sharing one manifest collapse into a single stage. Use this whenever someone wants the repo's actual dependency structure instead of what folders, manifests, or docs claim — mapping the codebase's real architecture, finding true module/service boundaries before a split or refactor, generating an interactive map of which files call which files, or the specific manifest-collapse bug (two packages sharing one `pyproject.toml`/`package.json`/similar). This never reads docs, only code — for checking whether a doc's architecture claim matches this real structure, use self-assess-docs-drift.

Reports where self-assess's analysis stands for the current repository — which artifacts exist, whether they're stale relative to the current code, and the single most useful next skill to run. Use this when the user asks "where does self-assess stand", "what's stale in the self-assess analysis", "what should self-assess run next", or "self-assess status".

Synthesizes self-assess-stage-map's graph, self-assess-arch-health's deficiency findings, the reporting domains' file:line findings (code-idiom/lint-audit/docs-drift), complexity-score's ranking, and extract-rules' P0/P1 rules into an executable transformation plan — a current-state → target-state component mapping (explicitly 1:1, merge, or split per stage), a phased leaf-first sequence, per-phase code-change work items (ranked by severity × complexity), and a per-phase behavior contract of business rules that must stay equivalent — plus Mermaid exports and a fed interactive walkthrough on the existing topology viewer. Use this when the user asks for a modernization brief, a transformation plan, a prioritized refactoring/remediation plan, whether to merge or split modules before a refactor, a phased migration sequence, or "what's the target architecture and how do we get there" for a live repo. NOT a re-derivation of the import graph (self-assess-stage-map builds that), NOT a deficiency finder (self-assess-a

This skill should be used when a task has multiple genuinely viable approaches and the risk of anchoring on the first idea matters — the user asks to "explore different approaches", "what are my options here", "don't just go with the first idea", "compare a few strategies before we commit", or a scoped problem (from compass-clarify-scope, or compass-solve's Explore stage) needs a decision among distinct paths rather than a single obvious next step. Not for tasks with only one reasonable approach, or for expanding an already-chosen approach into stages (that is compass-decompose-chain's job).

Checks that every factual claim in a task's answer or artifact is traceable to a specific source — a file:line, a URL, or explicitly-flagged prior knowledge with a confidence marker — and refuses to assert anything beyond what's actually verified. Use this whenever an answer, summary, or report makes assertions that need grounding in an actual source rather than inference or plausible-sounding recall — "cite your sources," "don't make this up," "ground this in the actual transcript/code/docs/data," a specific number or metric that needs tracing back to where it came from, "verify before asserting," "does this claim have evidence," or when compass-solve's Execute phase reaches a factual-claim-heavy stage. Not just code-grounding — applies equally to business claims, meeting transcripts, and any other source material.

This skill should be used before committing, when the user asks to "review my changes before I commit", "check staged files for quality issues", "pre-commit quality check", or "run confab-code-change" — runs the confab plugin's four domain audits against only the currently-staged (or, if nothing is staged, currently-changed) files, for a fast pre-commit check. Never a substitute for the full-repo domain skills or confab-cycle.

This skill should be used when the user asks "where does quality stand", "what's stale in the quality analysis", "what should I run next", "quality status", or "confab-status" for the current repository. Reports which of the confab plugin's own artifacts exist, whether each is stale relative to current repo state, and the single most useful next skill to run.

Sweeps every repo under a parent directory and renders a heat-map dashboard from each repo's existing self-assess artifacts — languages, stage/wire counts, docs-drift contradictions, CI findings, lint violations, and an honest "not yet assessed" marker for repos with no artifacts yet. Use this when the user asks to sweep all our repos, get a portfolio view across our services, health-check our repos, which repo needs attention, or run self-assess across the whole org/monorepo-of-repos.

Executes exactly ONE human-authorized phase from self-assess-transform-brief's MODERNIZATION_BRIEF.md — a Merge or Split decision, or a layering-violation fix — via the transform-executor agent, then hands off to andon-verify's adversarial tribunal for proof (never self-verifies). Use this only when the user explicitly wants to actually apply a transformation-brief phase's code changes, has already resolved that phase's Open Question(s), and has set transform.mode to "execute" with that phase number listed in transform.authorized_phases in .claude/self-assess.local.md. This is the ONLY skill in self-assess with Edit/Write access to target source — every other self-assess skill, including self-assess-transform-brief itself, is read-only. Do not use for planning (self-assess-transform-brief), for mechanical single-line fixes (confab-cycle's fix mode), or for anything not already an authorized phase in an existing brief.

Internal doctrine skill for the cli-scaffold plugin, composed silently by scaffold-cli and the three paradigm skills (cli-scaffold-compiled, cli-scaffold-interpreted, cli-scaffold-shell) at the start of every generation — not intended for direct end-user invocation. Holds the five pillars every generated CLI must satisfy regardless of language, and the frozen cross-paradigm exit-code contract. Load this before generating any CLI scaffold, in any language.

This skill should be used when the user asks to "scaffold a CLI in Rust", "generate a Go command-line tool", "create a .NET CLI app", "make a production CLI in C#", or names .NET, C#, Rust, or Go as the target language for a new command-line tool — either directly or dispatched from scaffold-cli's language-routing. Generates a freeform, production-grade CLI scaffold for the compiled paradigm (.NET, Rust, Go), following cli-architecture's five-pillar doctrine and this skill's own per-language reference idioms — never from stored boilerplate.

This skill should be used when the user asks to "scaffold a CLI in Python", "generate a TypeScript command-line tool", "create a Ruby gem CLI", "make a PHP console app", "build a Perl script with proper argument parsing", or names Python, TypeScript, JavaScript, Ruby, PHP, or Perl as the target language for a new command-line tool — either directly or dispatched from scaffold-cli's language-routing. Generates a freeform, production-grade CLI scaffold for the interpreted paradigm, following cli-architecture's five-pillar doctrine and this skill's own per-language reference idioms — never from stored boilerplate.

This skill should be used when the user asks to "scaffold a Bash CLI", "generate a Zsh command-line tool", "create a PowerShell module CLI", "make a portable POSIX sh script", or names Bash, Zsh, PowerShell, or POSIX sh (sh/dash/ksh) as the target for a new command-line tool — either directly or dispatched from scaffold-cli's language-routing. Generates a freeform, production-grade CLI scaffold for the shell paradigm, following cli-architecture's five-pillar doctrine and this skill's own per-dialect reference idioms — never from stored boilerplate.

Proposes a fix for one gap maximally — from the codebase, the ledger's written artifacts, and domain best-practice — then grills the user one question at a time, only on genuinely load-bearing forks, each question paired with a recommended answer and a blast-radius/reversibility tag. Use this when andon-loop needs to decide what to fix next, or directly when the user asks "what should I fix here", "propose a fix for this gap", "grill me on this decision", or "what's the load-bearing question here".

Renders the andon board from the current OKF ledger state without running a new pass — which stages/wires are green, red, or unknown, the current cycle/pass counters, the active constraint, and the single most useful next step. Use this when the user asks "where does andon stand", "show me the andon board", "what's the current constraint", "what should andon fix next", or "andon status".