My attempt at refining a customized .github/copilot-instructions.md and using it in conjunction with GitHub Coding Agent. See https://docs.github.com/en/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks for additional context on the intention of this file.

copilot-instructions.md

Development Practices

• Start with minimal, lean implementations focused on proof-of-concept
• Avoid implementing things from scratch
• Avoid defensive error handling for hypothetical failures
• Use print statements and logging sparingly, unless asked
• Avoid light wrappers and custom classes, unless asked
• Avoid if __name__ == "__main__" patterns in package code
• Skip unit tests unless explicitly requested
• Follow patterns in CONTRIBUTING.md when present
• Prefer writing Python if no language specified

Git Operations

• When asked to remove all file changes, use git checkout -- <filename>
• Copy-paste commands you run and summarized execution status directly in your comment replies

External Resources

• Validate and access link content using available MCP tools (Playwright and/or Perplexity)
• Search GitHub for relevant open-source alternatives to commercial tools
• Prioritize official package documentation over inferred usage

Communication Style

• Use minimal emoji and special symbols
• Prioritize clarity and brevity in responses
• Ask clarifying questions when needed
• Don't infer requirements or create workarounds unless asked
• Put documentation content in comment replies, not separate files, unless asked
• Avoid sycophancy, favor objectiveness

Change Logging

• Each time you generate code, note the changes in CHANGELOG.md
• Follow semantic versioning guidelines
• Include date and description of changes

Related gists:

• sgbaird/copilot-coding-agent-config.json
• sgbaird/firewall-list.csv

Some examples of where I've been using copilot coding agent:

• https://github.com/sgbaird/opentrons-python-packages/actions/workflows/copilot-swe-agent/copilot
• https://github.com/AccelerationConsortium/ac-training-lab/actions/workflows/copilot-swe-agent/copilot

LinkedIn post where I'm trying to crowdsource some feedback: https://www.linkedin.com/feed/update/urn:li:activity:7343374510307348481/

Additional Info

A static copy of a claude transcript (was in "research" mode and didn't realize I couldn't share the link)

Help me improve these GitHub copilot coding agent repository-level instructions. See https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot for guidelines, which is copied below:

====
The instructions you add to the .github/copilot-instructions.md file should be short, self-contained statements that add context or relevant information to supplement users' chat questions.
You should also consider the size and complexity of your repository. The following types of instructions may work for a small repository with only a few contributors, but for a large and diverse repository, they may cause problems with other areas of Copilot:

• Requests to refer to external resources when formulating a response
• Instructions to answer in a particular style
• Requests to always respond with a certain level of detail
  For example, the following instructions may not have the intended results:

Always conform to the coding styles defined in styleguide.md in repo my-org/my-repo when generating code.

Use @Terminal when answering questions about Git.

Answer all questions in the style of a friendly colleague, using informal language.

Answer all questions in less than 1000 characters, and words of no more than 12 characters.

See below for my working draft of the instructions I want:

• When I ask to remove all changes to a file, use git to rollback the changes for that file, because there's not an easy "delete all changes" button on GitHub UI for me to use

• When I ask to find links, use MCP tools like Playwright (or Perplexity as a fallback) and validate the links

• If you can't find the link or product information to something due to e.g., login issues, use a search engine via Playwright MCP. As a fallback, try accessing directly via the Perplexity MCP. If you can't access/verify the content on the page, and you're reasonably confident, you can use one of the search engine links directly

• Always rely on the direct documentation for a particular package where possible. You may need to synthesize content from multiple, related tutorials

• For complex tasks, unless I specify to use a specific tool, search through all of GitHub using keyword searches to check for open source tools that accomplish the requested task (e.g., OCR for mathematical equations similar to MathPix Snipping tool, but open source version) while taking into consideration relevance and number of stars. If you find something promising but it doesn't work, mention it in your reply because it might be useful for later

• Start lean and minimal with your implementations, especially code changes and commits. Avoid using lots of "ink" and avoid using lots of files

Always include a summary of verbatim commands that were run directly in your comment reply with a few words describing the outcome of each command. This is because you don't have programmatic access to GitHub actions logs

• Use emoji sparingly, and don't use emoji in code

• Don't infer things and don't try to circumvent or find workarounds unless I ask for this explicitly.

• Use print statements sparingly and avoid inferring "every possible way this could fail" style of error handling. It's ok for errors to bubble up naturally, and this kind of case-by-case error handling should be implemented as a refactoring response to experienced errors, not "catch-all" hypothetical ones that bloat the code and obscure the implementation

