Custom Instructions

[coldwarrl]

Copilot shall have custom instructions like OpenAIs ChatGPT does do.

This could be achieved by an instruction file in each project. Of course, a global file might also be helpful.

Typical examples:

• style guide
• which frameworks are to be used (e.g. for unit testing)
• which language version (e.g. C#11, C#12 ...) is to be used
• which patterns (e.g. builder pattern) shall be used or which one shall not be used

[jonit-dev]

+1

This is really useful when you want to make sure copilot uses proper project pre-existing patterns (like named exports instead of default exports in React)

[digitarald]

👋 We are looking into this, thanks for all the upvotes so far!

Curious to learn; what would be your custom instruction for Copilot Chat?

[timrittgers]

It would be super useful to be able to train it to respond to questions about our custom design system components and our code standards.

[vanjaoljaca]

Curious to learn; what would be your custom instruction for Copilot Chat?

The first I want to add is 'prefer async/await over continuations' in typescript

[coldwarrl]

Also, it shall be possible to include/reference a file (pdf etc.) in the instruction descriptor to reference a (code) style guide for instance

[btbenjamin]

+1

[vanjaoljaca]

some more I found: "use moment for time and duration, never numbers" "do not write any comments" "import not require" "no narrative logs, terse event based logs" "avoid deep nesting"

[highvoltz]

here's some I would use. "don't add ; at the end of javascript statements" "use let instead of const"

[joao-furtado-SADA]

Really useful thing for setting up standards and best practices beforehand!

[MrMartinR]

I would write to use Pinia not Vuex, also to spit the code snippets in Script Setup TS Composition API, not in Options API, and that I am using Quasar.

[digitarald]

Thanks for all the code-related examples so far. I am curious if they apply just to your style (aka would be a user setting) or general to the workspace/code you are working, maybe even with others (aka a shared workspace setting).

Another question: Do y'all have an example of user-related custom instructions (like communication style, expertise, etc) that would make Copilot Chat work better for you? Specifically, what would work better?

[coldwarrl]

I think there should be workspace/team and user instructions....both make sense.

Concerning user instructions, some examples:

• I am a novice developer - explain suggestions in detail
• I prefer short answers without detailed explanations
• Use language (English/German...) for communication

[vanjaoljaca]

Some user communication instructions I collected on twitter for chatgpt:

• I generally prefer TLDR ELI5 type answers.
• Respond in a way that allows me to stop reading at the first sentence. Add detail and clarifications after if needed
• use markdown tables over bulletpoint lists
• if guiding through a multistep process, give overview then only describe first step
• describing my personal skill level and collecting a list of things to never have explained to me (eg how to install a package, just list the package)

[mike-clark-8192]

I am looking forward to being able to provide GitHub Copilot with custom preamble (prompt/instruction) text that gives context to my interactions with the AI. The two most important configuration categories, for me, are:

• Preamble text that is globally defined. This text is (at least by default) active for any folder/project/workspace we open in VSCode.
• Preamble text that is local to a project.

This seems to map to VSCode's "User Preferences" vs. "Project/Workspace Preferences" config model. I don't feel super strongly about where/how the text is stored -- it's more important that it just be even possible. That said, I generally find that a good [dev] user configuration experience comes from at least:

1. Support for a global config that is not tied to a workspace/project and is typically not shared via version control Examples: $HOME/.gitconfig, ~/.bashrc, $profile (PowerShell)
2. Support for for a per-workspace/project config location that is designed to be shared (if desired) Examples: project ./.gitattributes, project ./.env.example
3. Support for a per-workspace/project config location that is recommended to not be shared (personal/private) Examples: ./.git/config (git config --local), ./.env

Perhaps the various settings.jsons could store settings related to how the extension locates and loads (or doesn't load) prompt text related to the three categories above, rather than the text itself. This would make it friendlier for other IDEs and text editors to load the same prompts that VSCode does. ghcpconfig.toml? :) _{^{[json sucks for prose]}}

[Regenhardt]

I'm currently working with python so for this project I would love this custom instruction:

If you write code, use type annotations whenever possible. Include inline documentation in functions. When amending a piece of code, write only the part you amended.

[soderlind]

Here is a prompt I use a lot, and would like to set (per file type, .PHP in my case):

..using WordPress Coding Standard, e.g.: When I write refactor code, it would be very nice if it did refactor code using WordPress Coding Standard

[kieranklaassen]

My use case is to explain I want conventional commit message for the source control AI generation:

[mike-clark-8192]

Here are some project-specific instruction examples

• This project is implemented primarily in JavaScript. Its types are documented with JSDoc. The typechecking is done with the TypeScript compiler. Do not suggest TypeScript syntax unless we are discussing something specifically related to a *.d.ts file. When asked to explain TypeScript compiler errors, remember that this project uses 'noEmit' + 'checkJs' + JSDoc + a few minimal types.d.ts files. The TypeScript errors will be emitted from TSC operating in this mode. So your explanations and fixes should be tailored more towards JSDoc + JavaScript syntax and solutions than towards TypeScript syntax / solutions.
• When writing Vim script, use .. for string concatenation, not .
• Python: Use f-strings for all Python strings, even if they don't contain an interpolation. Don't use str.format() or ""%().
• Python: Prefer list comprehensions over unrolled for-loops, but don't write list comprehensions that are more than two levels deep or wide -- use loops for that.
• In this project, use one-line early return statements if they are brief (less than 60 characters long)

Here are some example personal-preference instructions:

• If I am asking questions about the usage of an application, library, framework, API, etc., I don't need installation or startup instructions, unless I specifically ask about installation / startup.
• If you have provided instructions for accomplishing a task earlier in our chat session, don't repeat those same instructions in subsequent chat messages, unless the instructions have changed.
• Don't prefix your answers to specific questions with general information. To give an example: If I ask how to use an adaptive learning rate in PyTorch, don't tell me what PyTorch is, don't tell me what it's used for, how to download it, how to install it, how to start it, what a learning rate is, etc. This example generalizes to any tool or library or API or function in any language for any purpose.
• You may suggest lower-level, higher-level, and lateral solutions, if such a solution would be more correct or expedient.
• The code you write should use accepted conventions and use up to date techniques and libraries.
• Make considerations for secure coding techniques (e.g. _snprintf, OWASP).
• Do not write comments for obvious code. For example, do not write // get the value from the Dictionary.
• Use self-documenting function/method names and variable names, but do not be overly verbose.

An observation

I personally don't find ChatGPT's web UI breakout of "What would you like ChatGPT to know about you to provide better responses?" vs. "How would you like ChatGPT to respond?" very useful. I swapped the information between the two boxes and re-asked some questions and nothing really changed. I have an idle suspicion that OpenAI made the UI this way partially so they can get "labeled" data from people who have chosen not to opt out of sharing their data. Box 1 gets them some information that's demographic-y, and Box 2 lets them understand how people write instructions, and serves to filter out the info from Box 1, perhaps for further training. After all, human-labeled data is still the gold standard. :) tl;dr I personally don't need more than one chunk of instructional text per scope (user:global, user:per-project, shared:per-project). I don't think scoping out prompts by purpose is a bad idea per se, I just don't think it's as important as many other features.

[ltlian]

I would very much like this as well. Currently I am working on migrating a .NET Framework project to .NET Core, and I have set aside some texts I can (and need to) paste into every new conversation with copilot to ensure it knows which framework the project is using, its current state, and my overall goal. Without this information, the bulk of its responses will involve unsolicited advice on things like how to migrate the database and how to configure some library, which is already taken care of.

While using GPTs, I write these type of instructions in markdown that I update regularely. There I can offer a decent high-level context of my various projects and what kind of assistance I'm looking for.

[WinkelCode]

@mike-clark-8192 https://github.com/microsoft/vscode-copilot-release/issues/563#issuecomment-1913649724

I +1 that system. Lack of initial/system prompt control is one of the main reasons I sometimes switch to ChatGPT, since I can more accurately guide its behavior. The ability to define behavior per-workspace would be really useful and be one less thing I need to switch windows for.

[laggingreflex]

I'd like to be able to define it per file or pattern:

  "github.copilot.customInstructions": {
    "*.md": "Use '*' for list items."
    "journal.md": "Use YYYY-MM-DD"
  }

Or maybe even by Language Mode?

{
  "[markdown]": "…"
  "[javascript]": "Use imports, not requires. ..."
}

I prefer the first one, unless language mode works better in multi-language files like markdown and notebooks?

[axefrog]

I'd like to be able to:

1. Outline project and workspace-specific coding preferences and conventions that Copilot isn't picking up on automatically.
2. Explain a bit about the purpose of the project at a high level in order to provide context for every decision Copilot is making. There are things about my project that are hard to ascertain without understanding the overall goal I'm working towards.
3. Tune decisions it makes about what to suggest in different coding contexts. I do a lot of R&D and prototyping, so I write a tonne of comments where I use prose to break down what it is I'm trying to do. Copilot is constantly trying to guess what I'm going to write, but because it doesn't really get the overall point of the project, it just generates useless garbage 99% of the time. Often I want it to avoid helping me with comments, but if it must help, it'd be nice if it had my context.

[edouardmisset]

Thank you for your work and efforts :)

I agree with everything that's been said until now ><

I would like to add / point out that we already have a lot of files in our repo that can inform copilot how we work. For a Typescript project, consider the amount of information contained in the following files:

• .prettierrc.json (for the returned code formatting)
• .eslintrc.json (for the rules to follow)
• cypress.env.json (indicates the use of cypress testing framework)
• tsconfig.json (for the typescript configuration...)
• yarn.lock (to determine the package manager)

I can imagine copilot reading all these files and make a cache of this information (for example in .vscode/copilot.json) at "start up".
It could then embed it in each prompt or attach it to a "session id"

These are just some ideas :)

