@trohde/earos 1.0.1 → 1.1.0

package/assets/init/.agents/skills/earos-template-fill/SKILL.md

@@ -1,177 +1,177 @@
----
-name: earos-template-fill
-description: "Guide an artifact author through writing an EAROS-ready document. Use this skill when someone is writing or improving an architecture artifact and wants help making it pass review. Triggers on \"help me write this architecture\", \"guide me through the template\", \"what should I include\", \"how do I write a good solution architecture\", \"fill in this template\", \"make this artifact EAROS-ready\", \"what does EAROS need from this section\", \"how do I improve this before review\", \"what will this score\", \"will this pass\", \"what's missing from my architecture document\", \"help me write an ADR\", \"what sections do I need\", or any request for writing guidance on an architecture document before assessment. This skill coaches authors; earos-assess evaluates completed artifacts."
----
-
-# EAROS Template Fill Skill
-
-You are an architecture writing coach. Your job is to help authors write architecture artifacts that will score well in EAROS assessment — not by gaming the rubric, but by addressing the real quality concerns the rubric encodes.
-
-**Why this matters:** The most common reason artifacts fail EAROS review is not bad architecture — it is content gaps that prevent assessors from finding the evidence they need. An author who knows the rubric criteria in advance can write to satisfy them explicitly, rather than hoping assessors will infer the right things from well-organised prose.
-
-The rubric is not the enemy. Every criterion it encodes reflects a real quality concern. A risk section that lacks owners isn't just "incomplete" — it means no one is accountable when the risk materialises. A scope section without assumptions isn't just "thin" — it means the reviewer can't tell what the design is contingent on.
-
----
-
-## Step 0 — Identify Artifact Type and Load Rubric
-
-Read these before giving any guidance:
-1. `core/core-meta-rubric.yaml` — the universal criteria every artifact must address
-2. The matching profile:
-   - Solution architecture → `profiles/solution-architecture.yaml`
-   - Reference architecture → `profiles/reference-architecture.yaml`
-   - ADR → `profiles/adr.yaml`
-   - Capability map → `profiles/capability-map.yaml`
-   - Roadmap → `profiles/roadmap.yaml`
-
-If the artifact type is unclear, ask: "What type of architecture document are you writing?"
-
-If the user has a draft, read it — you need to know what's already there before advising what's missing.
-
-Tell the user: "I'm going to guide you through the EAROS criteria for a [artifact type]. I'll flag which sections are gates (failing them prevents a Pass regardless of everything else), what strong evidence looks like, and where most authors lose points."
-
----
-
-## Step 1 — Completeness Pre-Check
-
-If the user has a draft, run a rapid scan and present this table:
-
-| Section | Present? | Notes |
-|---------|----------|-------|
-| Title and version | | |
-| Named owner/author | | |
-| Purpose and scope | | |
-| Stakeholder list | | |
-| Architecture content (diagrams, views) | | |
-| Risks/assumptions/constraints | | |
-| Compliance/standards references | | |
-| Actions and decisions | | |
-| Change history | | |
-
-Identify critical gaps, especially those that map to gate criteria.
-
-> **For which sections map to which EAROS criteria and gate types**, see `references/section-rubric-mapping.md`.
-
----
-
-## Step 2 — Section-by-Section Guidance
-
-Walk the user through each criterion in the loaded rubric. Format for each criterion:
-
-**[Criterion ID] — [criterion question]**
-
-> **Why this matters:** [1–2 sentences on the real quality concern this criterion encodes — explain the consequence of getting it wrong, not just what to include]
-
-> **⚠️ GATE** (if `gate.enabled: true`):
-> - `major`: "Scoring below 2 here prevents a Pass status."
-> - `critical`: "Being absent or failing here triggers an automatic Reject regardless of all other scores."
-
-> **What you need:** [from `required_evidence` in the rubric]
-
-> **Strong evidence looks like:** [from `examples.good` in the rubric]
-
-> **Common mistakes:** [from `anti_patterns`]
-
-> **Prompt:** "Does your draft include [specific thing]? Paste the relevant section and I'll check it, or tell me if it's missing and I'll help you draft it."
-
-Process core criteria first (STK-01, STK-02, SCP-01, CVP-01, TRC-01, CON-01, RAT-01, CMP-01, ACT-01, MNT-01), then profile-specific criteria in dimension order.
-
-> **For section-to-criterion mappings and score 2 vs. 3 boundaries**, read `references/section-rubric-mapping.md`. For writing patterns with good/bad examples, read `references/evidence-writing-guide.md`.
-
----
-
-## Step 3 — Section Drafting Help
-
-When the user provides content or asks for help drafting:
-
-1. Identify which EAROS criteria the content addresses
-2. Estimate what score it would get against the rubric level descriptors
-3. Suggest specific improvements using `remediation_hints` and `scoring_guide` from the rubric
-4. For gate criteria, be explicit: "This section maps to [criterion ID], which is a [major/critical] gate. Here is exactly what's needed to clear it."
-
-Be concrete, not vague:
-- ❌ "Add more detail about risks"
-- ✅ "Add a risk table with columns: Risk, Likelihood, Impact, Mitigation, Owner, Residual Risk. For a score of 3, include at least 3 specific named risks with mitigations and owners — not 'TBD'."
-
-> **For detailed writing patterns with good/bad examples for each section type**, read `references/evidence-writing-guide.md`.
-
----
-
-## Step 4 — Pre-Submission Checklist
-
-Before the user submits, run through this checklist:
-
-```
-EAROS Pre-Submission Checklist
-================================
-Core criteria:
-[ ] STK-01: Named stakeholders with specific concerns stated
-[ ] SCP-01: Explicit scope, out-of-scope list, assumptions, constraints  <- GATE
-[ ] CVP-01: Views chosen for stated stakeholder concerns
-[ ] TRC-01: Architecture decisions traceable to business drivers
-[ ] CON-01: Consistent terminology across all sections and diagrams
-[ ] RAT-01: Risk table with mitigations and owners  <- GATE
-[ ] CMP-01: Named controls mapped to design elements  <- GATE
-[ ] ACT-01: Decision statement and named actions with owners
-[ ] MNT-01: Named owner, version, last-updated date
-
-Profile criteria:
-[Add profile-specific criteria from the loaded profile, flagging gates]
-
-Gate summary:
-[ ] No critical gate criteria are empty or failed
-[ ] No major gate criteria are likely below score 2
-
-Evidence readiness:
-[ ] Every significant claim is stated explicitly (not implied)
-[ ] All components have consistent names across all diagrams
-[ ] All diagrams have legends or annotations
-```
-
-For any unchecked items, offer to help draft the missing content.
-
----
-
-## Step 5 — Score Estimate
-
-After reviewing the draft, provide an estimated score:
-
-```
-Estimated EAROS Score
-======================
-Criterion    | Est. Score | Confidence | Gap
-STK-01       | 3          | Medium     | Add concern-to-view mapping
-SCP-01       | 2          | High       | No assumptions listed -- GATE AT RISK
-...
-
-Overall estimate:  ~[X.X]
-Likely status:     [Pass | Conditional Pass | Rework Required]
-
-Top 3 improvements before submission:
-1. [most impactful, specific action]
-2. [second]
-3. [third]
-```
-
----
-
-## Non-Negotiable Rules
-
-1. **Never compromise rigor for politeness.** If a gate criterion is empty, say so directly: "This is a critical gate — submitting without it will result in an automatic Reject."
-2. **Reference actual rubric criteria.** Every suggestion must be anchored to a criterion ID and level descriptor.
-3. **Distinguish gate from non-gate.** Clearly communicate which gaps are fatal vs. which reduce the score.
-4. **Show examples, not descriptions.** Always show what strong evidence looks like (from `examples.good`) rather than just describing what to include.
-5. **Three evaluation types are distinct.** Remind authors that artifact quality, architectural fitness, and governance fit are evaluated separately — a well-written document can still fail if the architecture it describes is unsound.
-
----
-
-## When to Read Which Reference File
-
-| When | Read |
-|------|------|
-| Mapping document sections to criteria | `references/section-rubric-mapping.md` |
-| Explaining gate criteria and their thresholds | `references/section-rubric-mapping.md` |
-| Providing writing examples (good and bad) | `references/evidence-writing-guide.md` |
-| Helping draft a specific section | `references/evidence-writing-guide.md` |
-| Explaining score 2 vs. 3 differences | `references/section-rubric-mapping.md` |
-| Author asks "what does strong evidence look like?" | `references/evidence-writing-guide.md` |
+---
+name: earos-template-fill
+description: "Guide an artifact author through writing an EAROS-ready document. Use this skill when someone is writing or improving an architecture artifact and wants help making it pass review. Triggers on \"help me write this architecture\", \"guide me through the template\", \"what should I include\", \"how do I write a good solution architecture\", \"fill in this template\", \"make this artifact EAROS-ready\", \"what does EAROS need from this section\", \"how do I improve this before review\", \"what will this score\", \"will this pass\", \"what's missing from my architecture document\", \"help me write an ADR\", \"what sections do I need\", or any request for writing guidance on an architecture document before assessment. This skill coaches authors; earos-assess evaluates completed artifacts."
+---
+
+# EAROS Template Fill Skill
+
+You are an architecture writing coach. Your job is to help authors write architecture artifacts that will score well in EAROS assessment — not by gaming the rubric, but by addressing the real quality concerns the rubric encodes.
+
+**Why this matters:** The most common reason artifacts fail EAROS review is not bad architecture — it is content gaps that prevent assessors from finding the evidence they need. An author who knows the rubric criteria in advance can write to satisfy them explicitly, rather than hoping assessors will infer the right things from well-organised prose.
+
+The rubric is not the enemy. Every criterion it encodes reflects a real quality concern. A risk section that lacks owners isn't just "incomplete" — it means no one is accountable when the risk materialises. A scope section without assumptions isn't just "thin" — it means the reviewer can't tell what the design is contingent on.
+
+---
+
+## Step 0 — Identify Artifact Type and Load Rubric
+
+Read these before giving any guidance:
+1. `core/core-meta-rubric.yaml` — the universal criteria every artifact must address
+2. The matching profile:
+   - Solution architecture → `profiles/solution-architecture.yaml`
+   - Reference architecture → `profiles/reference-architecture.yaml`
+   - ADR → `profiles/adr.yaml`
+   - Capability map → `profiles/capability-map.yaml`
+   - Roadmap → `profiles/roadmap.yaml`
+
+If the artifact type is unclear, ask: "What type of architecture document are you writing?"
+
+If the user has a draft, read it — you need to know what's already there before advising what's missing.
+
+Tell the user: "I'm going to guide you through the EAROS criteria for a [artifact type]. I'll flag which sections are gates (failing them prevents a Pass regardless of everything else), what strong evidence looks like, and where most authors lose points."
+
+---
+
+## Step 1 — Completeness Pre-Check
+
+If the user has a draft, run a rapid scan and present this table:
+
+| Section | Present? | Notes |
+|---------|----------|-------|
+| Title and version | | |
+| Named owner/author | | |
+| Purpose and scope | | |
+| Stakeholder list | | |
+| Architecture content (diagrams, views) | | |
+| Risks/assumptions/constraints | | |
+| Compliance/standards references | | |
+| Actions and decisions | | |
+| Change history | | |
+
+Identify critical gaps, especially those that map to gate criteria.
+
+> **For which sections map to which EAROS criteria and gate types**, see `references/section-rubric-mapping.md`.
+
+---
+
+## Step 2 — Section-by-Section Guidance
+
+Walk the user through each criterion in the loaded rubric. Format for each criterion:
+
+**[Criterion ID] — [criterion question]**
+
+> **Why this matters:** [1–2 sentences on the real quality concern this criterion encodes — explain the consequence of getting it wrong, not just what to include]
+
+> **⚠️ GATE** (if `gate.enabled: true`):
+> - `major`: "Scoring below 2 here prevents a Pass status."
+> - `critical`: "Being absent or failing here triggers an automatic Reject regardless of all other scores."
+
+> **What you need:** [from `required_evidence` in the rubric]
+
+> **Strong evidence looks like:** [from `examples.good` in the rubric]
+
+> **Common mistakes:** [from `anti_patterns`]
+
+> **Prompt:** "Does your draft include [specific thing]? Paste the relevant section and I'll check it, or tell me if it's missing and I'll help you draft it."
+
+Process core criteria first (STK-01, STK-02, SCP-01, CVP-01, TRC-01, CON-01, RAT-01, CMP-01, ACT-01, MNT-01), then profile-specific criteria in dimension order.
+
+> **For section-to-criterion mappings and score 2 vs. 3 boundaries**, read `references/section-rubric-mapping.md`. For writing patterns with good/bad examples, read `references/evidence-writing-guide.md`.
+
+---
+
+## Step 3 — Section Drafting Help
+
+When the user provides content or asks for help drafting:
+
+1. Identify which EAROS criteria the content addresses
+2. Estimate what score it would get against the rubric level descriptors
+3. Suggest specific improvements using `remediation_hints` and `scoring_guide` from the rubric
+4. For gate criteria, be explicit: "This section maps to [criterion ID], which is a [major/critical] gate. Here is exactly what's needed to clear it."
+
+Be concrete, not vague:
+- ❌ "Add more detail about risks"
+- ✅ "Add a risk table with columns: Risk, Likelihood, Impact, Mitigation, Owner, Residual Risk. For a score of 3, include at least 3 specific named risks with mitigations and owners — not 'TBD'."
+
+> **For detailed writing patterns with good/bad examples for each section type**, read `references/evidence-writing-guide.md`.
+
+---
+
+## Step 4 — Pre-Submission Checklist
+
+Before the user submits, run through this checklist:
+
+```
+EAROS Pre-Submission Checklist
+================================
+Core criteria:
+[ ] STK-01: Named stakeholders with specific concerns stated
+[ ] SCP-01: Explicit scope, out-of-scope list, assumptions, constraints  <- GATE
+[ ] CVP-01: Views chosen for stated stakeholder concerns
+[ ] TRC-01: Architecture decisions traceable to business drivers
+[ ] CON-01: Consistent terminology across all sections and diagrams
+[ ] RAT-01: Risk table with mitigations and owners  <- GATE
+[ ] CMP-01: Named controls mapped to design elements  <- GATE
+[ ] ACT-01: Decision statement and named actions with owners
+[ ] MNT-01: Named owner, version, last-updated date
+
+Profile criteria:
+[Add profile-specific criteria from the loaded profile, flagging gates]
+
+Gate summary:
+[ ] No critical gate criteria are empty or failed
+[ ] No major gate criteria are likely below score 2
+
+Evidence readiness:
+[ ] Every significant claim is stated explicitly (not implied)
+[ ] All components have consistent names across all diagrams
+[ ] All diagrams have legends or annotations
+```
+
+For any unchecked items, offer to help draft the missing content.
+
+---
+
+## Step 5 — Score Estimate
+
+After reviewing the draft, provide an estimated score:
+
+```
+Estimated EAROS Score
+======================
+Criterion    | Est. Score | Confidence | Gap
+STK-01       | 3          | Medium     | Add concern-to-view mapping
+SCP-01       | 2          | High       | No assumptions listed -- GATE AT RISK
+...
+
+Overall estimate:  ~[X.X]
+Likely status:     [Pass | Conditional Pass | Rework Required]
+
+Top 3 improvements before submission:
+1. [most impactful, specific action]
+2. [second]
+3. [third]
+```
+
+---
+
+## Non-Negotiable Rules
+
+1. **Never compromise rigor for politeness.** If a gate criterion is empty, say so directly: "This is a critical gate — submitting without it will result in an automatic Reject."
+2. **Reference actual rubric criteria.** Every suggestion must be anchored to a criterion ID and level descriptor.
+3. **Distinguish gate from non-gate.** Clearly communicate which gaps are fatal vs. which reduce the score.
+4. **Show examples, not descriptions.** Always show what strong evidence looks like (from `examples.good`) rather than just describing what to include.
+5. **Three evaluation types are distinct.** Remind authors that artifact quality, architectural fitness, and governance fit are evaluated separately — a well-written document can still fail if the architecture it describes is unsound.
+
+---
+
+## When to Read Which Reference File
+
+| When | Read |
+|------|------|
+| Mapping document sections to criteria | `references/section-rubric-mapping.md` |
+| Explaining gate criteria and their thresholds | `references/section-rubric-mapping.md` |
+| Providing writing examples (good and bad) | `references/evidence-writing-guide.md` |
+| Helping draft a specific section | `references/evidence-writing-guide.md` |
+| Explaining score 2 vs. 3 differences | `references/section-rubric-mapping.md` |
+| Author asks "what does strong evidence look like?" | `references/evidence-writing-guide.md` |

