mirror of
https://github.com/dotnet/skills.git
synced 2026-09-20 09:49:54 +08:00
Petr Pokorny
06dd46e5f1
* Add VS Code subagent metadata to dotnet-test code-testing agents
Enable the code-testing-* Research-Plan-Implement pipeline to fan out as
subagents in VS Code while keeping the GitHub Copilot CLI working.
Frontmatter (VS Code "coordinator/worker" pattern; portable tool aliases that
map in both VS Code and the CLI):
- code-testing-generator: tools: [agent, read, search, edit, execute] + an
agents: list (researcher, planner, implementer, builder, tester, fixer,
linter); softened the three runSubagent({ agent, prompt }) blocks to
tool-agnostic delegation prose.
- code-testing-implementer: tools: [agent, read, search, edit, execute] +
agents: (builder, tester, fixer, linter).
- Leaf agents (researcher/planner/builder/tester/fixer/linter):
tools: [read, search, edit, execute].
Why explicit tools (not ["*"]): VS Code has no all-tools wildcard for ools:
and a subagent's ools: overrides its inherited set, so ["*"] matched nothing
and stripped subagents of file tools (they ran without read/edit/search). The
CLI treats ["*"] as all-tools, so this was VS-Code-specific. The portable
aliases agent/read/search/edit/execute map to real tools in both environments;
agents: is ignored by the CLI.
README: document the VS Code chat.subagents.allowInvocationsFromSubagents
setting (off by default) needed for the nested implementer->builder/tester/
fixer/linter layer to fan out on large scopes; the CLI has no such gate.
Validated end to end: VS Code shows researcher->planner->implementer fanning out
with real file I/O (no "subagents lack file tools" warning); CLI fan-out intact
with skills still loading and tests passing. An all-tools baseline used only
tools within this enumerated set, confirming no CLI capability is restricted.
* Include skill tool in code-testing agent tool allowlists
Address PR review: the explicit `tools:` allowlists omitted the `skill`
tool, but every code-testing-* agent's prompt instructs calling skills
(e.g. `code-testing-extensions` for per-language guidance, `test-gap-analysis`,
`assertion-quality`). Because `tools:` is an override, omitting `skill` can
prevent the agents from loading those skills in environments that gate skill
invocation by the allowlist.
Add `skill` to all eight agents:
- orchestrators (generator, implementer): [agent, skill, read, search, edit, execute]
- workers (researcher/planner/builder/tester/fixer/linter): [skill, read, search, edit, execute]
Re-verified in the Copilot CLI: full fan-out (researcher -> planner ->
implementer/tester), the `code-testing-extensions` skill is invoked, and the
generated tests pass.
86 lines
2.4 KiB
Markdown
86 lines
2.4 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"]
|
|
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
|