docs(workspace): add health dashboard prompt

This commit is contained in:
saravanakumardb1 2026-03-21 12:40:51 -07:00
parent bb1069930b
commit cf9617cda5
2 changed files with 165 additions and 0 deletions

View File

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

61
.github/reports/health/README.md vendored Normal file
View File

@ -0,0 +1,61 @@
# Workspace Health Dashboard Template
Saved workspace health dashboards should follow this structure.
## Filename
Use a dated filename such as:
- `workspace-health-2026-03-21.md`
- `workspace-health-web-only-2026-03-21.md`
- `workspace-health-failures-first-2026-03-21.md`
## Required 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 |
| -------- | ---- | ------ | ------ | --------------- | ---------------- |
## Health Levels
- `critical`: broken typecheck or test infrastructure in key repos
- `high`: repeatable failures in important code paths or major workflow blockers
- `medium`: partial failures or missing automation with workable fallbacks
- `low`: minor gaps with limited impact on day-to-day development
## Repo Drill-Down Checklist
For each repo, capture:
- what commands were run
- what passed
- what failed
- whether the issue is setup, environment, flaky, or code-related
- the smallest sensible next action
## Notes
- Keep saved dashboards concise and decision-ready.
- Separate missing automation from true failures.
- Call out expensive native or mobile validations if they were intentionally skipped.