test-scaffold
Skill0 starsChanged 7 months agoApache-2.0View on GitHub
Generate tests for an existing FastMCP tool, resource, or custom route. Use when: adding missing tests, improving test coverage, writing tests for a tool that has none, scaffolding route tests, adding error-path tests, or creating tests for a resource URI. Detects the module type and generates correctly structured tests without the user needing to remember fixture or assertion patterns.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Read pyproject.toml to find the current PACKAGE name.
- Very specific: line 23
Ask the following questions.
- Distinctive: line 35
Read the source file to understand:
- Distinctive: line 38
Default parameter values for optional arguments
- Distinctive: line 42
Use ./references/test-patterns.md for the exact assertion and fixture patterns for each module type.
- Distinctive: line 46
Default parameter path (if any parameters have defaults)
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Scaffold Tests for an Existing Module
Generates correctly structured pytest tests for a tool, resource, or custom route already present in the codebase, using the exact patterns established in this project.
When to use
- A tool, resource, or route exists but has no test file
- An existing test file is missing error-path or edge-case coverage
- Unsure about fixture usage, assertion patterns, or how to test error responses
Step 1 — Detect the package name
Read pyproject.toml to find the current PACKAGE name.
Step 2 — Interview the user
Ask the following questions. Use vscode_askQuestions if available.
| # | Question | Notes |
| 1 | What to test? | Tool name, resource URI (e.g. resource://config), or route path (e.g. /health) |
| 2 | Module type | Auto-detect from the answer: tool → tools/, URI → resources/, path → routes/. Ask if ambiguous |
| 3 | Does a test file already exist? | Check tests/test_<name>.py; if yes, ask whether to append or create a companion file |
| 4 | What scenarios to cover? | Ask the user to list them, or offer a default set based on module type |
| 5 | Include edge cases? | Empty/null input, type errors, not-found, auth failure (optional) |
Step 3 — Read the source module
Read the source file to understand:
- Function/handler signature and parameter names
- Return type and error cases (
ToolError,ResourceError, status codes) - Default parameter values for optional arguments
Step 4 — Generate the test file
Use ./references/test-patterns.md for the exact assertion and fixture patterns for each module type.
Tool test file → tests/test_TOOL_NAME.py
- Success path with a representative input
- Default parameter path (if any parameters have defaults)
- Error path using
raise_on_error=Falseand assertingresult.is_error - Uses the shared
clientfixture fromconftest.py
Resource test file → tests/test_RESOURCE_NAME.py
- Success path reading the resource URI
- JSON field assertion for structured resources
- Not-found error path for templated resources using
pytest.raises(McpError)
Route test file → tests/test_ROUTE_NAME.py
- Success path asserting status code and response body
- Error path for each documented error response
- Uses
httpx.ASGITransport(app=mcp.http_app())— import the route module for side effects
Step 5 — Validate
ruff check .
pytest tests/test_<name>.py -vFix any issues before reporting completion.
Step 6 — Report
Tell the user:
- The test file path
- How many test cases were generated
- Any scenarios that could not be auto-generated and require manual implementation
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- rcelebrone/DotAgents★ 15same name
- tlzmw001/aitest-kit★ 13same name
- michaelalber/ai-toolkit★ 3same name
- UfukCetinkaya57/backend-governance★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-resourceSkill
- add-routeSkill
- add-toolSkill
- auth-setupSkill
- bootstrap-personalizeSkill
- deployment-profileSkill
- docs-syncSkill
- observability-setupSkill
- release-readinessSkill
- rename-projectSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

