Improving Copilot's Output for Meteor 3 – Let's Build Better Instructions Together!

1

Hey everyone! :wave:

I’ve been experimenting with GitHub’s copilot-instructions feature in my Meteor 3 projects, and I’ve got to say—it’s been surprisingly effective at nudging Copilot to write cleaner, more relevant code for our stack.

For those unfamiliar, copilot-instructions let you guide how Copilot behaves across a repo. Think of it like setting the ground rules so Copilot becomes your personal pair programmer who actually “gets” your project.

I put together some instructions specifically for Meteor 3.x apps using Blaze, with a focus on:

  • Using callAsync and async/await with Meteor methods
  • Switching to findAsync, insertAsync, etc. for Mongo queries
  • ES6 module syntax instead of CommonJS
  • Code style preferences (single quotes, 2 space tabs, etc.)

You can check out what I have so far here:
:point_right: meteor-copilot-instructions - GitHub

:rocket: Why I’m Sharing

This has already helped me get more useful completions from Copilot in both client and server files. Instead of generic or outdated Meteor 2.x patterns, Copilot now suggests stuff that’s actually usable with Meteor 3—big win!

:handshake: Let’s Collaborate!

I’d love to expand this idea and start building shared copilot-instructions templates for other Meteor workflows too—whether you’re using:

  • Blaze (like me)
  • React
  • Svelte
  • TypeScript
  • Or other combinations

If you’re interested in contributing or just want to try it in your own project, let’s connect! Drop a reply here or feel free to fork the repo and open a PR. Let’s make Copilot smarter for all Meteor devs :smile:

Happy coding!
— Will

6 Likes
2

I’m finding these are also a good introductions to people for the project.
I don’t have anything so fancy looking, but I have over 300 lines of instructions for Windsurf. A lot of extra stuff for the front-end around React, Apollo GraphQL and other front-end libraries.
@wreiske would that be of interest?

5 Likes
3

Absolutely!
I was thinking we could create separate instructions.md files tailored to different use cases—like one for Blaze, one for React, etc. Then, the main README.md could simply link out to each of those.

Also, do you think it makes sense to move the repo to the community-packages org, or maybe even to the meteor org itself?

4

I think this would be very useful. Not sure what the best way would be to share this info as I guess everyone will pick and mix and refine to their needs. We’ve got one currently about switching to Meteor 3 - not really started that whole process yet though :see_no_evil:

1 Like