Claude Skills by OutlineDriven

Use when adding telemetry, composing a durable observability surface, reviewing alerting rules, shipping a production feature, or diagnosing an opaque production issue. Instruments code with structured logs, bounded metrics, and critical-path tracing, then verifies local emission. Not for diagnosing a live failure right now, profiling measured slowness, or launch-day runbooks.

Use when a human says "overhaul", "rebuild this subsystem", or "rewrite it from scratch" and the broken structure must be demolished and re-derived from its contracts. Deletes rather than deprecates, collapses special cases into the general case, and migrates every caller in one change. Not for thin-slice features — use incremental-implementation; not for root-cause bug repair — use strike-the-root.

Use when multi-step work must be broken into dependency-ordered tasks before implementation begins. Gives every task a checkable acceptance criterion and a coherent size bound, then requires explicit user approval. Not for scoring a plan; use planning. Not for a committed-direction brief; use plan.

Use when a request names a working principle (subtract before you add, idempotent operations, never block on the human) or asks which principle governs a decision. Returns the law and its bite point; routes to the owning skill for execution. Not for running a repair — use fix.

Use when a trusted bug or performance report needs reproduction and fix. Drives the application, captures reproduction evidence, implements the minimal fix, and opens one draft PR with human approval. Not for untrusted reports or scope beyond the named feature.

Use when a bug report or UI-visible defect exists. Spawns repro agents to reproduce it locally and writes an artifact directory containing a structured summary with status, steps, environment, evidence, and next step. Not for fixing the bug — use reproduce-and-fix-issues.

Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts. Read both intents from primary sources, resolve every hunk, verify with scoped checks, and finish the integration. Not for people-mediation conflicts — use culture-conflict-mediation.

Use when asked to receive code review feedback: clarify every item, implement accepted items locally with tests, draft technical pushback for questionable items, and stop before any GitHub reply or remote mutation. Not for posting replies — use resolve-pr-feedback.

Use when a human asks for the change shape before reading a diff. Renders a compact summary of added/removed files, line counts, and change type so the human can decide where to dive in. Not for a full findings report — use review; for an interactive walk — use show-review.

Use when asked to run smoke tests or verify a local build. Applies minimal fixes that unblock a stable passing result and reports flake risk honestly. Not for iterative bug fixing — use fix.

Use when a user supplies existing SARIF to inspect, filter, aggregate, deduplicate, diff, convert, or gate findings without running a scanner. Produces the requested findings or derived artifacts. Not for running a scanner — use the relevant security-review skill.

Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Backs every framework decision with a cited official source and flags unverified patterns. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a significant feature begins or specs are checked in: author or update behavioral specs and keep them current with what ships. Not for producing the initial approved spec and plan — use spec-driven. Don''t use for remote or irreversible changes.

Use when starting a project or feature, requirements are unclear, or a change crosses modules. Produces an approved six-area spec, plan, tasks, and an offensive-first TDD implementation. Not for implementation from existing specs — use spec-driven-implementation.

Use when asked to develop a fix or feature test-first, plan a multi-step TDD build, or work red-to-green in slices. Writes attacks before implementation, probes the suite with mutations, and advances one vertical slice at a time. Not for hardening existing code without a change; use tests-adversarial. Not for deleting weak tests; use tests-purge-unneeded.

Use when settled conversation decisions need synthesis into an agent-ready implementation spec at docs/specs/<feature-slug>-spec.md, stopping before publication. Not for turning plans into tickets — use to-tickets; not for remote, credential, publish, deploy, or irreversible changes.

Use when a quick structural overview of a target directory is needed before deeper codebase analysis. Runs a read-only Trailmark summary returning detected languages, Entrypoints, and Dependencies. Not for detailed structural analysis — use trailmark-structural; not for full graph queries — use build-program-graph; not for source or remote-system changes.

Use when a user explicitly invokes this skill to apply an invariant-first, fail-fast, special-case-eliminating baseline to a named implementation. Not for encoding domain models in types or design-by-contract — use type-driven or contract-driven.

Use when asked to compare implementation against repository specs, report material mismatches, and resolve each one by the user''s decision. Also handles acknowledged PR-review commitments when the branch has review history. Not for general fact-checking — use verify-both-ways.

Use when asked to review a diff and produce a 7-section visual page: scope, before/after, risk, coupling, and merge recommendation, each cited from evidence. Not for interactive review walks or PR-specific review — use show-review or pr-review.

Use when a new isolated worktree or branch is requested, or an existing ref or PR needs isolation. Creates or attaches an isolated git worktree the harness can see and reports its exact path and status. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when the caller supplies one falsifiable out-of-happy-path invariant and a finite patch budget. Restores it through bounded candidate patches or reverts the run and reports non-convergence. Not for normal feature delivery or universal retries.

Use when one issue or PR is too large for a worker and partitions into disjoint write sets. Builds a task DAG, composes a reviewed result, or names the falsified node or split. Not for independent parallel tasks — use parallel-launch. No remote or irreversible changes.

Use when any bounded workflow starts or reaches an action, path, proposal, or merge boundary. Loads constraints before the first action, re-evaluates them at every boundary, and refuses rather than default-allow on an unreadable constraint set.

