What a Skill Extension Is
A skill extension is a Markdown file in your repository whose text PRFlow adds to the end of a command’s own instructions each time that command runs. The file belongs to you, not to the plugin. A plugin update never overwrites your instructions, but preserved instructions can still refer to PRFlow behavior that has changed. Review those references when upgrading. Settings in.prflow/config.json change values PRFlow already knows about. A skill extension adds instructions PRFlow could not know about, such as the name of your verification command or a rule about code that must never change.
Where the File Goes
Put the file at.prflow/skill-extensions/<command>.md. Replace <command> with the command name without the /prflow: prefix.
For example, /prflow:review reads .prflow/skill-extensions/review.md.
Running /prflow:init creates the directory and writes one commented example per command, named <command>.md.example. An example file is inert. It is a single Markdown comment, so it changes nothing even if you rename it by mistake. To activate it, rename it to <command>.md and replace the commented body with your own instructions.
Commit the file. Your team shares one copy, and cloud runs read it from the committed tree.
This directory was named
.prflow/prompt-extensions/ in an earlier release. If your repository still has it under the old name, everything keeps working: every command resolves .prflow/skill-extensions/ first and falls back to a present .prflow/prompt-extensions/, printing a breadcrumb that names the old path. Running /prflow:init (or re-running the installer, which runs the same scaffolder) renames the directory to .prflow/skill-extensions/ for you, carrying every file across; when both directories already exist it renames nothing and tells you to merge them by hand.Which Commands Read One
Every PRFlow command reads its own file. These are the commands documented on this site:/prflow:review-and-fix reads two files because its fix loop applies the code-review reception rules without running that command, so a rule you write once in fix.md reaches every fix pass. When the loop loaded review-and-fix.md with content and a fingerprint, the reviewer that checks each fix iteration’s changes loads the file itself and applies it only when it loads a copy matching the loop’s; otherwise it reports that check as not verified. Without that load the reviewer gets no extension, for example when the file is empty or cannot be read, or when your vendored PRFlow is too old to report the fingerprint, which the loop notes in its reflections.
The
fix extension was renamed from an earlier name in a recent release. If you customized the extension under its previous name, it keeps applying across the upgrade: when fix.md is absent the loader reads your old file and prints a breadcrumb naming the exact file to rename to fix.md. Running /prflow:init (and re-running the installer, which runs the same scaffolder) renames the file to fix.md for you. On a cloud run the base-branch materialization still finds the old file and warns. Renaming it yourself, or letting init do it, ends the transitional read-through. The release notes name the previous file.docs-sync-internal.md, docs-sync-external.md, docs-release-notes.md, docs-verify.md, docs-bootstrap-internal.md and docs-bootstrap-external.md. The review engine reads requesting-code-review.md for its final-pass reviewer.
How the Text Reaches the Run
The command loads the file at the start of the run and appends its contents, word for word, to the end of its own instructions for that run only. Nothing is merged, summarized or rewritten. Long commands reload the file when they enter a new phase, so your instructions stay in effect through a run that lasts an hour./prflow:implement also checks the file again when it merges your base branch just before review, so an extension change merged meanwhile applies to the review. /prflow:pr-description is a single pass and loads it once.
Write instructions that state the repository outcome you need instead of copying PRFlow’s core mechanics or anchoring rules to incidental internal names. If you want a tool called, say so.
Follow Two headings the spec extension treats specially below for the requirements it covers. Use ordinary prose for other requirements, retaining exact literals that a tool reads.
Write One
A team keeps its checks behind one command and treats shipped database migrations as immutable. They commit this file./prflow:implement run: the workpad’s Skill extension resolved line shows the extension loaded (see Check That It Was Applied), the run uses make verify as its verification command, opens the pull request with a “Rollback” section and refuses to edit a shipped migration, proposing a new migration file instead. See Tool Permissions for the grant format.
Two headings the spec extension treats specially
Two headings the spec extension treats specially
/prflow:spec reads two headings in .prflow/skill-extensions/spec.md by name, in addition to using the whole file as instructions.A section headed exactly ## Audit dimensions is added to the standard audit checklist. PRFlow applies it to its own draft before the first audit round, and each audit round’s auditor receives it too. Use it to teach the drafter and the auditor the assumptions your issues must respect. See Approval Points for audit preparation.A section headed exactly ## Evidence axes is passed to the pass that gathers evidence before the draft is written. Use it to name the kinds of evidence a draft must cover for your repository.A section runs from its heading line to the next line that starts with ## . An extension without these headings changes nothing about those passes and still works as ordinary appended instructions. The scaffolded spec.md.example contains an inert sample of both headings.Check That It Was Applied
Do not assume the extension was used. Confirm it:- Run the command.
- For
/prflow:review,/prflow:review-and-fix,/prflow:pr-descriptionand/prflow:fix, read the command’s output: it names the extension’s resolved status — content was loaded, the file was absent or empty, or the status could not be established. Other commands do not report the status themselves when the extension loads or its file is absent or empty;/prflow:implementrecords it in its workpad (step 3). For what a failed load reports, see When the File Cannot Be Read. - For
/prflow:implement, open the workpad comment on the issue. Its progress list carries aSkill extension resolvedline for theimplement,review-and-fixandfixextensions. The run cannot report itself complete while such a line is unresolved and unexplained. Thereviewextension, and each reviewer’s extension, is loaded by the review itself and has no line: when the review reports that one of them failed to load, was refused or could not be established, the run records that in the workpad’s reflections; if that write fails, no workpad or pull request records the failed load.
implement for /prflow:implement, and for /prflow:review, /prflow:review-and-fix or /prflow:pr-description that command’s extension plus requesting-code-review (for /prflow:review) or fix (for /prflow:review-and-fix). A review command’s job fails with an error when one of those files is present but cannot be delivered; an implement job fails when the run finishes Complete, or successfully with no workpad, and the implement extension’s arrival cannot be established. Everything else, on either tier, rests on the command’s own reported status: a run that cannot establish that an extension arrived records that fact in a durable place (the workpad, the pull-request description, or the command’s own output) rather than passing silently — except a failed review or reviewer extension load in an implement run, which reaches the workpad only when its reflection write lands (step 3).
When the File Cannot Be Read
If a run reports an unestablished state, fix it before you trust the run’s output. That run followed none of your house rules.
On cloud runs the
review, review-and-fix, pr-description, fix and requesting-code-review extensions are read from a copy taken from the pull request’s base branch, not from the branch under review. A change to one of those files takes effect after it merges. This stops a pull request from editing the instructions its own reviewer follows. See Security.