@nurix/etna 0.19.33 → 0.19.35

package/data/harnesses/delivery/skills/prompt-eval/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: prompt-eval
+description: Use when a prompt needs its quality measured — after drafting or revising a prompt, before certifying a library entry, or when comparing prompt variants. Runs the golden-set eval loop with rubric grading and reports deltas. Triggers on /prompt-eval, "eval this prompt", "does this variant score better", "run the golden set", "certify this prompt".
+---
+
+# Prompt Eval — the golden-set loop
+
+A prompt's quality claim is its eval result, nothing else. This skill runs the loop; conventions for golden sets, rubrics, and thresholds are `.claude/rules/evals.md`.
+
+## Procedure
+
+1. **Locate the family's golden set** at `evals/{family}/` — the owning feature doc names the family. A prompt with no golden set gets one *first* (eval-first: the set ships with the prompt, and `data-generator` drafts edge-case items for human review).
+2. **Run the set** against the prompt via `eval-runner` — every item, not a sample. Batch variants in one run so scores are comparable.
+3. **Grade with the family's rubric.** Mechanical checks (format, required fields, refusal correctness) grade in code; judgment dimensions grade against the rubric's anchors. Report per-dimension scores and the delta against the incumbent prompt's certified score.
+4. **Gate:** meeting the family's threshold on iteration is a *candidate*; certification for the library additionally requires the `judge` ship gate (frontier, one dispatch — the only frontier call in the loop).
+5. **Record:** the winning variant's scores go into its `prompt-library` entry; the losing variants' deltas belong in the changelog entry's refinement context.
+
+## Rules
+
+- **Iteration stays cheap.** The draft → eval → revise loop runs on economy (`eval-runner`) and standard (`prompt-iterator`) tiers; the frontier judge appears once, at the gate — never inside the loop.
+- **Never weaken a rubric to pass a prompt.** A rubric change is a design change to the family's eval suite: it goes through the owning feature doc, re-runs the whole family, and re-certifies every entry.
+- **A failing eval is a result, not an obstacle.** Report it honestly; if the family genuinely needs a stronger tier, that is the `escalate` skill's evidence.

package/data/harnesses/delivery/skills/prompt-library/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: prompt-library
+description: Use when creating, versioning, retrieving, or auditing a production prompt — any write into prompts/{family}/, any "which prompt do we use for X", any certification question. Owns the library entry format - tier certification, eval score, date. Triggers on /prompt-library, "add this to the library", "what's our prompt for", "is this prompt certified", "bump the prompt version".
+---
+
+# Prompt Library — versioned, certified entries
+
+`prompts/{family}/` is a library of certified production artifacts, not a scratchpad. Every entry is versioned, eval-scored, and tier-certified; scratch iterations live outside until they pass.
+
+## The entry format
+
+Each prompt is one file at `prompts/{family}/{name}.md` with frontmatter:
+
+```yaml
+---
+version: 3            # integer, bumped on every content change
+tier: standard        # the tier this prompt is certified for (economy | standard | frontier)
+eval-score: 0.94      # the certified golden-set score at this version
+certified: 2026-07-26 # date of the certifying run
+status: active        # active | candidate | retired
+---
+```
+
+The body is the prompt itself, verbatim — no narration, no history (the journey lives in changelog entries). A `candidate` has passed its family threshold but not the `judge` gate; `retired` entries stay in place for provenance (consumers must never load them — status is the filter).
+
+## Procedure
+
+- **Create / update**: a content change bumps `version`, resets `status` to `candidate`, and goes through `prompt-eval` → `judge` before flipping back to `active` with fresh `eval-score` and `certified` values. The owning feature doc's `owns:` glob covers the family — read it first.
+- **Retrieve**: match by family + status `active`; the entry's `tier` names the tier it runs on — dispatch accordingly, never stronger (that is an unevidenced promotion).
+- **Audit** (on demand, and by `regression-runner` after a model-generation change): every `active` entry whose `certified` date precedes the current `model-tiers` mapping is stale — re-certify or flag.
+
+## Rules
+
+- **Certification is per tier.** A prompt certified on standard says nothing about economy; a demotion experiment that passes produces a *new* certification at the lower tier.
+- **One prompt, one entry.** Variants under comparison are `candidate` siblings; only one `active` per name.
+- **Never hand-edit `eval-score`** — it is written by the certifying run or not at all.

