PRFlow makes agentic coding work on real codebases, a one-line request becomes a complete, tested, reviewed, documented pull request that's ready for your final review, and it improves itself weekly. Includes /prflow:implement orchestrator, /prflow:review + /prflow:review-and-fix engines (which audit their own…
Turn 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.
Phase 3.4 claim verifier. Checks the shipped code against each in-scope acceptance criterion's literal claim from the diff and the current tree, in a fresh context, and EXECUTES NOTHING (no verification command, no single-flight). For a verification-command criterion it reads the command's SOURCE and checks each…
Phase 3.4 evidence verifier. Establishes each in-scope acceptance criterion's verification evidence in a fresh context, and is the ONLY verifier that runs an in-env verification command or touches the single-flight coordination. Reports one status per criterion (satisfied | unmet | unestablished) with an evidence…
PRFlow's implement-phase Branch-Setup agent. Runs Phase 1.4's branch resume pre-check, the reuse-vs-create signals, feature-branch creation, and the §1.4.0.5 Verdict-B ahead-of-base classification against the actual repository, records each durable outcome on the workpad, and returns a structured record for the…
Merges multiple batches of checklist items from checklist-generator into a single deduped checklist. Preserves traceability by recording which original IDs were merged. Does NOT judge correctness or re-tag items.
Use when an orchestrator needs to enumerate every verifiable claim in a code diff (dependency interactions, test-mock alignment, data format assumptions, API contracts) and return a JSON checklist for independent verification. Does NOT judge correctness.
Verifies a single claim from the verification checklist against the actual source code. Reports PASS, FAIL, or INCONCLUSIVE with file:line evidence. Used for verificationmode: "agent" items; lite-mode items are resolved by the orchestrator directly via grep.
PRFlow's implement-phase planning agent. Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences.
PRFlow's implement-phase discovery agent. Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development.
PRFlow's project-guidelines reviewer, dispatched by the review engine and available directly. Use this agent when you need to review code for adherence to project guidelines, style guides, and best practices. This agent should be used proactively after writing or modifying code, especially before committing changes or…
PRFlow's comment-quality reviewer, dispatched by the review engine and available directly. Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes (1) after generating large documentation comments or docstrings, (2) before finalizing a pull request…
PRFlow's implement-phase Deferral-Drafter agent. Holds the Phase 4.0 follow-up-issue composition procedure. Given the outstanding deferred acceptance criteria, the parent issue body, and the Phase 2.2.5 scope-decision note, it composes the follow-up issue bodies under .prflow/tmp/ and returns a filing plan of those…
PRFlow's implement-phase Issue-Claim Audit agent. Runs Phase 1.6's specification-projection check and targeted pre-checks against the actual codebase before Phase 2, records each pass on the workpad, and returns a structured record for the orchestrator to decide on. Dispatches nothing itself.
PRFlow's test-coverage reviewer, dispatched by the review engine and available directly. Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases.…
PRFlow's silent-failure reviewer, dispatched by the review engine and available directly. Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk…
PRFlow's type-design reviewer, dispatched by the review engine and available directly. Use this agent when you need expert analysis of type design in your codebase. Specifically use it (1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, (2) during pull…
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.…
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…
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…
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…
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…
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…
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…