4.4 KiB
| name | description | argument-hint | agent |
|---|---|---|---|
| workspace-coverage-report | Run code coverage across the current multi-repo workspace and produce a consolidated drill-down report with actions. | Scope or focus, for example "all repos", "web only", "backend only", "changed repos only", or "high-risk gaps first" | agent |
Create a workspace-wide code coverage audit across all repositories in the current VS Code workspace and produce a consolidated, decision-ready report.
Scope
Treat the current multi-root workspace as the source of truth.
- Include all workspace repositories unless the user narrows scope.
- Respect each repo's documented build and test conventions.
- Prefer existing coverage, test, and typecheck scripts over ad hoc commands.
- Do not install dependencies or modify source code unless the user explicitly asks for remediation.
Discovery
- Identify all repositories in the current workspace.
- For each repository, detect:
- primary stack and languages
- available test and coverage commands
- whether coverage is already configured
- whether the repo is currently dirty
- If a repo has no runnable coverage path, mark it clearly as
coverage unavailableand explain why.
Execution Rules
- Run the smallest reliable command set that yields meaningful coverage data.
- Prefer repo-native commands such as
npm test -- --coverage,pnpm test -- --coverage,vitest --coverage,pytest --cov,xcodebuild testwith coverage when already configured, or other documented equivalents. - Avoid destructive actions.
- If a command is too expensive or unsupported, fall back to test inventory plus uncovered-file analysis.
- Capture failures separately from coverage gaps.
Output Requirements
Produce a consolidated markdown report that is easy to scan and act on.
The report must include these sections in order:
- Executive summary
- Workspace scorecard
- Repo-by-repo breakdown
- Cross-repo hotspot analysis
- Drill-down tables
- Recommended actions
- Command log summary
- Risks and blockers
Visual Structure
Make the report feel visual and analytical even in markdown. Use:
- compact summary tables
- severity labels such as
critical,high,medium,low - clear coverage bands such as
<50%,50-69%,70-84%,85%+ - optional Mermaid charts when they add value
- grouped drill-down sections by repo, platform, or risk
Required Tables
Include at minimum:
Workspace scorecard
| Repo | Stack | Coverage status | Approx coverage | Test health | Dirty | Notes |
Hotspot table
| Repo | File or module | Area | Signal | Why it matters | Suggested next step |
Action table
| Priority | Repo | Action | Effort | Expected impact | Safe to automate |
Drill-Down Expectations
For each repo, include:
- what was run
- what coverage data was available
- top uncovered or weakly covered areas
- whether failures were caused by missing setup, broken tests, or real code risk
- the smallest sensible next action
Filtering Behavior
If the user provides a focus argument, adapt the audit accordingly. Supported patterns include:
- platform filter:
web,backend,mobile,ios,android,python,shared packages - repo filter: specific repo names
- risk filter:
critical only,high-risk first - state filter:
dirty repos only,clean repos only - workflow filter:
coverage only,coverage plus typecheck,coverage plus audit
Actionability
Recommendations should be concrete, not generic. Prefer suggestions like:
- add tests for a specific uncovered wrapper or hook
- enable coverage in a repo that has tests but no coverage output
- split flaky tests from true coverage gaps
- fix broken setup before chasing percentages
- prioritize pure logic modules before UI-heavy surfaces
Default Behavior
If no argument is provided:
- audit all repositories in the workspace
- prioritize repos with existing automated coverage support
- include dirty-state awareness
- remain read-only and do not remediate code
- produce a single consolidated report in the response
Optional Saved Artifact
If the user asks to save the report, create a dated markdown file under /Users/sd9235/code/mygh/learning_ai_common_plat/.github/reports/coverage/ and mention its path.
Final Response Style
Keep the final response concise but useful:
- start with the overall outcome
- include the highest-signal findings first
- link any saved report file
- end with a short numbered list of next actions