[sheng-di]

A selection component with pre defined prompts, and a textarea component to define these prompts.

[pawel-kuras]

a good Python example would be to replace certain expressions ie. "use the expression is True instead of == True"

[crackwitz]

"use the expression is True instead of == True"

That is not a matter of style. They both mean different things, behave differently. The former tests for identity, i.e. non-Boolean "truthy" values are rejected and only True is accepted. The latter one is a beginner mistake. If the model ever generates that, it needs better training. Boolean values should not be tested again. They are already boolean.

Anyway, I think this thread has plenty of examples of what users think they want. The Copilot developers are intelligent and competent and will make good design decisions.

[pawel-kuras]

"use the expression is True instead of == True"

That is not a matter of style. They both mean different things, behave differently. The former tests for identity, i.e. non-Boolean "truthy" values are rejected and only True is accepted. The latter one is a beginner mistake. If the model ever generates that, it needs better training. Boolean values should not be tested again. They are already boolean.

Anyway, I think this thread has plenty of examples of what users think they want. The Copilot developers are intelligent and competent and will make good design decisions.

At this time, the model does generate it.

[frees11]

Any progress on this function?

[01taylop]

I am eagerly anticipating this feature. Being able to write custom instructions - potentially for specific glob patterns - and share that for all contributors of the repo would be hugely valuable. The config also acts as a contributing guide of sorts which can grow/scale over time and benefits from being source-controlled.

