What this prompt does
This prompt asks the AI to teach you the input patterns that make GitHub Copilot's inline suggestions land in a single tab, rather than asking the AI to write code for you directly. It is parameterized on [language] so the advice is idiomatic to your stack, and it walks through seven concrete levers: function-signature priming, comment-driven development, test-name-driven implementation, pattern repetition, type annotations, anti-patterns to avoid, and a way to measure your acceptance rate over time.
The structure works because Copilot completes from local context, not magic — what is already on screen shapes what it offers next. By setting [example_count] you control how many primed function signatures it generates, so you can study several priming styles side by side instead of guessing which one helps. The [use_case] placeholder grounds the comment-driven demo in a realistic shape of code, such as a controller that fetches, validates, transforms, and returns data, where step comments map cleanly to lines Copilot can fill. Finally, [remaining_count] frames the repetition lesson around a real batch of work: write the first route or model method cleanly, then let Copilot replicate the established pattern for the rest while you correct any drift.
When to use it
- You accept few Copilot suggestions and want a concrete way to raise your hit rate.
- You are about to write a series of similar functions — routes, model methods, mappers — and want the first one to set the template.
- You are onboarding to a typed language and suspect weak annotations are hurting suggestion quality.
- You want to teach a team a repeatable priming habit instead of ad-hoc prompting.
- You keep getting confidently wrong completions and need to spot the anti-patterns causing them.
- You want a lightweight way to compare your acceptance rate before and after a workflow change.
Example output
Expect a structured walkthrough rather than a single snippet. You get several primed function signatures in your [language] with descriptive parameter names and return types, an annotated example of step comments filling in a function body, a describe/it() block Copilot can implement straight from the test names, a first-implementation example with a note on how the pattern repeats, a short list of confusing anti-patterns, and a suggestion for tracking acceptance rate. Each section is meant to be copied into your editor and tested live so you can see the effect for yourself.
Pro tips
- Set
[language]precisely (for example TypeScript, not just "JS") — explicit types are the single biggest lever, so a strongly typed language gets noticeably better completions. - Keep
[example_count]small, around four to six, so you actually study each priming style instead of skimming twenty near-identical examples. - Make
[use_case]match code you really write; a vague use case yields vague comment-driven demos that do not transfer to your work. - Set
[remaining_count]to your real batch size so the repetition advice maps to the task in front of you — write the first item carefully, then tab through the rest. - If your suggestions are bad, ask it to expand the anti-patterns section; naming the failure modes you are hitting is often more useful than the list of good patterns.
- Treat the acceptance-rate idea as a rough directional signal, not a precise metric, since Copilot does not expose official per-developer numbers in every plan.
