PACREF for Claude Code: The Six Things Every Prompt Needs
Most prompt frameworks were built for chat. You open ChatGPT, you write a message, you get a message back. The whole exchange happens in a context where the AI knows nothing about you, your code, or what you're working on.
Claude Code is a different beast. The model can read your entire repository before you finish typing. It can run commands. It can write files. It can break things. The prompt isn't just a request for a response, it's an instruction handed to a system that's about to act.
That changes what makes a good prompt.
I've been using Claude Code in production since the start of 2025, and I've noticed that the prompts that work are not the prompts that look impressive. They're boring. They follow the same six-part structure every time, because every part is doing real work.
A friend of mine working in marketing introduced me to a framework called PACREF: Persona, Action, Context, References, Structure, Format. It was built for non-developers using Cowork to draft emails and reports. I stole it, kept the bones, and rewired the priorities for Claude Code. The result is below, with examples from the WordPress workflows I actually run every week.
P — Persona
For chat prompts, persona is everything. "You are a senior copywriter with twenty years of experience" steers tone, vocabulary, and confidence level.
For Claude Code, persona is nearly useless. The model is editing files, not writing prose. Telling it to "act as a senior PHP developer" doesn't change much because the code either compiles or it doesn't. At the end of the day, it’s a binary process.
When I do use persona, it's narrow and specific:
"Treat this codebase as a WordPress.org plugin that has to pass the official Plugin Check. Apply WordPress Coding Standards strictly."
See? Not a persona, but an explicit rule. It works because it tells the model which of its many internalized styles to default to. Without that line, you get generic PHP that will fail the WordPress plugin review for things like prefixed function names or sanitization conventions.
The lesson: if the persona doesn't change what gets written, it's decoration. Cut it.
A — Action
This is where most people fail. They write the action like a wish list.
"Fix the bug in checkout."
Fine for a teammate who knows what bug. Useless for Claude Code, which will read all of WooCommerce, trying to figure out what you mean, and then helpfully refactor things you didn't ask about.
Better:
"In the file includes/class-checkout-validator.php, the validate_billing_address method returns true even when the postal code is empty. Find why and propose a fix. Do not modify any other file unless necessary."
Specific scope. Specific behavior to look for. Specific constraint on blast radius. The action verbs matter: "find why" before "propose a fix" gives you a diagnosis you can review before any code changes. "Do not modify any other file" prevents the helpful sprawl.
A good action says what to do, where to do it, and when to stop.
C — Context
In chat, context is whatever you paste. In Claude Code, context is mostly already there. The model can read the project. It can run grep. It can pull commit history.
What you add manually is the context that isn't in the code. The why.
"This plugin has a 7-year-old codebase with two senior contributors who are no longer active. Style is inconsistent across files. We need to introduce new features without breaking the existing patterns that the current users depend on. Backward compatibility is more important than internal consistency."
That paragraph changes everything about how the model behaves. Without it, Claude Code will try to "improve" the code by normalizing patterns. With it, the model knows that the inconsistency is a feature, not a bug.
The context that matters most is the kind you can't read from the files: client priorities, historical decisions, things that look wrong but exist for a reason.
R — References
This is the dimension that breaks furthest from chat-based PACREF.
In chat, references are usually one or two examples pasted into the prompt. In Claude Code, references are files, directories, URLs, or specific git commits. You point at them by path.
"Use the structure of plugins/wp-myplugin/includes/class-api-handler.php as a reference for how API integrations should be organized in this codebase. Match the docblock style and the exception handling pattern."
This is the prompt that turns generic AI output into output that fits your codebase. Without a reference, Claude Code generates plausible code that you will need to adapt to your conventions during the review process. With a good reference file, the output drops in clean.
The mistake I see most often is referencing too many files. Pick one or two canonical examples. The model will pattern-match better from a focused reference than from "use the rest of the codebase as a guide."
S — Structure
Structure is how the response is organized. For a piece of writing, that's headings and paragraphs. For a Claude Code task, it's the order of operations.
"Approach this in three phases. First, audit. Read all files matching the pattern admin/views/*.php and report which ones have unsanitized user input. Stop after the audit. Wait for me to confirm before any fixes. Second, propose fixes for each finding, one file at a time, showing me the diff before applying. Third, apply only the fixes I approve."
Three explicit phases. Pause points. Approval gates. This is the difference between letting Claude Code loose and using it as a structured collaborator. The structure is a contract. Without it, the model will collapse all three phases into one heroic response, and you'll spend the afternoon untangling what it changed.
If the prompt doesn't say where and how to stop, the model will not stop. Discipline lives in the structure.
F — Format
For chat, format is "bullet points" or "table" or "JSON." For Claude Code, format is closer to "what artifact do I want at the end."
A diff. A new file at a specific path. A markdown report. A modified config. An updated test suite. The output type tells the model what shape its work needs to take.
"Output: a single git commit with a clear commit message in conventional commit format, no other changes. The commit should contain only the bug fix and a regression test that fails on the old code and passes on the new."
That's a tightly specified format. Every constraint exists because something went wrong before. Conventional commits because I review PR titles in bulk and need them to be parseable. Single commit because mixing fix and refactor in one commit makes it impossible to bisect later. Regression test because that's how you know the fix actually fixes the bug.
Format is where the senior developer's instincts go. Junior devs ask "should I write a test?" Senior devs assume the test exists because nothing ships without one. The prompt has to encode the same defaults.
A complete PACREF prompt
Here's how all six pieces look together for a real task I ran last month:
[Persona]
Apply WordPress Coding Standards. This plugin must pass Plugin Check
for the WordPress.org repository.
[Action]
The shortcode [wpai_recent_posts] occasionally returns no output
when called from a widget context. Find why. Propose a fix.
Do not modify the public template files.
[Context]
This shortcode worked correctly until WordPress 6.5. The bug appeared
after a client upgraded. The plugin is used in production by ~3,000
sites and breaking changes are not acceptable.
[References]
Use the error handling pattern from includes/shortcodes/class-author-list.php
as a reference. Logging should match what's in includes/class-logger.php.
[Structure]
First, diagnose. Show me the root cause with file/line references
before any code changes. Second, propose the fix as a diff.
Third, write a unit test that reproduces the bug.
[Format]
Final output should be: a markdown diagnosis, a single diff applied
to one file, and a new test file under tests/shortcodes/.
That prompt is 180 words. Reading it takes thirty seconds. It saves an hour of cleanup compared to the version where I would've just typed "fix the recent posts shortcode."
The point isn't the acronym
PACREF isn't magic. None of these frameworks available online is. The point is that it forces you to articulate what you actually want before the model starts working. The acronym is scaffolding to keep you from forgetting a dimension.
The dimensions that matter most for Claude Code, in order of impact: References, Structure, Action. Those three carry roughly 80% of the quality difference between a prompt that works and a prompt that doesn't. Persona and Format are useful at the margins. Context fills the gaps that the model can't read from the code.
If your prompts feel hit-or-miss, try writing your next one with all six labels in the actual prompt, in this order. Once it's a habit, you can drop the labels, and the structure stays. That's the goal. Or, maybe, create a skill that does the heavy work for you.
If you're building AI workflows for your team and want help getting them past the demo-and-pray stage, that's what I do for a living. Drop a line.