Claude Skills by OutlineDriven

Use when shaping a source document paragraph by paragraph without modifying it. Not for selected-beat assembly: use writing-beats. Not for fragment capture: use writing-fragments.

Use when validating crypto against Project Wycheproof vectors, or explaining a disagreement with a vector. Not for vector creation: use vector-forge. Not for zeroization: use zeroize-audit.

Use when asked to run /xcode-simulator-testing with a scheme name or current to build and launch an iOS app in a simulator. Not for project regeneration: use ios-build-fix.

Use when writing, reviewing, optimizing, validating, or migrating YARA or YARA-X malware-detection rules, including CRX or DEX rules. Not for network IDS or memory-forensics rules.

Use when auditing C, C++, or Rust secret-handling code to verify zeroization survives compiler optimization. Not for test vectors: use wycheproof.

Use when agent strategies need a reproducible finite tournament under a frozen evaluation protocol. Not for open-ended or infinite matchups: use a continuous benchmark.

Use when non-trivial code needs a design, codebase design or architecture needs improving, or one module needs targeted interface narrowing, seams, or testability. Not for diagrams, deploy, or irreversible changes.

Use when bloated code needs clean re-derivation, or the user says "this module is bloated" or "break it and rebuild". Not for untracked data or changes without VCS rollback.

Use when asked to run /clean-clean-cut to cut accumulated records and residue. Not for untracked or non-VCS changes, or branch/worktree cleanup: use git-cleanup.

Use when asked to remove old code, migrate consumers, or decide whether to maintain or sunset a system. Not for untracked data or changes without VCS rollback.

Use when asked to design a module interface, seam, or testable boundary. Not for UI direction picking: use design. No source or remote-system changes.

Use when code mixes units, fixed-point precisions, scaling factors, rates, prices, shares, or conversions. Not for type-level unit modeling: use type-driven.

Use when reconciling an API endpoint''s generated OpenAPI schema and declared response types with its actual runtime response. Not for general API documentation: use docs-and-adrs.

Use when replacing a greenfield attempt with a clean pad of verified requirements. Not for rebuilding from primitives: use from-first-principle. Requires a committed, VCS-recoverable attempt.

Use when dead, duplicate, superseded, or generated residue must leave more than one artifact class of a repo or subsystem, preserving behavior. Not for one enumerated record set: use clean-clean-cut.

Use when asked to optimize code, make a path faster, make this as fast as possible, reduce allocations, repair a regression, profile a target, grill every inefficiency, or run a subsystem or repo-wide performance campaign against a measured floor; when a performance requirement, slowness report, Core Web Vitals miss, or profiling evidence identifies a bottleneck; or for an "extremely optimize" performance campaign, optimizing suspected hot paths without waiting for benchmarks, or estimating h...

Use when modernizing APIs, removing compat shims, killing feature flags, or rewriting a subsystem cleanly. Not for additive refactors that must preserve the old path.

Use when an implementation has more workarounds than structure and another patch will not pay. Not for in-place re-derivation: use breaking-driven. Not for one-artifact rewrites: 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. Not for source changes or broad repository exploration.

Use when a bug, failure, flake, regression, review finding, or ticket needs the core fixed so it cannot recur. Not for greenfield features: use tdd. Not for style-only review or typo-class one-liners.

Use when the user says greenfield this or rescue this codebase, names a field (dark, red, blue, or brown), or diagnoses a subsystem. Not for specs: use to-spec. Not for remote or irreversible changes.

Use when an abstraction leak must be sealed as a module seam, configuration option, or explicit override, or exposed as a named boundary. Not for detecting concealment patterns: use no-hide.

Use when the user wants adversarial stress-testing of a proposed architecture, structure, or shape. Not for tasks that require source or remote-system changes.

Use when the user asks for a council, second opinions, or parallel investigation. Not for cross-examination of existing proposals: use cross-critique.

Use when independent proposals on a contested decision need cross-critique before choosing, reusing the original authors. Not for parallel multi-stance investigation: use council.

Use when one reviewer is not enough because failure modes are heterogeneous, or a claim needs cross-lens pressure before it ships. Not for collapsing a decision field: use converge.

Use when a current decision needs pressure-testing until the rationale is clear to a skeptic. Not for tasks requiring source or remote-system changes.

Use when a non-trivial decision sits under uncertainty and correctness matters more than speed. Not for patch review: use review. Not for plan attacks: use load-bearing-assumption-test.

Use when the user asks why a plan is wrong or says "poke holes in this". Not for tasks that require source or remote-system changes.

Use when one reviewer angle is insufficient or the user suspects a direction is tunnel-visioned or inherited its framing. Modes: artifact, direction. Not for source or remote-system changes.

Use when a workflow, plan, diff, or completed work cycle must be checked for practices that punish the project later. Not for source, remote, credential, publish, deploy, or irreversible changes.

Use when asking "overkill?", "elegant?", "audit", or "taste-test this", or setting a taste register. Not for tasks that require source or remote-system changes.

Use when asked to push an already-working artifact to finished composition, texture, and feel. Not for remote or irreversible changes. Not for hygiene routing: use clean-and-true.

Use when a visual needs repeatable fixed-view rendering and independent rubric scoring. Not for free-form visual review or subjective critique.

Use when a rendering path needs stable frame-time, CPU, GPU, and memory evidence against fixed targets. Not for one-shot profiling or visual quality review.

Use when an authorized reference surface needs a clean-room frontend reconstruction across static, motion, and responsive fidelity. Not for styling or component work without a reference surface.

Use when a human invokes this skill to build a webhook UI that wakes a bot. Not for unpreviewed or unapproved credential, host, Tailscale, deployment, remote, paid, or irreversible changes.

Use when asked to prototype one design question through a cheap logic or UI experiment, including button-driven state-model checks. Not for polished artifacts: use polished-web-prototype.

Use when thumbnail concepts need real-size, accuracy-first scoring without misleading claims. Not for generating thumbnails or declaring winners that fail the accuracy rubric.

Use when asked to build spring, easing, gesture, and choreographed animations with correct physics and reduced-motion support. Not for auditing existing motion or finding animation opportunities.

Use when the user requests an accessibility audit, a11y check, or WCAG compliance review. Don''t use for tasks that require source or remote-system changes.

Use when asked to design, write, review, refactor, lint, or performance-diagnose Lean 4 proofs, libraries, or tactics. Not for non-Lean code or changes outside source, API, proof, or linter scope.

Use when a user needs coverage-guided fuzzing for Python code or a Python native extension using Atheris. Not for remote, credential, publish, deploy, or irreversible changes.

Use when initializing, running, measuring coverage, or triaging a cargo-fuzz target in a Rust crate. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a user needs to create or improve a deterministic, engine-agnostic fuzz harness for raw or structured target inputs. Not for coverage measurement: use fuzzing-coverage-analysis.

Use when a user needs to measure fuzz corpus coverage, explain a coverage plateau, or turn uncovered regions into campaign work. Not for harness creation: use fuzz-harness-writing.

Use when a parser, protocol, or file format fuzzer stalls at fixed-token validation gates and needs a coverage dictionary. Not for patching the SUT: use fuzzing-obstacles.

Use when asked to identify and bypass checksums, nondeterminism, or validation barriers that block fuzzing coverage. Not for dictionary creation: use fuzzing-dictionary. Local writes only.

Use when a LibAFL fuzzer needs an executor, observer, feedback, mutator, scheduler, or objective composed around a target. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to build, run, or triage a coverage-guided C/C++ fuzz campaign on the libFuzzer or AFL++ engine. Not for harness design: use fuzz-harness-writing.