GitHub collection
outlinedriven/odin-claude-plugin
Imported from GitHub — is this yours?
120 skills imported from this repository.
api-and-interface-design
Use when asked to design or change a public API, route, CLI flag, or module boundary. Not for remote, credential, publish, deploy, or irreversible changes.
breaking-driven
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.
clean-clean-cut
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.
code-simplification
Use when the user asks to simplify, clean, or refine code. Not for new abstractions or whole-codebase refactors.
constraint-driven-development
Use when asked to implement under non-negotiable constraints: performance budgets, platform limits, legal or API rules. Not for remote, credential, publish, deploy, or irreversible changes.
contract-driven
Use when crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. Not for remote or irreversible changes.
deprecate-and-migrate
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.
deps-upgrade
Use when dependency upgrades need batching for CVEs, a major release, forced compatibility, a scheduled or vulnerability-triggered sweep. Not for PR queue triage: use github-backlog-triage.
design-it-twice
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.
dimensional-analysis
Use when code mixes units, fixed-point precisions, scaling factors, rates, prices, shares, or conversions. Not for type-level unit modeling: use type-driven.
document-api-endpoint
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.
guillotine
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.
incremental-implementation
Use when implementing a multi-file change, building a feature from a breakdown, or writing a large amount of code. Not for a single settled ticket: use work.
minimalism-driven
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. Not for performance tuning: use optimize.
no-comments
Use when asked to audit comments in code files and propose structural replacements or deletions with per-candidate approval. Not for deterministic commented-out-code removal: use deslop.
principles
Use when a request names a working principle (subtract before you add, idempotent operations, never block on the human) or asks which principle applies. Not for running a repair: use strike-the-root.
refactor-break-compat
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.
reproduce-and-fix-issues
Use when a trusted bug or performance report needs reproduction and fix. Not for untrusted reports or scope beyond the named feature.
restart-keeping-lessons
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.
slicing-code-context
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.
source-driven
Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Not for remote, credential, publish, deploy, or irreversible changes.
spec-driven-implementation
Use when a 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.
strike-the-root
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.
to-greenfield
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.
unleak-abstraction
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.
ai-collab-protocols
Use when the user describes an AI workflow gap or uses an ambiguous cross-session reference such as 'the PR Bob mentioned'. Not for tasks that require source or remote-system changes.
axiom-mode
Use when the user requests axiom, axiom-mode, axiom-compact, formal-logic, or compact form. Not for changing code or remote state.
enforce-workflow-constraints
Use when any bounded workflow starts or reaches an action, path, proposal, or merge boundary. Refuses rather than default-allow on an unreadable constraint set.
necessary-work
Use when work is about to grow past the ask, the task may already be done, or the user requests only the minimum. Not for executing the work: use tdd to build or strike-the-root to fix.
post-change-check-gate
Use when an artifact or skill has just changed and is about to be called done, committed, or handed off. Not for remote, credential, publish, deploy, or irreversible changes.
skill-gap-finder
Use when the user suspects no installed skill covers a task and wants proof. Names the owning skill or writes a missing-skill brief. Never routes or invokes the matched skill.
verification-before-completion
Use when a task, feature, or fix is called done, complete, finished, or fixed, or before a commit, PR, or next task. Not for fact-checking: use verify-both-ways. Not for measuring: use verify-this.
attack-shape
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.
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.
cross-lens-converge
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.
decision-rationale-gaps
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.
doubt-driven
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.
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.
punishing-practices
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.
abstract-well
Use when the user wants to classify abstractions as useful, bad, or busy and keep one shallow level. Not for tasks requiring source or remote-system changes.
define-goalstate
Use when the user wants the finished-system contract for a piece of work: behavior, protocols, allowed, forbidden, and impossible states with a state-space proof. Not for runtime verification.
entropy-assisted-planning
Use when the user explicitly requests a Tarot draw or casually delegates an ambiguous choice among multiple valid approaches.
fail-design
Use when a user wants to define failure states, recovery actions, bypasses, and degraded modes for a component during design. Not for runtime recovery.
from-first-principle
Use when a user wants to rebuild a design, organization, or API from primitives. Not for a perspective take: use from-*-perspective seats.
generalize
Use when asked to derive the general rule a request carries as examples instead of a stated rule, then bound it. Not for ambiguity in a stated request: use askme. Read-only.
graph-backbone
Use when defining, revising, or gate-replanning the project structural backbone in project-root graph.yaml. Not for remote, credential, publish, deploy, or irreversible changes.
idea-sparkbox
Use when the user asks to park ideas or inspiration for later. Not for code, backlog, or divergence-class cards, or remote, credential, publish, deploy, or irreversible changes.
leave-only-first-principle
Use when asked to prune a design or codebase until only primitives remain, producing a first-principles map. Not for remote, credential, publish, deploy, or irreversible changes.
next-best-action
Use when a project is between phases, the author asks what to do next, too many threads are open, or work needs re-entry. Not for gating whether one named task may proceed.
possible-worlds
Use when a design dispute has at least two live interpretations and the caller wants worlds made explicit or a plain-language recommendation. Not for selecting a design or source/remote changes.
readiness-assessment
Use when a user asks for a gut-check on a decision or action, or asks whether enough is known to proceed. Not for numeric confidence scoring.
spec-driven
Use when starting a project or feature, requirements are unclear, or a change crosses modules. Not for implementing from an existing spec: use spec-driven-implementation.
state-machine-workflow
Use when work has distinct modes and the user wants states, events, guards, outcomes, illegal transitions, not a prose todo list. Not for remote, credential, publish, deploy, or irreversible changes.
tasty-abstraction
Use when a user wants to design an abstraction boundary that collapses a complex implementation into a simpler interface without leaking internal state. Not for implementation.
todos-enhance
Use when tasks are too vague, read as headings, or the user asks to sophisticate the todos. Not for stale reconciliation: use todos-update. Not for adding requirements: use todo-add.
todos-update
Use when user asks to update todos, resync the task list, say what to do next, or plan and tree have drifted apart. Not for coarse lists: use todos-enhance. Not for adding requirements: use todo-add.
to-questionnaire
Use when user wants an async questionnaire, a discovery questionnaire, or a knowledge gap needs answers outside the repo. Not for direct conversation: use askme. Not for agent research: use research.
to-tickets
Use when a settled plan needs implementation tickets published as blocker-linked slices, tracer bullets, or expand-contract sequencing. Not for implementation: use work.
buyer-objection-research
Use when product copy needs buyer-objection evidence collected through approved, consented outreach. Not for unsolicited outreach or survey design.
buzzword-analysis
Use when the user wants the current jargon weather of a domain described without advocacy. Not for choosing a positioning move: use buzzword-hijack.
buzzword-hijack
Use when a user wants to choose and execute a bounded positioning move that rides a jargon wave. Not for describing the jargon weather of a domain: use buzzword-analysis.
competitor-feature-research
Use when asked to research a feature across competitor products or to analyze competitor release changelogs (mode: changelog), and publish a cited report.
customer-feedback-report
Use when customer feedback, NPS, churn, email feedback, call transcripts, or voice-of-the-customer analysis needs a report over a time window.
developer-experience-review
Use when dogfooding a developer-facing product or workflow to produce an evidence-backed DX scorecard. Not for visual UI audit: use web-design-review.
pricing-projection
Use when projecting cost, estimating BYO cost or spend, or sizing a deal. Not for remote, credential, publish, deploy, or irreversible changes.
product-signal-pulse
Use when invoking /product-signal-pulse with an optional lookback window to query configured product signals. Not for credential, publish, deploy, or irreversible changes.
recorded-feedback-analysis
Use when asked to analyze a screen recording, voice capture, or meeting notes artifact for product feedback. Not for credential, publish, deploy, or irreversible changes.
release-promotion
Use when asked to draft launch or promotion copy for a shipped feature across channels via /release-promotion. Not for posting, publishing, scheduling, or committing, drafts only.
social-sentiment
Use when the user asks for a weekly sentiment report, weekly social summary, or how mentions looked this week. Not for continuous monitoring or alerting.
viral-opportunity-scout
Use when asked to find distribution opportunities for a template, tool, or artifact. Not for content creation or campaign management.
write-product-spec
Use when a user asks for a product spec with invariants, a tech spec, or a PRD. Modes: product (default), technical, requirements. Not for task breakdown: use plan.
audit-project
Use when the user says "audit my code", "find all the bugs", "review until clean", or "grill my changes". Not for remote, credential, or irreversible changes.
blast-radius
Use when asked to determine what a change could break before it ships. Not for remote, credential, publish, deploy, or irreversible changes.
complexity-grill
Use when a user wants to identify the true sources of complexity qualitatively before counting metrics. Not for source or remote mutation.
feedback-pattern-sweep
Use when recent resolved feedback may reveal a broader recurring defect pattern across the project surface. Not for source-level feedback collection: use feedback-sweep.
perspective-complete-review
Use when one named review viewpoint must run fix cycles until a fresh reviewer finds nothing. Not for multi-viewpoint review or remote, credential, publish, deploy, or irreversible changes.
pr-impact-quiz
Use when the user invokes this skill to generate targeted questions proving the author understands the change's codebase effect. Not for reviewing the change: use review.
show-review
Use when the user wants a per-finding visual walk through a diff or PR. Not for written review reports: use review. Not for codebase tours: use show-me.
spec-to-code-compliance
Use when implementation must be checked against an authoritative specification, or during PR review for spec drift against checked-in specs. Not for spec updates: use spec-driven-implementation.
browser-qa
Use when the user runs /browser-qa for report-only QA results without entering a fix loop. Not for remote, credential, publish, deploy, or irreversible changes.
control-cli
Use when asked to reproduce, profile, or verify CLI/TUI behavior. Produces a deterministic transcript or profile proof with session cleanup. Not for CLI design advice, use cli-for-agents.
control-ui
Use when asked to verify or reproduce browser or Electron UI behavior with before-and-after evidence and no leftover processes. Not for remote, credential, publish, deploy, or irreversible changes.
exhaustive
Use when asked to prove coverage, find missing cases, or enumerate state, decision, requirement, or behavior space. Not for round-based or single-property tests: use askme, property-test-authoring.
full-product-evaluation
Use when a complete product needs production-like acceptance evidence against documented acceptance criteria. Not for single-component evaluation or evaluation without documented criteria.
lighter-checks
Use when verification is looping, would re-run untouched code, or duplicates an established proof. Not for tasks that require source or remote-system changes.
meaningful-test-coverage
Use when a test surface needs behavior-guarding coverage raised to a configured target with mutation kill evidence. Not for line-coverage inflation without mutation proof.
mutation-campaign-configuration
Use when asked to initialize, scope, estimate, configure, validate, or optimize a mewt, muton, or mutation testing campaign before execution. Writes the TOML config. Not for running it: use the mewt CLI.
mutation-triage-genotoxic
Use when a mutation campaign leaves surviving mutants needing triage. Classifies each as false-positive, missing-test, genotoxic, or removable. Not for setup: use mutation-campaign-configuration.
possible-worlds-qa
Use when a product surface must be tested against extreme or hostile worlds. Not for design disputes: use possible-worlds. Not for remote, credential, publish, deploy, or irreversible changes.
proof-driven
Use when property-based testing, theorem proving, or formal proof tactics require zero unproven properties. Not for remote, credential, publish, deploy, or irreversible changes.
MCP servers (4)
-
critic
stdio
npx -
repomix
stdio
npx -
sequential
stdio
npx -
shannon
stdio
npx
Connection details are shown as declared in the repository; arguments and environment values are deliberately not imported.