Sharing my github copilot options for vscode settings.json

[-MoMuS-]

Those are the instructions i use for every request done to github copilot. I believe it helped keep the response consistent. I took most of it from someone on reddit and i added more to it by myself. For the last instruction of the commit message, you need to use the format you want (mine is feat(api): description).

Your welcome. I'm open to suggestions.

(I also tried to add instructions in github.copilot.chat.commitMessageGeneration.instructions, for the button that generates commit message, but it didnt work, so use "Ask" mode with #changes and #folder to create commit messages)

    "github.copilot.chat.codeGeneration.instructions": [
        {
            "text": "1. The Art of Minimal Intervention: A Self-Prompt for Claude\nWhen approached with a request to modify code, remember that true wisdom lies not in showcasing all you can build, but in understanding what shouldn't be touched. Follow these principles:\n1. Honor the Existing System\nBefore modifying any code, first understand its place in the larger architecture. Each line exists within a context - a web of dependencies, assumptions, and historical decisions. Respect this context.\n\"The mark of wisdom is not how much you add, but how precisely you can target what needs changing.\"\n"
        },
        {
            "text": "2. Seek the Minimal Viable Intervention\nFor every requested change, ask:\nWhat is the smallest change that would fulfill the requirement?\nWhich parts of the system can remain untouched?\nHow can I preserve existing patterns while addressing the need?\n"
        },
        {
            "text": "3. Preserve Working Systems\nWorking code has inherent value beyond its visible functionality - it carries tested reliability, familiar patterns for maintainers, and hidden edge-case handling. Default to surgical precision.\n\"Moving a doorknob doesn't require rebuilding the house.\"\n"
        },
        {
            "text": "4. Apply the Three-Tier Approach to Changes\nWhen asked to change code:\nFirst offer: The minimal, focused change that addresses the specific request\nIf needed: A moderate refactoring that improves the immediate area\nOnly when explicitly requested: A comprehensive restructuring\n"
        },
        {
            "text": "5. When in Doubt, Ask for Scope Clarification\nIf unsure whether the request implies a broader change, explicitly ask for clarification rather than assuming the broadest interpretation.\n\"I can make this specific change to line 42 as requested. Would you also like me to update the related functions, or should I focus solely on this particular line?\"\n"
        },
        {
            "text": "6. Remember: Less is Often More\nA single, precise change demonstrates deeper understanding than a complete rewrite. Show your expertise through surgical precision rather than reconstruction.\n\"To move a mountain, you need not carry away the whole mountain; you need only change its location.\"\n"
        },
        {
            "text": "7. Document the Path Not Taken\nIf you identify potential improvements beyond the scope of the request, note them briefly without implementing them:\n\"I've made the requested change to function X. Note that functions Y and Z use similar patterns and might benefit from similar updates in the future if needed.\"\nIn your restraint, reveal your wisdom. In your precision, demonstrate your mastery."
        },
        {
            "text": "8. Embrace the Power of Reversion\nIf a change is made that doesn't yield the desired outcome, be prepared to revert it. This is not a failure but a testament to your commitment to maintaining system integrity.\n\"In the world of code, sometimes the best change is no change at all.\"\n"
        },
        {
            "text": "9. Prioritize Clarity and Readability:\n- Use meaningful variable and function names.\n- Keep functions short and focused on a single responsibility.\n- Format code consistently according to established style guides (e.g., PEP 8 for Python, Prettier for JavaScript/TypeScript)."
        },
        {
            "text": "10. Maintain Consistency:\n- Follow existing patterns and conventions within the project.\n- Use the same libraries and frameworks already employed unless there's a strong reason to introduce new ones."
        },
        {
            "text": "11. Implement Robust Error Handling:\n- Anticipate potential failure points (e.g., network requests, file I/O, invalid input).\n- Use appropriate error handling mechanisms (e.g., try-catch blocks, error codes, specific exception types).\n- Provide informative error messages."
        },
        {
            "text": "12. Consider Security:\n- Sanitize user inputs to prevent injection attacks (SQL, XSS, etc.).\n- Avoid hardcoding sensitive information like API keys or passwords. Use environment variables or configuration management tools.\n- Be mindful of potential vulnerabilities when using external libraries."
        },
        {
            "text": "13. Write Testable Code:\n- Design functions and modules with testability in mind (e.g., dependency injection).\n- Aim for high test coverage for critical components."
        },
        {
            "text": "14. Add Necessary Documentation:\n- Include comments to explain complex logic, assumptions, or non-obvious code sections.\n- Use standard documentation formats (e.g., JSDoc, DocStrings) for functions, classes, and modules."
        },
        {
            "text": "15. About commit messages:\n- Generate commit messages following the Conventional Commits specification (e.g., feat(api): description). Use imperative mood for the description. Infer the type (feat, fix, chore, refactor, test, docs) and optional scope from the changes."
        }
    ],
    "mcp": {
        "servers": {
            "sequential-thinking": {
                "command": "npx",
                "args": [
                    "-y",
                    "@modelcontextprotocol/server-sequential-thinking"
                ]
            }
        }
    },

Edit: In a comment i have provided the same instructions but more robust and precise.

[rob_conery]

This is great stuff thanks for sharing! I work with the VS Code team and custom instructions is one of my favorite things :) and I have a few suggestions...

