devcanon

Continues a normalized issue-priming workflow into design and implementation readiness, with optional autonomous execution to a reviewable PR. Use when `linear-issue-priming` or `github-issue-priming` hands off a normalized issue payload. Do not use when starting from a raw Linear identifier or GitHub issue number — invoke the entrypoint instead.

Explicit-invocation workflow for guiding executable ideas into approved designs saved to `.ephemeral/`, or emitting durable owner referral notices for non-executable work. Use only when the user explicitly invokes `play-brainstorm` or an owning workflow explicitly requires brainstorming.

Primes a GitHub issue into a research-backed implementation workflow with isolated worktree and brainstorming. Use when starting work on a GitHub issue — triggers on issue numbers, issue URLs, or phrases like "start issue", "work on issue", "prime issue".

Provider-neutral batch routing for GitHub and Linear issue work across owner threads, PR gates, approvals, merges, and archival. Use when monitoring or routing a mixed batch of issue-provider records through existing issue, review, CI, PR, and thread workflows.

Primes a Linear issue into a research-backed implementation workflow with isolated worktree and brainstorming. Use when starting work on a Linear issue — triggers on Linear identifiers (ENG-123), Linear URLs, or phrases like "start issue", "work on issue", "prime issue".

Explicit-invocation workflow for verification-first response to code review feedback. Use only when the user explicitly invokes `play-review-response` or asks to address review feedback through that workflow.

PR merge automation with CI polling and in-scope failure investigation. Use when a PR is ready to merge pending CI, or when asked to "merge this PR" or "check CI and merge".

Audits a repository's documentation against the repository's own documentation standard, surfaces findings by severity, and applies user-selected fixes. Use when explicitly invoked with phrases like "garden docs", "documentation audit", "doc rot check", or "documentation health check". Do not use for incidental doc edits, prose rewrites, ADR drafting, or deciding what should be documented.

Writes durable Linear project descriptions and content briefs. Use when asked to draft, dry-run, apply, revise, or update a Linear project's short description or detailed content/brief. Do not use when writing time-windowed project updates, health reports, or update history posts.

Writes concise Linear project updates from project evidence. Use when asked to draft, dry-run, apply, post, create, revise, or update a stakeholder-readable Linear project update or health report based on project issues, updates, milestones, target date, linked PRs, and repository evidence.

Product requirements authoring workflow for durable product intent before behavior specs or issue slicing. Use when creating, updating, drafting, reviewing, or shaping docs/product-requirements content. Do not use for acceptance-ready behavior specs, roadmap sequencing, architecture decisions, implementation plans, or live issue tracking.

Behavior-spec authoring workflow for durable product and workflow behavior under docs/specs. Use when writing, creating, updating, drafting, reviewing, or shaping acceptance-ready behavior requirements. Do not use for broad product intent or PRDs; use write-product-requirements for docs/product-requirements work.

Drafts, revises, adapts, and reviews prose while preserving meaning, evidence, terminology, and artifact-owner contracts. Use for direct prose work or post-owner polish after an owning workflow has established artifact type, evidence, structure, and mutation boundaries. Do not use for owner-artifact drafting, product intent, behavior requirements, Linear mutation policy, documentation audit scope, or missing owner documentation.

Multi-agent code review of a local branch's commits against a base ref. Use when reviewing a branch before creating a PR or when the user asks to review changes without a GitHub PR.

Explicit-invocation workflow for closing out a development branch via squash merge, push and PR, or discard cleanup. Use only when the user explicitly invokes `play-branch-finish` or an owning workflow explicitly requires branch completion.

Internal multi-agent review pipeline shared by `branch-review` and `pr-review`. Use when invoked by one of those wrappers. Do not use directly — call `branch-review` for local diffs or `pr-review` for GitHub PRs.

Explicit-invocation workflow for writing comprehensive implementation plans as bite-sized tasks saved to `.ephemeral/`. Use only when the user explicitly invokes `play-planning` or an owning workflow explicitly requires implementation planning.

Shared pull request title and body authoring policy for PR creation and pre-merge validation. Use from PR workflow skills that need consistent PR descriptions.

Multi-agent code review of a GitHub pull request, with critic-verified findings and user-gated posting. Use when asked to review a GitHub PR, re-review after author pushes fixes, or check a pull request for issues. Triggers on PR numbers, PR URLs, or phrases like "review PR", "check this PR", "follow-up review".

Drafts an upstream DevCanon issue for a reusable shared-skill or shared-agent need surfaced from a consumer repo. Use when the user explicitly asks to draft or create an upstream DevCanon issue for a reusable shared skill or shared agent problem, or when a sanitized PR-comment follow-up explicitly requests filing one.

Read-only readiness review for durable AFDS artifacts before issue slicing. Use when checking whether a PRD, behavior spec, roadmap item, guideline, ADR, or source-owner artifact is ready to become executable work. Do not use for implementation-vs-spec review.

Internal controller procedure for tracking, cleaning up, and recovering subagent sessions before workflows spawn additional subagents. Use only when another shared workflow invokes or references it.

Support-only runtime bundle for DevCanon skill helper entrypoints. Use only through explicit helper adapters that need packaged deterministic runtime support.

Explicit-invocation workflow for executing an implementation plan with fresh subagents per independent task. Use only when the user explicitly invokes `play-subagent-execution` or an owning workflow explicitly requires plan execution.

Support-only validation contract for shared Play review artifacts. Use when a Play review wrapper or adapter must delegate deterministic review-artifact validation across PR review, branch review, or generated and installed review skill bundles.

Provisions an isolated worktree for issue work as the single source of truth for worktree-setup policy across consumer skills. Use when a workflow needs an issue worktree from either the primary checkout or a managed worktree.

Deterministic cleanup of Git worktrees and local branches back to the remote default branch. Use when the user asks to clean all linked worktrees, return the primary checkout to the remote default branch, or delete local branches after work is complete.

Explicit-invocation workflow for dispatching independent tasks to parallel subagents with isolated context. Use only when the user explicitly invokes `play-agent-dispatch` or an owning workflow explicitly requires parallel agent dispatch.

Explicit-invocation workflow for systematic root-cause debugging before fixes. Use only when the user explicitly invokes `play-debug` or an owning workflow explicitly requires root-cause debugging.

Explicit-invocation workflow for TDD-style skill authoring with subagent pressure scenarios for baseline testing and loophole closure. Use only when the user explicitly invokes `play-skill-authoring` or an owning workflow explicitly requires skill-authoring verification.

Explicit-invocation workflow for test-driven development discipline before implementation. Use only when the user explicitly invokes `play-tdd` or an owning workflow explicitly requires tests-before-implementation.

Explicit-invocation workflow for evidence-backed completion checks before claiming work is complete, fixed, or passing. Use only when the user explicitly invokes `play-verification` or an owning workflow explicitly requires completion verification.

Drafts provider-neutral executable issue bodies from durable AFDS evidence. Use when slicing a PRD, behavior spec, roadmap item, guideline, ADR, source-owner artifact, or readiness review into GitHub Issues or Linear work.