@nurix/etna 0.19.24 → 0.19.25
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 +20 -14
- package/data/harness-index.json +1 -1
- package/data/harnesses/code/harness.json +2 -2
- package/data/harnesses/code/skills/boundary/SKILL.md +1 -1
- package/data/harnesses/code/skills/brainstorm/SKILL.md +1 -2
- package/data/harnesses/code/skills/design/SKILL.md +1 -1
- package/data/harnesses/code/skills/documentation/SKILL.md +1 -1
- package/data/harnesses/code/skills/test-plan/SKILL.md +1 -1
- package/data/harnesses/code/skills/workflow-mapper/SKILL.md +1 -1
- package/data/harnesses/discussion/harness.json +1 -1
- package/data/harnesses/etna/harness.json +2 -2
- package/data/harnesses/etna/skills/boundary/SKILL.md +1 -1
- package/data/harnesses/etna/skills/brainstorm/SKILL.md +1 -2
- package/data/harnesses/etna/skills/documentation/SKILL.md +1 -1
- package/data/harnesses/etna/skills/workflow-mapper/SKILL.md +1 -1
- package/data/harnesses/hr/harness.json +2 -2
- package/data/harnesses/hr/skills/evaluator/SKILL.md +1 -1
- package/data/harnesses/hr/skills/interview-eval/SKILL.md +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -20,7 +20,7 @@ npx --yes @nurix/etna --name=code
|
|
|
20
20
|
|
|
21
21
|
The `--yes` flag skips npx's install confirmation, so the command runs unattended. On startup the CLI also **self-updates**: it checks the registry and, if the copy npx resolved is behind the latest published version, re-execs the latest before installing — so `npx --yes @nurix/etna` always runs the newest harness, even when npx has an older copy cached. The check is quick but synchronous; set `ETNA_NO_SELFUPDATE=1` to skip it (CI, offline, or a pinned local build).
|
|
22
22
|
|
|
23
|
-
After this completes:
|
|
23
|
+
After this completes (the `code` harness shown — the component folders differ per harness, and one a harness ships nothing for is simply absent):
|
|
24
24
|
|
|
25
25
|
```
|
|
26
26
|
your-project/
|
|
@@ -30,17 +30,17 @@ your-project/
|
|
|
30
30
|
├── .prettierignore
|
|
31
31
|
├── .vscode/settings.json ← editor settings (markdown formatter on save)
|
|
32
32
|
└── .claude/
|
|
33
|
-
├── skills/ ←
|
|
34
|
-
├── agents/ ← lld-mode,
|
|
35
|
-
├── rules/ ←
|
|
36
|
-
├── hooks/ ← generate-ownership-index (SessionStart)
|
|
33
|
+
├── skills/ ← boundary, brainstorm, design, documentation, test-plan, workflow-mapper
|
|
34
|
+
├── agents/ ← brainstorm, change-review, lld-mode, maintenance, performance-review, retro
|
|
35
|
+
├── rules/ ← database.md, express.md, frontend.md, general.md, nomenclature.md, pnpm.md, testing.md
|
|
36
|
+
├── hooks/ ← generate-ownership-index (SessionStart) + hooks.json
|
|
37
37
|
├── settings.json ← the hook is deep-merged in here (your existing keys preserved)
|
|
38
|
-
└── harness.json ← {version, digest, owned} — the installed-harness sentinel
|
|
38
|
+
└── harness.json ← {harness, name, version, files, digest, owned} — the installed-harness sentinel
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
-
Alongside the Claude tree, the installer projects the **Codex** artifacts so the repo also works under OpenAI Codex: `AGENTS.md` (above), `.agents/skills/` (a mirror of `.claude/skills/`, Codex's skill-scan path), and `.codex/agents/*.toml` + `.codex/hooks.json` (its subagents and SessionStart hook). Nothing is written outside the project. No marketplace registration, no `enabledPlugins` entry, no global cache dependency — Claude Code picks up the project-scoped agents/skills/rules on its next session start (and Codex reads `AGENTS.md` + `.agents/` + `.codex/`), and the hooks wire in through `.claude/settings.json`.
|
|
41
|
+
Alongside the Claude tree, the installer projects the **Codex** artifacts so the repo also works under OpenAI Codex: `AGENTS.md` (above), `.agents/skills/` (a mirror of `.claude/skills/`, Codex's skill-scan path), and `.codex/agents/*.toml` + `.codex/hooks.json` (its subagents and SessionStart hook) — each surface written only when the harness ships that component kind. Nothing is written outside the project. No marketplace registration, no `enabledPlugins` entry, no global cache dependency — Claude Code picks up the project-scoped agents/skills/rules on its next session start (and Codex reads `AGENTS.md` + `.agents/` + `.codex/`), and the hooks wire in through `.claude/settings.json`.
|
|
42
42
|
|
|
43
|
-
Re-run `npx --yes @nurix/etna --name=code` anytime to refresh the harness content with what the latest published package ships. Existing same-named files are overwritten; files you've added that aren't part of the harness are left alone. In a git repo the previous `CLAUDE.md`
|
|
43
|
+
Re-run `npx --yes @nurix/etna --name=code` anytime to refresh the harness content with what the latest published package ships. Existing same-named files are overwritten, and a component the harness used to own but no longer ships is pruned; files you've added that aren't part of the harness are left alone. In a git repo the previous `CLAUDE.md` and `.claude/` are overwritten and refreshed in place (recover them with `git checkout`); outside a git repo `CLAUDE.md` is backed up to `CLAUDE.md.bak.<ISO-timestamp>` and the whole `.claude/` tree is snapshotted to `.claude.bak.<ISO-timestamp>` first. Because the new `harness.json` carries the installed `{version, digest}`, a re-run whose **major** version is ahead of your repo's stamped `harness-version` is what the reconcile (below) detects as a structural upgrade.
|
|
44
44
|
|
|
45
45
|
## After install: bootstrap the harness
|
|
46
46
|
|
|
@@ -53,7 +53,7 @@ Then work normally. Boundaries aren't generated as files — the `boundary` skil
|
|
|
53
53
|
|
|
54
54
|
One thing worth knowing on an existing repo:
|
|
55
55
|
|
|
56
|
-
- **Your root `CLAUDE.md` is replaced** with the harness policy file (
|
|
56
|
+
- **Your root `CLAUDE.md` is replaced** with the harness policy file (recoverable from git, or from `CLAUDE.md.bak.<ISO>` outside a git repo). If it held project-specific instructions, fold them back in after install — the harness file is the policy skeleton; your domain specifics sit alongside it.
|
|
57
57
|
|
|
58
58
|
## Migrating from 0.1.x
|
|
59
59
|
|
|
@@ -67,8 +67,12 @@ Listed by `npx --yes @nurix/etna` (no args) using the bundled `data/harness-inde
|
|
|
67
67
|
|
|
68
68
|
| Harness | Source in etna | What it ships |
|
|
69
69
|
| --- | --- | --- |
|
|
70
|
-
| `code` | [`harness/code/`](../../harness/code/) |
|
|
71
|
-
| `
|
|
70
|
+
| `code` | [`harness/code/`](../../harness/code/) | The canonical Nurix code-project harness — 6 governance/session agents, 6 workflow skills, 7 stack rules, the ownership-index `SessionStart` hook |
|
|
71
|
+
| `discover` | [`harness/discover/`](../../harness/discover/) | The product-discovery harness — 11 owned dimension-collector agents and 9 owned method rules, plus a `tooling-recommendations.md` at the project root. No skills, no hooks |
|
|
72
|
+
| `discussion` | [`harness/discussion/`](../../harness/discussion/) | The deliberation-workspace harness — 2 owned agents, 2 owned rules, and the `update-topics` hook that keeps the topic index current. No skills |
|
|
73
|
+
| `etna` | [`harness/etna/`](../../harness/etna/) | The forge's own governance harness — a deliberate fork of `code` reframed for authoring artifacts: 5 agents, 4 skills, 4 rules, the ownership-index hook |
|
|
74
|
+
| `hr` | [`harness/hr/`](../../harness/hr/) | The hiring / AI-steering evaluation harness — the `interview-eval` and `evaluator` skills plus one batching rule. No agents, no hooks |
|
|
75
|
+
| `kb-agi` | [`harness/kb-agi/`](../../harness/kb-agi/) | The self-improving knowledge-base harness — 3 owned vault agents (`kb-init`, `kb-audit`, `kb-apply`) and the owned `kb-export.mjs` script. No skills, no rules |
|
|
72
76
|
|
|
73
77
|
## How it works
|
|
74
78
|
|
|
@@ -88,15 +92,17 @@ Two kinds of membership:
|
|
|
88
92
|
# harness/code/readme.md
|
|
89
93
|
---
|
|
90
94
|
name: code
|
|
91
|
-
skills:
|
|
95
|
+
skills:
|
|
96
|
+
[boundary, test-plan, brainstorm, documentation, workflow-mapper, design]
|
|
92
97
|
rules: [general, frontend, express, nomenclature, database, testing, pnpm]
|
|
93
|
-
agents:
|
|
98
|
+
agents:
|
|
99
|
+
[brainstorm, change-review, lld-mode, maintenance, performance-review, retro]
|
|
94
100
|
---
|
|
95
101
|
```
|
|
96
102
|
|
|
97
103
|
- **Owned, by location** — hooks, scripts (and any unlisted, harness-specific agents) live inside the harness folder (`harness/<name>/{agents,hooks,scripts}/`). No list — membership is presence in the folder, exactly how a Claude Code plugin ships them. Shared governance agents are listed instead (above) and resolved from the `agents/` catalog, local-first; a harness can still drop its own copy beside it to override one by name.
|
|
98
104
|
|
|
99
|
-
`scripts/build-data.js` (run by `prepack`) resolves the listed skills/rules/agents from the catalogs (local-first), copies any unlisted harness-owned agents plus the harness's `hooks/` and `scripts/` wholesale into `data/harnesses/<folder
|
|
105
|
+
`scripts/build-data.js` (run by `prepack`) resolves the listed skills/rules/agents from the catalogs (local-first), copies any unlisted harness-owned agents plus the harness's `hooks/` and `scripts/` wholesale into `data/harnesses/<folder>/`, adds the `harness/common/` root files and each bundled agent's `*.codex.toml` twin, and writes the `harness.json` marker (version, `files` list, kit digest); a listed skill/rule/agent that doesn't exist is a hard error. The marketplace channel (`.github/scripts/publish.mjs`) reads the same harness folder and resolves the listed skills/rules/agents the same local-first way — but the two channels' **footprints differ**: the marketplace plugin carries no root policy, and its Codex surface is skills + hooks only (Codex custom agents ship through this CLI). The installer (`bin/etna.js`) reads from the bundle at install time; no GitHub fetch at runtime.
|
|
100
106
|
|
|
101
107
|
## Building / contributing
|
|
102
108
|
|
package/data/harness-index.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: boundary
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when a plan or diff might break a cross-cutting contract. Boundary diagnostic: reads the source a plan touches — db schema, wire envelope, auth, events — and reports violations with a pass/block verdict. Read-only; also runs on a diff. Triggers on 'boundary check', 'what could break'."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Boundary Diagnostic
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brainstorm
|
|
3
|
-
description: "
|
|
4
|
-
argument-hint: "start | stop"
|
|
3
|
+
description: "Use when starting or stopping a large-scale design brainstorm via `/brainstorm start | stop` — never on phrases like 'let's plan' or 'let's design'. Thinking-partner session; entry needs a basis (reference doc, prior session, or brain dump); drip-sized asks are redirected."
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
# Brainstorm
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: design
|
|
3
|
-
description:
|
|
3
|
+
description: "Use when building, improving, judging, or extracting operator web UIs — dashboards, CRMs, work queues, admin panels, internal tools. Also the @nurix/components reference: forms, data tables, modals, side panels, any import. Any web stack. Not marketing sites, storefronts, or mobile-native."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# design
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: documentation
|
|
3
|
-
description:
|
|
3
|
+
description: "Use when creating or substantively editing ANY markdown doc — invoke BEFORE writing. Templates + style authority for technical docs: LLDs, ADs, plans, changelogs, READMEs, runbooks. Owns the tense rule: truth docs state the present; history only in dated records. Baselining is the maintenance agent."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Documentation Skill
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: test-plan
|
|
3
|
-
description: "Test-obligation diagnostic
|
|
3
|
+
description: "Use when deriving the tests a plan owes. Test-obligation diagnostic: runs at the plan gate after boundary, reads the plan's Proposed Changes + owning LLD, and writes a Test Obligations section (a row per behavior: layer, target file, oracle, fixtures). Writes no test files. Triggers on 'test plan'."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Test-Obligation Diagnostic
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: workflow-mapper
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when mapping a codebase's major workflows — traces call chains from user action to database or external system and produces mermaid sequence diagrams + markdown. Triggers on 'map workflows', 'trace flows', 'sequence diagram', 'how does X work end-to-end'."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Workflow Mapper Skill
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: boundary
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when a plan or diff might break a cross-cutting contract. Boundary diagnostic: reads the source a plan touches — db schema, wire envelope, auth, events — and reports violations with a pass/block verdict. Read-only; also runs on a diff. Triggers on 'boundary check', 'what could break'."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Boundary Diagnostic
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: brainstorm
|
|
3
|
-
description: "
|
|
4
|
-
argument-hint: "start | stop"
|
|
3
|
+
description: "Use when starting or stopping a large-scale design brainstorm via `/brainstorm start | stop` — never on phrases like 'let's plan' or 'let's design'. Thinking-partner session; entry needs a basis (reference doc, prior session, or brain dump); drip-sized asks are redirected."
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
# Brainstorm
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: documentation
|
|
3
|
-
description:
|
|
3
|
+
description: "Use when creating or substantively editing ANY markdown doc — invoke BEFORE writing. Templates + style authority for technical docs: LLDs, ADs, plans, changelogs, READMEs, runbooks. Owns the tense rule: truth docs state the present; history only in dated records. Baselining is the maintenance agent."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Documentation Skill
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: workflow-mapper
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when mapping a codebase's major workflows — traces call chains from user action to database or external system and produces mermaid sequence diagrams + markdown. Triggers on 'map workflows', 'trace flows', 'sequence diagram', 'how does X work end-to-end'."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Workflow Mapper Skill
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: evaluator
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when scoring a single software project for production-readiness + product quality. Takes a repo + output dir; writes a per-project workspace (README, `scorecard.yaml`, flat `raw/`) scoring 8 sub-criteria (4 Code + 4 Product) to /100 with evidence and gates. One project, no cohort."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Evaluator
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: interview-eval
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when assessing how a human steered a Claude Code session — prompting, decomposition, verification, debugging, judgment — from `.jsonl` transcripts. For interview/hiring of engineers using AI coding agents; writes a per-session report + scorecard plus a rollup. Judges the human, not the code."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# interview-eval
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@nurix/etna",
|
|
3
|
-
"version": "0.19.
|
|
3
|
+
"version": "0.19.25",
|
|
4
4
|
"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).",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|