package/data/harnesses/delivery/skills/route/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: route
+description: Use when starting any piece of prompt work — drafting, evaluating, generating test data, probing, or judging — before dispatching any agent or choosing any tier. The entry point that classifies the task into a task type, reads the routing table, and dispatches the pinned agent. Triggers on /route, "work on this prompt", "run the evals", "which model should this use", or any prompt task whose tier hasn't been routed yet.
+---
+
+# Route — classify, look up, dispatch
+
+The model decision belongs to the routing table in `CLAUDE.md` § The Routing Policy, not to you and not to the user. This skill is the single entry point that applies it.
+
+## Procedure
+
+1. **Classify the task into exactly one task type** from the routing table's rows. Classification is mechanical work — do it inline at the cheapest capable tier, never by dispatching a frontier agent to think about it. When a task spans types (e.g. "draft a prompt and evaluate it"), decompose: each leg routes separately.
+2. **Read the row**: task type → tier → executing agent.
+3. **Dispatch the named agent.** The agent's own pin enforces the tier — never override the model at dispatch time. Work with no matching row is new: route it provisionally to the standard tier, do the work, and record the missing row as an out-of-scope discovery so the table gains it.
+4. **Never route around a failing eval.** If the routed tier's output fails its evals, the answer is the `escalate` skill (evidence-gated promotion), not a quiet re-dispatch on a stronger agent.
+
+## What this skill refuses
+
+- Naming a model. Tiers only; the mapping lives in `.claude/rules/model-tiers.md` and the agents' pins.
+- Frontier dispatch for mechanical work (eval runs, data generation, classification) — the routing guardrails in `CLAUDE.md` prohibit it regardless of who asks.
+- Skipping the table because the task "obviously" needs the strongest model — that intuition is exactly what the escalation ladder exists to test.

package/data/harnesses/etna/CLAUDE.md

@@ -152,7 +152,7 @@ When a plan's implementation surfaces work that is important but outside the pla
 
 ❌ prohibitions hold unless the user explicitly asks otherwise; ✅ and ⚠️ items are standing policy:
 
-- ❌ **Tests** — etna is a markdown-authoring repo plus a small CLI with no test suite; never generate, update, or modify test files unless the user explicitly asks. (The `code` harness ships a suite-first posture for the projects it governs — that is a shipped rule, not etna's own.)
+- ❌ **Tests** — etna is a markdown-authoring repo plus a small CLI with no test suite; never generate, update, or modify test files unless the user explicitly asks. (The `code` harness ships a gated-verification posture for the projects it governs — that is a shipped rule, not etna's own.)
 - ❌ **Dependencies** — never upgrade frameworks, libraries, or dependencies.
 - ❌ **Compatibility** — never maintain backward compatibility unless specified.
 - ❌ **Branches & Worktrees [override]** — never self-create git branches or worktrees; commit straight to the checked-out branch. This replaces any built-in "branch first on the default branch" default. Exception: when the user asks for a pull request, create the branch the PR requires before committing its changes.

package/data/harnesses/etna/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "etna",
   "name": "etna",
-  "version": "1.3.2",
+  "version": "1.3.4",
   "files": [
     ".prettierignore",
     ".prettierrc.json",
     ".vscode/settings.json"
   ],
-  "digest": "c7f202566db9"
+  "digest": "4a94c1c4b34c"
 }

package/data/harnesses/etna/rules/general.md

@@ -22,6 +22,7 @@ Runtime versions, the canonical package list, and GitHub Actions pins — the wo
 | `@reduxjs/toolkit` | ^2.11.2 | State management | `zustand`, `jotai` |
 | `react-redux` | ^9.2.0 | Redux React bindings | — |
 | `axios` | ^1.13.2 | HTTP requests | `fetch` |
+| `@microsoft/fetch-event-source` | ^2.0.1 | SSE over POST — streaming agent output | hand-rolled `getReader()` loops, `EventSource` |
 | `date-fns` | ^4.1.0 | Date formatting | `moment`, `dayjs` |
 | `@dnd-kit/core` | ^6.3.1 | Drag and drop | `react-beautiful-dnd` |
 | `@xyflow/react` | ^12.11.0 | Node-based flow charts | `reactflow`, `react-flow-renderer` |

package/data/harnesses/etna/rules/testing.md

@@ -1,6 +1,6 @@
 # Testing
 
-Test technology and placement — framework per stack, suite layout, mocking policy; the suite-first policy (what gets tests, run-and-report discipline) is the harness `CLAUDE.md` Tests guardrail, not here. Framework choice is **never** ad hoc and never the user's problem mid-task: detect the stack, use its row; if the repo already has a runner, that runner wins — **never** introduce a second framework beside it.
+Test technology and placement — framework per stack, suite layout, mocking policy; **when** a test is written and how work is proven is [`verification.md`](verification.md), not here. Framework choice is **never** ad hoc and never the user's problem mid-task: detect the stack, use its row; if the repo already has a runner, that runner wins — **never** introduce a second framework beside it.
 
 ## Frameworks by stack
 

package/data/harnesses/hr/harness.json

@@ -1,7 +1,7 @@
 {
   "harness": "hr",
   "name": "hr",
-  "version": "0.1.12",
+  "version": "0.1.13",
   "files": [
     ".prettierignore",
     ".prettierrc.json",

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.19.33",
+    "version": "0.19.35",
     "description": "Bootstrap a project with a Nurix harness — copies the harness's CLAUDE.md, skills, agents, rules, and hooks directly into the project from a bundled payload (no marketplace fetch, no network).",
     "type": "module",
     "bin": {