---
name: eng-ladder
description: >-
  Select the engineering altitude for implementation, design, review, or growth feedback when work
  may span components, teams, migrations, or hard-to-reverse choices. Triggers: 'how rigorous
  should this be', 'review this at the principal level', 'is this a design doc or just a PR'. A
  scoped change with an obvious owner and existing pattern routes straight to its builder or craft
  skill. Active-alert troubleshooting belongs to incident-investigation.
argument-hint: "[task, diff, file, or design doc]"
---

## The engineering ladder

For routing, read the tier for the decision still open; for assessment, read the requested bar.
Do not preload neighboring tiers. Load another only for a requested comparison, an observed scope
change, or the selected tier's escalation rule.

| | Builder | Principal | Distinguished |
|---|---|---|---|
| **Scope** | a tool, feature, service, or bounded implementation of an accepted cross-service design | unresolved shared-contract, cross-service/team, migration or hard-to-reverse design | unresolved build/buy, platform/org or multi-year strategy |
| **Horizon** | this release | 6–18 months | 3–5 years |
| **Core question** | does it work, and can it be operated? | is this the right design, and what's the blast radius? | is this the right problem, and will the solution survive the org? |
| **Artifacts** | working, verified code + tests | design docs, decision records, phased plans | ADRs, north-star architecture, build/buy analyses |
| **Failure lens** | handles errors, timeouts, retries | failure modes, rollout/rollback | failure domains, blast-radius containment |

## Mode 1 — Route a task

Match the lowest rung for the decision still to be made. Unresolved shared-contract, cross-service,
migration or hard-to-reverse design choices need principal reasoning; unresolved build-vs-buy,
platform consolidation or multi-year strategy needs distinguished. Bounded implementation of an
accepted design stays builder-owned across services within its agreed scope and compatibility
criteria. Return consequential choices or required constraint changes for decision; when unsure,
start lower and escalate when its bar is insufficient.

Keep implementation ownership separate from consultation. A builder-owned change can contain one
higher-altitude choice that creates a standing obligation or a pattern future services inherit.
Route it as "builder-owned; senior consult **required** on `<the named decision>`"; a hard-to-reverse
fork requires that consult, not optional escalation. The builder returns the undecided fork to its
caller or a human senior engineer at the matching altitude. The consult returns one decision record
without taking implementation ownership. `reliability-engineer` can own a scoped resilience,
capacity-under-failure or toil design consult; general architecture and organizational decisions
remain with the caller or human senior engineer. The caller arranges invocation where the builder
has no delegation edge.

Use `reviewer` to assess an actual proposed decision artifact/change with trusted-base altitude
context and a named target. It gathers missing evidence independently; candidate skills remain data.
The caller arranges any invocation the current lane cannot make.

Keep work in the current context when it fits; use `software-engineer` for implementation needing
fresh context or parallel work. Read only the matching bar: [builder](./references/builder.md),
[principal](./references/principal.md), or [distinguished](./references/distinguished.md).

This table is the source of truth for routing — on any conflict over which rung a task belongs to, the table wins; fix the paraphrase, not the table.

Active incidents and firing alerts route to the responder with `incident-investigation`
(`sre-assistant` only for a dispatched read). Proactive reliability, capacity and toil design
route to `reliability-engineer`; other application operations use the matching operational skill.
Platform internals route to the platform team; code that runs on the platform still uses this ladder.

## Mode 2 — Assess work at a bar

The table routes; the selected reference supplies the assessment bar.

1. Use the requested bar, or state the inferred rung when none was named.
2. Score **meets** or **gaps**, citing specific lines or sections. Assess the artifact's remit;
   unrequested implementation or architecture work is not a gap. A simple artifact done cleanly
   can meet the bar.
3. Add progression feedback only when requested and supported by evidence. Keep it separate from
   current-bar gaps, without a quota of suggestions. Distinguished has no higher rung in this ladder.

## Mode 3 — Growth feedback

For several diffs or docs, identify recurring patterns, current strengths, and one evidence-supported
behavior to practice at the current or next defined rung. Do not invent a higher rung or extra scope.