105 lines
2.7 KiB
Markdown
105 lines
2.7 KiB
Markdown
---
|
|
name: workspace-health-dashboard
|
|
description: 'Audit test health and typecheck status across the current multi-repo workspace and produce a consolidated dashboard.'
|
|
argument-hint: Scope or focus, for example "all repos", "web only", "backend only", "changed repos only", or "failures first"
|
|
agent: agent
|
|
---
|
|
|
|
Create a workspace-wide health dashboard for the current multi-repo workspace, focused on typecheck status, test health, and execution readiness.
|
|
|
|
## Scope
|
|
|
|
- Treat the current VS Code multi-root workspace as the audit boundary.
|
|
- Include all repositories unless the user narrows scope.
|
|
- Prefer documented repo-native commands.
|
|
- Stay read-only unless the user explicitly asks for remediation.
|
|
|
|
## Discovery
|
|
|
|
For each repository, identify:
|
|
|
|
- primary stack and languages
|
|
- available typecheck commands
|
|
- available test commands
|
|
- whether commands are fast, medium, or expensive
|
|
- whether the repository is dirty
|
|
|
|
## Execution Rules
|
|
|
|
- Run the smallest reliable command set that gives useful signal.
|
|
- Prefer repo-native commands such as `npm run typecheck`, `pnpm typecheck`, `npm test`, `pnpm test`, `pytest`, `xcodebuild test`, or documented equivalents.
|
|
- If a repo lacks a formal typecheck or test path, mark it clearly.
|
|
- Separate command failures from code quality findings.
|
|
|
|
## Output Requirements
|
|
|
|
Produce one consolidated markdown dashboard with these sections:
|
|
|
|
1. Executive summary
|
|
2. Workspace scorecard
|
|
3. Repo-by-repo status
|
|
4. Failure clusters
|
|
5. Recommended actions
|
|
6. Command log summary
|
|
7. Risks and blockers
|
|
|
|
## Required Tables
|
|
|
|
### Workspace scorecard
|
|
|
|
| Repo | Typecheck | Tests | Dirty | Health | Notes |
|
|
|
|
### Failure clusters
|
|
|
|
| Repo | Category | Signal | Likely cause | Suggested next step |
|
|
|
|
### Action table
|
|
|
|
| Priority | Repo | Action | Effort | Expected impact | Safe to automate |
|
|
|
|
## Classification Rules
|
|
|
|
Use clear labels such as:
|
|
|
|
- `passing`
|
|
- `failing`
|
|
- `missing`
|
|
- `blocked`
|
|
- `not run`
|
|
|
|
Use health levels such as:
|
|
|
|
- `critical`
|
|
- `high`
|
|
- `medium`
|
|
- `low`
|
|
|
|
## Drill-Down Expectations
|
|
|
|
For each repo, include:
|
|
|
|
- what commands were run
|
|
- whether typecheck passed
|
|
- whether tests passed
|
|
- whether failures are setup, environment, flaky, or real code issues
|
|
- the smallest next action
|
|
|
|
## Default Behavior
|
|
|
|
If no argument is provided:
|
|
|
|
- audit all repositories in the workspace
|
|
- prioritize fast typecheck and unit-test signals first
|
|
- produce a single dashboard in the response
|
|
|
|
## Optional Saved Artifact
|
|
|
|
If the user asks to save the dashboard, write a dated markdown file under `/Users/sd9235/code/mygh/learning_ai_common_plat/.github/reports/health/`.
|
|
|
|
## Final Response Style
|
|
|
|
- start with the highest-signal outcome
|
|
- keep the summary concise
|
|
- surface blockers early
|
|
- end with a short numbered list of next actions
|