prflow

Plugin prflow from marketplace devflow-marketplace in The01Geek/prflow. Commands read from the repo's manifest — 4 days ago.

Skills (21)

• challenge

  Use when asked to challenge, refute, push back on, or stress-test an idea, feature request, bug report, GitHub issue, approach, or PR, including one already review-approved. Returns an evidence-backed recommendation without implementing it.

• create-issue

  Permanent alias for /prflow:spec, which runs the same issue-drafting pipeline; prefer /prflow:spec. Use when a rough user story, bug report, feature idea, piece of feedback, or an implementation plan should be recorded as a GitHub issue rather than built right now. Kept so existing /prflow:create-is

• 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 c

• 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

• 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

• 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".

• 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

• 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

• 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 singl

• fix

  PRFlow's code-review reception skill (formerly receiving-code-review). Use when addressing review feedback already posted on a pull request — verifying each finding before fixing it or pushing back — as distinct from /prflow:review-and-fix, which runs the review itself and then fixes what it found.

• help

  Use when a PRFlow command misbehaved, failed, ran slow or cost too much and the user wants to know why — "PRFlow is broken", "implement got stuck", "help me troubleshoot PRFlow", "file a PRFlow bug report". Checks the user's PRFlow setup, gives one verdict, and writes a local bug report for a likely

• 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

• 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

• pr-description

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

• requesting-code-review

  Use when completing a task or major feature, or before merging, to have PRFlow's final-pass reviewer check the work against its requirements.

• 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

• retrospective-weekly

  Run the weekly PRFlow 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 wee

• 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.

• 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". Require

• 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 cur

• spec

  Turn a rough request into an implementable GitHub issue through bounded clarification and design decisions — "file a ticket", "open an issue", "track this bug", "spec this out for later". Open-ended product exploration belongs to brainstorming; building the work belongs to implementation.

Subagents (21)

• ac-claim-verifier

  PRFlow implement's Phase 3.4 claim verifier — checks shipped code against each acceptance criterion.

• ac-evidence-verifier

  PRFlow implement's Phase 3.4 evidence verifier — establishes each criterion's verification evidence.

• branch-setup

  PRFlow implement's Phase 1.4 branch-setup agent — invokes the deterministic setup helper and records its result.

• checklist-generator

  PRFlow review-engine agent; use to enumerate every verifiable claim in a code diff as a JSON checklist.

• checklist-verifier

  PRFlow review-engine agent; use to verify one checklist claim against the source code.

• code-architect

  PRFlow implement's planning agent — designs an implementation blueprint from codebase patterns.

• code-explorer

  PRFlow implement's discovery agent — answers remaining questions about existing behavior and affected consumers.

• code-reviewer

  PRFlow reviewer; reviews a diff for guidelines, style and bugs, or for cleanups when a dispatch selects cleanup mode.

• comment-analyzer

  PRFlow review-engine reviewer; use to check code comments match the code before a PR.

• deferral-drafter

  PRFlow implement's Phase 4.0 agent — drafts follow-up issue bodies for deferred criteria.

• fix-delta-reviewer

  PRFlow fix-delta reviewer; use to review a fix's own diff, blinded, for defects the fix introduced.

• implement-finalization

  Use when implement reaches Phase 4 or resumes unfinished finalization.

• implement-intake

  PRFlow Phase 1 intake: issue requirements, acceptance criteria, resume/workpad preparation and dependency checks.

• issue-claim-auditor

  PRFlow implement's Phase 1.6 audit agent — pre-checks the issue's claims against the codebase.

• pr-test-analyzer

  PRFlow review-engine reviewer; use to review a PR's test coverage for gaps.

• requesting-code-review

  PRFlow final-pass reviewer; reviews a change against its acceptance criteria and for correctness, design and tests.

• review-engine

  Fix-loop review-engine entry: runs /prflow:review Phases 0-4.3 fresh; returns dispatch_mode + return-file path.

• review-fix-worker

  PRFlow implement Phase 3.3 worker: runs the docs pass and review-and-fix loop; returns a validated handoff.

• silent-failure-hunter

  PRFlow review-engine reviewer; use to hunt silent failures and weak error handling in a diff.

• spec-risk-investigator

  Use when spec dispatches early risk investigation alongside discovery, before drafting.

• type-design-analyzer

  PRFlow review-engine reviewer; use to review newly-added types' invariants and encapsulation.

Similar plugins