菜单
Measure codebase health across seven metrics: test count, clippy warnings, TODO density, public API surface, dependency count, average module size, and doc coverage. Track trends vs previous runs and persist scores to history.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | godmode:health-score |
| description | Measure codebase health across seven metrics: test count, clippy warnings, TODO density, public API surface, dependency count, average module size, and doc coverage. Track trends vs previous runs and persist scores to history. |
| requires | [] |
| next | ["dead-code","dep-audit"] |
Measure codebase health metrics on demand. Produces a scorecard with seven metrics and tracks trends over time by persisting scores to a JSON history file.
Collection: Run cargo nextest list --workspace (compiles but does not
execute tests) and count output lines containing ::. Each line is one test.
Fallback: cargo test --no-run and count binary artifacts.
Interpretation: More tests = better coverage. Trend: increases indicate more comprehensive testing. Decreases may indicate cleanup or removed features.
Example: "272 tests" or "Ran 272 tests"
Collection: Run cargo clippy --workspace (compile-only, no test
execution) and count warning lines. Use --message-format json and count
lines containing "level":"warning". Count only warnings, not notes or errors.
Interpretation: Zero is ideal. Each warning represents a potential code quality issue. Trend: increases indicate code quality degradation; decreases indicate refactoring or fixes.
Example: 0 or 5
Collection: Use Grep to search for TODO|FIXME pattern across all Rust files
in crates/. Divide match count by total Rust line count × 1000 to get density
per thousand lines.
Interpretation: Lower is better. High density indicates unresolved technical decisions or incomplete implementations. Expressed as "N per 1,000 lines of code".
Example: "0.5 per 1k lines" means roughly one TODO per 2,000 lines.
Collection: Count all pub fn, pub struct, pub enum, pub trait
declarations in crates/*/src/**/*.rs using Grep with pattern
^\s*pub\s+(fn|struct|enum|trait). Sum across workspace.
Interpretation: Growing API surface can indicate feature expansion or API bloat. Stable or shrinking surface may indicate consolidation. Use as a trend indicator, not an absolute measure.
Example: "145 public items"
Collection: Read Cargo.lock and count [[package]] section markers. This
includes all direct and transitive dependencies.
Interpretation: More dependencies = larger attack surface and more maintenance burden. Fewer dependencies = simpler dependency tree. Trend is most useful: increases may signal feature additions; decreases indicate cleanup.
Example: "98 total dependencies"
Collection: List all .rs files in crates/*/src/. Count lines in each
with wc -l. Compute arithmetic mean. Round to nearest integer.
Interpretation: Higher average module size may indicate modules are doing too much. Lower average indicates more focused modules. Ideal range is 100–300 lines per module depending on domain.
Example: "180 lines per module"
Collection: Count all items with pub visibility (functions, structs, enums,
traits). Count how many are immediately preceded by /// doc comments. Compute
percentage: (documented / total) × 100. Round to one decimal place.
Interpretation: Higher is better. 80%+ is good; <50% indicates undocumented public API. Public items without docs are harder for consumers to use correctly.
Example: "92.5% (138 of 149 public items documented)"
For each metric, compare current value to the most recent previous value:
File: .ctx/memory-bank/health-history.jsonl
Each line is a valid JSON object with timestamp and all seven metrics:
{
"timestamp": "2026-06-02T14:35:22Z",
"test_count": 272,
"clippy_warnings": 0,
"todo_density": 0.5,
"api_surface": 145,
"dependency_count": 98,
"avg_module_lines": 180,
"doc_coverage": 92.5
}
Markdown table showing current metrics, previous (if available), and trend:
## Codebase Health Scorecard
Generated: 2026-06-02 14:35:22 UTC
Workspace: godmode
| Metric | Current | Previous | Trend |
| --------------- | ------- | -------- | ----- |
| Tests | 272 | 270 | ↑ |
| Clippy warnings | 0 | 0 | → |
| TODO density | 0.5/1k | 0.6/1k | ↑ |
| Public API | 145 | 142 | → |
| Dependencies | 98 | 100 | ↑ |
| Avg module | 180 | 182 | ↑ |
| Doc coverage | 92.5% | 91.0% | ↑ |
### Summary
- **Improving**: 5 metrics
- **Stable**: 2 metrics
- **Degraded**: 0 metrics
### Health Grade: A
Criteria:
- A: test_count ≥ 200, clippy_warnings == 0, doc_coverage > 80%
- B: test_count ≥ 100, no severe clippy issues
- C: otherwise
- Subtract one grade if doc_coverage < 50% or todo_density > 2/1k
cargo-tarpaulin or cargo-llvm-cov
for precise code coverage metrics.Use these metrics for trend detection and relative comparison, not absolute quality judgment.
health-score-agent.md — invokes this skill to measure and reportCLAUDE.md — build and test conventions for collecting accurate countsAudit godmode skills, agents, and plugin files for internal consistency, broken references, stale commands, and cross-skill contradictions. Use when asked to "introspect", "audit the skills", "review godmode", or after adding new skills.
Use at the start of every conversation to orient to available skills and workspace rules. Replaces superpowers entirely. Triggers on session start, "/godmode", or "what skills do you have".
Generate and maintain a `.ctx/godmode/memory-bank/` directory that captures project context backed by source code. The memory bank is injected into prompts via lifecycle hooks and updated incrementally as work progresses. Use when starting a new project, onboarding to an unfamiliar codebase, or when context drift is detected.
Patterns and techniques for adding governance, safety, and trust controls to AI agent systems in Rust. Use this skill when building agents that call external tools, implementing policy-based access controls, adding semantic intent classification to detect dangerous prompts, creating trust scoring systems for multi-agent workflows, building audit trails, or enforcing rate limits and content filters. Covers policy composition, tool wrappers, trust decay, and JSONL audit trails — all in Rust.
Parse git history into structured changelogs. Use to generate release notes, audit commit conventions before tagging, or integrate with `godmode release` workflow.
Dead code detector for Rust workspaces. Finds unused public API surface, orphaned test helpers, stale feature flags, and plugin artifacts referencing removed CLI subcommands. Cross-references pub exports against call sites across the workspace.