一键导入
test-map
Maps source files to their test files so only relevant tests run after a change. Use after modifying source files or when asked which tests cover a file.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Maps source files to their test files so only relevant tests run after a change. Use after modifying source files or when asked which tests cover a file.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Turn a codebase into an onboarding playlist — Claude-authored analysis docs plus NotebookLM explainer videos (one overview + one per subsystem). Use when asked to explain a codebase, onboard onto a repo, make explainer/walkthrough videos of the code, or 'help me understand how this whole thing works'.
Syncs the current feature branch with the team base branch (merge base into feature) before creating a PR, resolving merge conflicts safely with build/test verification. Use when preparing a branch for a PR, when asked to sync with or merge in the base/developer branch, when a PR shows conflicts, or before pushing a long-lived feature branch.
Team commit-message conventions. Use when writing a commit message, committing or amending changes, or when asked about the project's commit format. Reads the per-project style from .claude/idev/commit-style.md.
Scaffolds the per-project .claude/idev/ state directory (caches, journal, lessons, config templates) for the idev plugin. Use when starting idev in a new project, when the SessionStart hook reports the state directory is missing, or when the user runs /idev:idev-init or asks to 'set up idev'.
Evaluates and benchmarks Agent Skill quality via static analysis and evaluation methodology. Use when assessing or reviewing skill quality, benchmarking skills, measuring skill activation accuracy, optimizing skill descriptions, or running /idev:benchmark-skills.
Token-optimized context loading: load the cached project index at session start, then Grep before Read, expanding only as needed. Use when starting a session, deciding what context to load, or generating/refreshing the project index. For feature-name → file-path lookups, the file-index skill answers directly from this index.
| name | test-map |
| description | Maps source files to their test files so only relevant tests run after a change. Use after modifying source files or when asked which tests cover a file. |
Map test files to source features so Claude can run targeted tests after modifying code, instead of running the full test suite or guessing which tests are relevant.
A compact test-to-feature mapping is maintained at:
.claude/idev/test-map/map.json
This maps: feature/source file → [test files that cover it]
Auto-detect the testing setup:
JavaScript/TypeScript:
package.json scripts containing "test" → detect runner
jest.config.* → Jest
vitest.config.* → Vitest
.mocharc.* → Mocha
karma.conf.* → Karma
playwright.config.* → Playwright (E2E)
cypress.config.* → Cypress (E2E)
.NET:
Glob for *.Tests.csproj or *.Test.csproj → xUnit/NUnit/MSTest
Read .csproj for <PackageReference Include="xunit|NUnit|MSTest">
Python:
pytest.ini or pyproject.toml [tool.pytest] → pytest
Glob for test_*.py or *_test.py
Java:
src/test/ directory → JUnit
Glob for *Test.java or *Tests.java
Go:
Glob for *_test.go → built-in testing
Ruby:
spec/ directory → RSpec
test/ directory → Minitest
Scan for test files using detected patterns:
.NET:
Glob: **/*.Tests/**/*Test*.cs
Glob: **/*.Test/**/*Test*.cs
Convention: {Service}Tests.cs tests {Service}.cs
JavaScript/TypeScript:
Glob: **/*.test.ts, **/*.test.tsx, **/*.spec.ts, **/*.spec.tsx
Glob: **/__tests__/**/*.ts
Convention: {Component}.test.tsx tests {Component}.tsx
Python:
Glob: **/test_*.py, **/*_test.py
Glob: tests/**/*.py
Go:
Glob: **/*_test.go
Convention: {file}_test.go tests {file}.go
OrderServiceTests.cs → tests OrderService.cs → feature: Orders
OrdersDashboard.test.tsx → tests OrdersDashboard.tsx → feature: Orders
Read test file imports:
import { OrderService } from "../../services/OrderService"
→ This test covers OrderService
→ Feature: Orders
Tests in same feature folder:
features/Orders/__tests__/ → covers Orders feature
Tests in parallel test project:
Services.Test/Orders/ → covers Services/Orders/
Write to .claude/idev/test-map/map.json:
{
"generated": "YYYY-MM-DD",
"testFrameworks": {
"backend": {
"framework": "xunit|nunit|mstest",
"testProject": "relative/path/to/test/project",
"runCommand": "dotnet test path/to/Tests.csproj",
"runFilteredCommand": "dotnet test --filter {TestClassName}",
"runSingleCommand": "dotnet test --filter FullyQualifiedName~{TestName}"
},
"frontend": {
"framework": "jest|vitest",
"runCommand": "npm test -- --watchAll=false",
"runFilteredCommand": "npm test -- --testPathPattern={pattern} --watchAll=false",
"runSingleCommand": "npm test -- {testFile} --watchAll=false"
},
"e2e": {
"framework": "playwright|cypress",
"runCommand": "npx playwright test",
"runFilteredCommand": "npx playwright test {testFile}"
}
},
"featureToTests": {
"Orders": {
"backend": [
{
"testFile": "relative/path/to/OrderServiceTests.cs",
"covers": ["OrderService.cs"],
"testCount": 12
}
],
"frontend": [
{
"testFile": "relative/path/to/OrdersDashboard.test.tsx",
"covers": ["OrdersDashboard.tsx"],
"testCount": 8
}
]
}
},
"sourceToTests": {
"relative/path/to/OrderService.cs": ["relative/path/to/OrderServiceTests.cs"],
"relative/path/to/OrdersDashboard.tsx": ["relative/path/to/OrdersDashboard.test.tsx"]
},
"untestedFiles": [
"relative/path/to/file/with/no/tests.ts"
]
}
Notes on the format:
testCount and untestedFiles are OPTIONAL fields — they are expensive to compute and rot quickly. Omit them unless cheap to derive.--testPathPattern, newer Jest uses --testPathPatterns. If the filtered command fails, check npx jest --help and update the cached command.1. Load test-map
2. Look up sourceToTests for the modified file
3. Verify the mapped test file still exists before running it (if missing, update the map)
4. If tests exist → run them with the filtered command
5. Report: "3/3 tests passed" or "1 test failed: ..."
1. Check if test files should be created
2. Suggest test file names following project convention
3. If user wants tests → create them using detected patterns
1. Determine scope:
- "run tests" → run all tests
- "run tests for Orders" → use featureToTests mapping
- "run tests for OrderService" → use sourceToTests mapping
2. Use the appropriate run command from testFrameworks
3. Report results
Modified: OrderService.cs
→ sourceToTests → OrderServiceTests.cs
→ Command: dotnet test --filter OrderServiceTests
→ Result in ~10 seconds instead of full suite (~2 minutes)
Modified: 5 files in Orders
→ featureToTests.Orders → all test files
→ Command: dotnet test --filter "Namespace~Orders"
→ Result in ~30 seconds instead of full suite