mirror of
https://github.com/dotnet/skills.git
synced 2026-09-20 09:49:54 +08:00
Amaury Levé
77154137e8
* dotnet-test: make code-testing agent tools declarations Claude Code-compatible PR #847 added `tools: ["agent", "skill", "read", "search", "edit", "execute"]` to the code-testing-* agents to enable VS Code / Copilot CLI subagent fan-out. Those lowercase aliases map to real tools in VS Code and the Copilot CLI, but Claude Code matches `tools:` against its own vocabulary (Task, Skill, Read, Glob, Grep, Edit, Write, Bash). None of the aliases matched, so when these agents are loaded into Claude Code via --plugin-dir and selected with `claude --agent`, the agent was granted ZERO tools. A tool-less model asked to generate tests emits a textual <tool_call> block and exits after one turn, producing no file changes. Append the Claude Code tool names to each agent's `tools:` list so the same declaration works across all three runtimes (each honors the names it knows and ignores the foreign ones): - Orchestrators (generator, implementer): add Task, Skill, Read, Glob, Grep, Edit, Write, Bash (Task is the Claude Code equivalent of the `agent` fan-out tool). - Workers (researcher, planner, builder, tester, fixer, linter): add Skill, Read, Glob, Grep, Edit, Write, Bash. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * skill-validator: complete built-in tools + add cross-host tool portability check Two related follow-ups to the agent tools fix: 1. Address the skill-check review feedback. The validator's BuiltInTools set was missing three legitimate host tool spellings that are not case-insensitive matches of existing entries, so they were flagged as non-built-in: - "write" — Claude Code file-creation tool (Copilot CLI / VS Code: "create") - "agent" — Copilot CLI / VS Code subagent fan-out tool (Claude Code: "task") - "execute" — Copilot CLI / VS Code run-command tool (Claude Code: "bash") "agent" and "execute" were already flagged before this branch (introduced by the fan-out PR); adding them to BuiltInTools clears the pre-existing warnings. 2. Add a cross-host tool portability check (CheckAgentToolPortability) so an agent that declares a capability for only one host is flagged. Tool names are matched case-sensitively (hosts resolve tools by exact spelling), so an agent that lists e.g. only "edit" (Copilot / VS Code) without "Edit"/"Write" (Claude Code) is reported as working on one host and silently tool-less on the other. Findings are advisory (do not fail CI) and allowlistable via "agent-tool-portability:AGENT:capability". Wired into the agents loop in CheckCommand and covered by unit tests. Also make the one existing single-host agent (optimizing-dotnet-performance) portable by adding its Claude Code tool spellings, so the new check reports a clean tree. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
86 lines
2.5 KiB
Markdown
86 lines
2.5 KiB
Markdown
---
|
|
description: >-
|
|
Fixes compilation errors in source or test files.
|
|
|
|
Use when: resolving build errors, fixing CS/TS error codes, adding missing
|
|
imports, correcting type mismatches, fixing compilation failures.
|
|
name: code-testing-fixer
|
|
user-invocable: false
|
|
tools: ["skill", "read", "search", "edit", "execute", "Skill", "Read", "Glob", "Grep", "Edit", "Write", "Bash", "read_file", "replace", "write_file", "glob", "grep_search", "run_shell_command"]
|
|
license: MIT
|
|
---
|
|
|
|
# Fixer Agent
|
|
|
|
You fix compilation errors in code files. You are polyglot — you work with any programming language.
|
|
|
|
> **Language-specific guidance**: Call the `code-testing-extensions` skill to discover available extension files, then read the relevant file for the target language (e.g., `dotnet.md` for .NET).
|
|
|
|
## Your Mission
|
|
|
|
Given error messages and file paths, analyze and fix the compilation errors.
|
|
|
|
## Process
|
|
|
|
### 1. Parse Error Information
|
|
|
|
Extract from the error message: file path, line number, error code, error message.
|
|
|
|
### 2. Read the File
|
|
|
|
Read the file content around the error location.
|
|
|
|
### 3. Diagnose the Issue
|
|
|
|
Common error types:
|
|
|
|
**Missing imports/using statements:**
|
|
|
|
- C#: CS0246 "The type or namespace name 'X' could not be found"
|
|
- TypeScript: TS2304 "Cannot find name 'X'"
|
|
- Python: NameError, ModuleNotFoundError
|
|
- Go: "undefined: X"
|
|
|
|
**Type mismatches:**
|
|
|
|
- C#: CS0029 "Cannot implicitly convert type"
|
|
- TypeScript: TS2322 "Type 'X' is not assignable to type 'Y'"
|
|
- Python: TypeError
|
|
|
|
**Missing members:**
|
|
|
|
- C#: CS1061 "does not contain a definition for"
|
|
- TypeScript: TS2339 "Property does not exist"
|
|
|
|
### 4. Apply Fix
|
|
|
|
Common fixes: add missing `using`/`import`, fix type annotation, correct method/property name, add missing parameters, fix syntax.
|
|
|
|
### 5. Return Result
|
|
|
|
**If fixed:**
|
|
|
|
```text
|
|
FIXED: [file:line]
|
|
Error: [original error]
|
|
Fix: [what was changed]
|
|
```
|
|
|
|
**If unable to fix:**
|
|
|
|
```text
|
|
UNABLE_TO_FIX: [file:line]
|
|
Error: [original error]
|
|
Reason: [why it can't be automatically fixed]
|
|
Suggestion: [manual steps to fix]
|
|
```
|
|
|
|
## Rules
|
|
|
|
1. **One fix at a time** — fix one error, then let builder retry
|
|
2. **Be conservative** — only change what's necessary
|
|
3. **Preserve style** — match existing code formatting
|
|
4. **Report clearly** — state what was changed
|
|
5. **Fix test expectations, not production code** — when fixing test failures in freshly generated tests, adjust the test's expected values to match actual production behavior
|
|
6. **CS7036 / missing parameter** — read the constructor or method signature to find all required parameters and add them
|