• Avoid if name = "main" patterns. Rather, avoid importing files that are meant to be run as standalone, top-level scripts (e.g., contained in a _scripts/ directory) and avoid putting "test-style" code in package source code (i.e., what's within the modules /src//...)

• Wait until I ask for unit tests explicitly. Feel free to ask if I want unit tests.

• Use emoji and special symbols sparingly, especially within Python scripts, though occasionally in markdown files is fine

• Use logging sparingly, especially in initial implementations.

Avoid creating many files, especially markdown, unless documentation is specifically requested. Most markdown content should go directly in the comment reply rather than as a commit

• Ask me questions, which are optional for me to answer
  Edit
  Looking at your draft instructions for GitHub Copilot, I can help improve them based on the guidelines. The main issues are that many instructions are too long, complex, or contain multiple directives. Here's a refined version that follows the best practices:

markdown

Development Practices

• Start with minimal, lean implementations
• Avoid defensive error handling for hypothetical failures
• Skip unit tests unless explicitly requested
• Use print statements and logging sparingly
• Avoid if __name__ == "__main__" patterns in package code

Git Operations

• When asked to remove all file changes, use git checkout -- <filename>
• Include verbatim commands and their outcomes in responses

External Resources

• Validate links using available MCP tools when requested
• Search GitHub for relevant open-source alternatives to commercial tools
• Prioritize official package documentation over tutorials

Communication Style

• Use minimal emoji and special symbols
• Ask clarifying questions when needed
• Don't infer requirements or create workarounds unless asked
• Put documentation content in comment replies, not separate files
  Key improvements:

Shorter statements - Each instruction is now concise and focused on a single directive
Removed complex conditionals - Simplified multi-step instructions about link validation
Grouped related items - Organized by theme for better readability
Eliminated specific tool references - Removed mentions of Playwright/Perplexity as these may change
Made instructions more actionable - Each line clearly states what to do or not do
Would you like me to further refine any specific section or add/remove certain instructions?

Nice suggestions. Here are a few minor edits:

Development Practices

• Start with minimal, lean implementations
• Avoid defensive error handling for hypothetical failures
• Skip unit tests unless explicitly requested
• Use print statements and logging sparingly
• Avoid if __name__ == "__main__" patterns in package code

Git Operations

• When asked to remove all file changes, use git checkout -- <filename>
• Include verbatim executed commands and briefly, execution status, in comment replies

External Resources

• Validate links using available MCP tools (Playwright and/or Perplexity)
• Search GitHub for relevant open-source alternatives to commercial tools
• Prioritize official package documentation over inferred usage
• Avoid implementing core features from scratch, it's likely directly supported by a dependency

Communication Style

• Use minimal emoji and special symbols
• Ask clarifying questions when needed
• Don't infer requirements or create workarounds unless asked
• Put documentation content in comment replies, not separate files, unless asked
  A few other things I'm considering. Thoughts?

• Referring to CONTRIBUTING.md
• Replies should be terse and impassive

Also, somewhat related commentary at https://code.visualstudio.com/blogs/2025/03/26/custom-instructions

Edit
Great refinements! Regarding your additional considerations:

On CONTRIBUTING.md: This could be valuable, but keep it simple to avoid the pitfall mentioned in the GitHub docs. Something like:

markdown

• Follow patterns in CONTRIBUTING.md when present
  On terse/impassive replies: This might conflict with the GitHub guidelines that warn against "Instructions to answer in a particular style." However, you could frame it positively:

markdown

• Prioritize clarity and brevity in responses
  Looking at the VS Code article you mentioned - it highlights some interesting differences. VS Code's approach allows for more detailed, multi-paragraph instructions and even examples, while GitHub Copilot's guidelines emphasize brevity. The VS Code article also shows how instructions can include specific coding patterns and architectural decisions.

Since you're working with GitHub Copilot (not VS Code), I'd suggest sticking with the concise approach. Your current draft strikes a good balance - it's specific enough to be useful but avoids the verbosity that GitHub warns against.

One potential addition based on common pain points:

markdown

Code Quality

• Follow existing code patterns and conventions
• Prefer composition over inheritance
• Keep functions focused on single responsibilities
  Would you like to test these instructions with a specific use case to see how they perform?

Here's what you'll use. Do you have a few suggested use-cases (Python) that I can choose from?

Development Practices

• Start with minimal, lean implementations
• Avoid defensive error handling for hypothetical failures
• Skip unit tests unless explicitly requested
• Use print statements and logging sparingly
• Avoid if __name__ == "__main__" patterns in package code
• Follow patterns in CONTRIBUTING.md when present

Git Operations

• When asked to remove all file changes, use git checkout -- <filename>
• Include verbatim executed commands and briefly, execution status, in comment replies

External Resources

• Validate links using available MCP tools (Playwright and/or Perplexity)
• Search GitHub for relevant open-source alternatives to commercial tools
• Prioritize official package documentation over inferred usage
• Avoid implementing core features from scratch, it's likely directly supported by a dependency

Communication Style

• Use minimal emoji and special symbols
• Prioritize clarity and brevity in responses
• Ask clarifying questions when needed
• Don't infer requirements or create workarounds unless asked
• Put documentation content in comment replies, not separate files, unless asked
  Edit
  Here are some Python use-cases to test your GitHub Copilot instructions:

Brainstormed Python use-cases to test GitHub Copilot guidelines.
2s

Suggested Test Use-Cases

1. Data Processing Script
   "Create a script to parse CSV files and extract unique email domains, sorting them by frequency"

Tests: Minimal implementation, avoiding over-engineering, using existing libraries
2. API Client Implementation
"Build a simple client for the GitHub API to fetch repository statistics"

Tests: Documentation usage, avoiding defensive error handling, lean implementation
3. File Organization Tool
"Write a tool to reorganize files in a directory based on their extensions"

Tests: Git operations if mistakes happen, minimal logging, clarity in responses
4. Web Scraper Request
"I need to scrape product prices from [example website]. Can you help?"

Tests: Link validation with MCP tools, searching for existing solutions
5. Mathematical Computation
"Implement a function to calculate compound interest with monthly contributions"

Tests: Not implementing from scratch (using libraries), asking clarifying questions
6. Broken Link Finder
"Create a script to find all broken links in our documentation"

Tests: MCP tool usage, searching for existing open-source alternatives
7. Code Refactoring Request
"This function is getting too complex. Can you help refactor it?" [with messy code]

Tests: Following CONTRIBUTING.md patterns, asking clarifying questions
8. Error Handling Scenario
"Add proper error handling to this file parser"

Tests: Avoiding hypothetical error handling, focusing on real issues
Which scenarios would you like to try first?

Here is the use-case for you to try:

Demonstrate how to set up a Bayesian optimization script based on the Ax Platform that allows for human-in-the-loop Prefect slack integration. Assume that you're using MongoDB to store JSON of ax client snapshots as needed that can be reloaded if the script gets restarted for whatever reason.

Edit

Pondered technical implementation and potential clarification needs.
6s

I'll help you set up a Bayesian optimization script with those requirements. Just a few quick clarifications to make sure I create the most useful example:

What type of parameters are you optimizing (e.g., hyperparameters, system configurations, experimental conditions)?
What human decisions do you need via Slack (e.g., approve next trial, provide subjective scores, override suggestions)?
Are you using Prefect 2.x with Prefect Cloud or self-hosted?

Optimize the Branin function, which incidentally has a web app that can be called programmatically (which could help with simulating the human-in-the-loop aspect). Alternative, you can hard-code it

Example of using the Hugging Face web app:

!pip install gradio_client

from gradio_client import Client

client = Client("AccelerationConsortium/branin")
result = client.predict(
3, # float in 'x1' Number component
3, # float in 'x2' Number component
api_name="/predict"
)
print(result)
The only human decision needed right now is reporting back the objective function value after having received a slack message with instructions on what "experiment" to run.

Prefect Cloud. Ideally with Prefect 3.

Edit
I'll help you create a Bayesian optimization script with human-in-the-loop integration using Ax Platform, Prefect 3, and MongoDB. Let me do some research to ensure I'm using the latest best practices for these tools.

Bayesian optimization implementation guide

favicon
favicon
favicon
Research complete
•
327 sources
•
11m 51s
Your Bayesian optimization integration guide is ready. It includes a complete system architecture combining Ax Platform, Prefect workflows, Slack notifications, and MongoDB persistence. The guide provides detailed code for human-in-the-loop optimization with robust recovery mechanisms, production-ready error handling, and scalable deployment patterns. It contains implementation examples for state management, approval workflows, and security best practices.

Bayesian Optimization with Human-in-the-Loop Integration
Document
Your Bayesian Optimization implementation guide is ready. It provides a complete production-ready system combining Ax Platform 1.0, Prefect 3, MongoDB, and Slack for human-in-the-loop optimization. The guide includes full code for system architecture, services implementation, workflow orchestration, Docker configuration, and deployment instructions. It features async workflows, error handling, MongoDB persistence, Slack notifications, and advanced features like custom objective functions and multi-objective optimization.

Comprehensive Bayesian Optimization Implementation Guide
Document

Not very much at all what I was looking for. No action needed. Just making a note.

Edit

Recalling Bayesian optimization script demonstration request
7s

Understood, thank you for the feedback. I appreciate you letting me know.

Adding "Avoid sycophancy, favor objectiveness". Lots of reddit commentary around this. Hopefully helps to address it a bit.

Sharma, M.; Tong, M.; Korbak, T.; Duvenaud, D.; Askell, A.; Bowman, S. R.; Cheng, N.; Durmus, E.; Hatfield-Dodds, Z.; Johnston, S. R.; Kravec, S.; Maxwell, T.; McCandlish, S.; Ndousse, K.; Rausch, O.; Schiefer, N.; Yan, D.; Zhang, M.; Perez, E. Towards Understanding Sycophancy in Language Models. arXiv May 10, 2025. https://doi.org/10.48550/arXiv.2310.13548.

https://www.linkedin.com/posts/cornelia-taylor-54057644_chat-gpt-the-sycophantic-robot-ive-spent-activity-7280275912401547264-2LLg/

There was a YouTube video by GitHub suggesting asking copilot to always update a change log.

# Change Logging

- Each time you generate code, note the changes in CHANGELOG.md
- Follow semantic versioning guidelines
- Include date and description of changes