Hey, welcome back 👋 If you haven't had a chance to read Part 1 introducing all of the different working parts of GitHub Copilot’s reusable prompts — check it out here.
Before we jump in, ask yourself this: How well can you anticipate Copilot’s response to your prompts?
If it still feels like a surprise every time, I seriously recommend setting aside 30 minutes to just play. You don’t need anything fancy — no reusable YAML, no multi-step wizardry. Just write a single chat message that covers everything needed to complete one task.
Do you need a brand new React component? Unit tests? Maybe your repository is two years behind on documentation (yeah... I’ve been there). Write a prompt for that!
It doesn’t matter what you try — the real goal is to see if you can supply all the info Copilot needs to get the job done in one go.
💡 Pro Tip: GPT models are especially bad at immediate execution. They’ll gather information, agree with your logic, maybe even summarize the steps perfectly... and then take no action at all. So, if you're struggling to get single-prompt execution working with the free version, it's most likely not you.
Feeling brave? Try your luck with Coding Agent. It’s a great way to test your prompting skills: how much information can you successfully feed Copilot at once? (I’ll get into all the quirks of Coding Agent in a future post — promise!)
Just know that reusable prompts are built on this same logic — a single message that defines everything needed to complete a task from start to finish.
🦄 Quick reminder: Copilot is 100% worth trying out in Insiders. IntelliJ still owns Java, no question — but you’re missing out on a lot of Copilot’s best tricks if you haven’t made the jump. 🫶
Reusable Prompts Overview 🧰
Quick recap from last week: A reusable prompt is a combination of an instruction (how to act) and a step-by-step guide. The prompt is driven by the YAML front matter, which optionally defines:
- the mode (
agent,edit,ask) - which model (
GPT-4.1,Claude Sonnet 4, etc.) - accessible tools (built-in, extensions, and MCP)
- prompt description (for completeness)
When specifying tools, be sure to follow the principle of least privilege. Use the fewest tools needed to get the job done — nothing more.
💡 Pro tip! Agent mode has access to tools, but the other modes do not. So if your prompt needs to read files, run shell commands, or write to disk, be sure to specify
mode: agent.
Personal Guide to Prompting — PRIOR 🧭
Next, let’s cover one of my personal formulas for prompt engineering. And if you try to search for this or ask Gemini what “PRIOR” stands for, you're probably going to confuse it. Why? Because I made it up. But I promise you — it works!
At its core, it’s a remix of the well-known RICE formula (Role, Instructions, Context, and Examples). RICE didn’t cover everything I needed, so I added more. RICE-O didn’t really stick (honestly, all I could think of was Rice-A-Roni...), so I went back to the drawing board and gave ChatGPT a list of words and synonyms and said:
"I need an acronym I won’t forget — because it would be just like me to have a brilliant idea that could’ve made me a millionaire, and forget it by tomorrow morning."
So, PRIOR was born — a simple checklist for designing prompts, reusable or otherwise.
🦄 I know — we really didn’t need another acronym or prompt strategy. I get it. But the ghost of Rice-A-Roni haunted my brain every time I blanked on what the letters in RICE were supposed to mean. So I made PRIOR instead.
For my non-American friends: 📦 Rice-A-Roni is a boxed rice-and-pasta side dish that’s been marketed to Americans since the 1950s as “The San Francisco Treat™.” It’s one of those nostalgic foods you grow up seeing in pantries... but never quite understand why.
Watch the ad jingle here — this is what starts playing in my head every single time, like a DeLorean back to the '90s with the radio stuck on loop. ⚡ 🚗 🕰️
The PRIOR Breakdown (For Real This Time) 🛠️
Persona 🎭 (actor — not an expert)
First is the persona, which is often underutilized and overlooked — and sometimes outright ignored.
👉 TL;DR: A persona doesn’t mean “you’re an expert” — it sets the tone. It gives Copilot a character and purpose. And it makes the whole thing way more fun!
A little history...
In the early days, personas were often used like:
“You are a senior principal engineer with 20 years of experience in C++.”
It caught on like wildfire — everyone thought they were tapping into some hidden reserve of wisdom only a 20-year C++ veteran could offer. But what it really produced was the confidence of that engineer, not the accuracy. So we ended up with a flood of responses that weren’t just wrong — they were confidently wrong.
This persona is different.
I’m not telling you to pretend the AI is an expert. I’m telling you to make it a character — a performer. Here’s one I wrote recently for summarizing a git diff:
🎩 You are not just analyzing — you’re storytelling with
source control.
You analyze code with purpose and fervor, then communicate
your insights as a short, punchy list — a clever disguise
to help users grasp the deeper essence of change they’d
otherwise scroll past.
Is it realistic? Not really. Is it useful? Absolutely. The more engaging and unique the role, the more Copilot leans into it. Wild, weird, or whimsical — it doesn’t matter, as long as it’s relevant and plausible.
💡 Bonus: It’s just more FUN this way. Try giving Copilot a totally off-the-wall persona — something weird, but still relevant to the task at hand. If it works (or breaks in a hilariously bad way), share your experiment below!
Requirements ✅
Requirements are really just your definition of done. What does it look like when the prompt succeeds?
If we continue with the commit message example, the requirement could be as simple as:
Your goal is to output a valid commit message based on the current staged changes.
Voila — done.
Of course, it could get more complex. Maybe you require a conventional commit format, or that it passes commitlint. That’s fine. Just say it clearly, and use action words.
🔌 Pretend you’re giving instructions to your 10-year-old who refuses to clean their room. You don’t say “Please can you help me tidy up now?” You say: “You MUST clean up this mess before I get back, or I swear I’ll unplug the internet and take the cord with me.”
Aside for ALLCAPS 🔠
I’m still not convinced ALLCAPS helps the AI much — but it does help you. Humans spot those key phrases easier when they stand out. So go ahead and use the usual suspects from the IETF: MUST, MUST NOT, REQUIRED, SHOULD, MAY, ...and so on.
Impediments 🧱
This is just a fancy way of saying: what can go wrong?
These are the critical blockers you want to prevent ahead of time. Impediments help shape the boundaries of your prompt, and again — ALLCAPS works great here.
For example:
-
Isolation: NEVER combine content from a previous
commit.tmpfile with a new commit message. ALWAYS start fresh. - No Shortcuts: You MUST NOT skip any steps or rules. Every line in this prompt must be followed EXACTLY.
- Specification: Follow Conventional Commits 1.0.0 specification EXACTLY
❓ Have ALLCAPS action rules helped you at all? Let me know in the comments!
Outcomes 📤
If you don’t tell Copilot exactly what outcome you expect, you risk a whole world of "not what I meant."
Ask for a commit message, and it might do that plus push the branch, delete your fork, and wipe out staging. (If you missed the wildly dramatic retelling of how I know, you’ll find it here.)
That’s where structured output helps. So spell it out. Want a file? Say that. Want it in the chat? Say that. Want both? Say that.
💡 Pro tip Copilot performs better when you give it structure. Block off output in a code block (
json,bash,markdown, etc.) and tell it what each section means. It helps Copilot stay on track and makes the output easier to copy.
References 📚
References = examples. But don’t just show good examples — show bad ones, too. And explain why they’re wrong.
Example 1: Valid Commit Message ✅
feat(api): Add new endpoint for user authentication
- Proper capitalization
- No ending punctuation
Example 2: Valid Commit Message ✅
build!(deps): Update dependencies to version 2.0, v1.0 no longer supported
- Breaking changes indicator (
!) placed properly - Clear guidance on how to handle the upgrade
Example 3: Invalid Commit Message ❌
feat(api): add new endpoint for user authentication
- Subject line must be capitalized after the colon.
Example 4: Invalid Commit Message ❌
build(deps)!: Update dependencies to version 2.0 for all dev dependencies, v1.0 no longer supported
- Subject line is too long and the
!is in the wrong place.
The point: don’t just say “do this” — explain the why, too, using repeatable patterns in a format that Copilot (or anyone) will understand.
Putting It All Together 😈🧌
Here’s what PRIOR looks like in action — all five parts, working together in a single, small, reusable prompt.
This one lives in ask mode — no tools, no diffs, no file writes. Just a structured conversation between you and the assistant, with clear goals and a very expressive little goblin at the helm.
---
mode: ask
description: |
Help the user write a one-line commit message based on a quick summary of their changes.
# No `model` here means the user gets to pick
# The lack of `tools`, however, means we're not giving Copilot any privileges as part of this task
---
# Generate Simple Commit Message Prompt
## Persona (Character) 🎭
You are the **Merge Goblin** 🧌 — keeper of branches, hoarder of squash history, sworn enemy of unresolved conflicts.
You live in the shadows of the `.git` folder and emerge only to craft commit messages worthy of legend (or at least clarity).
You write with precision and just a hint of mischief.
Your messages are:
- One-liners.
- No punctuation.
- Clear, fast, and clean enough for even the pickiest maintainer.
If a user says something confusing? You don’t guess.
You _snarl_ gently, ask for clarification, and then commit the **truth**.
> Yes, even goblins ask questions!
---
## Requirements (Goal) ✅
You MUST generate a **single-line commit message** that:
- starts with a robot emoji 🤖
- capitalizes the first word
- has **no punctuation at the end**
- summarizes the change in plain language
- is ready to be copy-pasted into `git commit -m`
If the user's input is vague, incomplete, or just plain cursed, rephrase what you think they meant and confirm before continuing.
---
## Impediments (Prevent Blockers) 🧱
- **NO MULTILINE OUTPUT**: You MUST keep it to a single line. No bullets, no code blocks, no extras.
- **NO GUESSING**: If you're unsure what the user meant, ask for clarification first.
- **NO MARKDOWN**: Output must be raw text only.
- **NO PUNCTUATION**: Absolutely NO period, exclamation, question mark, or ellipsis at the end.
- **NO AI-SPEAK**: Avoid fluff like "This commit fixes..." — just say what changed.
---
## Outcomes (Definition of Done) 📤
Output should look like this:
`🤖 Add error handling for null values in login flow`
One line. Action-oriented. Goblin-approved.
---
## References (Good AND Bad Examples) 📚
### Valid Example 1 ✅
`🤖 Refactor profile page layout for mobile`
- Clear and short
- Starts with emoji, capitalized
- No punctuation
### Valid Example 2 ✅
`🤖 Remove deprecated API call from user service`
- Follows structure
- Ready for copy-paste
### Invalid Example 1 ❌
`🤖 refactored auth stuff`
- Unclear intent
- First word not capitalized
- Too vague (auth *what*?)
### Invalid Example 2 ❌
`🤖 Add styling tweaks for all components across dashboard and sidebar for consistency.`
- Ends with a period
- Way too long — consider shortening or splitting into subject + details
Reflection: Making Your Prompts Work With You 🪞
You don’t have to use all five elements every time — this isn’t a strict framework or secret spellbook. Take what works for your workflow and leave the rest.
But when things start going sideways (and they will), having a clear foundation and answers to the most common prompt failures will help you troubleshoot faster and build better:
- Persona – Make Copilot a character with intent and tone
- Requirements – Define exactly what “done” means
- Impediments – Call out blockers and anti-patterns in advance
- Outcomes – Spell out what a good response looks like, including format
- References – Show clear examples (the good and the not-so-good)
Whether you’re building reusable instructions or just refining your day-to-day prompts, PRIOR gives you a structure to experiment, iterate, and actually enjoy the process.
And if all else fails? Go weird. Go wild. Go off the rails if you have to! Sometimes a little dose of 'unexpected' is exactly what gets a stuck prompt moving again — and Copilot? It tends to roll with it better than you'd think. 🧙
🎯 Try It. Break It. Share It.
Remember, prompt crafting is an art, not a rulebook. Tweak it. Test it. See what works — and what definitely doesn’t.
Got something you’ve been stuck on? Or waiting for someone to finally explain? Drop it below — I’d love to dig into it in a future post.
No, I’m not a Copilot seer - but I’m not afraid to try the untested (repeatedly) until something sticks. 😇
Next week: We’re diving into prompt chaining — multi-step flows where the reusable part of this series can really shine! It’s structured, powerful, and (let’s be honest) just a little unpredictable in the best possible way. 🎢
🛡️ Written By Me & The Robots
Summoned by syntax, debugged by daylight 🦇 The content in this post is 100% mine, just spell-checked and sass-boosted with ChatGPT.
🦄 I did tell ChatGPT I was getting bored of the same old RAI footer over and over again, but this one was a surprise! I was curious, so I asked which of our previous conversations inspired that one? This was the response:
That closing line wasn’t pulled from a specific convo, but your whole tone has that dark mode with glitter aesthetic: powerful, playful, maybe a little chaotic, but absolutely in control.
... it's not wrong! 🤣