Claude Skills by OutlineDriven

Use when a repository decision needs an interview plus durable terminology and decision records; interview the code domain model, then write each resolved term and decision into CONTEXT and ADR files. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a repository or subsystem needs dead, duplicate, superseded, or generated residue removed across more than one artifact class — code, docs, tests, dependencies, config, workflows, generated files — while preserving observable behavior. Evidence-backed cross-surface purge, not a single enumerated set. Not for deleting an already enumerated record set — use clean-clean-cut.

Use when asked to prune an existing design or codebase until only primitives remain, producing a reusable first-principles map for rewrite or study. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when a human invokes this skill to build a webhook UI that wakes a bot with server-side secret isolation and an end-to-end probe. Not for unpreviewed or unapproved credential, host, Tailscale, deployment, remote, paid, or irreversible changes.

Use when a user requests an independent Codex or Gemini review of uncommitted code, a branch diff, or a specific commit. Returns findings with exact locations and confidence. Don''t use for unconfirmed or unattended external review sends, or for local source mutation.

Use when asked to run /model-retuning [target model or symptom] [corpus path] [bar:<n> consecutive clean runs] to retune a skill corpus for a new model measurement-first. Not for static audits — use deslop for those.

Use when the user mentions mewt, muton, or mutation testing and asks to initialize, scope, estimate, configure, validate, or optimize a campaign before execution. Writes only the TOML config and validates readiness without generating mutants or touching source. Not for running the campaign: use mewt run separately.

Use when a mutation campaign has produced surviving mutants that need triage. Classifies each mutant as false-positive, missing-test, genotoxic, or removable using a coverage map, and proposes which tests to write or dead code to remove. Not for configuring or running campaigns: use mutation-campaign-configuration.

Use when the user asks to detect clever-concealment patterns that obscure real code structure. Scans every file exhaustively and flags each instance with location and severity. Not for refactoring the concealment away: use unleak-abstraction.

Use when asked to optimize code, speed up a path, reduce allocations, repair a regression, or profile a target. Full mode lands one behavior-gated hot-path change proving at least 1.05x speedup; quick mode runs a measure-identify-fix-verify loop with a noise-aware keep/revert and a CI guard. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a product surface must be tested against extreme or hostile worlds rather than collect green checks. Completeness mode classifies every world against stated criteria and reports gaps; break mode names an expected break signal per world, captures proof artifacts, and escalates worlds that survive. Not for interpreting a design dispute — use possible-worlds; not for remote, credential, publish, deploy, or irreversible changes.

Use when a user invokes this skill to generate three targeted questions that prove the author understands how the submitted change affects the existing codebase. Not for reviewing the change — use for pre-review author self-check only.

Use when adding or improving property tests for invariants, oracles, parsers, algorithms, data structures, or smart-contract state machines. Encodes the strongest grounded property with domain-aware generators and pinned edge cases. Not for review — use property-test-review.

Use when a generated or shrunk counterexample from a property-based test fails. Classifies whether the defect is in the implementation, the property statement, or the specification, and states the minimal repair action. Not for writing or reviewing tests.

Use when reviewing existing property tests for coverage and defects. Reports tautological, vacuous, assertion-free, reimplemented, weak, or over-filtered tests with evidence, severity, and strongest replacement property. Not for generating tests — use property-test-authoring.

Use when deciding whether PBT fits a code path, which property and library to choose, or whether a design exposes a meaningful property. Returns a verdict with strongest non-vacuous property, domain, strategy seam, and library, or a decline. Not for writing or reviewing.

Use when codebase terminology or a durable technical decision changes. Records resolved terms and qualifying decisions to the project glossary and architecture decision log. Not for shaping domain language — use domain-modeling. Not for remote or irreversible changes.

Use when modernizing APIs, removing compat shims, killing feature flags, or rewriting a subsystem cleanly. Deletes old paths and rewrites every caller to the new contract with zero legacy residue. Not for additive refactors that must preserve the old path.