Use when the user explicitly requests a Tarot draw or casually delegates an ambiguous choice among multiple valid approaches. Runs a cryptographically random 12-house Tarot draw and interprets the spread to state one planning or investigation direction.

Use when defining, revising, or gate-replanning the project structural backbone in project-root graph.yaml; produces a validated approved revision preserving immutable topology and additive metadata. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a request is long, bundled, high-stakes, or has ambiguous referents. Verifies understanding before non-trivial work: restates, cross-checks context, proceeds silently, surfaces a surviving fork. Not for tiered scans — use clarify; not for interviews — use interview-me.

Use when material arrives without a fully formed ask or the ask is thinner than the data suggests. Proposes the intent as a confirmation-ready proposal with a next-step sketch. Not for an interview — use interview-me.

Use when repository content crosses into working context or synthesized knowledge. Flags encoded, disguised, and imperative injections by source and blocks derived instructions. Don''t use for tasks that require source or remote-system changes.

Use when a compact current-work view is needed from Git state, recorded repository test evidence, and optional graph.yaml. Return one read-only view that classifies every claim as conquered, disputed, or fog. Don''t use for tasks that require source or remote-system changes.

Use when work is about to grow past the ask, the task may already be done, or the user requests only the minimum. Produce a bounded contract whose every admitted action is necessary, then stop at proof. Not for executing the work — use the appropriate build or fix skill.

Use when a design dispute has at least two live interpretations and the caller wants those worlds made explicit or needs one plain-language paragraph ending in one recommendation. Emits one paragraph at a five-year-old abstraction level with one non-binding recommendation. Not for selecting a design or changing source or remote systems.

Use when an artifact or skill has just changed and is about to be called done, committed, or handed off. Runs the relevant hygiene checks and applies their findings. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user suspects no installed skill covers a task and wants proof. Searches the installed catalog exhaustively, names the owning skill if one exists without invoking it, or writes a precise missing-skill brief if none does. Never routes or invokes the matched skill.

Use when about to report a task, feature, or fix as done, complete, finished, working, or ready, or before a commit, PR, or next-task move. Runs the narrow proving action and classifies the claim VERIFIED, PARTIAL, UNVERIFIED, FAILED, or TIMEOUT. Not for fact-checking assertions — use verify-both-ways; not for measuring a claim — use verify-this.

Use when the user wants to classify abstractions as useful, bad, or busy and keep one shallow level. Classifies each by whether its cooked form is easier than its raw form, and selects one shallow level. Don''t use for tasks that require source or remote-system changes.

Use when a user wants to enumerate plausible designs, configurations, scenarios, and paths and diagram the field before choosing. Produces an exhaustive enumerated field and a diagram before any choice. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when a user wants adversarial stress-testing of a proposed architecture, structure, or shape. The agent attacks while the human defends, or the agent proposes while the human attacks, until the shape survives or breaks. Records the surviving shape as a decision. Not for tasks that require source or remote-system changes.

Use when the user wants a cybernetic flow design document for an interactive system. Specifies sensors, actuators, feedback paths, delays, and oscillation risk, and writes the design to a named local file. Not for implementing or deploying the system.

Use when a user wants a looser conceptual graph for exploratory work. Generates a freeform conceptual graph that the user can explore. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to render documentation as an interactive, navigable HTML canvas. Fetches files, directories, or URLs, extracts headings and sources, and produces a self-contained HTML artifact with a table of contents. Not for writing or restructuring docs.

Use when a user wants to define failure states, recovery actions, bypasses, and degraded modes for a component during design. Produces a failure-state design document mapping every bounded failure state to its recovery, bypass, or degraded mode. Not for runtime recovery.

Use when a user wants to rebuild a design, organization, or API from primitives. Produces a first-principles rebuild spec naming primitives, structure, and open assumptions. Not for a perspective take — use from-*-perspective seats. Writes one local spec; no remote mutation.

Use when the user wants to replace a greenfield attempt with a clean pad carrying only verified requirements. Preserves the old attempt in VCS history. Not for rebuilding from primitives — use from-first-principle. Requires a committed, VCS-recoverable current attempt.

Use when asked to render a GitHub PR as a standalone review HTML page. Fetches PR data via gh API, renders diffs with move detection, and serves the artifact on a local port. Not for Cursor Canvas output — use pr-review-canvas.

Use when asked to render a PR review in Cursor Canvas. Produces a local canvas artifact with risky hunks foregrounded. Not for standalone HTML rendering — use pr-review-canvas-html.

Use when asked to create a presentation, pitch deck, or web deck from a topic and audience. Originates the narrative spine, slide content, and speaker notes, then applies design and runs an editorial QA pass. Not for formatting existing content into slides.

Use when asked to draft launch or promotion copy for a shipped feature across channels via /release-promotion. Returns every drafted channel as a labeled copy-pasteable block with a revision offer. Not for posting, publishing, scheduling, or committing — drafts only.

Use when the user says "give this rhythm", "vary the structure", or "the sections all read the same". Derives a rhythm constraint from the document''s own sections or from a disclosed seed with random inputs. Not for judging an artifact''s overall taste — use taste.

Use when a course needs numbered problem, solution, and explainer scaffolds. Creates type-specific files with non-colliding names, populates them, and validates with the course linter. Not for a CLI or Next.js project scaffold — use scaffold-cli or scaffold-nextjs.