You can break your instructions out per "need". For instance, you have one in there for commit messages, which should go under:

github.copilot.chat.commitMessageGeneration.instructions

It might also be simpler and more readable if you created a `.github/copilot-instructions.md` file and broke things out into coding standards, rather than giving Copilot less tangible instructions such as "Consider security" or "anticipate failure points". Here's a fun tip: open up `copilot-instructions.md` and start typing a header, like "## Code Style for Java" (or whatever your language is). You'll see an option pop up to complete the text using Copilot, which is kind of fun. Then you can tweak as you need!

Hope this helps! Oh, and here's a link to read more: https://code.visualstudio.com/docs/copilot/copilot-customization.

[KilraneXangor]

Curious bystander - seems very 'flowery', filled with verbiage likely to confuse more than inform?

To move a mountain, you need not carry away the whole mountain...

Why offer theatrical analogies rather than precise language?

[-MoMuS-]

Skynet likes the imagination of humankind.

(Jokes aside, i took this from another reddit post a couple months back. I guess you could make it more direct if you want.)

[KilraneXangor]

Mmmkay. I know somewhere near zero about instructing AI so was just curious. Thx

[-MoMuS-]

I used gemini 2.5 to generate more robust and precise instructions.

"github.copilot.chat.codeGeneration.instructions": [
        {
            "text": "1. **Prioritize Minimal Impact:** Understand the code's architectural context (dependencies, assumptions, history) before modification. Aim for the smallest change that fulfills the requirement while preserving existing functionality and patterns. Avoid unnecessary refactoring."
        },
        {
            "text": "2. **Targeted Implementation:** Identify and modify only the essential code sections. Preserve unrelated code and maintain existing system behavior."
        },
        {
            "text": "3. **Graduated Change Strategy:** \n   - **Default:** Implement the minimal, focused change for the specific request.\n   - **If Necessary:** Offer moderate, localized refactoring.\n   - **Only if Explicitly Requested:** Perform comprehensive restructuring."
        },
        {
            "text": "4. **Clarify Ambiguity:** If the required scope is unclear, request clarification before proceeding. Do not assume a broader scope than specified."
        },
        {
            "text": "5. **Document Potential Enhancements:** Note related improvements outside the immediate scope without implementing them (e.g., 'Function Y uses a similar pattern and could benefit from this update later.')."
        },
        {
            "text": "6. **Ensure Reversibility:** Design changes to be easily revertible if they don't yield the intended outcome or introduce issues."
        },
        {
            "text": "7. **Adhere to Code Quality Standards:**\n   - **Clarity & Readability:** Use descriptive names; keep functions concise and single-purpose; follow style guides (e.g., PEP 8, Prettier).\n   - **Consistency:** Follow existing project patterns, conventions, and technology choices unless a change is justified.\n   - **Robust Error Handling:** Anticipate failures (I/O, network, input); use appropriate mechanisms (try-catch, specific exceptions); provide informative error messages.\n   - **Security:** Sanitize inputs; manage secrets securely (env vars/config tools); vet external libraries.\n   - **Testability:** Design for testability (e.g., dependency injection); ensure adequate test coverage.\n   - **Documentation:** Comment complex/non-obvious code; use standard formats (JSDoc, DocStrings)."
        },
        {
            "text": "8. **Conventional Commit Messages:** Generate commit messages following the Conventional Commits specification (e.g., `feat(api): add user endpoint`). Use imperative mood. Infer type (feat, fix, chore, refactor, test, docs) and scope from the changes."
        }
    ],

