The01Geek

create-issue

Use when you have a rough user story, bug report, or feature idea that needs to become a well-structured GitHub issue.

docs-verify

Use when you need to verify or update internal documentation for a specific topic, or when documentation may be outdated or missing for a feature.

implement

Use when a comment or message contains /devflow:implement followed by a GitHub issue number. Runs the full 4-phase lifecycle — setup, implementation, code review, and documentation.

init

Use when setting up DevFlow in a repo for the first time, or after a plugin update — scaffolds .devflow/config.json from the shipped template (when absent) or backfills newly-added keys into an existing one (preserving your values), and refreshes config.schema.json. Invoke explicitly with /devflow:init.

pr-description

Use when generating or updating a PR description for the current branch. Takes an optional issue number as argument.

review-and-fix

Use when you need findings on a PR or current branch to be auto-applied, not just reported.

review

Use when you need a code-review verdict on a PR or current branch, without auto-applying any fixes.

docs-bootstrap-external

Use when setting up external documentation for the first time, performing a comprehensive documentation refresh, or when large portions of internal docs need corresponding external docs created.

docs-bootstrap-internal

Use when setting up internal documentation for the first time, when the docs directory is empty or poorly organized, or when a codebase has no structured developer documentation yet.

docs-release-notes

Use when a PR has customer-visible changes (new features, bug fixes, UI changes) that need a release note entry, or when finalizing a branch before merge.

docs-sync-external

Use when internal documentation has been updated and external customer-facing docs need to be aligned, or when checking for outdated, missing, or confidential content in external docs.

docs-sync-internal

Use when code changes on the current branch need corresponding internal documentation updates, or when reviewing a branch before pushing to ensure docs are aligned with code.

docs

Use when all documentation needs updating for a branch — internal docs, external docs, and release notes — in a single pass before pushing or merging.

retrospective-audit

Stage B of /devflow:retrospective-weekly: given the bundled context of every occurrence PR for one recurring pattern, re-derive the root cause, make the intervention edits in the working tree, and return the touched paths + PR title + PR body as JSON. Invoked as a subagent on a branch the orchestrator already created.

retrospective-weekly

Run the weekly devflow self-improvement loop locally: scan freshly-merged watched-author PRs, write per-PR retrospective entries (LLM only for PRs that fail the mechanical clean-gate), derive recurring patterns, and open one human-reviewed intervention PR per actionable pattern. Use when running the weekly devflow retrospective + audit.

retrospective

Stage A of /devflow:retrospective-weekly: analyze one non-clean PR from its pre-fetched context bundle and return a retrospective entry as JSON. Invoked as a subagent — do not call it directly.