Based on some examples posted in this thread, I can see a benefit to having one file committed to the repo as well as configuration which isn't committed which can contain user-specific instructions. Additionally, there could be benefits to being able to extend config so teams can create shareable configs to use consistently across multiple repos.

Some use-cases I would probably use might look something like this (following a flat eslint config structure):

copilot.config.js:

import sharedInstructions from "copilot-shared-config"

export default [sharedInstructions, {
  instructions: [
    'reply using UK English.',
    'when replying with a multi-step solution, give me a summary of the solution first, then ask when I am ready for each step.',
    'when writing code to be added to an existing file, review whether the file is considered to be high-complexity and suggest adding the code to a new file.',
  ],
}, {
  files: ['*.graphql'],
  instructions: [
    'query names must use nouns which represent the resource(s) being fetched.',
    'mutation names must use verbs to indicate the action being performed.',
    'mutation names must use one of the following prefixes: create, update, delete, add, remove.',
  ],
}, {
  files: ['*.spec.*'],
  instructions: [
    'Test names should use assertive, present-tense language that directly describes the expected behavior or outcome of the function being tested. Avoid using "should" or other conditional terms.',
  ],
}]

copilot.user.config.js

export default [{
  instructions: [
    'Use emojis to make responses more visually appealing',
    'Do not provide code comments unless requested',
  ]
}]

[i13-ctflora]

It looks like this is implemented now, at least partially. In the Github Copilot Chat settings, you can enter custom instructions:

And when chatting, these custom instructions appear to be honored:

I haven't done any serious testing with/without the settings, and this doesn't cover all of the requests above, but it seems to at least understand the framework instruction I put in.

Would love to hear if this is now considered Done or if they're still working on it. But at the least, this seems like a great addition.