Mastering GitHub Copilot : Standardize Repetitive Work with Shared Prompts

Chapter 2 : Standardize Repetitive Work with Shared Prompts

Helping Copilot Do the Same Thing… the Same Way

“I asked Copilot to do the same task, but it gave me something totally different.”

If that sentence sounds familiar, you’re not alone.

In the previous article, we talked about small rules — async usage, logging style, thin APIs — and how those rules dramatically improve Copilot’s output.

Those rules solve how Copilot should behave. But there’s still a gap. Even with rules in place, developers still ask Copilot questions in different ways.
And different questions lead to different results. This article focuses on the next step: Standardizing repetitive work with shared prompts.

Why This Matters ?

Let’s start with a very normal situation. Three developers are asked to: “Add a new API endpoint”. All three use Copilot.

Developer A types: “Create a new API endpoint.”

Developer B types: “Add a POST endpoint with validation and logging.”

Developer C types: “Generate a Minimal API with tests.”

None of these prompts are wrong. But the outputs will almost certainly differ: one endpoint is too large , one misses tests , one logs differently

That’s not Copilot being unreliable. That’s humans being inconsistent. Shared prompts fix this.

What Are Shared Prompts?

Think of a shared prompt like a checklist you give Copilot.

Instead of saying: “Do this task”

You say: “Do this task using these exact steps and expectations.”

And instead of every developer writing their own checklist in their head,
the checklist lives in the repository — shared by everyone.

Shared prompts turn: tribal knowledge , code review comments , “this is how we usually do it” into something repeatable.

What Actually Changes with Shared Prompts

The difference isn’t Copilot. The difference is intent clarity.

Where Shared Prompts Live (This Is Important)

Shared prompts should live inside the repository, so everyone uses the same ones.

A simple, practical structure looks like this:

.github/
  copilot-instructions.md
  prompts/
    create-api.prompt.md
    generate-tests.prompt.md
    refactor-service.prompt.md

This does two things:

1. Makes prompts easy to discover
2. Ensures Copilot always sees them as part of project context

A Real Example: A Shared Prompt File

Here’s an example of a shared prompt for creating a new API endpoint.

📄 .github/prompts/create-api.prompt.md

Create a new Minimal API endpoint following team standards.

Requirements:
- Keep the endpoint thin
- Move business logic into a service or handler
- Validate inputs early
- Use structured logging
- Return explicit HTTP status codes
- Do not include business rules in the endpoint

Testing:
- Generate unit tests for new logic
- Follow existing test naming and setup patterns
- Include happy path and failure scenarios

Before coding:
1. Briefly outline the approach
2. List edge cases
3. Then generate the code

Now every developer starts from the same expectations.

Before vs After: Creating an API Endpoint

Without a Shared Prompt

Copilot might generate this:

app.MapPost("/resource", async (RequestModel request) =>
{
    // validation
    // business logic
    // logging
    return Results.Ok();
});

It works but logic is mixed together , hard to test ,grows messy over time.

With the Shared Prompt

Copilot generates:

app.MapPost("/resource", async (
    RequestModel request,
    IProcessingService service) =>
{
    await service.HandleAsync(request);
    return Results.Ok();
});

Same task but much better structure. This isn’t luck. It’s repeatable guidance.

Another Example: Unit Tests

Without a Shared Prompt

[Fact]
public void TestSomething()
{
    Assert.True(true);
}

This technically passes — but adds no value.

With a Shared Prompt

[Fact]
public async Task HandleAsync_Throws_WhenInputIsInvalid()
{
    // arrange
    // act
    // assert
}

Now tests explain intent ,protect behavior and help future readers.

A Simple Analogy

Think of shared prompts like training wheels.

Get Mayank patel’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

They:

• don’t slow you down
• don’t take control away
• keep you from falling while you learn

As you grow, you rely on them less , but they quietly keep things stable.

Common Mistakes Teams Make

Even good teams slip here:

• ❌ Everyone writes their own version of the same prompt
• ❌ Prompts become long essays
• ❌ Prompts aren’t updated when standards change
• ❌ Teams expect prompts to replace thinking
• ❌ Prompts live in docs instead of the repo

Shared prompts are tools, not documentation.

Best Practices for Shared Prompts

Keep Them Short : Copilot follows constraints better than explanations.

One Prompt per Repetitive Task : If you repeat it weekly, it deserves a prompt.

Match Code Review Feedback : If reviewers always ask for something — bake it into the prompt.

Review Prompts Like Code : Prompts evolve. Standards evolve. Update them.

Why This Helps Developers the Most

Shared prompts remove guesswork , reduce fear of “doing it wrong” , teach patterns through repetition

Instead of wondering: “How should I ask Copilot?”

You just:

• use the shared prompt
• review the output
• learn the team’s style naturally

That’s mentorship — built into the workflow.

Final Thoughts

Rules shape behavior. Prompts shape execution.

When both are shared:

• quality becomes predictable
• reviews become calmer
• teams move faster without losing control

Copilot stops being creative. And in production systems — that’s exactly what you want.

A Question for You

What’s one task your team asks Copilot to help with
over and over again?

That’s probably the first shared prompt you should create.