Claude Skills by OutlineDriven

Use when the user wants to batch-close resolved or outdated tracker items. Fetches item metadata, filters by evidence-backed criteria, and presents a prepared batch for the user to close manually. The agent never closes tracker items itself. Not for individual item closure or items still under active work.

Use when the user asks to create a PR, open or update a draft PR, write or refresh a PR description, or summarize changes for review. Runs the full template-gated flow by default; a quick mode opens a lightweight PR when the user asks for speed. Not for multi-PR stacks or release publishing.

Use when the user asks to cut, trigger, or start a release candidate for a release branch. Validates the branch against configured channel prefixes, dispatches the release workflow, receives the run URL, and posts a status notification. Don''t use for full releases, hotfixes, or non-release-candidate workflow dispatches.

Use after a build, QA pass, demo, user complaint, or abandoned attempt when the next pass needs lessons rather than code. Writes an evidence-backed memo and next-cycle plan so a fresh agent can preserve working assets, reject failed patterns, and test the right gates first. Not for changelog extraction; not for session handoff — use handoff.

Use when the user needs to restore service from a specific known failure by applying a single prescribed recovery operation. Verifies the symptom, validates the prescription against its authority source, records the rollback path, applies the operation, and confirms restoration via a health signal. Not for design-time failure definition or open-ended debugging.

Use when implementation is complete and the full test suite is green and an integration decision is needed for a development branch or worktree. Don''t use for branches with failing tests or for starting new work.

Use when the user says ship it now, no phases, or finish it now, or when in-scope work would otherwise be deferred to phases, rollouts, follow-up PRs, or TODOs. Implements every in-scope path in one change. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user asks to fix P0s, address critical issues, or work on priorities from the weekly product briefing. Don''t use for non-P0 issues or local bug fixes.

Use when a set of open PRs needs landing together: gate, fix minor findings, merge parent-first. Not for single-PR review feedback — use resolve-pr-feedback. Not for gate-only evaluation without merge — use gate-proposed-change. Human-only.

Use when the user asks to find PRs to review or check the team review queue. Returns a table of open PRs needing review with URLs and reasons. Not for summarizing PR feedback — use get-pr-comments. Read-only.

Use when the user explicitly invokes branch or worktree cleanup for a repo with accumulated local branches. Also handles tidy''s scratch-file cleanup when the user says tidy and the target is scratch artifacts. Don''t use for remote branch deletion or force-push operations.

Use when the user asks for release, version bump, changelog, or branch workflow beyond a single commit. Don''t use for single commits or for publishing to a package registry.

Use when the user explicitly invokes backlog triage for a GitHub repository''s open pull requests and issues. Don''t use for proactive triage, non-GitHub trackers, or single-issue bug triage — use github-bug-report-triage for one bug issue.

Use when evaluating whether a bug issue has sufficient detail and identifying missing information from the reporter. Don''t use for feature requests, questions, non-bug issues, or repo-wide backlog triage — use github-backlog-triage.

Use when finding duplicate GitHub issues or checking for similar issues against a target issue. Runs a multi-strategy search and returns a duplicates classification. Don''t use for closing, labeling, or modifying any duplicate issue.

Use when a durable effort needs an approved, checkable success predicate before work starts; writes the goal, verifier, budget, and run-log scaffold. Not for requirement-to-evidence contract ledgers. Never remote, credential, publish, deploy, or irreversible.

Use when a task carries guardrail-adjacent material — stealth, scraping, privacy, IP, policy, security — or mixes reversible work with irreversible, credential, data-at-rest, migration, or deletion work, or the user says "autobahn this", or the moment the agent is about to hedge, soften, or silently skip. Carves risky items into a descope ledger, then runs the safe remainder in a fresh subagent. Not for performing the carved risky work.

Use when a ticket DAG from a complete specification needs parallel execution into a green draft PR. A single approved feature is the degenerate one-ticket DAG. Not for a single settled ticket with no spec — use work; not for ticket decomposition — use to-tickets.

Use when the user explicitly asks to choose which issues or pull requests to abandon interactively. Don''t use for closing items without per-item selection and explicit approval.

Use when filing an approved task spec as a GitHub issue with a local archive and optional worktree implementer. Don''t use for spec drafting without human interrogation and redaction gates.

Use when a human asks to compare one closed or stale tracker issue with current reality and mark it done or update it. Don''t use for bulk issue reconciliation or multi-issue sweeps.

Use when a human invokes triage on a new configured Slack issue report. Produces a single classified verdict and posts it to the Slack thread, with deduped tracker state. Don''t use for triaging reports from other channels or posting more than one verdict.

Use when a maintainer or collaborator explicitly asks to review and land one external pull request. Don''t use for internal pull requests or landing without preserving contributor authorship.

Use when the user says "loop me" or asks to design a recurring workflow. Produces workflow specs that an implementer can build without another question. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when a human explicitly asks to reshape or annotate one pull request for review. Don''t use for pushing the rewritten branch or mutating any remote.

Use when a browser extension that talks to a native messaging host fails: the extension reports disconnected, tools time out, or the wrong host spawns because two client applications registered manifests for the same host name. Reconciles to exactly one active host with a reachable socket. Not for network, browser-install, or unrelated extension failures.

