he-skill-repo/he-maintainer/references/scoring-rubric.md

Harness Health Scoring Rubric

Use this when asked to audit or score a repository's harness quality.

Dimensions

1. Project map clarity

• strong: key directories, entrypoints, and subsystem boundaries are documented and current
• partial: some structure is documented but stale, shallow, or incomplete
• weak: little or no useful repo map exists

2. Validation commands

• strong: build, test, lint, typecheck, or equivalent validation commands are clear and runnable
• partial: some commands exist but are incomplete, stale, or ambiguous
• weak: commands are missing, misleading, or unverified

3. Fast feedback

• strong: targeted package-, crate-, app-, or feature-scoped checks exist
• partial: only slower validation paths exist, or quick checks are incomplete
• weak: no obvious fast validation path exists

4. Task contract quality

• strong: reusable task contracts or templates define scope, constraints, validation, and acceptance criteria
• partial: ad hoc task instructions exist but are inconsistent or underspecified
• weak: every task must be reinvented from scratch

5. Guardrails

• strong: high-risk areas, forbidden changes, generated-file boundaries, and slow validations are explicit
• partial: some constraints exist but are vague or fragmented
• weak: almost no meaningful constraints are documented

6. Architecture decision durability

• strong: durable decisions are easy to find in ADRs, accepted docs, or equivalent records
• partial: some decisions are documented but scattered, stale, or inconsistently applied
• weak: important architecture or workflow decisions must be rediscovered from chat or code archaeology

7. Failure feedback loop quality

• strong: repeated AI or implementation failures are converted into durable harness, validation, or CI improvements
• partial: some failures are documented, but fixes remain mostly conversational or one-off
• weak: the same classes of failure recur without system updates

8. Doc-code alignment

• strong: harness docs match the current repo layout, commands, and constraints
• partial: mixed accuracy with some stale sections
• weak: obviously stale or misleading guidance dominates

Output format

Keep the score compact. Example:

• project map clarity: partial
• validation commands: strong
• fast feedback: weak
• task contract quality: weak
• guardrails: partial
• architecture decision durability: weak
• failure feedback loop quality: weak
• doc-code alignment: partial

Top priorities:

1. Add a targeted validation command for the touched package or crate
2. Record one durable architecture decision in an ADR or accepted design note
3. Turn the most common repeated failure into a task-contract, guardrail, or CI rule