Before I get to the example, there’s a distinction in Copilot CLI that I think is underused - skills vs extensions.

A skill is just text. It’s a markdown file the agent reads when it thinks a topic is relevant, like “here’s how to write a good commit message” or “here’s the convention we use for branch names”. The agent can use it, or it can quietly ignore it. It costs context window. At the end of the day, it’s just special prompt.

An extension is code. It hooks directly into the agent’s runtime - it can inspect and rewrite CLI calls before they execute, validate the output of a tool call after it runs, or inject prompts when specific events happen. It’s deterministic. The agent can’t talk its way out of an extension the way it can talk its way past a skill it didn’t feel like reading.

That distinction matters because some rules in your workflow are “nice to have” and some are “never break this”. Examples of rules I defined for Copilot:

• Never open a non-draft PR by accident.

• Never @-mention people or teams from inside an agent - those notifications go to real humans and should be purposefully triggered by humans.

• Always attempt to update my Obsidian vault with substantial information when a session ends

Those aren’t suggestions. They’re hard rules. So they live in extensions, not skills.

The extension I want to show off is pr-lifecycle. It does three things automatically: it silently injects --draft into any gh pr create that’s missing it, it blocks commands containing @ mentions before they run, and it validates that PR bodies have the structure I want (a human-written summary followed by an AI-generated <details> block for agents). On top of that it exposes a finalize_pr tool that, when called, pops up two UI prompts asking me for the PR title and the description.

Here’s the workflow in practice. I tell Copilot to open a PR. The hook injects --draft, the PR opens with a placeholder body, and I get a reminder to call finalize_pr once CI is green - which ensures I only need to pay attention to it after changes were validated. When I do, the agent has to stop and ask me:

Then, separately, the description:

And the final PR ends up looking like this - my words at the top, with the AI’s structured summary tucked into a collapsible <details> block underneath that reviewers can expand if they want the agent’s take:

(example PR)

Now here’s the part that actually matters, and the reason this extension exists at all.

The PR description is the one moment in the loop where I force myself to stop, slow down, and think. Not “review the diff and click merge” think - actually think. Did I consider the performance implications? Did I pick this architecture for a reason I can articulate? Is there a simpler version of this change I rejected, and why? Writing that down in my own words, in my own voice, is the closest thing I have to a guarantee that I actually understood what just got built. If I can’t describe the change, I don’t really understand it, and I shouldn’t be shipping it.

The PR description is also the artifact my reviewer should read carefully - they will skim the diff, they will not thoroughly read a wall of AI-generated text. Description written in my own words, is the signal I send them about how I think about my own changes. Outsourcing that part to the agent is outsourcing the one piece of the workflow where being a human actually matters and that's why I decided to purposely do it on my own. But the AI-summary part allows to preserve context for future agent sessions.

So the extension exists to make that pause non-skippable. The agent literally cannot finalize the PR without coming back to me and asking. It’s a tiny piece of friction, and it’s the most valuable friction in my entire workflow.

This is part 2 of “Reasons why your prompts suck” - a mini-series about closing the gap between what AI agents can do and what you’re actually getting out of them.

I think there’s a common pattern I keep seeing with people who are frustrated with AI coding agents. They give the agent a task, the agent produces something, and then they’re disappointed with the result. But when I look at how they set things up, the problem usually isn’t the prompt itself - it’s that the agent had no way to check its own work.

Think about it this way - imagine you’re building a website but you’re not allowed to look at it. No browser, no preview, nothing. You just write code and hope for the best. That’s essentially the situation we put AI agents in most of the time, and then we’re surprised when the output isn’t great.

I feel like the fix here isn’t about writing better prompts. It’s about building better harnesses - giving the agent something to validate its output against so it can actually iterate and converge on a good result instead of guessing.

What I mean by harness

A harness is anything that closes the feedback loop. Most people act as a harness themselves when they manually evaluate the agent’s output, even in situations where this could be completely avoided in favor of an automated harness.

There are a few approaches that I’ve found work well in practice.

The most obvious one is tests. If you have a test suite, the agent can run it after every change and immediately know whether something broke. If you don’t have tests, you can tell the agent to write them first and then use them as guardrails for the actual implementation. This alone makes a huge difference.

Another thing is that modern agents like Copilot are multimodal - they can actually look at images. You can tell the agent to take a screenshot of your page and evaluate it visually. Instead of guessing whether the layout looks right, it’s actually seeing it. I think a lot of people don’t realize this is even possible.

The same principle applies to document rendering. If you’re working with PDFs or generated documents, you can have the agent convert them to images and inspect the output. It’s the same idea - close the feedback loop and let the agent see what it produced.

For browser or mobile development you can go even further and tell the agent to use debugging tools to click through your app, take screenshots at each step, and verify the behavior. It’s basically giving the agent a QA workflow, and the results are significantly better than just generating code and hoping it works.

And last but not least - most mature projects have a CI setup. This single line in copilot-instructions.md has saved me hundreds of interactions with Copilot:

When opening or iterating on a PR, never consider the work done until CI is green. Always wait for CI to complete and verify all required jobs pass.

Where this leaves us

I think the productivity gap most people experience with AI agents isn’t really about the model being too dumb. It’s about the model being blind. Once you give it ways to validate its own output - tests, screenshots, interactive tools - the quality of what it produces goes up dramatically. It’s worth spending time on the harness before you spend time on the prompt.

This is part 1 of “Reasons why your prompts suck” - a mini-series about closing the gap between what AI agents can do and what you’re actually getting out of them.