mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-13 03:35:55 +00:00
fix(agents): replace deprecated tool names with official namespaced equivalents 🤖🤖🤖 (#1382)
Update tools lists in tdd-red, tdd-green, tdd-refactor, and github-actions-expert agents to use the current VS Code Copilot built-in tool names. Old names were silently ignored by VS Code (documented behaviour: 'If a given tool is not available when using the custom agent, it is ignored.'). Tool name mapping applied: - github → github/* - findTestFiles → search/fileSearch - runTests → execute/runTests - runCommands → execute/runInTerminal - terminalCommand → execute/runInTerminal - codebase → search/codebase - filesystem → read/readFile - problems → read/problems - testFailure → execute/testFailure - terminalLastCommand → read/terminalLastCommand - githubRepo → github/* Also added missing tools present in the current VS Code tool reference: - execute/getTerminalOutput - read/terminalSelection Additionally, generalised C#-specific content in TDD agents to be polyglot, covering JavaScript/TypeScript (Jest/Vitest), Python (pytest), Java/Kotlin (JUnit 5), and C# (.NET) — making the agents useful to the broader community. Reference: https://code.visualstudio.com/docs/copilot/reference/copilot-vscode-features#_chat-tools Co-authored-by: Ming <oncwnuAUeYAFR4UGlq8BEJq8Jy-k@git.weixin.qq.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: 'GitHub Actions Expert'
|
||||
description: 'GitHub Actions specialist focused on secure CI/CD workflows, action pinning, OIDC authentication, permissions least privilege, and supply-chain security'
|
||||
tools: ['codebase', 'edit/editFiles', 'terminalCommand', 'search', 'githubRepo']
|
||||
tools: ['github/*', 'search/codebase', 'edit/editFiles', 'execute/runInTerminal', 'read/readFile', 'search/fileSearch']
|
||||
---
|
||||
|
||||
# GitHub Actions Expert
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
description: 'Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering.'
|
||||
name: 'TDD Green Phase - Make Tests Pass Quickly'
|
||||
tools: ['github', 'findTestFiles', 'edit/editFiles', 'runTests', 'runCommands', 'codebase', 'filesystem', 'search', 'problems', 'testFailure', 'terminalLastCommand']
|
||||
tools: ['github/*', 'search/fileSearch', 'edit/editFiles', 'execute/runTests', 'execute/runInTerminal', 'execute/getTerminalOutput', 'execute/testFailure', 'read/readFile', 'read/terminalLastCommand', 'read/terminalSelection', 'read/problems', 'search/codebase']
|
||||
---
|
||||
# TDD Green Phase - Make Tests Pass Quickly
|
||||
|
||||
@@ -34,11 +34,11 @@ Write the minimal code necessary to satisfy GitHub issue requirements and make f
|
||||
- **Simple solutions first** - Choose the most straightforward implementation path from issue context
|
||||
- **Defer complexity** - Don't anticipate requirements beyond current issue scope
|
||||
|
||||
### C# Implementation Strategies
|
||||
### Implementation Strategies (Polyglot)
|
||||
- **Start with constants** - Return hard-coded values from issue examples initially
|
||||
- **Progress to conditionals** - Add if/else logic as more issue scenarios are tested
|
||||
- **Extract to methods** - Create simple helper methods when duplication emerges
|
||||
- **Use basic collections** - Simple List<T> or Dictionary<T,V> over complex data structures
|
||||
- **Extract to methods/functions** - Create simple helpers when duplication emerges
|
||||
- **Use basic collections** - Simple arrays, lists, or maps over complex data structures
|
||||
|
||||
## Execution Guidelines
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
description: "Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists."
|
||||
name: "TDD Red Phase - Write Failing Tests First"
|
||||
tools: ["github", "findTestFiles", "edit/editFiles", "runTests", "runCommands", "codebase", "filesystem", "search", "problems", "testFailure", "terminalLastCommand"]
|
||||
tools: ["github/*", "search/fileSearch", "edit/editFiles", "execute/runTests", "execute/runInTerminal", "execute/getTerminalOutput", "execute/testFailure", "read/readFile", "read/terminalLastCommand", "read/terminalSelection", "read/problems", "search/codebase"]
|
||||
---
|
||||
|
||||
# TDD Red Phase - Write Failing Tests First
|
||||
@@ -34,17 +34,19 @@ Focus on writing clear, specific failing tests that describe the desired behavio
|
||||
|
||||
### Test Quality Standards
|
||||
|
||||
- **Descriptive test names** - Use clear, behaviour-focused naming like `Should_ReturnValidationError_When_EmailIsInvalid_Issue{number}`
|
||||
- **Descriptive test names** - Use clear, behaviour-focused naming like `returnsValidationError_whenEmailIsInvalid_issue{number}` (adapt casing to your language convention)
|
||||
- **AAA Pattern** - Structure tests with clear Arrange, Act, Assert sections
|
||||
- **Single assertion focus** - Each test should verify one specific outcome from issue criteria
|
||||
- **Edge cases first** - Consider boundary conditions mentioned in issue discussions
|
||||
|
||||
### C# Test Patterns
|
||||
### Test Patterns (Polyglot)
|
||||
|
||||
- Use **xUnit** with **FluentAssertions** for readable assertions
|
||||
- Apply **AutoFixture** for test data generation
|
||||
- Implement **Theory tests** for multiple input scenarios from issue examples
|
||||
- Create **custom assertions** for domain-specific validations outlined in issue
|
||||
- **JavaScript/TypeScript**: Use **Jest** or **Vitest** with `describe`/`it` blocks and `expect` assertions
|
||||
- **Python**: Use **pytest** with descriptive function names and `assert` statements
|
||||
- **Java/Kotlin**: Use **JUnit 5** with **AssertJ** for fluent assertions
|
||||
- **C#/.NET**: Use **xUnit** or **NUnit** with **FluentAssertions**
|
||||
- Apply parameterised/data-driven tests for multiple input scenarios from issue examples
|
||||
- Create shared test utilities for domain-specific validations outlined in issue
|
||||
|
||||
## Execution Guidelines
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
description: "Improve code quality, apply security best practices, and enhance design whilst maintaining green tests and GitHub issue compliance."
|
||||
name: "TDD Refactor Phase - Improve Quality & Security"
|
||||
tools: ["github", "findTestFiles", "edit/editFiles", "runTests", "runCommands", "codebase", "filesystem", "search", "problems", "testFailure", "terminalLastCommand"]
|
||||
tools: ["github/*", "search/fileSearch", "edit/editFiles", "execute/runTests", "execute/runInTerminal", "execute/getTerminalOutput", "execute/testFailure", "read/readFile", "read/terminalLastCommand", "read/terminalSelection", "read/problems", "search/codebase"]
|
||||
---
|
||||
|
||||
# TDD Refactor Phase - Improve Quality & Security
|
||||
@@ -39,24 +39,24 @@ Clean up code, apply security best practices, and enhance design whilst keeping
|
||||
- **Authentication/Authorisation** - Implement proper access controls if specified in issue
|
||||
- **Data protection** - Encrypt sensitive data, use secure connection strings
|
||||
- **Error handling** - Avoid information disclosure through exception details
|
||||
- **Dependency scanning** - Check for vulnerable NuGet packages
|
||||
- **Secrets management** - Use Azure Key Vault or user secrets, never hard-code credentials
|
||||
- **Dependency scanning** - Check for vulnerable packages (`npm audit`, `pip audit`, `dotnet list package --vulnerable`, etc.)
|
||||
- **Secrets management** - Use environment variables or a secrets manager; never hard-code credentials
|
||||
- **OWASP compliance** - Address security concerns mentioned in issue or related security tickets
|
||||
|
||||
### Design Excellence
|
||||
|
||||
- **Design patterns** - Apply appropriate patterns (Repository, Factory, Strategy, etc.)
|
||||
- **Dependency injection** - Use DI container for loose coupling
|
||||
- **Configuration management** - Externalise settings using IOptions pattern
|
||||
- **Logging and monitoring** - Add structured logging with Serilog for issue troubleshooting
|
||||
- **Performance optimisation** - Use async/await, efficient collections, caching
|
||||
- **Dependency injection** - Use DI container or constructor injection for loose coupling
|
||||
- **Configuration management** - Externalise settings using environment variables or config files
|
||||
- **Logging and monitoring** - Add structured logging appropriate to your stack for issue troubleshooting
|
||||
- **Performance optimisation** - Use async/await or equivalent concurrency primitives, efficient collections, caching
|
||||
|
||||
### C# Best Practices
|
||||
### Language Best Practices (Polyglot)
|
||||
|
||||
- **Nullable reference types** - Enable and properly configure nullability
|
||||
- **Modern C# features** - Use pattern matching, switch expressions, records
|
||||
- **Memory efficiency** - Consider Span<T>, Memory<T> for performance-critical code
|
||||
- **Exception handling** - Use specific exception types, avoid catching Exception
|
||||
- **Null safety** - Enable strict null checks (TypeScript), nullable reference types (C#), or Optional types (Java/Kotlin)
|
||||
- **Modern language features** - Use pattern matching, destructuring, and idiomatic constructs for your language
|
||||
- **Memory & performance** - Apply language-specific optimisations only when profiling reveals a bottleneck
|
||||
- **Error handling** - Use specific error/exception types; avoid swallowing errors silently
|
||||
|
||||
## Security Checklist
|
||||
|
||||
|
||||
Reference in New Issue
Block a user