---
name: workspace-coverage-report
description: 'Run code coverage across the current multi-repo workspace and produce a consolidated drill-down report with actions.'
argument-hint: Scope or focus, for example "all repos", "web only", "backend only", "changed repos only", or "high-risk gaps first"
agent: 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

1. Identify all repositories in the current workspace.
2. For each repository, detect:
   - primary stack and languages
   - available test and coverage commands
   - whether coverage is already configured
   - whether the repo is currently dirty
3. If a repo has no runnable coverage path, mark it clearly as `coverage unavailable` and 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 test` with 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:

1. Executive summary
2. Workspace scorecard
3. Repo-by-repo breakdown
4. Cross-repo hotspot analysis
5. Drill-down tables
6. Recommended actions
7. Command log summary
8. 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