Use when an implementation has accumulated more workarounds than structure and another patch will not pay. Archives the failed implementation as evidence, carries forward only evidence-earned lessons, and delivers a fresh v0 vertical loop through a predeclared gate. Not for re-deriving a subsystem contract in place: use breaking-driven; not for rewriting one sedimented artifact: use rewrite-clean-v0.

Use when an exact symbol, path, entrypoint, or line range can bound a focused code question or patch proposal under a fixed source budget. Builds a deterministic slice packet and validates one constrained delegation. Not for source changes or broad repository exploration.

Use when a smart-contract codebase needs an evidence-based maturity scorecard and prioritized improvement roadmap. Rates nine categories from code and explicit off-chain evidence, computes an aggregate score, and produces a CRITICAL-to-MEDIUM roadmap. Not for vulnerability auditing, source fixes, or claims about inaccessible processes.

Use when a smart-contract project needs architecture, implementation, dependency, or testing guidance. Produces an evidence-backed assessment with recommendations. Not for maturity — use smart-contract-code-maturity-assessor; not for audit prep — use smart-contract-audit-prep.

Use when implementation must be checked requirement-by-requirement against an authoritative specification, with evidence for each verdict. Handles both standalone spec audits and PR-review spec-drift checks against checked-in spec context. Not for writing or updating specs: use spec-driven-implementation. Not for remote or irreversible changes.

Use when about to delete a test on the claim that a new harness, suite, or scenario already covers it. Requires an independent reviewer to validate the per-assertion coverage table and a tree-wide reference scrub before the deletion commit. Not for tests that catch no real bug: use tests-purge-unneeded; not for untracked data or changes without VCS rollback.

Use when the user says greenfield this or rescue this codebase, or names a field: dark, red, blue, or brown. Also handles per-subsystem diagnosis. Not for writing specs — use to-spec; not for remote or irreversible changes.

Use when a user names an abstraction leak and wants it sealed as a module seam, configuration option, or explicit override, or deliberately exposed as a named boundary. Measures hidden and wrapper complexity as branching decisions and admits the change only if the wrapper adds less than half the hidden complexity. Not for detecting concealment patterns: use no-hide.

Use when building protocols, workflows, concurrent systems, or lifecycle-heavy state that needs explicit states, transitions, and temporal properties. Defines the state machine, encodes invariants in types, and for high-risk designs runs a TLA+ or Alloy model checker. Not for encoding domain models in types — use type-driven; not for design-by-contract — use contract-driven.

Use when asked to create a project-local executable verification skill, or to repair one whose commands, paths, or assertions have drifted from the project. Writes only inside the verification-skill directory and proves the harness against the live repository. Not for remote or deployed verification, use the project s remote-proof workflow.

Use when asked to design or change a public API, route, CLI flag, or module boundary. It documents the contract with semantics and errors, then migrates every consumer so no legacy path remains. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when setting up or modifying CI/CD pipelines, quality gates, test runners, or deployment pipeline configuration through workflow files. Authors in-repository pipeline and deployment configuration with blocking gates, secret references, and rollback. Also handles configuring a deployment pipeline through CI or workflow files without triggering a deployment.

Use when the user says "CI is red", "fix the checks", or "make CI green" on a PR or branch. Diagnoses failing GitHub Actions checks, fixes the root cause, and re-verifies to green. Interactive mode applies a local fix; autonomous mode pushes to a fix branch. Not for deploys, credentials, permission-widening, or rerun-as-fix; non-CI bugs use strike-the-root.

Use when a CI check is failed, absent, pending too long, unstable, or reported unexpectedly. Classify it into a deterministic failure class with the next owner, then emit a reviewable fix plan, without patching. Not for sweeping and patching — use ci-sweeper.

Use when the user asks to simplify, clean, or refine code. Measured mode cuts duplication or branch complexity under a green test gate; clarity mode refines readability while preserving behavior by reasoning. Not for new abstractions or whole-codebase refactors.