Use when a human explicitly asks to ship work through a clean branch and pull request. Don''t use for force-pushing, reusing conflicting branches, or widening the change scope.

Use when a user starts a new work session and asks to split human decisions from agent execution. Writes a contract-bound brief under run/<session-id>/ and runs spawn, work, review, and human-gate phases to completion. Not for remote, credential, publish, deploy, or irreversible 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. Returns exactly one next action with an observable done-when and a cited reason it beats other visible options. Not for gating whether one named task may proceed.

Use when the user explicitly asks to create, update, query, or archive Notion pages, databases, or blocks. Not for bulk operations, recursive edits, or widening the workspace scope.

Use when the user asks to choose, reconcile, or apply an open-source license and package metadata. Classifies candidates using standard OSI families, checks dependency license compatibility against the reciprocity goal, and when requested applies the chosen license atomically across LICENSE, package metadata, and README. Not for readiness auditing.

Use when a plan must be stress-tested, iteratively improved, and scored against a 5/5 quality bar across six dimensions. Drafts, scores with a deterministic rubric, and revises up to a fixed iteration limit. Not for a committed-direction brief; use plan. Not for task breakdown; use planning-and-task-breakdown.

Use when a human explicitly requests the daily on-call Sentry issue digest for a configured Slack channel. Not for posting without explicit human authorization for that run.

Use when a landed merge, release, or completed change needs its cleanup surface reconciled. Scans the diff for stale TODOs, satisfied deprecations, unused flags, and documentation gaps; applies bounded local fixes in a worktree and files tickets with assigned ownership for the rest. Not for unrelated refactoring.

Use when a user explicitly asks to post, update, or check cherry-pick status for a release as a single Slack Block Kit status board. Lists PRs belonging to the release, maps observed evidence to defined cherry-pick statuses, merges manual overrides, and posts or updates exactly one message. Not for mutating pull requests or posting to multiple messages.

Use when the user explicitly asks to share a message on Slack through an incoming webhook. Not for posting without an explicit request or for retrying an ambiguous delivery.

Use when a human explicitly asks to link a GitHub issue and Linear ticket to a pull request body. Appends one Issues block with the supplied references. Not for unlinking, searching for issues, or substituting missing identifiers.

Use when asked to prepare a repository for public launch: audit for secrets, harden licensing, documentation, CI, and release automation; stop before the visibility switch. Don''t use for remote, credential, publish, deploy, or irreversible changes.

Use when the user asks to propose an issue, file or open a bug report, or turn a reported defect into a tracked issue. Grounds the defect in cited source, gates it, and files one issue. Don''t use for fixing the defect, triaging existing issues, or reviewing PRs.

Use when asked to commit and push to the currently checked-out branch, including the default branch. Don''t use for creating branches, opening PRs, force pushes, or pushing any branch other than the current one.

Use when the user decides to ship a release. Bumps version, commits, writes release notes, and pushes a signed tag after two explicit human confirmations. Not for running workflow-owned steps by hand — use the CI/CD workflow. Not for PR-based releases — use publish-release-pr.

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 a scheduled or watcher tick requests a repository-health pass. Classifies CI, PR, issue, commit, discussion, and run-state signals as High, Watch, or Noise with evidence, then persists a bounded report. Not for source, label, merge, or close mutation.

Use when addressing GitHub PR review comments or resolving review threads. Fixes valid findings, posts quoted replies, and resolves threads via GraphQL. Don''t use for non-GitHub review feedback (use resolve), merging PRs, or branch management.

Use when the user explicitly wants to walk PR review comments, collect per-comment decisions, and post approved replies or resolve threads on GitHub. Don''t use for analyzing whether a comment is valid (use resolve) or for non-GitHub review feedback.

Use when the user asks to reply to or follow up on a specific Slack thread. Converts a permalink to channel and thread_ts, posts one reply, and returns its permalink. Not for top-level messages, deleting messages, or composing the reply text.

Use when a human directly requests review and publication of an existing diff, or work passes the explicit signal authority: delegated. Reviews the diff, fixes release-blocking findings, verifies with native checks, packages atomic commits, and opens or updates a pull request. Not for merging pull requests, force pushes, history rewrites, or deployment.

Use when asked to set, list, pause, update, or delete a personal reminder or lightweight local task that fires at a confirmed time or interval. Installs through the platform backend with per-platform mechanisms, writes a metadata record, and verifies both. Refuses destructive scheduled actions. Not for remote, credential, publish, or deploy operations.

Use when creating or hardening an npm release with Trusted or Staged Publishing. Writes hardened workflow drafts, configures cooldown and postinstall settings, and produces a human handoff for every remote-only action. Partitions E404 packages so Trusted Publisher setup is sequenced after first publish. Not for remote changes or publishing.

Use when a user opens a new build cycle in a repo with an established iteration convention and wants the casebook directory to exist with real content from the first observable moment. Builds the complete seed in a temporary sibling directory and atomically renames it into place. Not for ongoing triage or multi-repo setup.