Claude Skills by OutlineDriven

Use when the user asks to choose, reconcile, or apply an open-source license and package metadata. Not for readiness auditing.

Use when the user asks whether a repository is ready for public release or wants a gap assessment. Not for choosing or applying a license: use open-source-license-selection.

Use when a user asks to post, update, or check cherry-pick status for a release as a single Slack Block Kit board. Not for mutating pull requests or posting to multiple messages.

Use when asked to prepare a repository for public launch or open source it. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user decides to ship a release as a signed tag or a redaction-gated PR. Modes: tag (default) and pr. Not for running workflow-owned steps by hand: use the CI/CD workflow.

Use when the user runs /release-landing-report to summarize landed changes and return a landing summary report. Not for tasks that require source or remote-system changes.

Use when creating or hardening an npm release with Trusted or Staged Publishing, including E404 packages sequenced after first publish. Not for remote changes or publishing.

Use when deploying to production, planning a feature release, setting up launch safeguards, or running a canary release. Not for local dev deploys or deploys without a confirmed rollback plan.

Use when the user asks to research a topic and produce a thorough sourced report. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a genealogical identity or relationship needs correlation, conflict analysis, and negative-search proof. Not for non-genealogical identity proof.

Use when researching a named library, framework, SDK, API, or service, or finding a migration guide. Not for codebase-internal research. Dispatch a scout agent.

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.

Use when asked to audit an agent or AI feature for agentic-experience quality (AX review, agent-native critique, trust question). Not for source or remote-system changes.

Use when asked to determine what a change could break before it ships. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a user wants to identify the true sources of complexity qualitatively before counting metrics. Not for source or remote mutation.

Use when auditing the developer-facing surface of a CLI, SDK, library, or package: API contracts, errors, public types, onboarding, and config.

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.

Use when asked to "interrogate" or run an adversarial multi-model review of a supplied code artifact. Not for tasks that require source or remote-system changes.

Use when the user asks to detect clever-concealment patterns that obscure real code structure. Not for refactoring the concealment away: use unleak-abstraction.

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.

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.

Use when a human asks for the change shape before reading a diff. Not for a full findings report: use review. For an interactive walk: use show-review.

Use when asked to review a pull request, examine code changes, find bugs, or audit a branch, in standard or depth mode. Not for an iterative review-and-fix loop: use audit-project.

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

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.

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.

Use when asked to compare implementation against repository specs, report mismatches, resolve by user decision, or check PR-review commitments. Not for general fact-checking: use verify-both-ways.

Use when asked to review a diff and produce a 7-section visual page. Not for interactive review walks or PR-specific review: use show-review.

Use when asked to run /artifact-arena to generate and judge competing artifact implementations. Not for remote, credential, publish, deploy, or irreversible changes.

Use when loop scaffold files have drifted from their provenance-pinned templates. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a human has an approved delivery plan and wants the full chain run under phase gates. Not for planning, open-ended debugging, or single-step execution: use work directly.

Use when a human explicitly runs /cloud-task-orchestrator for a large task across cloud agents to drain a verified task graph. Not for local subagent coordination: use orchestration-patterns.

Use when a candidate patch or answer needs independent corroboration before it is trusted. Not for multi-stance investigation: use council.

Use when a long agentic project needs each cycle to end in a learning memo and a keep/iterate/restart decision. Not for single-pass builds.

Use when the caller supplies a falsifiable out-of-happy-path invariant and a finite budget. Restores via bounded patches or reverts. Not for normal feature delivery or universal retries.

Use when a configured loop misbehaves, produces unexpected results, or its setup soundness is questioned. Not for tasks that require source or remote-system changes, not for loop design.

Use when one issue or PR is too large for a worker and partitions into disjoint write sets. Not for independent parallel tasks: use parallel-launch. No remote or irreversible changes.

Use when asked to /feedback-sweep [setup|reconfigure] [mode:non-interactive]. Not for pattern discovery: use feedback-pattern-sweep.

Use when non-trivial work should run a matched playbook to verified real-surface completion, or a bespoke workflow when none fits. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to evaluate a proposed commit, merge, or auto-merge against a gate config. Not for landing PRs: use gate-and-merge. Read-only.

Use when asked to draft copy-ready /goal objectives for long-running agents. Not for source or remote-system changes.

Use when a button click, dashboard check, or human verdict sits inside an iteration loop and needs an autonomous gate. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a high-priority run reaches at least 90% of its budget and requests an extension. Never self-grants. Not for low-priority runs: let those exhaust silently.

Use when work decomposes across subagents or role panels and needs coupling-based orchestration. Not for cloud-agent task-graph orchestration: use cloud-task-orchestrator.

Use when work splits into independent sub-tasks or cross-domain research. Not for durable scope ownership with per-scope review: use partition-scopes-to-subagents.

Use when asked to partition non-overlapping scopes across subagents and drive each to completion. Not for concurrent independent sub-tasks: use parallel-launch.

Use when asked to change state in an external system: propose the write locally and halt at the human gate without executing. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a user runs saga or asks to autonomously build a sizable feature. Not for executing a given plan: use subagent-driven.

Use when a user says execute with subagents or hands over an ordered multi-task plan. Not for credential, paid, or deployment work, or any mutation outside the skill''s designated workspace.

Use when asked to run partitioned parallel coverage or races across isolated workers. Don''t use for remote, credential, publish, deploy, or irreversible changes.