docs(workspace): add coverage remediation prompt
This commit is contained in:
parent
89b38cadfa
commit
bb1069930b
73
.github/prompts/workspace-coverage-remediate.prompt.md
vendored
Normal file
73
.github/prompts/workspace-coverage-remediate.prompt.md
vendored
Normal file
@ -0,0 +1,73 @@
|
||||
---
|
||||
name: workspace-coverage-remediate
|
||||
description: 'Take the top safe coverage actions from a workspace audit and implement them incrementally with validation and isolated commits.'
|
||||
argument-hint: Scope or remediation plan, for example "top 3 safe fixes", "web only", "Local Memory GPT and FlowMonk", or "tests only no source changes"
|
||||
agent: agent
|
||||
---
|
||||
|
||||
Use the current workspace coverage findings to take the safest, highest-signal remediation actions across the current multi-repo workspace.
|
||||
|
||||
## Goal
|
||||
|
||||
Select a small number of low-risk, high-value actions and complete them end to end.
|
||||
Default to the top 3 safest actions unless the user specifies a different scope.
|
||||
|
||||
## Safety Rules
|
||||
|
||||
- Respect repo boundaries.
|
||||
- Respect existing dirty worktrees and other in-progress changes.
|
||||
- Stage and commit only the files you changed.
|
||||
- Prefer isolated incremental commits, one repo or one logical fix at a time.
|
||||
- Avoid broad refactors.
|
||||
- Do not fix unrelated failures.
|
||||
|
||||
## Selection Heuristics
|
||||
|
||||
Prefer targets that are:
|
||||
|
||||
- pure logic modules
|
||||
- thin API clients or wrappers
|
||||
- hooks with deterministic behavior
|
||||
- small uncovered utilities
|
||||
- test-only additions when they add meaningful confidence
|
||||
|
||||
Avoid by default:
|
||||
|
||||
- broad UI snapshot work
|
||||
- unstable E2E surfaces
|
||||
- setup-heavy mobile or native test changes
|
||||
- changes that require dependency installation unless explicitly approved
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. Review the current coverage findings or infer them from nearby reports and tests.
|
||||
2. Choose the smallest safe target.
|
||||
3. Implement the change.
|
||||
4. Run targeted validation first, then repo-level validation if reasonable.
|
||||
5. Commit only your files with a conventional commit message.
|
||||
6. Repeat for the next target until the requested scope is complete.
|
||||
|
||||
## Output Requirements
|
||||
|
||||
For each remediation step, report:
|
||||
|
||||
- chosen target
|
||||
- why it was selected
|
||||
- files changed
|
||||
- validation run
|
||||
- commit hash
|
||||
- remaining risks or blockers
|
||||
|
||||
## Default Mode
|
||||
|
||||
If no argument is provided:
|
||||
|
||||
- take the top 3 safe actions
|
||||
- prefer web and shared-package targets first
|
||||
- keep each change small and independently commit-ready
|
||||
|
||||
## Constraints
|
||||
|
||||
- If a repository is dirty, work around unrelated changes rather than reverting them.
|
||||
- If a target conflicts with other active changes, skip it and choose the next safe candidate.
|
||||
- If no safe code change is available, produce a ranked remediation queue instead of forcing edits.
|
||||
Loading…
Reference in New Issue
Block a user