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 it and never conflicts with it, in the same way that your.prflow/config.json stays yours across updates.
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.
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 final-pass reviewer inside the review engine reads requesting-code-review.md.
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:pr-description is a single pass and loads it once.
Write the file as instructions, not as background reading. If you want a tool called, say so, because the agent acts on what the text tells it to do.
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 run reports that the extension loaded, 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 passed to the pass that audits the draft issue, added to its standard checklist. Use it to teach the auditor the assumptions your issues must respect.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.
- Read the command’s own output. It reports the extension’s resolved status: content was loaded, the file was absent or empty, or the status could not be established.
- For
/prflow:implement, open the workpad comment on the issue. Its progress list carries aprompt extension resolvedline for each extension the run loaded. The run cannot report itself complete while such a line is unresolved and unexplained.
/prflow:implement or a /prflow:review command — the workflow also checks arrival on its own, separately from what the run says about itself. If the repository has an extension whose text never reached the run, the job fails with an error rather than finishing quietly. On the local tier and on a run with no workpad, the same check is made from the command’s own reported status: a run that cannot establish that the 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.
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.