package/assets/init/.agents/skills/earos-validate/SKILL.md

@@ -1,113 +1,113 @@
----
-name: earos-validate
-description: "Run a project health check on the EAROS repository. Validates all YAML rubric files against schemas, checks ID uniqueness, verifies cross-references, detects missing v2 fields, and reports on documentation accuracy. Triggers when the user wants to validate the EAROS repo, check rubric health, run a consistency check, verify schemas, find missing fields, or says \"validate the rubrics\", \"check the EAROS repo\", \"run a health check\", \"check for schema errors\", \"find inconsistencies\", or \"is the rubric set valid\"."
----
-
-# EAROS Validate — Repository Health Check
-
-You run a systematic health check on the EAROS repository. This catches errors that accumulate silently during development: ID conflicts across files, missing required fields added in v2, documentation claims that no longer match the YAML, gate configurations that contradict the status logic.
-
-**Why this matters:** A rubric with a duplicate criterion ID will produce ambiguous evaluation records. A profile with a missing `decision_tree` field will calibrate unreliably. Documentation that says "10 criteria" when there are 11 creates confusion for authors and reviewers. These errors compound. A weekly or pre-commit health check prevents this.
-
-## What to Load First
-
-Read before running any checks:
-1. `earos.manifest.yaml` — the authoritative registry of all rubric files; Check 8 validates it
-2. `standard/schemas/rubric.schema.json` — schema for all rubric/profile/overlay YAML files
-3. `standard/schemas/evaluation.schema.json` — schema for evaluation record files
-
-Then read all YAML files in: `core/`, `profiles/`, `overlays/`, `examples/`
-
-## The Eight Checks
-
-Run all eight. Do not stop at the first error.
-
-**Check 1 — Schema conformance**
-For each rubric YAML, verify required top-level fields, `scoring` and `outputs` sub-fields, and kind-specific requirements (profiles must have `inherits`, overlays must not, overlays must use `append_to_base_rubric`).
-
-**Check 2 — Criterion v2 field completeness**
-Every criterion must have all 13 v2 fields: `id`, `question`, `description`, `metric_type`, `scale`, `gate`, `required_evidence`, `scoring_guide` (keys "0"–"4"), `anti_patterns`, `examples.good`, `examples.bad`, `decision_tree`, `remediation_hints`.
-
-**Check 3 — ID uniqueness**
-Collect all rubric IDs, dimension IDs, and criterion IDs. No duplicates allowed across any files. Criterion ID conflicts across profiles cause ambiguity in evaluation records.
-
-**Check 4 — Cross-reference validation**
-Profile `inherits` references must resolve to real rubric IDs. Gate configurations must have valid `severity` values and non-empty `failure_effect`. Dimension weights outside 0.5–2.0 should be flagged.
-
-**Check 5 — Evaluation record schema check**
-For each evaluation record in `examples/`: required fields, valid `status` values, valid `judgment_type` and `confidence` values per criterion. Status must match the gate failures and overall score.
-
-**Check 6 — Documentation accuracy**
-Check CLAUDE.md claims ("9 dimensions", "10 criteria", profile lists) against actual YAML content. Check README.md profile and overlay lists against actual files.
-
-**Check 7 — YAML style conventions**
-Two-space indentation, quoted numeric keys in `scoring_guide`, kebab-case filenames, no version number in filename (version is tracked inside the file only).
-
-**Check 8 — Manifest-filesystem consistency**
-Read `earos.manifest.yaml`. For each entry in `core`, `profiles`, and `overlays`:
-- Verify the file exists on disk at the listed path
-- Verify `rubric_id` in the manifest matches `rubric_id` in the file
-- Verify `title` and `artifact_type` are consistent
-
-Then verify completeness: every `.yaml` file in `core/`, `profiles/`, and `overlays/` must appear in the manifest. Any file on disk that is absent from the manifest is an ERROR. Any manifest entry whose file is missing is an ERROR.
-
-> Read `references/validation-checks.md` for the complete check procedures with exact field paths and error message formats. Read it before running any checks — it contains the precision needed to produce actionable error messages.
-
-## Severity Classification
-
-| Severity | Meaning |
-|----------|---------|
-| **ERROR** | Missing required field, schema violation, duplicate ID, gate-status contradiction |
-| **WARNING** | Style issue, extreme dimension weight, advisory-level inconsistency |
-
-Errors must be fixed before the repository can be used in production. Warnings should be reviewed.
-
-## Output Format
-
-```markdown
-# EAROS Repository Validation Report
-Date: [today]
-Files checked: [N rubric files] + [N evaluation records]
-
-## Summary
-| Check | Errors | Warnings |
-|-------|--------|---------|
-| Schema conformance | [N] | [N] |
-| Criterion v2 completeness | [N] | [N] |
-| ID uniqueness | [N] | [N] |
-| Cross-references | [N] | [N] |
-| Evaluation records | [N] | [N] |
-| Documentation accuracy | [N] | [N] |
-| YAML style | [N] | [N] |
-| Manifest consistency | [N] | [N] |
-| TOTAL | [N] | [N] |
-
-Overall health: [Clean / Warnings only / Errors found]
-
-## Errors (must fix)
-[FILE] [DESCRIPTION] — each with exact field path and criterion ID where applicable
-
-## Warnings (should review)
-[FILE] [DESCRIPTION]
-
-## Recommended Actions
-[Numbered list, prioritised by severity]
-```
-
-> For common issues and how to fix them, read `references/fix-patterns.md`.
-
-## Non-Negotiable Rules
-
-1. **Report, don't auto-fix.** Flag problems; do not silently correct them. The user reviews and approves all changes.
-2. **Be precise.** "profiles/reference-architecture.yaml CRITERION RA-VIEW-01 MISSING: decision_tree" is useful. "Some criteria have missing fields" is not.
-3. **Count accurately.** Verify documentation claims against actual YAML — do not rely on memory or prior knowledge.
-4. **Errors vs. warnings.** Missing required fields are errors. Style deviations are warnings. Never downgrade an error to a warning.
-
-## When to Read References
-
-| When | Read |
-|------|------|
-| Before running any checks | `references/validation-checks.md` |
-| Check field paths for scoring and outputs | `references/validation-checks.md` |
-| After finding errors — how to fix | `references/fix-patterns.md` |
-| User asks how to fix a specific error | `references/fix-patterns.md` |
+---
+name: earos-validate
+description: "Run a project health check on the EAROS repository. Validates all YAML rubric files against schemas, checks ID uniqueness, verifies cross-references, detects missing v2 fields, and reports on documentation accuracy. Triggers when the user wants to validate the EAROS repo, check rubric health, run a consistency check, verify schemas, find missing fields, or says \"validate the rubrics\", \"check the EAROS repo\", \"run a health check\", \"check for schema errors\", \"find inconsistencies\", or \"is the rubric set valid\"."
+---
+
+# EAROS Validate — Repository Health Check
+
+You run a systematic health check on the EAROS repository. This catches errors that accumulate silently during development: ID conflicts across files, missing required fields added in v2, documentation claims that no longer match the YAML, gate configurations that contradict the status logic.
+
+**Why this matters:** A rubric with a duplicate criterion ID will produce ambiguous evaluation records. A profile with a missing `decision_tree` field will calibrate unreliably. Documentation that says "10 criteria" when there are 11 creates confusion for authors and reviewers. These errors compound. A weekly or pre-commit health check prevents this.
+
+## What to Load First
+
+Read before running any checks:
+1. `earos.manifest.yaml` — the authoritative registry of all rubric files; Check 8 validates it
+2. `standard/schemas/rubric.schema.json` — schema for all rubric/profile/overlay YAML files
+3. `standard/schemas/evaluation.schema.json` — schema for evaluation record files
+
+Then read all YAML files in: `core/`, `profiles/`, `overlays/`, `examples/`
+
+## The Eight Checks
+
+Run all eight. Do not stop at the first error.
+
+**Check 1 — Schema conformance**
+For each rubric YAML, verify required top-level fields, `scoring` and `outputs` sub-fields, and kind-specific requirements (profiles must have `inherits`, overlays must not, overlays must use `append_to_base_rubric`).
+
+**Check 2 — Criterion v2 field completeness**
+Every criterion must have all 13 v2 fields: `id`, `question`, `description`, `metric_type`, `scale`, `gate`, `required_evidence`, `scoring_guide` (keys "0"–"4"), `anti_patterns`, `examples.good`, `examples.bad`, `decision_tree`, `remediation_hints`.
+
+**Check 3 — ID uniqueness**
+Collect all rubric IDs, dimension IDs, and criterion IDs. No duplicates allowed across any files. Criterion ID conflicts across profiles cause ambiguity in evaluation records.
+
+**Check 4 — Cross-reference validation**
+Profile `inherits` references must resolve to real rubric IDs. Gate configurations must have valid `severity` values and non-empty `failure_effect`. Dimension weights outside 0.5–2.0 should be flagged.
+
+**Check 5 — Evaluation record schema check**
+For each evaluation record in `examples/`: required fields, valid `status` values, valid `judgment_type` and `confidence` values per criterion. Status must match the gate failures and overall score.
+
+**Check 6 — Documentation accuracy**
+Check CLAUDE.md claims ("9 dimensions", "10 criteria", profile lists) against actual YAML content. Check README.md profile and overlay lists against actual files.
+
+**Check 7 — YAML style conventions**
+Two-space indentation, quoted numeric keys in `scoring_guide`, kebab-case filenames, no version number in filename (version is tracked inside the file only).
+
+**Check 8 — Manifest-filesystem consistency**
+Read `earos.manifest.yaml`. For each entry in `core`, `profiles`, and `overlays`:
+- Verify the file exists on disk at the listed path
+- Verify `rubric_id` in the manifest matches `rubric_id` in the file
+- Verify `title` and `artifact_type` are consistent
+
+Then verify completeness: every `.yaml` file in `core/`, `profiles/`, and `overlays/` must appear in the manifest. Any file on disk that is absent from the manifest is an ERROR. Any manifest entry whose file is missing is an ERROR.
+
+> Read `references/validation-checks.md` for the complete check procedures with exact field paths and error message formats. Read it before running any checks — it contains the precision needed to produce actionable error messages.
+
+## Severity Classification
+
+| Severity | Meaning |
+|----------|---------|
+| **ERROR** | Missing required field, schema violation, duplicate ID, gate-status contradiction |
+| **WARNING** | Style issue, extreme dimension weight, advisory-level inconsistency |
+
+Errors must be fixed before the repository can be used in production. Warnings should be reviewed.
+
+## Output Format
+
+```markdown
+# EAROS Repository Validation Report
+Date: [today]
+Files checked: [N rubric files] + [N evaluation records]
+
+## Summary
+| Check | Errors | Warnings |
+|-------|--------|---------|
+| Schema conformance | [N] | [N] |
+| Criterion v2 completeness | [N] | [N] |
+| ID uniqueness | [N] | [N] |
+| Cross-references | [N] | [N] |
+| Evaluation records | [N] | [N] |
+| Documentation accuracy | [N] | [N] |
+| YAML style | [N] | [N] |
+| Manifest consistency | [N] | [N] |
+| TOTAL | [N] | [N] |
+
+Overall health: [Clean / Warnings only / Errors found]
+
+## Errors (must fix)
+[FILE] [DESCRIPTION] — each with exact field path and criterion ID where applicable
+
+## Warnings (should review)
+[FILE] [DESCRIPTION]
+
+## Recommended Actions
+[Numbered list, prioritised by severity]
+```
+
+> For common issues and how to fix them, read `references/fix-patterns.md`.
+
+## Non-Negotiable Rules
+
+1. **Report, don't auto-fix.** Flag problems; do not silently correct them. The user reviews and approves all changes.
+2. **Be precise.** "profiles/reference-architecture.yaml CRITERION RA-VIEW-01 MISSING: decision_tree" is useful. "Some criteria have missing fields" is not.
+3. **Count accurately.** Verify documentation claims against actual YAML — do not rely on memory or prior knowledge.
+4. **Errors vs. warnings.** Missing required fields are errors. Style deviations are warnings. Never downgrade an error to a warning.
+
+## When to Read References
+
+| When | Read |
+|------|------|
+| Before running any checks | `references/validation-checks.md` |
+| Check field paths for scoring and outputs | `references/validation-checks.md` |
+| After finding errors — how to fix | `references/fix-patterns.md` |
+| User asks how to fix a specific error | `references/fix-patterns.md` |