docs(workspace): add coverage audit prompt

.github/instructions/workspace-coverage-report.instructions.md

@@ -0,0 +1,21 @@
+---
+applyTo: '**'
+---
+
+Coverage audit work in this workspace should follow these defaults unless the user overrides them:
+
+- Treat the multi-root workspace rooted at `/Users/sd9235/code/mygh` as the audit boundary.
+- Include all current workspace repositories by default.
+- Prefer repo-native test, coverage, and typecheck commands documented in each repo.
+- Stay read-only by default. Do not edit code, install dependencies, or commit changes during a coverage-report run unless the user explicitly asks for remediation.
+- Surface dirty repositories separately from clean repositories.
+- Distinguish clearly between:
+  - coverage gaps
+  - failing or flaky tests
+  - missing coverage tooling
+  - environment or setup blockers
+- When saving reports, write them under `/Users/sd9235/code/mygh/learning_ai_common_plat/.github/reports/coverage/` using a dated filename.
+- Use the template in `.github/reports/coverage/README.md` as the default saved-report schema.
+- Make reports decision-ready: concise executive summary first, then scorecards, drill-downs, hotspots, and prioritized actions.
+- Prefer concrete next steps over generic advice, especially for small pure-logic modules, wrappers, hooks, and client utilities.
+- Avoid destructive git operations and never stage or commit unrelated changes.

.github/prompts/workspace-coverage-report.prompt.md

@@ -0,0 +1,131 @@
+---
+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

.github/reports/coverage/README.md

@@ -0,0 +1,69 @@
+# Workspace Coverage Report Template
+
+Saved workspace coverage reports should follow this structure.
+
+## Filename
+
+Use a dated filename such as:
+
+- `workspace-coverage-2026-03-21.md`
+- `workspace-coverage-web-only-2026-03-21.md`
+- `workspace-coverage-high-risk-first-2026-03-21.md`
+
+## Required Sections
+
+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
+
+## Required Tables
+
+### 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 |
+|----------|------|--------|--------|-----------------|------------------|
+
+## Severity Bands
+
+- `critical`: broken coverage flow, major blind spots in high-risk code, or failing test infrastructure
+- `high`: meaningful uncovered business logic or weak test health in important surfaces
+- `medium`: partial gaps with reasonable existing safety nets
+- `low`: minor or cosmetic gaps with limited risk
+
+## Coverage Bands
+
+- `<50%`
+- `50-69%`
+- `70-84%`
+- `85%+`
+
+## Repo Drill-Down Checklist
+
+For each repo, capture:
+
+- what was run
+- what coverage data was available
+- what failed and why
+- top weakly covered areas
+- the smallest sensible next action
+
+## Notes
+
+- Keep saved reports concise and decision-ready.
+- Prefer exact file or module names over vague subsystem labels.
+- Separate setup blockers from actual code-risk coverage gaps.