Repo Health Audit
Goal
Produce a structured maintenance report that separates urgent repository risks from polish, identifies gaps in onboarding and automation, and recommends the next practical maintainer actions.
When to use
- The user asks whether a repository is healthy, maintainable, or ready to publish.
- A repo needs a maintainer audit across docs, tests, CI, releases, and security hygiene.
- The user wants a prioritized cleanup plan without immediate code edits.
When not to use
- The user asks for a focused PR review; use
pr-review.
- The task is only documentation clarity; use
docs-audit.
- The user already asked for implementation instead of audit.
Inputs to inspect
- README, docs, examples, changelog, license, security policy, and contribution guide.
- Package files, lockfiles, test config, format/lint config, and validation scripts.
- CI workflows, issue templates, release automation, and dependency update config.
- Current
git status, recent commits, and validation output when available.
Review rubric
Score docs, build/test, CI, release readiness, dependency hygiene, security baseline, issue/PR operations, and agent context from 0 to 5. Read references/audit-rubric.md for scoring detail and references/report-template.md for the report shape.
Workflow
- Inspect top-level files and repository structure.
- Identify the main stack and validation commands.
- Review docs against actual commands and files.
- Check CI, release, security, and contribution surfaces.
- Run safe validation commands when the user expects implementation-level evidence.
- Produce a scored report with urgent issues, quick wins, backlog items, and the next action.
Safety rules
- Do not change repository files unless the user explicitly asks for implementation.
- Do not print secrets or sensitive config values in the audit.
- Mark live repository settings as unverified unless they were checked directly.
References
Read only when needed:
references/audit-rubric.mdreferences/report-template.md
Scripts
No bundled scripts.
Output format
Return:
- Summary
- Scores table
- Highest-risk issues
- Quick wins
- Suggested issue backlog
- Recommended next action
Failure modes
- If validation cannot run, explain the missing tool, dependency, or environment.
- If the repo lacks clear goals, state the inferred goal and mark it as an assumption.
- If live settings are required, say which settings need verification.
Completion criteria
- The report is grounded in file or command evidence.
- Risks are prioritized by maintainer impact.
- The next action is concrete and small enough to assign.
1---2name: repo-health-audit3description: Audit repository health and maintenance readiness. Use when the user asks for a repo review, maintainer audit, cleanup plan, onboarding audit, technical debt scan, CI/docs/release hygiene review, or public repo readiness check.4license: Apache-2.05---67# Repo Health Audit89## Goal1011Produce a structured maintenance report that separates urgent repository risks from polish, identifies gaps in onboarding and automation, and recommends the next practical maintainer actions.1213## When to use1415- The user asks whether a repository is healthy, maintainable, or ready to publish.16- A repo needs a maintainer audit across docs, tests, CI, releases, and security hygiene.17- The user wants a prioritized cleanup plan without immediate code edits.1819## When not to use2021- The user asks for a focused PR review; use `pr-review`.22- The task is only documentation clarity; use `docs-audit`.23- The user already asked for implementation instead of audit.2425## Inputs to inspect2627- README, docs, examples, changelog, license, security policy, and contribution guide.28- Package files, lockfiles, test config, format/lint config, and validation scripts.29- CI workflows, issue templates, release automation, and dependency update config.30- Current `git status`, recent commits, and validation output when available.3132## Review rubric3334Score docs, build/test, CI, release readiness, dependency hygiene, security baseline, issue/PR operations, and agent context from 0 to 5. Read `references/audit-rubric.md` for scoring detail and `references/report-template.md` for the report shape.3536## Workflow37381. Inspect top-level files and repository structure.392. Identify the main stack and validation commands.403. Review docs against actual commands and files.414. Check CI, release, security, and contribution surfaces.425. Run safe validation commands when the user expects implementation-level evidence.436. Produce a scored report with urgent issues, quick wins, backlog items, and the next action.4445## Safety rules4647- Do not change repository files unless the user explicitly asks for implementation.48- Do not print secrets or sensitive config values in the audit.49- Mark live repository settings as unverified unless they were checked directly.5051## References5253Read only when needed:5455- `references/audit-rubric.md`56- `references/report-template.md`5758## Scripts5960No bundled scripts.6162## Output format6364Return:65661. Summary672. Scores table683. Highest-risk issues694. Quick wins705. Suggested issue backlog716. Recommended next action7273## Failure modes7475- If validation cannot run, explain the missing tool, dependency, or environment.76- If the repo lacks clear goals, state the inferred goal and mark it as an assumption.77- If live settings are required, say which settings need verification.7879## Completion criteria8081- The report is grounded in file or command evidence.82- Risks are prioritized by maintainer impact.83- The next action is concrete and small enough to assign.
stark-ai-de