The01Geek
UserTurn feature requests into review-ready pull requests: issue, implementation, tests, a review-and-fix loop, and docs. Runs locally or on GitHub Actions, and is built for complex brownfield repos. Each week its retrospective reads what you actually merged and proposes improvements to your skill extensions.
Categories
Indexed Skills (37)
docs-verify
Use when the user asks whether the docs for one topic, feature, or subsystem are accurate — "is the auth flow documented?", "are the docs on retries still right?" — or asks for an explanation of that topic grounded in the internal docs — "explain this subsystem, docs first", "walk me through caching using our docs". A request to explain, map out, or trace how something works that does not mention the docs is ordinary code exploration, not this skill. Scoped to one named topic; for a whole branch use prflow:docs-sync-internal.
retrospective
Stage A of /prflow: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.
retrospective-audit
Stage B of /prflow:retrospective-weekly: given a most-recent-first subset of one recurring pattern's occurrence-PR context bundles (bounded by audit_bundle_cap), re-derive the root cause and return one JSON object carrying a ranked `findings` array (one to three sub-patterns) — no edits, no worktree. Invoked as a subagent — do not call it directly.
placeholder-probe
Render-time placeholder precondition probe for issue
pr-description
Use when generating or updating a PR description for the current branch. Takes an optional issue number as argument.
create-issue
Use when a rough user story, bug report, feature idea, piece of feedback, or an implementation plan should be recorded as a GitHub issue — "file a ticket for this", "open an issue", "write this up for the backlog", "we should track this", "log this bug", "spec this out as a ticket so we can pick it up later" — i.e. the user wants it tracked rather than built right now. For exploring or designing the work itself, reach for a brainstorming or planning skill first; this skill records the outcome as an issue.
review-and-fix
Use when the user wants problems in a pull request or the current branch both found AND corrected — "review my changes and fix what's wrong", "clean up whatever the review turns up", "address the review feedback on this branch", "tidy this PR up before merge", "find and fix the issues here". Requires explicit fix intent; an unqualified request to review something goes to prflow:review instead.
implement
Use when the user wants an existing GitHub issue turned into a finished, reviewed pull request — "implement issue 123", "pick up ticket 45", "build the feature described in issue 7", "go fix the bug in issue 99", "start working on that issue". Triggers on any request to do the work an issue already describes, whether or not a slash command is used.
review
Use when the user wants code assessed rather than changed — "review PR 88", "is this branch ready to merge?", "look over my changes", "any problems with this diff?", "give me a code review", "what do you think of this PR?", "sanity-check this branch", "ship it?". Applies to a pull request or the current branch when findings, a verdict, or a merge-readiness opinion is wanted. This is the default for an unqualified review request; use prflow:review-and-fix only when the user explicitly asks for the problems to be corrected.
init
Use when setting up PRFlow in a repo for the first time, or after a plugin update — scaffolds .prflow/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 /prflow:init.
docs
Use when documentation generally needs to catch up with a branch before pushing or merging, covering internal developer docs, external customer-facing docs, and release notes together — "update the docs", "do a docs pass before I merge", "make sure everything's documented". Prefer this when no single documentation target is named; use the narrower prflow:docs-sync-internal, prflow:docs-sync-external, or prflow:docs-release-notes when the user names one.
docs-sync-internal
Use when code changes on the current branch need matching internal or developer documentation — "update our internal docs", "the architecture docs are stale after this change", "document what I just changed", "do the dev docs still match the code?" — or as a pre-push check that developer docs track the code. Narrower than prflow:docs; use prflow:docs-bootstrap-internal when no structured internal docs exist yet, or prflow:docs-verify for a single named topic.
docs-bootstrap-external
Use when customer-facing documentation must be created from scratch or comprehensively rebuilt — "we have no public docs", "set up user-facing documentation", "build external docs from our internal ones", "do a full docs refresh" — or when large portions of the internal docs still have no external counterpart. For incremental alignment of external docs that already exist, use prflow:docs-sync-external.
docs-bootstrap-internal
Use when a codebase has no structured developer documentation yet and needs it built from scratch — "we have no docs at all", "set up internal docs for this repo", "the docs directory is a mess, start over", "create developer documentation for this codebase" — including an empty or disorganized docs directory or a ground-up reorganization. For incremental updates to docs that already exist, use prflow:docs-sync-internal.
docs-release-notes
Use when a change needs a user-visible release-note, changelog, or changeset entry — "add a release note", "add a changeset for this", "what goes in the changelog?", "write up what shipped", "note this for the next release" — or when finalizing a branch whose customer-visible features, bug fixes, or UI changes should be announced before merge. Narrower than prflow:docs, which sweeps internal docs, external docs, and release notes together.
docs-sync-external
Use when customer-facing or public documentation needs to catch up with internal docs or shipped changes — "our public docs still mention the old flag", "sync the user guide", "update the customer docs", "is anything in the external docs outdated or leaking internal detail?", "update the docs site". Narrower than prflow:docs; use prflow:docs-bootstrap-external when external docs do not exist yet.
requesting-code-review
PRFlow's final-pass review requester, dispatched by the review engine and available directly. Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
PRFlow's code-review reception skill, used by the review-and-fix loop and available directly. Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
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 file one human-reviewed GitHub issue per actionable pattern. Use when running the weekly devflow retrospective + audit.
review
Use when you need a code-review verdict on a PR or current branch, without auto-applying any fixes.
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.
review-and-fix
Use when you need findings on a PR or current branch to be auto-applied, not just reported.
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.
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.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
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 and return a single {title, body} JSON issue spec — no edits, no worktree. Invoked as a subagent — do not call it directly.
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 file one human-reviewed GitHub issue 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.
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.