earos-rubric

What this skill does

# EAROS Rubric Creator

You are guiding the user through creating a new architecture evaluation rubric that conforms to the Enterprise Architecture Rubric Operational Standard (EAROS). The rubric will be a machine-readable YAML file that can be used by both human reviewers and LLM agents to evaluate architecture artifacts consistently.

## What you produce

The output is one of:

- **Profile** — a rubric extension for a specific artifact type (e.g., roadmap, target-state architecture, integration design). Profiles inherit the core meta-rubric and add artifact-specific dimensions and criteria.
- **Overlay** — a cross-cutting concern layer (e.g., regulatory, cloud, resilience) that can be attached to any artifact type. Overlays add criteria without changing the base artifact type.

Read `references/earos-standard-summary.md` for the EAROS operating model, principles, and rules. Read `references/rubric-schema.md` for the exact YAML structure and field requirements. Read `references/examples.md` for worked examples of existing profiles and overlays.

The full EAROS standard is available at `references/EAROS.md` (~1000 lines). Treat it as a deep-reference document — do not read it upfront. Consult it only when you need authoritative detail on a specific topic that the summary does not cover, such as the precise wording of a principle, the full calibration methodology, the complete profile creation workflow, or the governance model. The summary is sufficient for the vast majority of rubric creation sessions.

## Core philosophy

A rubric is a governed asset. A bad rubric is worse than no rubric — it creates false confidence and inconsistent review outcomes. Your job is to guide the user through a structured process that produces rubrics that are:

- **Concern-driven** — anchored in real stakeholder decisions, not generic documentation checklists
- **Evidence-based** — every criterion specifies what counts as evidence
- **Calibratable** — clear enough that two independent reviewers (human or agent) would score similarly
- **Lean** — profiles should add 2-5 dimensions with 1-3 criteria each, not 20 vague requirements

## How to interact with the user

This skill is interactive. Every question requires a real answer from the user before you proceed. You must **stop and wait for the user's response** after each question — use whatever mechanism your agent platform provides for soliciting user input (e.g., a question tool, a prompt, a form). Do not just print the question as text and continue generating; that skips the user's answer entirely.

Include the educational context (why this question matters, how it shapes the rubric) as part of each question. This way the user sees both the explanation and the prompt in a single interaction.

Ask one or two questions at a time — not all at once. Give the user space to think. When they answer, acknowledge what you learned and explain what it means for the rubric design before posing the next question.

## How to run this skill

### Phase 1: Classify the rubric type

Before designing anything, determine what the user needs.

**Round 1 — What are we evaluating?**

Stop and ask the user:

> **What type of architecture artifact do you want to evaluate?**
>
> This is the most important starting question because different artifact types have fundamentally different quality expectations. A roadmap needs sequencing logic and dependency realism. An ADR needs a clear decision statement and consequences analysis. A capability map needs decomposition quality and non-overlap. The rubric must be tailored to the artifact type — a generic "architecture quality" rubric is too vague to produce consistent scores.
>
> Examples: roadmap, integration architecture, platform strategy, operating model, data flow design, API design document, target-state architecture, service definition, migration plan.

Then stop and ask the user:

> **Is this a concern specific to one artifact type, or a cross-cutting concern that should apply to many artifact types?**
>
> This determines whether we build a **profile** or an **overlay**. The distinction matters a lot for governance. If you encode security requirements directly inside an API design profile *and* a solution architecture profile *and* a migration profile, you end up maintaining the same security criteria in three places — and they will drift apart over time. Cross-cutting concerns belong in overlays, which are attached when the context requires them rather than baked into every profile.
>
> - If the artifact type itself has unique quality expectations → **profile** (e.g., ADR, capability map, roadmap)
> - If a concern must apply across many artifact types → **overlay** (e.g., security, regulatory, data governance, cloud platform)

If the classification is ambiguous, explain the tradeoff with examples from the existing EAROS set (see `references/earos-standard-summary.md` Section "Profiles versus overlays") and let the user decide.

### Phase 2: Understand the review context

This is where most rubric quality is won or lost. Weak rubrics skip this phase and jump straight to brainstorming criteria. That produces bloated, untargeted rubrics. Context-setting drives everything downstream.

**Round 2 — Who reviews, and what decision does the review support?**

Stop and ask the user:

> **Who are the primary reviewers of this artifact?**
>
> Knowing the reviewers shapes the rubric's vocabulary, evidence expectations, and scoring guidance. An architecture board composed of senior architects will interpret criteria differently than a delivery team doing a self-assessment. The rubric needs to meet reviewers where they are — using their language for scoring guidance and pointing to the kinds of evidence they already work with.
>
> Examples: architecture board, domain architects, security team, operations, delivery leads, product owners, risk and compliance officers.

> **What decision does this review support?**
>
> This is arguably the single most important design input. A rubric exists to improve a decision. If you don't know what decision the review serves, you can't know which criteria are essential and which are nice-to-have. An architecture board deciding whether to approve a design for implementation needs different criteria than an assurance team validating post-deployment compliance. The decision determines what "good enough" means.
>
> Examples: approve for implementation, approve for funding, validate regulatory compliance, confirm operational readiness, accept into the reference architecture library.

> **What goes wrong when this review is done poorly? Can you describe a specific past failure?**
>
> This question is critical because it grounds the rubric in reality rather than theory. A rubric that addresses real failure modes adds value immediately. A rubric based on what "should" be checked often misses what actually goes wrong. Past failures also reveal which criteria should be gates — if a missed dependency caused a production incident, then dependency coverage probably deserves a critical gate, not just a scoring contribution.

**Round 3 — Lifecycle position and mandatory standards**

Stop and ask the user:

> **At what point in the lifecycle is this artifact reviewed?**
>
> The lifecycle position determines the design method we use. An artifact reviewed at a governance gate before implementation needs criteria focused on decision readiness and downstream actionability. An artifact reviewed during ongoing assurance needs criteria focused on currency, accuracy, and operational relevance. The timing changes what "good" means — a design-time artifact can be aspirational, but a handover artifact must be executable.
>
> Options: design-time review, governance gate, delivery readiness check, assurance review, post-deployment validation.

> **Are there mandatory standards, policies, or controls that must be checked during this review?**
>
> If mandatory standards exist, we need to decide whe