Claude Skills by OutlineDriven

Use when a course needs numbered problem, solution, and explainer scaffolds. Not for a CLI or Next.js project scaffold: use scaffold-nextjs.

Use when the user wants a course, a learning workspace, or ongoing teaching across sessions, with cited lessons and retention-gated advancement. Not for one-off explanations: use explain-concept.

Use when the user says "wait, what", "the explanation is unclear", "say that again", or asks to restate the last response in plain language. Not for tasks that require source or remote-system changes.

Use when the user wants to be walked through code, not handed a report: "walk through this", "guided code walk", or "explain this codebase". Not for tasks that require source or remote-system changes.

Use when Survey and Job Culture Index profiles need analysis for stress, burnout, disengagement, or flight-risk signals. Not for clinical diagnosis: use a qualified clinician.

Use when two colleagues'' working friction needs trait-based explanation, accommodations, process changes, and escalation boundaries, or for manager-report friction. Not for performance adjudication.

Use when a Culture Index profile needs comparison with role requirements, team composition, and manager profile for hiring. Not for transcript prediction: use culture-interview-profile-prediction.

Use when asked to predict Culture Index traits from an interview transcript before a survey exists, including sparse or contradictory evidence. Not for interpreting completed survey results.

Use when a manager needs profile-specific communication, one-on-one, motivation, and energy guidance for a direct report. Not for general pair or team compatibility analysis.

Use when a signed new hire''s Culture Index profile and team profiles need a first-90-days plan. Not for manager coaching: use culture-manager-coaching.

Use when an agreement-seeking interaction arises, including mid-conversation moments the model detects.

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.

Use when the user wants to collapse an open decision field to one decision and record its rationale locally. Not for multi-lens pressure testing. No remote or irreversible changes.

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.

Use when the user wants to expand a decision field with additional options and dimensions. Not for selecting or applying an option: use decide. No source or remote-system changes.

Use when the user explicitly requests a Tarot draw or casually delegates an ambiguous choice among multiple valid approaches.

Use when a user wants to define failure states, recovery actions, bypasses, and degraded modes for a component during design. Not for runtime recovery.

Use when a user wants to rebuild a design, organization, or API from primitives. Not for a perspective take: use from-perspective.

Use when a durable effort needs an approved, checkable success predicate before work starts. Not for requirement-to-evidence ledgers. Never remote, credential, publish, deploy, or irreversible.

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.

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.

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.

Use when the user says "loop me" or asks to design a recurring workflow. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when the user needs a compact read-only current-work view from Git state, recorded test evidence, and optional graph.yaml. Not for tasks that need source or remote-system changes.

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.

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.

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.

Use when the user asks for a flattened view of roadmaps and next actions. Not for multi-session route planning: use wayfinder.

Use when the user wants to harden a chosen but tentative artifact into one durable result. Not for remote, credential, publish, deploy, or irreversible changes.

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.

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.

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.

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.

Use when settled conversation decisions need synthesis into an agent-ready implementation spec, stopping before publication. Not for turning plans into tickets: use to-tickets.

Use when product copy needs buyer-objection evidence collected through approved, consented outreach. Not for unsolicited outreach or survey design.

Use when the user wants the current jargon weather of a domain described without advocacy. Not for choosing a positioning move: use 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.

Use when asked to research a feature across competitor products or to analyze competitor release changelogs (mode: changelog), and publish a cited report.

Use when customer feedback, NPS, churn, email feedback, call transcripts, or voice-of-the-customer analysis needs a report over a time window.

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.

Use when invoking /product-signal-pulse with an optional lookback window to query configured product signals. Not for credential, publish, deploy, or irreversible changes.

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.

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.

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.

Use when asked to find distribution opportunities for a template, tool, or artifact. Not for content creation or campaign management.

Use when the user says release this, publish this package, or cut a release for a changesets-based npm package. Not for non-npm packages or releases without a changesets workflow.

Use when a release or a since-tag window needs user-facing release notes drafted. Not for publishing the release.

Use when the user asks to cherry-pick, backport, or apply a hotfix to a release branch. Not for merging feature branches or cutting new release branches.

Use when the user asks to cut, trigger, or start a release candidate for a release branch. Not for full releases, hotfixes, or non-release-candidate workflow dispatches.

Use when a human runs /merge-and-deploy to merge a PR and trigger or verify deployment. Don''t use for tasks that require source changes or without explicit human confirmation at each gate.