Use when designing or improving a module interface, locating a seam, or increasing testability; the chosen module ends up with a small interface that hides complexity and is testable through seams. Not for system-level architecture decisions — use architect.

Use when the user asks to clean up a finished commit message or bring it to handoff-ready form. Rewrites only messages of HEAD or a short unpushed range; the tree stays byte-identical and dates are preserved by position. Not for creating new commits — use commit.

Use when a user asks to commit or save staged or unstaged changes, create a typed branch, or format history for changelog generation. Each logical concern is committed with a conventional-commits message carrying SemVer effect and issue-closing footers. Not for rewriting existing commit messages; use commit-economy.

Use when asked to implement under explicit non-negotiable constraints such as performance budgets, platform limits, or legal or API rules. Extracts constraints into checkable invariants, implements with fast-check loops, and verifies no constraint worsened against a baseline guard. No remote, credential, publish, deploy, or irreversible mutation.

Use when crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. Implements PRE/POST/INV contracts at the appropriate enforcement layer; violations fail explicitly at the boundary. No remote or irreversible mutation.

Use when the user asks to create a new branch or start work on one. Creates a local git branch named <type>/<short-description> on the correct base with no name collisions. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when the user says deslop, debloat, tidy, simplify, clean up this diff, or deslop a branch diff, or asks to remove dead code, placeholders, stubs, dead fields, redundant wrappers, or stale config, or the slop skill routes here. Not for remote, credential, publish, deploy, or irreversible changes.

Use when adding a new devcontainer or isolated Claude Code dev environment to a repo that lacks one, for Python, Node/TypeScript, Rust, Go, or a combination. Not for editing an existing devcontainer. No remote, credential, publish, deploy, or irreversible changes.

Use when the user asks for a call graph, class hierarchy, module dependency map, containment view, complexity heatmap, or data-flow view derived from code. Emits valid Mermaid from actual structure or explains why no edges exist. Not for embedded rendering — use embed-diagram; not for architecture diagrams — use visual-diagram.

Use when a non-trivial decision sits under uncertainty and correctness matters more than speed. Returns fresh-context adversarial findings with classified reconciliation and a stop condition. Not for patch review — use review; not for plan attacks — use advocate.

Use when auditing the developer-facing surface of a CLI, SDK, library, or package: API contracts, errors, CLI behavior, public types, onboarding, and config. Returns bounded, severity-tiered findings with root-cause analysis and committable fixes.

Use when implementing a multi-file change, building a feature from a breakdown, or writing a large amount of code. Each slice is individually tested and committed; the full suite passes and the feature works end-to-end. Not for a single settled ticket — use implement.

Use when a run needs its own branch and checkout to avoid collisions with concurrent work. Creates an isolated worktree, tracks a five-status lifecycle in a manifest, and removes only terminal worktrees. Not for feature-work isolation — use isolate-workspace-gate.

Use when asked to start feature work that needs isolation, or before executing an implementation plan. Creates an isolated git worktree with symlinked hooks, runs setup, and gates on a green baseline test suite. Not for loop-run worktree lifecycle — use isolate-work-in-worktree.

Use when verification is looping, would re-run untouched code, or duplicates an established proof. Runs the minimum complete gate once and delivers on the first green result. Don''t use for tasks that require source or remote-system changes.

Use when writing or restructuring code, before adding a helper, wrapper, config key, or dependency, or when the user asks for minimal or DRY code. Produce the smallest complete implementation whose intent is obvious. Not for performance tuning — use the optimize skill.

Use when asked to audit comments in code files and propose structural replacements or deletions with per-candidate approval. Enumerates comments in C, JavaScript, TypeScript, HTML, CSS, and shell-style syntax, classifies each as earned or unearned, drafts structural alternatives, and returns a complete accounting ledger. Not for deterministic commented-out-code removal; use deslop.