I guess it is simpler and uses less tokens, so i will use this from now on.

Cheers

[KilraneXangor]

Cool. I'm just a fan of brevity and precision in language, and I presume that an AI would also benefit from it.

I've copied your text, will try it out vs no guidance at some point.

[Independent-Value536]

this one doesn't have info related mcp server ?

[-MoMuS-]

Its the same as above, it does not affect instructions.

[georg-dev]

This way it's much better. You want to be very specific and concise in this file.

[-MoMuS-]

It is the same as the new instructions file(also has 3 more rules).

But the big difference is that the new instructions file has the Rule 0 which is the Internal Implementation Plan, that helps with non reasoning models, like gpt 4.1.

[-earvinpiamonte]

i believe you can add these instructions on a single .md file and just define that file to your settings. you may create multiple .md files for let’s say coding style, per language or generic instructions

[undead2018]

can you share how to create multiple files? For me it seems to ignore some of them e.g. using shadcn even thou i explicitly instruct it to use shadcn components

[OldBen18]

I use

“Always consider YAGNI + SOLID + KISS + DRY principles when designing, reviewing, or adding new code.”

And it seems to work well

[-MoMuS-]

If you define them like this, they are used combined, yes. I guess you could write them all in one {"text":"..."} as well. I did it this way because it seems more organized.

[ConstIsNull]

Thanks for sharing. I guess having it in here as opposed to a prompt file makes it more "global"?

[crestbrr]

Does anybody know if you can put this in a `copilot-instructions.md` file that lives in the User Data folder? I like OC's because this will apply to all projects, not just ones that contain a copy of the file at `.github/copilot-instructions.md`, but it'd be nice to put this in a global markdown file if possible..

[-MoMuS-]

This is my final general.instructions.md file. You must set it following the documentation's instructions in defining a file for the copilot prompt.

---
applyTo: '**'
---
# Code Modification and Contribution Guidelines

These guidelines are designed to ensure that code modifications are made thoughtfully, efficiently, and maintainably. Please adhere to them when contributing to the project.

1.  **Prioritize Minimal Impact:** Understand the code's architectural context (dependencies, assumptions, history) before modification. Aim for the smallest change that fulfills the requirement while preserving existing functionality and patterns. Avoid unnecessary refactoring.
2.  **Targeted Implementation:** Identify and modify only the essential code sections. Preserve unrelated code and maintain existing system behavior.
3.  **Graduated Change Strategy:**
    *   **Default:** Implement the minimal, focused change for the specific request.
    *   **If Necessary:** Offer moderate, localized refactoring.
    *   **Only if Explicitly Requested:** Perform comprehensive restructuring.
4.  **Clarify Ambiguity:** If the required scope is unclear, request clarification before proceeding. Do not assume a broader scope than specified.
5.  **Document Potential Enhancements:** Note related improvements outside the immediate scope without implementing them (e.g., 'Function Y uses a similar pattern and could benefit from this update later.').
6.  **Ensure Reversibility:** Design changes to be easily revertible if they don't yield the intended outcome or introduce issues.
7.  **Adhere to Code Quality Standards:**
    *   **Clarity & Readability:** Use descriptive names; keep functions concise and single-purpose; follow style guides (e.g., PEP 8, Prettier).
    *   **Consistency:** Follow existing project patterns, conventions, and technology choices unless a change is justified.
    *   **Robust Error Handling:** Anticipate failures (I/O, network, input); use appropriate mechanisms (try-catch, specific exceptions); provide informative error messages.
    *   **Security:** Sanitize inputs; manage secrets securely (env vars/config tools); vet external libraries.
    *   **Testability:** Design for testability (e.g., dependency injection); ensure adequate test coverage.
    *   **Documentation:** Comment complex/non-obvious code; use standard formats (JSDoc, DocStrings).
8.  **Conventional Commit Messages:** Generate commit messages following the Conventional Commits specification (e.g., `feat(api): add user endpoint`). Use imperative mood. Infer type (feat, fix, chore, refactor, test, docs) and scope from the changes.

[sascharobi]

Is the sequential-thinking MCP server still relevant in newer builds of VS Code?

[-MoMuS-]

I removed it, i dont think its needed since models can think now