ra/agent-coordinator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update copilot instructions with something actually relevant

Browse Source
This commit is contained in:
Ra
2025-09-06 10:07:25 -07:00
parent b1f55799ec
commit 0327665fe2
6 changed files with 9 additions and 305 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.github/instructions/ascii-artist.instructions.md vendored
View File

@@ -1,3 +0,0 @@
---
applyTo: '**/*.md'
---

9
.github/instructions/example.instructions.md vendored Normal file
View File

@@ -0,0 +1,9 @@
---
applyTo: '**'
---
- You must always use the agent-coordinator mcp server, this will allow you to coordinate your work with other agents that may be actively working on the same codebase as you.
- All MCP tool calls which would alter anythings state should be done through the agent-coordinator, even vscode internal tool calls. Searches are fine to not be done through the agent coordinator. The core reason for running them through the agent-coordinator is for the heartbeat.
- Always make sure you append at least 2 random words onto the end of your agent name when registering / sending metadata, eg: `GitHub Copilot Silver Banana`, `GitHub Copilot Yellow Koala`, `GitHub Copilot Olive Llama`, this will assure that not agents have overlapping names and get tracked as the same agent (hopefully)
- Always check the task board when given new user input which will require making any changes to files.
- Always populate your own task board with your task set so other agents may be informed of your planned tasks, and in turn you will be able to see other agents' agendas.
- Once you are coming to an end of your current query, and you will be passing the turn to wait for user input, you must unregister yourself as an agent, and upon the followup you should re-register and follow through with the same registration flow.

50
.github/instructions/no-duplicate-files.instructions.md vendored
View File

@@ -1,50 +0,0 @@
---
applyTo: '**'
---
# No Duplicate Files Policy
## Critical Rule: NO DUPLICATE FILES
**NEVER** create files with adjectives or verbs that duplicate existing functionality:
- ❌ `enhanced_mcp_server.ex` when `mcp_server.ex` exists
- ❌ `unified_mcp_server.ex` when `mcp_server.ex` exists
- ❌ `mcp_server_manager.ex` when `mcp_server.ex` exists
- ❌ `new_config.ex` when `config.ex` exists
- ❌ `improved_task_registry.ex` when `task_registry.ex` exists
## What To Do Instead
1. **BEFORE** making changes that might create a new file:
```bash
git add . && git commit -m "Save current state before refactoring"
```
2. **MODIFY** the existing file directly instead of creating a "new" version
3. **IF** you need to completely rewrite a file:
- Make the changes directly to the original file
- Don't create `*_new.*` or `enhanced_*.*` versions
## Why This Rule Exists
When you create duplicate files:
- Future sessions can't tell which file is "real"
- The codebase becomes inconsistent and confusing
- Multiple implementations cause bugs and maintenance nightmares
- Even YOU get confused about which file to edit next time
## The Human Is Right
The human specifically said: "Do not re-create the same file with some adjective/verb attached while leaving the original, instead, update the code and make it better, changes are good."
**Listen to them.** They prefer file replacement over duplicates.
## Implementation
- Always check if a file with similar functionality exists before creating a new one
- Use `git add . && git commit` before potentially destructive changes
- Replace, don't duplicate
- Keep the codebase clean and consistent
**This rule is more important than any specific feature request.**