@nurix/etna 0.18.0 → 0.18.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -5
- package/data/harness-index.json +1 -1
- package/data/harnesses/code/CLAUDE.md +7 -18
- package/data/harnesses/code/agents/brainstorm.md +3 -3
- package/data/harnesses/code/agents/change-review.md +13 -10
- package/data/harnesses/code/agents/harness-manager.md +15 -15
- package/data/harnesses/code/agents/maintenance.md +10 -3
- package/data/harnesses/code/agents/performance-review.md +5 -0
- package/data/harnesses/code/harness.json +1 -1
- package/data/harnesses/code/rules/general.md +40 -36
- package/data/harnesses/code/skills/boundary/SKILL.md +15 -42
- package/data/harnesses/code/skills/boundary/references/boundary-taxonomy.md +366 -304
- package/data/harnesses/code/skills/brainstorm/README.md +9 -9
- package/data/harnesses/code/skills/brainstorm/SKILL.md +15 -15
- package/data/harnesses/code/skills/brainstorm/harvest.md +2 -2
- package/data/harnesses/code/skills/brainstorm/templates/backlog.md +2 -2
- package/data/harnesses/code/skills/brainstorm/templates/build.md +6 -6
- package/data/harnesses/code/skills/brainstorm/templates/decisions.md +3 -3
- package/data/harnesses/code/skills/brainstorm/templates/doctrine.md +2 -2
- package/data/harnesses/code/skills/brainstorm/templates/domain-model.md +2 -2
- package/data/harnesses/code/skills/brainstorm/templates/glossary.md +2 -1
- package/data/harnesses/code/skills/brainstorm/templates/non-goals.md +3 -7
- package/data/harnesses/code/skills/brainstorm/templates/questions.md +6 -5
- package/data/harnesses/code/skills/brainstorm/templates/state.md +1 -8
- package/data/harnesses/code/skills/brainstorm/templates/tech.md +6 -6
- package/data/harnesses/code/skills/brainstorm/templates/thesis.md +2 -2
- package/data/harnesses/code/skills/distiller/SKILL.md +48 -177
- package/data/harnesses/code/skills/distiller/references/docs-mode.md +116 -343
- package/data/harnesses/code/skills/distiller/references/method.md +37 -109
- package/data/harnesses/code/skills/documentation/SKILL.md +9 -6
- package/data/harnesses/code/skills/documentation/references/examples.md +30 -61
- package/data/harnesses/code/skills/documentation/references/style-guide.md +59 -62
- package/data/harnesses/code/skills/documentation/references/templates.md +25 -33
- package/data/harnesses/code/skills/workflow-mapper/SKILL.md +32 -11
- package/data/harnesses/code/skills/workflow-mapper/references/patterns.md +1 -1
- package/data/harnesses/code-fable/CLAUDE.md +12 -23
- package/data/harnesses/code-fable/agents/brainstorm.md +3 -3
- package/data/harnesses/code-fable/agents/change-review.md +13 -10
- package/data/harnesses/code-fable/agents/harness-manager.md +15 -15
- package/data/harnesses/code-fable/agents/maintenance.md +10 -3
- package/data/harnesses/code-fable/agents/performance-review.md +5 -0
- package/data/harnesses/code-fable/harness.json +1 -1
- package/data/harnesses/code-fable/rules/general.md +40 -36
- package/data/harnesses/code-fable/skills/boundary/SKILL.md +15 -42
- package/data/harnesses/code-fable/skills/boundary/references/boundary-taxonomy.md +366 -304
- package/data/harnesses/code-fable/skills/brainstorm/README.md +9 -9
- package/data/harnesses/code-fable/skills/brainstorm/SKILL.md +15 -15
- package/data/harnesses/code-fable/skills/brainstorm/harvest.md +2 -2
- package/data/harnesses/code-fable/skills/brainstorm/templates/backlog.md +2 -2
- package/data/harnesses/code-fable/skills/brainstorm/templates/build.md +6 -6
- package/data/harnesses/code-fable/skills/brainstorm/templates/decisions.md +3 -3
- package/data/harnesses/code-fable/skills/brainstorm/templates/doctrine.md +2 -2
- package/data/harnesses/code-fable/skills/brainstorm/templates/domain-model.md +2 -2
- package/data/harnesses/code-fable/skills/brainstorm/templates/glossary.md +2 -1
- package/data/harnesses/code-fable/skills/brainstorm/templates/non-goals.md +3 -7
- package/data/harnesses/code-fable/skills/brainstorm/templates/questions.md +6 -5
- package/data/harnesses/code-fable/skills/brainstorm/templates/state.md +1 -8
- package/data/harnesses/code-fable/skills/brainstorm/templates/tech.md +6 -6
- package/data/harnesses/code-fable/skills/brainstorm/templates/thesis.md +2 -2
- package/data/harnesses/code-fable/skills/distiller/SKILL.md +48 -177
- package/data/harnesses/code-fable/skills/distiller/references/docs-mode.md +116 -343
- package/data/harnesses/code-fable/skills/distiller/references/method.md +37 -109
- package/data/harnesses/code-fable/skills/documentation/SKILL.md +9 -6
- package/data/harnesses/code-fable/skills/documentation/references/examples.md +30 -61
- package/data/harnesses/code-fable/skills/documentation/references/style-guide.md +59 -62
- package/data/harnesses/code-fable/skills/documentation/references/templates.md +25 -33
- package/data/harnesses/code-fable/skills/workflow-mapper/SKILL.md +32 -11
- package/data/harnesses/code-fable/skills/workflow-mapper/references/patterns.md +1 -1
- package/data/harnesses/discover/CLAUDE.md +41 -109
- package/data/harnesses/discover/agents/api.md +11 -28
- package/data/harnesses/discover/agents/codebase.md +12 -30
- package/data/harnesses/discover/agents/community.md +9 -21
- package/data/harnesses/discover/agents/deployed-client-bundle.md +16 -67
- package/data/harnesses/discover/agents/distribution-artifacts.md +21 -59
- package/data/harnesses/discover/agents/docs.md +11 -20
- package/data/harnesses/discover/agents/infra-backend-fingerprint.md +28 -68
- package/data/harnesses/discover/agents/packages.md +12 -28
- package/data/harnesses/discover/agents/session.md +18 -50
- package/data/harnesses/discover/agents/website.md +9 -19
- package/data/harnesses/discover/agents/wire-capture.md +22 -72
- package/data/harnesses/discover/harness.json +1 -1
- package/data/harnesses/discover/rules/discovery.md +73 -182
- package/data/harnesses/discover/rules/evaluation.md +90 -98
- package/data/harnesses/discover/rules/ingestion.md +123 -322
- package/data/harnesses/discover/rules/self-correction.md +67 -92
- package/data/harnesses/discover/rules/tradecraft.md +201 -172
- package/data/harnesses/hr/CLAUDE.md +21 -51
- package/data/harnesses/hr/harness.json +1 -1
- package/data/harnesses/hr/skills/interview-eval/SKILL.md +23 -11
- package/data/harnesses/hr/skills/interview-eval/TEMPLATE.md +49 -29
- package/data/harnesses/hr/skills/interview-eval/rubric.md +30 -30
- package/data/harnesses/kb-agi/CLAUDE.md +8 -8
- package/data/harnesses/kb-agi/agents/kb-agi-init.md +31 -22
- package/data/harnesses/kb-agi/agents/kb-catch-stale.md +1 -1
- package/data/harnesses/kb-agi/agents/kb-find-gaps.md +1 -1
- package/data/harnesses/kb-agi/agents/kb-fix-links.md +1 -1
- package/data/harnesses/kb-agi/agents/kb-refresh-summaries.md +2 -2
- package/data/harnesses/kb-agi/agents/kb-sync-metadata.md +2 -2
- package/data/harnesses/kb-agi/harness.json +1 -1
- package/package.json +1 -1
|
@@ -1,50 +1,34 @@
|
|
|
1
1
|
# hr — AI-Steering Evaluation harness
|
|
2
2
|
|
|
3
|
-
This repo evaluates **how a person steered a Claude Code session** — for interview and hiring
|
|
4
|
-
assessment. You read session transcripts (`.jsonl`) and produce a calibrated, evidence-anchored read
|
|
5
|
-
on the candidate's ability to drive an AI coding agent.
|
|
3
|
+
This repo evaluates **how a person steered a Claude Code session** — for interview and hiring assessment. You read session transcripts (`.jsonl`) and produce a calibrated, evidence-anchored read on the candidate's ability to drive an AI coding agent.
|
|
6
4
|
|
|
7
|
-
You are the **evaluator**. The work is the `interview-eval` skill (its `rubric.md` holds the band
|
|
8
|
-
anchors, gates, and session-type matrix; `extract_session.py` is the deterministic extractor;
|
|
9
|
-
`TEMPLATE.md` holds the output shapes). This `CLAUDE.md` is the **policy** over that skill: the
|
|
10
|
-
pipeline, the discipline that keeps scores honest, and the things you must never do.
|
|
5
|
+
You are the **evaluator**. The work is the `interview-eval` skill (its `rubric.md` holds the band anchors, gates, and session-type matrix; `extract_session.py` is the deterministic extractor; `TEMPLATE.md` holds the output shapes). This `CLAUDE.md` is the **policy** over that skill: the pipeline, the discipline that keeps scores honest, and the things you must never do.
|
|
11
6
|
|
|
12
7
|
---
|
|
13
8
|
|
|
14
9
|
## The one rule above all others
|
|
15
10
|
|
|
16
|
-
**You score the human, not the model.** Claude writing clean code earns the candidate nothing;
|
|
17
|
-
Claude writing buggy code costs them nothing — *unless* the candidate's prompt caused it or they
|
|
18
|
-
failed to catch it. Reward the prompt that set the agent up, the verification that caught its
|
|
19
|
-
mistake, the redirect that pulled it off a bad path. Turn count, prompt length, and verbosity are
|
|
20
|
-
**not** quality — precision, judgment, and verification are. Re-read this before every scoring pass.
|
|
11
|
+
**You score the human, not the model.** Claude writing clean code earns the candidate nothing; Claude writing buggy code costs them nothing — _unless_ the candidate's prompt caused it or they failed to catch it. Reward the prompt that set the agent up, the verification that caught its mistake, the redirect that pulled it off a bad path. Turn count, prompt length, and verbosity are **not** quality — precision, judgment, and verification are. Re-read this before every scoring pass.
|
|
21
12
|
|
|
22
13
|
---
|
|
23
14
|
|
|
24
15
|
## Step 0 — first run
|
|
25
16
|
|
|
26
|
-
If the `interview-eval` skill isn't resolvable (no `.claude/skills/interview-eval/`), this project isn't set
|
|
27
|
-
up — tell the user to run `npx @nurix/etna --name=hr` (or point you at the skill) before continuing. Confirm
|
|
28
|
-
`python3` is on PATH; the extractor is stdlib-only and needs nothing else.
|
|
17
|
+
If the `interview-eval` skill isn't resolvable (no `.claude/skills/interview-eval/`), this project isn't set up — tell the user to run `npx @nurix/etna --name=hr` (or point you at the skill) before continuing. Confirm `python3` is on PATH; the extractor is stdlib-only and needs nothing else.
|
|
29
18
|
|
|
30
19
|
## Step 1 — intake interview
|
|
31
20
|
|
|
32
|
-
Before scoring anything, establish scope with a short `AskUserQuestion` round (skip a question if the
|
|
33
|
-
user already answered it):
|
|
21
|
+
Before scoring anything, establish scope with a short `AskUserQuestion` round (skip a question if the user already answered it):
|
|
34
22
|
|
|
35
23
|
1. **What am I evaluating?** → one candidate (one or many sessions) · several candidates · a cohort.
|
|
36
|
-
2. **What context governs expectations?** → the candidate's target role/seniority, the task brief
|
|
37
|
-
|
|
38
|
-
efficiency up, polish down) — it never changes the rubric's absolute band anchors.
|
|
39
|
-
3. **Where do the transcripts live, and where should output go?** → input `.jsonl` paths / a folder,
|
|
40
|
-
and an `out_dir` (default `./interview-eval-out/`).
|
|
24
|
+
2. **What context governs expectations?** → the candidate's target role/seniority, the task brief they were given, and any time box. This adjusts _expectations_ (a time-boxed take-home weights efficiency up, polish down) — it never changes the rubric's absolute band anchors.
|
|
25
|
+
3. **Where do the transcripts live, and where should output go?** → input `.jsonl` paths / a folder, and an `out_dir` (default `./interview-eval-out/`).
|
|
41
26
|
|
|
42
27
|
Keep it to those. Carry the answers forward; don't re-interview per session.
|
|
43
28
|
|
|
44
29
|
## Step 2 — run the pipeline (delegate to `interview-eval`)
|
|
45
30
|
|
|
46
|
-
For each candidate, invoke the `interview-eval` skill. It owns the mechanics; your job is to drive it and
|
|
47
|
-
hold the discipline below. The flow it runs:
|
|
31
|
+
For each candidate, invoke the `interview-eval` skill. It owns the mechanics; your job is to drive it and hold the discipline below. The flow it runs:
|
|
48
32
|
|
|
49
33
|
```
|
|
50
34
|
Extract → python3 extract_session.py SESSION.jsonl --out <out_dir>/<slug>/ --json
|
|
@@ -57,35 +41,21 @@ Roll up → if >1 session: dimension trends + consistency + one calibrated leve
|
|
|
57
41
|
→ <out_dir>/candidate-rollup.md
|
|
58
42
|
```
|
|
59
43
|
|
|
60
|
-
After the rollup, **always produce a one-page candidate brief** (verdict + level, the standout
|
|
61
|
-
evidence, the single biggest risk, and 3–4 interview follow-ups that would confirm or kill that risk).
|
|
62
|
-
That brief is the deliverable a hiring manager reads first.
|
|
44
|
+
After the rollup, **always produce a one-page candidate brief** (verdict + level, the standout evidence, the single biggest risk, and 3–4 interview follow-ups that would confirm or kill that risk). That brief is the deliverable a hiring manager reads first.
|
|
63
45
|
|
|
64
46
|
## Step 3 — calibration discipline (non-negotiable)
|
|
65
47
|
|
|
66
|
-
- **Evidence or it didn't happen.** Every band cites real `U<n>` turns with short verbatim quotes.
|
|
67
|
-
|
|
68
|
-
- **
|
|
69
|
-
|
|
70
|
-
- **
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
- **
|
|
78
|
-
invent verification or judgment the transcript doesn't show.
|
|
79
|
-
|
|
80
|
-
## What you do *not* do
|
|
81
|
-
|
|
82
|
-
- **You don't decide the hire.** You produce a level and a brief; the human decides. Frame the level
|
|
83
|
-
as a calibrated lens, never a verdict.
|
|
84
|
-
- **You don't mutate the source transcripts.** The skill is read-only over `.jsonl`; you only write
|
|
85
|
-
into `out_dir`.
|
|
86
|
-
- **You don't score Claude's code quality as if it were the candidate's.** If the agent proposed the
|
|
87
|
-
good design and the human only assented, say so — that's weaker judgment than originating it.
|
|
88
|
-
- **You don't fabricate a score from thin evidence.** A one-turn fragment or an empty/corrupt
|
|
89
|
-
transcript gets a stub that says so and defers to the rollup — not an invented band.
|
|
48
|
+
- **Evidence or it didn't happen.** Every band cites real `U<n>` turns with short verbatim quotes. "Seems thorough" is not a finding.
|
|
49
|
+
- **Absolute bands, not a curve.** Score each session against `rubric.md`'s anchors. With multiple candidates you may _report_ relative ranking, but each band is assigned absolutely.
|
|
50
|
+
- **Exclude harness noise.** API 529s / connection drops are Anthropic-side — never penalize them. Tool-permission prompts and model slips the human then caught are not candidate failures. Distinguish a sharp early interrupt (good) from thrash (bad) by reading the surrounding turns.
|
|
51
|
+
- **Gates require human direction.** A gate fires only on confirmed _unsafe steering_ the human directed or ratified (pasted a live secret, approved a destructive op unchecked, knowingly shipped broken output) — not on a model mistake. Verify the auto-detected red-flag leads against the transcript before firing one.
|
|
52
|
+
- **Charity with a spine.** Read terse prompts and typos in the best plausible light, but never invent verification or judgment the transcript doesn't show.
|
|
53
|
+
|
|
54
|
+
## What you do _not_ do
|
|
55
|
+
|
|
56
|
+
- **You don't decide the hire.** You produce a level and a brief; the human decides. Frame the level as a calibrated lens, never a verdict.
|
|
57
|
+
- **You don't mutate the source transcripts.** The skill is read-only over `.jsonl`; you only write into `out_dir`.
|
|
58
|
+
- **You don't score Claude's code quality as if it were the candidate's.** If the agent proposed the good design and the human only assented, say so — that's weaker judgment than originating it.
|
|
59
|
+
- **You don't fabricate a score from thin evidence.** A one-turn fragment or an empty/corrupt transcript gets a stub that says so and defers to the rollup — not an invented band.
|
|
90
60
|
|
|
91
61
|
Every output lands under `out_dir` and is plain markdown/YAML — reviewable, quotable, and reversible.
|
|
@@ -7,11 +7,11 @@ description: Evaluate how well a person steered a Claude Code session — the hu
|
|
|
7
7
|
|
|
8
8
|
Judge **how a human drove a Claude Code session** — not how good Claude's output was. The unit of evaluation is the person's steering: how they framed the problem, decomposed it, fed context, verified results, debugged, corrected course, and revealed engineering judgment through their prompts. One or many session transcripts in → per-session reports + scorecards out, plus a candidate-level rollup when there are several.
|
|
9
9
|
|
|
10
|
-
This is the **counterpart** to the sibling `evaluator` skill: `evaluator` scores a
|
|
10
|
+
This is the **counterpart** to the sibling `evaluator` skill: `evaluator` scores a _repo's artifacts_; `interview-eval` scores the _conversation that produced them_. They share no rubric.
|
|
11
11
|
|
|
12
12
|
## The one rule that governs every score
|
|
13
13
|
|
|
14
|
-
**You are scoring the human, not the model.** Claude's code being clean does not earn the candidate points; Claude's code being buggy does not lose them points —
|
|
14
|
+
**You are scoring the human, not the model.** Claude's code being clean does not earn the candidate points; Claude's code being buggy does not lose them points — _unless_ the human's prompt caused it or the human failed to catch it. Reward the prompt that set Claude up to succeed, the verification that caught Claude's mistake, the redirect that pulled Claude off a bad path. A candidate who wrote three sharp prompts and let a capable agent run is steering _well_, even if the turn count is low. A candidate who typed forty vague nudges and rubber-stamped broken output is steering _badly_, even if something shipped. Turn count, prompt length, and verbosity are **not** quality signals — precision, judgment, and verification are.
|
|
15
15
|
|
|
16
16
|
## Input
|
|
17
17
|
|
|
@@ -24,9 +24,11 @@ If the user just points at this folder, treat every `*.jsonl` as one candidate's
|
|
|
24
24
|
## Process
|
|
25
25
|
|
|
26
26
|
### 0. Preflight (cheap)
|
|
27
|
+
|
|
27
28
|
Only dependency is `python3` (stdlib only). No installs, no network. If `python3` is missing, say so and stop.
|
|
28
29
|
|
|
29
30
|
### 1. Extract an evidence pack per session (deterministic)
|
|
31
|
+
|
|
30
32
|
Run the extractor — it never scores, it only surfaces signal:
|
|
31
33
|
|
|
32
34
|
```bash
|
|
@@ -34,6 +36,7 @@ python3 <skill_dir>/extract_session.py SESSION.jsonl --out <out_dir>/<session-sl
|
|
|
34
36
|
```
|
|
35
37
|
|
|
36
38
|
It emits a markdown evidence pack on stdout and writes `<sessionId>.session.json`. The pack gives you:
|
|
39
|
+
|
|
37
40
|
- **Turn-by-turn**: each human prompt (IDE tags stripped) followed by a summary of what the agent did (tool counts + sample targets). This is your primary evidence — quote `U<n>` turn numbers in every finding.
|
|
38
41
|
- **Metrics**: prompt count, wall-clock & idle gaps, tool histogram, permission-mode transitions, plan-mode / subagent / AskUserQuestion / slash-command usage, interrupts, system/API errors.
|
|
39
42
|
- **Auto red-flag signals**: secrets pasted into prompts, destructive commands the agent ran (`rm -rf ~`, force-push, `DROP TABLE`, …). These are **leads to verify**, not verdicts.
|
|
@@ -43,14 +46,16 @@ It emits a markdown evidence pack on stdout and writes `<sessionId>.session.json
|
|
|
43
46
|
**Separate noise from signal.** `system_errors` that are `status: 529` / `ECONNRESET` are Anthropic-side overload, not the candidate's fault — never penalize them. `interrupts` may be a sharp early redirect (good) or thrash (bad) — read the surrounding turns to tell which.
|
|
44
47
|
|
|
45
48
|
### 2. Classify the session type
|
|
46
|
-
|
|
49
|
+
|
|
50
|
+
Pick the dominant type (a session can be a blend — note it): **greenfield-build · feature-add · debugging · refactor · ops/infra · research/Q&A · review/audit**. The type sets which dimensions are _primary_, _secondary_, or _N/A_ — see `rubric.md` → "Session-type matrix". A pure debugging session, for example, makes **E** the main event and may mark **B** N/A.
|
|
47
51
|
|
|
48
52
|
### 3. Score the 9 dimensions
|
|
53
|
+
|
|
49
54
|
Full band anchors (0–5, with concrete "looks like" descriptions and green/red flags) live in **[`rubric.md`](rubric.md)** — read it before every evaluation; do not score from memory. Summary:
|
|
50
55
|
|
|
51
56
|
| # | Dimension | Weight | The senior question it answers |
|
|
52
|
-
|
|
53
|
-
| **A** | Problem Framing & Specification | 15 | Did they tell the agent
|
|
57
|
+
| --- | --- | :-: | --- |
|
|
58
|
+
| **A** | Problem Framing & Specification | 15 | Did they tell the agent _what_ and _why_, at the right altitude, with constraints + acceptance criteria? |
|
|
54
59
|
| **B** | Decomposition & Sequencing | 12 | Did they break work into coherent, dependency-ordered, verifiable increments? |
|
|
55
60
|
| **C** | Context Curation | 10 | Did they ground the agent in real artifacts (files, logs, outputs) instead of making it guess? |
|
|
56
61
|
| **D** | Verification & Skepticism | 18 | Did they treat output as a draft to check — run it, read it, catch errors — rather than rubber-stamp? |
|
|
@@ -63,19 +68,22 @@ Full band anchors (0–5, with concrete "looks like" descriptions and green/red
|
|
|
63
68
|
Each dimension gets an integer **0–5 band**, a one-paragraph **rationale**, and **≥2 quoted turn citations** (`U7: "i see the rows but they are empty"`). No citation → no score; write `INSUFFICIENT_EVIDENCE` and exclude from the total. Mark genuinely inapplicable dimensions `N/A` and renormalize over the remaining weight.
|
|
64
69
|
|
|
65
70
|
### 4. Apply gates (hard caps), then green flags
|
|
66
|
-
|
|
71
|
+
|
|
72
|
+
**Gates** cap the overall band regardless of dimension scores — see `rubric.md` → "Gates". They fire only on _confirmed_ unsafe steering (pasted live secrets, approved a destructive/irreversible op without checking, knowingly shipped broken output). Auto-detected red flags are candidates for a gate — confirm against the transcript before firing one, and record why.
|
|
67
73
|
|
|
68
74
|
**Green flags** are noted as evidence of strength but never push a dimension above its band's ceiling.
|
|
69
75
|
|
|
70
76
|
### 5. Compute totals and level
|
|
77
|
+
|
|
71
78
|
```
|
|
72
79
|
weighted = Σ(band_d / 5 × weight_d) over scored dimensions
|
|
73
80
|
normalized = weighted / Σ(weight_d of scored dimensions) × 100
|
|
74
81
|
```
|
|
82
|
+
|
|
75
83
|
Map `normalized` to a **steering level** (after gate caps):
|
|
76
84
|
|
|
77
85
|
| Level | Normalized | Reads as |
|
|
78
|
-
|
|
86
|
+
| --- | :-: | --- |
|
|
79
87
|
| **Exemplary** | 85–100 | Operates the agent as a true force-multiplier; senior+ signal |
|
|
80
88
|
| **Strong** | 70–84 | Confident, effective, low-waste steering; clear senior signal |
|
|
81
89
|
| **Competent** | 55–69 | Gets results; real gaps in verification or framing; mid-level |
|
|
@@ -85,11 +93,14 @@ Map `normalized` to a **steering level** (after gate caps):
|
|
|
85
93
|
The level is a **calibration aid, not a verdict** — the human reviewer decides hire/no-hire. Present the level with the evidence that earned it, and call out the 1–2 dimensions that most moved it.
|
|
86
94
|
|
|
87
95
|
### 6. Write outputs (see [`TEMPLATE.md`](TEMPLATE.md))
|
|
96
|
+
|
|
88
97
|
Per session, write to `<out_dir>/<session-slug>/`:
|
|
98
|
+
|
|
89
99
|
- **`report.md`** — narrative: summary line, level, per-dimension table with citations, standout moments, weaknesses, gates/flags, and a "what a stronger operator would have done differently" section. Shape = TEMPLATE.md.
|
|
90
100
|
- **`scorecard.yaml`** — machine-readable: per-dimension band + rationale + citations, gates, green flags, totals, level.
|
|
91
101
|
|
|
92
102
|
When >1 session, also write `<out_dir>/candidate-rollup.md`:
|
|
103
|
+
|
|
93
104
|
- Per-session level + headline.
|
|
94
105
|
- Per-dimension trend across sessions (is verification consistently weak? is framing consistently strong?).
|
|
95
106
|
- **Consistency** read — does the candidate steer the same way under pressure (debugging) as when greenfield?
|
|
@@ -98,21 +109,22 @@ When >1 session, also write `<out_dir>/candidate-rollup.md`:
|
|
|
98
109
|
## Scoring discipline (read before every run)
|
|
99
110
|
|
|
100
111
|
- **Evidence or it didn't happen.** Every band cites real turns. "Seems thorough" is not a finding; `U7–U11 debugged the empty-rows bug by pasting the live API response (U9) and isolating restart behavior (U11)` is.
|
|
101
|
-
- **Absolute bands, not curve.** A lone session is scored against the anchors in `rubric.md`, not against other candidates. With multiple sessions you may
|
|
102
|
-
- **Don't confuse activity with skill.** A 40-turn session is not 40-turns-good. Ask what each turn
|
|
112
|
+
- **Absolute bands, not curve.** A lone session is scored against the anchors in `rubric.md`, not against other candidates. With multiple sessions you may _report_ relative trends, but each session's band is absolute.
|
|
113
|
+
- **Don't confuse activity with skill.** A 40-turn session is not 40-turns-good. Ask what each turn _accomplished_. Penalize wasted loops; reward turns that each move a verifiable step.
|
|
103
114
|
- **Don't penalize the harness.** API 529s, tool-permission prompts, and model mistakes the candidate then caught are not the candidate's failures. Idle gaps may be the candidate thinking, testing out-of-band, or away — note, don't assume.
|
|
104
115
|
- **Charity with a spine.** Read terse prompts in the best plausible light (typos, brevity ≠ low skill), but do not invent verification or judgment the transcript doesn't show. If you can't see it, it isn't scored there.
|
|
105
|
-
- **Surface the model's contribution honestly.** If Claude proposed the good architecture and the candidate merely said "yes", that is weak **G** with strong-agent luck — say so. If the candidate's prompt
|
|
116
|
+
- **Surface the model's contribution honestly.** If Claude proposed the good architecture and the candidate merely said "yes", that is weak **G** with strong-agent luck — say so. If the candidate's prompt _specified_ the operational concern, that is strong **G**.
|
|
106
117
|
|
|
107
118
|
## What good and weak steering look like (calibration vignettes)
|
|
108
119
|
|
|
109
|
-
- **Strong A+G+D:** Opens with a data model, the four API operations, and an explicit constraint ("use an in-memory DB"). Later, unprompted, asks for
|
|
120
|
+
- **Strong A+G+D:** Opens with a data model, the four API operations, and an explicit constraint ("use an in-memory DB"). Later, unprompted, asks for _reconciliation of stuck campaigns_ and _idempotent re-enqueue_ — operational maturity. Verifies by running the app and reading the actual response body, not by trusting the diff.
|
|
110
121
|
- **Strong E:** On a bug, pastes the literal API response (`U9`), then narrows it — "I see the rows but they are empty" → "restarting the server still shows old rows" — feeding the agent expected-vs-actual until root cause. Converges in a few turns.
|
|
111
122
|
- **Weak D:** Runs the whole session in an auto-accept mode and never once runs, reads, or questions the output; "make it work" → "still not working" → "ok ship it." No evidence the human ever confirmed correctness.
|
|
112
123
|
- **Weak F:** Lets the agent build for many turns down a path the candidate didn't want, then restarts from scratch instead of redirecting; or re-sends the identical prompt three times when it fails instead of adding information.
|
|
113
124
|
- **Gate fires:** Pastes a live API key into a prompt, or tells the agent to `git push --force` to a shared branch and approves it without looking — cap at **Developing** and flag, no matter how good the rest is.
|
|
114
125
|
|
|
115
126
|
## Notes
|
|
127
|
+
|
|
116
128
|
- The skill is read-only over the transcripts; it only writes into `out_dir`. Never mutate the source `.jsonl`.
|
|
117
129
|
- If a transcript is corrupt/empty or has zero human turns, write a stub report saying so rather than fabricating a score.
|
|
118
130
|
- Keep reports honest and specific enough that the candidate, if shown the report, would recognize the session. That is the bar for evidence quality.
|
|
@@ -8,17 +8,17 @@ Two per-session artifacts (`report.md`, `scorecard.yaml`) and one rollup (`candi
|
|
|
8
8
|
|
|
9
9
|
```markdown
|
|
10
10
|
# Steering evaluation — ‹session title›
|
|
11
|
+
|
|
11
12
|
`‹session-id›` · ‹session-type› · ‹N› human turns · ‹wall-clock› · cli ‹version›
|
|
12
13
|
|
|
13
|
-
> **Steering level: ‹Exemplary | Strong | Competent | Developing | Weak›**
|
|
14
|
-
> ‹One-sentence verdict — what kind of operator this session shows, in plain language.›
|
|
14
|
+
> **Steering level: ‹Exemplary | Strong | Competent | Developing | Weak›** (‹normalized›/100) ‹One-sentence verdict — what kind of operator this session shows, in plain language.›
|
|
15
15
|
|
|
16
16
|
**Headline:** ‹2–3 sentences. The single most important thing about how this person drove the agent — the strength that defines the session and the gap that most held it back.›
|
|
17
17
|
|
|
18
18
|
## Scores
|
|
19
19
|
|
|
20
20
|
| Dim | Dimension | Band | Wt | Note |
|
|
21
|
-
|
|
21
|
+
| --- | --- | :-: | :-: | --- |
|
|
22
22
|
| A | Problem Framing & Specification | ‹0–5› | 15 | ‹≤10 words› |
|
|
23
23
|
| B | Decomposition & Sequencing | ‹0–5› | 12 | ‹≤10 words› |
|
|
24
24
|
| C | Context Curation | ‹0–5› | 10 | ‹≤10 words› |
|
|
@@ -28,11 +28,12 @@ Two per-session artifacts (`report.md`, `scorecard.yaml`) and one rollup (`candi
|
|
|
28
28
|
| G | Technical & Architectural Judgment | ‹0–5› | 15 | ‹≤10 words› |
|
|
29
29
|
| H | Workflow & Tooling Leverage | ‹0–5› | 5 | ‹≤10 words› |
|
|
30
30
|
| I | Outcome & Efficiency | ‹0–5› | 5 | ‹≤10 words› |
|
|
31
|
-
|
|
|
31
|
+
| | **Weighted total** | | | **‹normalized›/100** |
|
|
32
32
|
|
|
33
33
|
‹If any gate fired:› **Gate: ‹GATE-NAME›** — ‹what triggered it, with the turn cite›. Level capped at ‹cap›.
|
|
34
34
|
|
|
35
35
|
## Per-dimension findings
|
|
36
|
+
|
|
36
37
|
For each dimension, 2–4 sentences of rationale + the turn citations that justify the band.
|
|
37
38
|
|
|
38
39
|
**A — Problem Framing (‹band›).** ‹rationale› _Evidence:_ ‹U1: "…"›, ‹U4: "…"›.
|
|
@@ -42,15 +43,19 @@ For each dimension, 2–4 sentences of rationale + the turn citations that justi
|
|
|
42
43
|
‹…repeat C–I…›
|
|
43
44
|
|
|
44
45
|
## Standout moments
|
|
46
|
+
|
|
45
47
|
- ✅ ‹The 1–3 best steering moves, each with a turn cite and why it was good.›
|
|
46
48
|
|
|
47
49
|
## Weaknesses
|
|
50
|
+
|
|
48
51
|
- ⚠ ‹The 1–3 most costly gaps, each with a turn cite and the consequence.›
|
|
49
52
|
|
|
50
53
|
## What a stronger operator would have done differently
|
|
54
|
+
|
|
51
55
|
‹3–5 concrete, specific alternatives — the actual better prompt or move at a named turn. This is the most useful section for a hiring decision; make it sharp, not generic.›
|
|
52
56
|
|
|
53
57
|
## Caveats
|
|
58
|
+
|
|
54
59
|
‹Harness noise excluded from scoring (e.g. "8 system errors were all API 529s — not penalized"), idle gaps, anything the transcript couldn't show.›
|
|
55
60
|
```
|
|
56
61
|
|
|
@@ -66,22 +71,31 @@ turns: ‹N›
|
|
|
66
71
|
duration_human: ‹3h42m›
|
|
67
72
|
|
|
68
73
|
dimensions:
|
|
69
|
-
framing:
|
|
70
|
-
decomposition:
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
74
|
+
framing: { band: ‹0-5›, weight: 15, rationale: "‹…›", cites: ["U1", "U4"] }
|
|
75
|
+
decomposition:
|
|
76
|
+
{ band: ‹0-5›, weight: 12, rationale: "‹…›", cites: ["U2", "U4"] }
|
|
77
|
+
context: { band: ‹0-5›, weight: 10, rationale: "‹…›", cites: ["U9"] }
|
|
78
|
+
verification:
|
|
79
|
+
{ band: ‹0-5›, weight: 18, rationale: "‹…›", cites: ["U7", "U11"] }
|
|
80
|
+
debugging:
|
|
81
|
+
{
|
|
82
|
+
band: ‹0-5|null›,
|
|
83
|
+
weight: 10,
|
|
84
|
+
na: ‹false|true›,
|
|
85
|
+
rationale: "‹…›",
|
|
86
|
+
cites: ["U9"],
|
|
87
|
+
}
|
|
88
|
+
correction: { band: ‹0-5›, weight: 10, rationale: "‹…›", cites: ["U13"] }
|
|
89
|
+
judgment: { band: ‹0-5›, weight: 15, rationale: "‹…›", cites: ["U23"] }
|
|
90
|
+
tooling: { band: ‹0-5›, weight: 5, rationale: "‹…›", cites: ["U17"] }
|
|
91
|
+
outcome: { band: ‹0-5›, weight: 5, rationale: "‹…›", cites: ["U26"] }
|
|
92
|
+
|
|
93
|
+
gates_triggered: [] # e.g. [BLIND-SHIP]
|
|
94
|
+
green_flags: [] # e.g. [empirical-debugging, unprompted-operability]
|
|
95
|
+
|
|
96
|
+
weighted_total: ‹float› # Σ(band/5 × weight) over scored dims
|
|
97
|
+
available_weight: ‹int› # Σ weight of scored (non-N/A) dims
|
|
98
|
+
normalized: ‹float› # weighted_total / available_weight × 100, after gate caps
|
|
85
99
|
level: ‹Exemplary | Strong | Competent | Developing | Weak›
|
|
86
100
|
|
|
87
101
|
evidence_excluded_from_scoring:
|
|
@@ -94,31 +108,37 @@ evidence_excluded_from_scoring:
|
|
|
94
108
|
|
|
95
109
|
```markdown
|
|
96
110
|
# Candidate steering rollup — ‹candidate / label›
|
|
111
|
+
|
|
97
112
|
‹K› sessions · ‹total turns› · ‹combined wall-clock›
|
|
98
113
|
|
|
99
|
-
> **Overall steering level: ‹level›**
|
|
100
|
-
> ‹One-paragraph calibrated read of the candidate as an AI-pairing operator across all sessions.›
|
|
114
|
+
> **Overall steering level: ‹level›** ‹One-paragraph calibrated read of the candidate as an AI-pairing operator across all sessions.›
|
|
101
115
|
|
|
102
116
|
## Sessions
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
|
117
|
+
|
|
118
|
+
| Session | Type | Level | Norm. | Headline |
|
|
119
|
+
| ------- | ------ | ------- | :---: | ----------- |
|
|
120
|
+
| ‹title› | ‹type› | ‹level› | ‹n› | ‹≤12 words› |
|
|
106
121
|
|
|
107
122
|
## Dimension trend across sessions
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
|
111
|
-
|
|
|
123
|
+
|
|
124
|
+
| Dim | S1 | S2 | … | Read |
|
|
125
|
+
| --------- | :-: | :-: | --- | ------------------------------------------- |
|
|
126
|
+
| A Framing | ‹b› | ‹b› | | ‹consistent? improving? context-dependent?› |
|
|
127
|
+
| … | | | | |
|
|
112
128
|
|
|
113
129
|
## Consistency
|
|
130
|
+
|
|
114
131
|
‹Does the candidate steer the same under pressure (debugging) as greenfield? Where does quality drop — and is the drop in a dimension that matters for the role?›
|
|
115
132
|
|
|
116
133
|
## Strongest evidence (top 3 across all sessions)
|
|
134
|
+
|
|
117
135
|
1. ‹session · U‹n› · what it shows›
|
|
118
136
|
|
|
119
137
|
## Weakest evidence (top 3 across all sessions)
|
|
138
|
+
|
|
120
139
|
1. ‹session · U‹n› · what it shows›
|
|
121
140
|
|
|
122
141
|
## Interview follow-ups to probe the gaps
|
|
142
|
+
|
|
123
143
|
- ‹Concrete question that would confirm/deny the weakest dimension, e.g. "Walk me through how you'd have verified the worker actually drained the queue — what would you have checked?"›
|
|
124
144
|
```
|
|
@@ -5,7 +5,7 @@ Score each dimension **0–5** against the anchors below. Bands are **absolute**
|
|
|
5
5
|
Read the whole file before scoring. The general meaning of the 0–5 scale:
|
|
6
6
|
|
|
7
7
|
| Band | Meaning |
|
|
8
|
-
|
|
8
|
+
| :-: | --- |
|
|
9
9
|
| **5** | Exemplary. The behavior a senior+ operator exhibits deliberately and consistently. |
|
|
10
10
|
| **4** | Strong. Mostly present and effective, minor lapses. |
|
|
11
11
|
| **3** | Competent. Present but inconsistent or shallow; gets by. |
|
|
@@ -17,13 +17,13 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
17
17
|
|
|
18
18
|
---
|
|
19
19
|
|
|
20
|
-
## A — Problem Framing & Specification
|
|
20
|
+
## A — Problem Framing & Specification (weight 15)
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
_Did the human tell the agent what to build and why, at the right altitude, with the constraints and acceptance criteria it needed?_ The opening prompt matters most, but framing recurs every time a new sub-task starts.
|
|
23
23
|
|
|
24
|
-
**Look for:** goal + intent ("why"), not just mechanics; explicit constraints (stack, storage, perf, scope); data shapes / interfaces / acceptance criteria; stated non-goals; the
|
|
24
|
+
**Look for:** goal + intent ("why"), not just mechanics; explicit constraints (stack, storage, perf, scope); data shapes / interfaces / acceptance criteria; stated non-goals; the _right altitude_ — outcome-with-guardrails, neither a vague one-liner nor line-by-line dictation that wastes the agent.
|
|
25
25
|
|
|
26
|
-
- **5** — Specs are rich and structured: goal, constraints, data/interface shapes, and acceptance criteria are all present at the right altitude; non-goals stated; the agent has everything it needs and freedom in
|
|
26
|
+
- **5** — Specs are rich and structured: goal, constraints, data/interface shapes, and acceptance criteria are all present at the right altitude; non-goals stated; the agent has everything it needs and freedom in _how_. Re-framing on each new sub-task is equally crisp.
|
|
27
27
|
- **4** — Clear, well-scoped specs with constraints and shapes; occasionally leaves a gap the agent has to guess, but the guess space is small.
|
|
28
28
|
- **3** — Gets the core ask across but under-specifies constraints or acceptance; the agent fills meaningful gaps, sometimes wrongly, requiring a follow-up.
|
|
29
29
|
- **2** — Vague or mechanics-only ("add a function that does X") with little context; the agent frequently guesses; or over-dictates exact code, wasting the agent and inviting transcription errors.
|
|
@@ -34,9 +34,9 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
34
34
|
|
|
35
35
|
---
|
|
36
36
|
|
|
37
|
-
## B — Decomposition & Sequencing
|
|
37
|
+
## B — Decomposition & Sequencing (weight 12)
|
|
38
38
|
|
|
39
|
-
|
|
39
|
+
_Did the human break the work into coherent, dependency-ordered, individually verifiable increments?_
|
|
40
40
|
|
|
41
41
|
**Look for:** a sensible build order (foundations before features, data before UI, happy-path before edge-cases); each turn advancing a bounded step you could check; dependencies respected; no big-bang dump that forces the agent to do everything blind; no chaotic re-ordering or contradictory re-scoping.
|
|
42
42
|
|
|
@@ -51,9 +51,9 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
51
51
|
|
|
52
52
|
---
|
|
53
53
|
|
|
54
|
-
## C — Context Curation
|
|
54
|
+
## C — Context Curation (weight 10)
|
|
55
55
|
|
|
56
|
-
|
|
56
|
+
_Did the human ground the agent in the real artifacts it needed instead of making it guess?_
|
|
57
57
|
|
|
58
58
|
**Look for:** pasting actual error text, logs, API responses, or stack traces; pointing at specific files (IDE-open context, `@file`, paths); referencing prior decisions to keep the agent coherent; managing the context window (not dumping irrelevant noise, not starving it); using CLAUDE.md / plan files / memory where appropriate.
|
|
59
59
|
|
|
@@ -68,13 +68,13 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
68
68
|
|
|
69
69
|
---
|
|
70
70
|
|
|
71
|
-
## D — Verification & Skepticism
|
|
71
|
+
## D — Verification & Skepticism (weight 18 — the strongest senior signal)
|
|
72
72
|
|
|
73
|
-
|
|
73
|
+
_Did the human treat the agent's output as a draft to be checked — running it, reading it, probing it — rather than rubber-stamping?_ This is where seniors separate from juniors. Weight it accordingly.
|
|
74
74
|
|
|
75
75
|
**Look for:** running the app/tests and reporting results; reading diffs and pushing back on questionable choices; inspecting actual behavior/output; catching subtle or superficial work the agent slipped in; confirming a fix actually fixed it before moving on; not declaring "done" on faith.
|
|
76
76
|
|
|
77
|
-
> Permission mode is **not** the signal. `acceptEdits` / bypass mode is a legitimate pragmatic choice — judge whether the human
|
|
77
|
+
> Permission mode is **not** the signal. `acceptEdits` / bypass mode is a legitimate pragmatic choice — judge whether the human _verified behavior_, by any means (running, testing, reading output, inspecting the UI), not whether they clicked approve on each edit.
|
|
78
78
|
|
|
79
79
|
- **5** — Systematic verification throughout: runs the thing, inspects real output, catches agent errors the agent missed, confirms each fix before advancing, and pushes back on shaky choices. Skepticism is the default stance.
|
|
80
80
|
- **4** — Verifies most consequential output and catches real issues; a few steps taken on faith.
|
|
@@ -83,15 +83,15 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
83
83
|
- **1** — Effectively no verification; accepts and moves on regardless of correctness.
|
|
84
84
|
- **0** — Blindly ships output known or shown to be broken.
|
|
85
85
|
|
|
86
|
-
**Green flags:** "restarting the server still shows old rows" (confirming a fix
|
|
86
|
+
**Green flags:** "restarting the server still shows old rows" (confirming a fix _didn't_ take); reading the actual response body rather than the diff; spotting that the agent stubbed/faked something. **Red flags:** "looks good" with no evidence; shipping immediately after a failed run; never once running the code in a build session.
|
|
87
87
|
|
|
88
|
-
**Gate interaction:** if the human is
|
|
88
|
+
**Gate interaction:** if the human is _shown_ the output is broken and ships/commits it anyway, cap **D ≤ 2** and consider the BLIND-SHIP gate.
|
|
89
89
|
|
|
90
90
|
---
|
|
91
91
|
|
|
92
|
-
## E — Debugging Collaboration
|
|
92
|
+
## E — Debugging Collaboration (weight 10)
|
|
93
93
|
|
|
94
|
-
|
|
94
|
+
_When something broke, did the human drive toward root cause with high-signal diagnostics, or just nudge vaguely?_
|
|
95
95
|
|
|
96
96
|
**Look for:** precise reproduction; exact error/output pasted; expected-vs-actual framing; stated hypotheses; isolating variables one at a time; converging instead of flailing. (In a pure debugging session this is the main event; in a clean build it may be minor or `N/A`.)
|
|
97
97
|
|
|
@@ -106,9 +106,9 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
106
106
|
|
|
107
107
|
---
|
|
108
108
|
|
|
109
|
-
## F — Course Correction & Steering Control
|
|
109
|
+
## F — Course Correction & Steering Control (weight 10)
|
|
110
110
|
|
|
111
|
-
|
|
111
|
+
_Did the human catch the agent drifting and redirect surgically — and know when to refine vs. undo vs. restart?_
|
|
112
112
|
|
|
113
113
|
**Look for:** early detection of off-track work; minimal, targeted redirects that preserve good work; tightening constraints constructively ("run 10 at a time, spend 1s per task"); well-timed interrupts; choosing the cheapest correction (refine > undo > restart). Avoid: letting a wrong path run for many turns; chaotic yanking; re-sending an identical failing prompt; nuking good work to fix a small issue.
|
|
114
114
|
|
|
@@ -123,13 +123,13 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
123
123
|
|
|
124
124
|
---
|
|
125
125
|
|
|
126
|
-
## G — Technical & Architectural Judgment
|
|
126
|
+
## G — Technical & Architectural Judgment (weight 15)
|
|
127
127
|
|
|
128
|
-
|
|
128
|
+
_Do the prompts themselves reveal engineering maturity?_ This reads the **content** of the human's instructions for evidence of senior thinking — independent of whether the agent executed well.
|
|
129
129
|
|
|
130
130
|
**Look for:** anticipating operational concerns unprompted (idempotency, reconciliation of stuck state, observability/logging, backpressure, failure/retry, race conditions, data consistency); sound trade-offs; right-sizing to context (descoping auth for a demo; not gold-plating); awareness of the system beyond the happy path; sensible tech choices for the stated constraints.
|
|
131
131
|
|
|
132
|
-
> Attribute carefully: if
|
|
132
|
+
> Attribute carefully: if _Claude_ proposed the mature design and the human only assented, that is weaker **G** than if the human's prompt _specified_ it. Note who originated the judgment.
|
|
133
133
|
|
|
134
134
|
- **5** — Prompts repeatedly surface senior-level concerns the agent wouldn't have without being told — operability, failure modes, consistency — and make sound, explicit trade-offs right-sized to the context.
|
|
135
135
|
- **4** — Clear engineering maturity in most prompts; raises real operational concerns; a few missed opportunities.
|
|
@@ -142,9 +142,9 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
142
142
|
|
|
143
143
|
---
|
|
144
144
|
|
|
145
|
-
## H — Workflow & Tooling Leverage
|
|
145
|
+
## H — Workflow & Tooling Leverage (weight 5)
|
|
146
146
|
|
|
147
|
-
|
|
147
|
+
_Did the human use the agent and harness well, and pick the right level of autonomy?_ Credit when applicable; **do not penalize** a session that legitimately didn't need advanced features.
|
|
148
148
|
|
|
149
149
|
**Look for:** plan mode for genuinely ambiguous/large work; subagents for parallel or large-scope fan-out; slash commands / skills; sane git hygiene (branch, review, meaningful commits); MCP/CI where useful; matching autonomy to risk (high autonomy on safe mechanical work, tighter control on risky/irreversible work); economy of interaction.
|
|
150
150
|
|
|
@@ -155,13 +155,13 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
155
155
|
- **1** — Fights the tool; ignores obvious leverage; risky autonomy with no guardrails.
|
|
156
156
|
- **0** — Tooling actively works against the goal.
|
|
157
157
|
|
|
158
|
-
**Green flags:** plan mode before a big ambiguous build; subagents for an audit sweep; a clean commit/push flow with a written README. **Red flags:** bypass-all-permissions on destructive ops; no version control on substantial work.
|
|
158
|
+
**Green flags:** plan mode before a big ambiguous build; subagents for an audit sweep; a clean commit/push flow with a written README. **Red flags:** bypass-all-permissions on destructive ops; no version control on substantial work. _(Absence of advanced features in a small, well-handled task is fine — score around 3, not down.)_
|
|
159
159
|
|
|
160
160
|
---
|
|
161
161
|
|
|
162
|
-
## I — Outcome & Efficiency
|
|
162
|
+
## I — Outcome & Efficiency (weight 5)
|
|
163
163
|
|
|
164
|
-
|
|
164
|
+
_Did the session reach a correct, working end state, with economy proportional to scope?_ A capstone — partly downstream of the other dimensions, so weighted light to avoid double-counting.
|
|
165
165
|
|
|
166
166
|
**Look for:** a working, correct result the human verified; effort (turns/time/tokens) proportional to the scope; little wasted looping; a clean stopping point (committed/pushed/documented).
|
|
167
167
|
|
|
@@ -181,13 +181,13 @@ When between two bands, pick the lower unless a green flag justifies the higher.
|
|
|
181
181
|
Gates fire only on **confirmed** behavior in the transcript (use auto red-flags as leads, then verify). When a gate fires, cap the overall level as stated, record the gate, and quote the turn. Multiple gates stack downward.
|
|
182
182
|
|
|
183
183
|
| Gate | Fires when | Cap |
|
|
184
|
-
|
|
184
|
+
| --- | --- | --- |
|
|
185
185
|
| **SECRETS-LEAKED** | The human pastes a live secret (API key, token, private key, real password) into a prompt, or directs the agent to commit one, and doesn't immediately remediate. | ≤ **Developing** |
|
|
186
186
|
| **DESTRUCTIVE-UNCHECKED** | The human approves an irreversible/destructive op (`rm -rf` on a real path, `git push --force` to a shared branch, `DROP TABLE`/prod data loss, force-pushing over others' work) without verifying intent/scope. | ≤ **Developing** |
|
|
187
|
-
| **BLIND-SHIP** | The human is
|
|
187
|
+
| **BLIND-SHIP** | The human is _shown_ output is broken (failed run, wrong result) and ships/commits/declares-done anyway, with no remediation. | **D ≤ 2** and overall ≤ **Competent** |
|
|
188
188
|
| **PROMPT-INJECTION-NAIVE** | The human pipes untrusted external content into the agent as instructions and acts on it without scrutiny in a context where that's dangerous. | ≤ **Competent** |
|
|
189
189
|
|
|
190
|
-
A gate is about
|
|
190
|
+
A gate is about _unsafe steering_, not mere mistakes. A bug the candidate then caught is **not** a gate — it's evidence _for_ dimension D. Distinguish "the harness/model did X" from "the human directed X": gates require human direction or human ratification.
|
|
191
191
|
|
|
192
192
|
---
|
|
193
193
|
|
|
@@ -207,7 +207,7 @@ A gate is about *unsafe steering*, not mere mistakes. A bug the candidate then c
|
|
|
207
207
|
Classify the dominant type; blends are common — note them. "Primary" = weigh heavily and expect strong evidence; "Secondary" = score if present; "N/A" = exclude and renormalize unless the session actually exercises it.
|
|
208
208
|
|
|
209
209
|
| Type | Primary | Secondary | Often N/A |
|
|
210
|
-
|
|
210
|
+
| --- | --- | --- | --- |
|
|
211
211
|
| **greenfield-build** | A, B, G, D | C, F, I | — |
|
|
212
212
|
| **feature-add** | A, D, G | B, C, F, I | — |
|
|
213
213
|
| **debugging** | E, D, C | F, G | B (little to decompose) |
|