@nurix/etna 0.18.17 → 0.18.19
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/data/harness-index.json +1 -1
- package/data/harnesses/code/harness.json +2 -2
- package/data/harnesses/code/rules/general.md +2 -1
- package/data/harnesses/etna/CLAUDE.md +99 -89
- package/data/harnesses/etna/harness.json +2 -2
- package/data/harnesses/etna/rules/general.md +2 -1
- package/data/harnesses/mobile/harness.json +2 -2
- package/data/harnesses/mobile/rules/general.md +2 -1
- package/package.json +1 -1
package/data/harness-index.json
CHANGED
|
@@ -41,6 +41,7 @@ No alternatives. Just use these.
|
|
|
41
41
|
| @monaco-editor/react | ^4.7.0 | Code editor | codemirror, ace |
|
|
42
42
|
| localforage | ^1.10.0 | Client-side storage | idb, dexie |
|
|
43
43
|
| react-markdown | ^10.1.0 | Markdown rendering | marked, markdown-it |
|
|
44
|
+
| remark-gfm | ^4.0.1 | GFM (tables, tasklists) | remark-github, custom |
|
|
44
45
|
| fast-deep-equal | ^3.1.3 | Deep equality checks | lodash.isEqual |
|
|
45
46
|
| @ngneat/falso | latest | Fake data generation | @faker-js/faker, chance |
|
|
46
47
|
| pino | ^10.1.0 | Logging | winston |
|
|
@@ -49,7 +50,7 @@ No alternatives. Just use these.
|
|
|
49
50
|
|
|
50
51
|
Tailwind v4 + shadcn-based UI; conventions below.
|
|
51
52
|
|
|
52
|
-
- **Build every UI through the `
|
|
53
|
+
- **Build every UI through the `design` skill** — route the brief through it instead of hand-rolling layouts; it owns the archetype, personality tokens, and `@nurix/components` wiring.
|
|
53
54
|
- **Light mode is the default** — design for the light theme as the default; dark mode is opt-in, never the default.
|
|
54
55
|
- **@nurix/\* are restricted-scope npm packages** — installed from the npm registry, auto-authed by a read token in `~/.npmrc`. Just attempt the install; the token authenticates you automatically. Don't pre-empt or second-guess it. If the install actually fails, flag it to the user — never reach for alternatives, a substitute package, or `npm login`.
|
|
55
56
|
- **@nurix/components** — the UI component library (restricted-scope npm package, pre-built); import by subpath, e.g. `@nurix/components/button`.
|
|
@@ -1,150 +1,160 @@
|
|
|
1
1
|
# Agent Instructions
|
|
2
2
|
|
|
3
|
-
This
|
|
3
|
+
This repo is **etna — the forge** where every Nurix harness is authored: skills, agents, rules, and harness definitions, composed into plugins and shipped to consumer repos by the `@nurix/etna` CLI. Working here means editing **authoring artifacts** — almost all markdown, plus the CLI and hook scripts (ESM JS) — not application source. etna has no `src/` app, no database, and no runtime API of its own; the code-project scaffolding you may expect (schema, wire contracts, a test suite) mostly doesn't apply, and where a rule below would in a normal repo, it's reframed for the forge.
|
|
4
|
+
|
|
5
|
+
etna governs itself with the **`etna`** harness — deliberately forked from the **`code`** harness it ships, so a capability added to `code` (a new mode, a new agent) never silently lands in the forge's own governance. Rules marked **[override]** deliberately replace a Claude Code default; the rule here wins.
|
|
4
6
|
|
|
5
7
|
---
|
|
6
8
|
|
|
7
|
-
##
|
|
9
|
+
## Maintenance
|
|
8
10
|
|
|
9
|
-
|
|
10
|
-
- Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent)
|
|
11
|
-
- Ignore **[`README.md`](README.md)** – it's for human reference only
|
|
12
|
-
- Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
|
|
13
|
-
- Look at similar modules/files and follow existing patterns
|
|
11
|
+
Invoke the `maintenance` agent whenever you judge the docs need it — not just at first setup. Standing triggers: a `harness-version` marker behind the installed version, docs contradicting the components they describe, unowned source paths, or drift you notice while working. Don't reconcile these by hand:
|
|
14
12
|
|
|
15
|
-
|
|
13
|
+
1. Invoke `maintenance` ("reconcile the harness" / "docs health"). It auto-selects its mode — baseline when the version marker is missing or behind, coherence audit otherwise — then hands back.
|
|
14
|
+
2. If it hands back a follow-up (typically the module proposal), re-invoke it to finish.
|
|
16
15
|
|
|
17
|
-
|
|
16
|
+
Each component's internals live in the component, not here.
|
|
18
17
|
|
|
19
18
|
---
|
|
20
19
|
|
|
21
|
-
##
|
|
20
|
+
## Getting Started
|
|
22
21
|
|
|
23
|
-
|
|
22
|
+
- Read **[`docs/structure.md`](docs/structure.md)** — the documentation authority map (what belongs in `architecture/`, `features/`, `operations/`, `skills/`, `history/`, `memory/`). Don't restate it here.
|
|
23
|
+
- Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent).
|
|
24
|
+
- Prefer `docs/` over `README.md` — `docs/` is canonical for agents.
|
|
25
|
+
- The CLI and hooks are the only real code — detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, else npm) for anything under `packages/`.
|
|
24
26
|
|
|
25
|
-
|
|
27
|
+
---
|
|
26
28
|
|
|
27
|
-
|
|
29
|
+
## Authoring & Distribution
|
|
28
30
|
|
|
29
|
-
|
|
31
|
+
etna authors the components it also runs and ships, so **three copies of every component exist** — know which you are editing:
|
|
30
32
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
33
|
+
| Copy | Where | Role |
|
|
34
|
+
| --- | --- | --- |
|
|
35
|
+
| **Source** (canonical) | the shared catalogs — `skills/`, `agents/`, `rules/`, plus `plugins/*/` (composition) and `harness/*/` (harness definitions) | Edit here. Etna is the source of truth. |
|
|
36
|
+
| **Dogfood** | `.claude/skills/`, `.claude/agents/`, `.claude/rules/`, `.claude/hooks/` (git-tracked) | The subset the `etna` harness installs on itself — the copy this repo actually runs this session. |
|
|
37
|
+
| **Shipped bundle** | `packages/cli/data/harnesses/*/` (gitignored, built by `packages/cli/scripts/build-data.js`) | Generated at publish. Never hand-edit. |
|
|
35
38
|
|
|
36
|
-
|
|
39
|
+
- **Keep source and dogfood in sync.** When you edit a component etna dogfoods, mirror the change into its `.claude/` copy in the same change — otherwise the skill this session runs diverges from the one you authored.
|
|
40
|
+
- **A component edit ships.** On push to `dev`, CI fingerprints the payload, patch-bumps, and publishes to the marketplace and `@nurix/etna` npm — reaching every consumer repo. Weigh catalog edits with that blast radius in mind. The pipeline authority is **[`docs/architecture/distribution.md`](docs/architecture/distribution.md)** — link, don't restate.
|
|
37
41
|
|
|
38
|
-
|
|
42
|
+
---
|
|
39
43
|
|
|
40
|
-
|
|
44
|
+
## Workflows
|
|
41
45
|
|
|
42
|
-
|
|
46
|
+
Three peer modes plus a Completion step — enter wherever the user's thinking already is. Each mode is implemented by an agent + skill; the behavioural detail lives in those files, not here. "Code" below means **authoring artifacts** — a feature LLD owns `skills/**`, `plugins/**`, `packages/cli/**`, not `src/`.
|
|
43
47
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
48
|
+
| Mode | Enter when | Implemented by | Exits to |
|
|
49
|
+
| --- | --- | --- | --- |
|
|
50
|
+
| **Brainstorming** | explicit ask (`/brainstorm start`); or the user brings a large piece of work — a new component, a design with many unknowns — most users don't know this mode exists, so recommend it: name what makes the work big and offer a session; or a user utterance contradicts a recorded design principle (a pillar) → name the principle and offer a session. Never auto-enter. | `brainstorm` agent + skill | LLD, Plan, or close + harvest |
|
|
51
|
+
| **LLD** (low-level design) | new component/feature work | `lld-mode` agent + `documentation` skill | Plan |
|
|
52
|
+
| **Plan** | an LLD is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
|
|
47
53
|
|
|
48
|
-
|
|
54
|
+
> Brainstorm entry needs a **basis** — a reference document or a one-shot brain dump; drip-sized asks (a one-line fix) are too small and get redirected. A **pillar** is a recorded strategic principle from a past brainstorm: kept records under `docs/brainstorm/`, harvested doctrine under `docs/architecture/`. The LLD is the feature doc itself — `docs/features/{feature}.md`, design intent first, extended in place at Completion.
|
|
49
55
|
|
|
50
|
-
|
|
56
|
+
**On Plan Completion:**
|
|
51
57
|
|
|
52
|
-
|
|
58
|
+
1. Freeze the plan — `Status: Complete`, fill the Completed date. The file is now frozen.
|
|
59
|
+
2. Flip the feature LLD to `status: active`; extend it in place with the how-it-works sections; confirm its `owns:` globs against the actual components.
|
|
60
|
+
3. The `boundary` skill must already have gated this plan before its first implementation step — see Ownership, Boundaries & Documentation.
|
|
53
61
|
|
|
54
|
-
|
|
55
|
-
| --- | --- | --- |
|
|
56
|
-
| `docs/memory/main.md` | Main agent | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code |
|
|
57
|
-
| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (research patterns, taxonomy, ownership conflict zones). Never user-centric. |
|
|
58
|
-
| `~/.claude/projects/...` | Auto-memory system | User preferences, role, communication style, cross-project habits |
|
|
62
|
+
**On Brainstorm Close** (when a session ends, not when a plan completes):
|
|
59
63
|
|
|
60
|
-
|
|
64
|
+
- The session record lives at `docs/brainstorm/{topic}/` (committed, one subfolder per topic) and stays in place as provenance.
|
|
65
|
+
- Harvest conclusions by scope: doctrine, glossary, non-goals, IA changes → `docs/architecture/`; decisions → `docs/architecture/adr/`; backlog items → `docs/history/backlog.md`.
|
|
66
|
+
- Open questions block close.
|
|
61
67
|
|
|
62
|
-
|
|
68
|
+
---
|
|
63
69
|
|
|
64
|
-
|
|
70
|
+
## Ownership, Boundaries & Documentation
|
|
65
71
|
|
|
66
|
-
|
|
72
|
+
These three mechanisms keep the repo self-updating: **ownership** routes you to the canonical doc before you touch a component, the **boundary** check reads both sides of every contract your change participates in so you can't ship one side of it, and **documentation** closes the loop so the next session inherits the truth. Skipping any leg breaks the other two.
|
|
67
73
|
|
|
68
|
-
|
|
69
|
-
- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
|
|
70
|
-
- Do NOT ask permission. Just append and mention it in your response.
|
|
74
|
+
### Ownership — route before you edit
|
|
71
75
|
|
|
72
|
-
|
|
76
|
+
Which doc is canonical for which paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (path globs — the only ownership key, pointing at `skills/**`, `plugins/**`, `packages/cli/**`, …), an optional `module:` label, `keywords:`, and `status:`. Path → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. Architecture docs describe cross-cutting patterns and own nothing; operations docs describe procedures.
|
|
73
77
|
|
|
74
|
-
|
|
78
|
+
Before modifying a component in an unfamiliar area:
|
|
75
79
|
|
|
76
|
-
|
|
80
|
+
1. Consult the **injected ownership index** — the `glob → doc · module · keywords · status` map. Match your path or topic to the owning feature doc and read it first. (No index in context ⇒ the repo isn't reconciled — see Maintenance.)
|
|
81
|
+
2. If a `docs/memory/` file exists for the area, read it for domain knowledge and failure modes.
|
|
77
82
|
|
|
78
|
-
|
|
83
|
+
The `lld-mode` agent checks for ownership conflicts during LLD research — feature docs whose `owns:` globs overlap at equal specificity. Resolve them in the LLD before proceeding.
|
|
79
84
|
|
|
80
|
-
|
|
85
|
+
### Boundaries — check while you change
|
|
81
86
|
|
|
82
|
-
|
|
87
|
+
etna has no db schema, wire envelope, or auth of its own — the `boundary` skill's stack mechanisms describe the contracts of the **rules etna ships**, checked in the consumer's repo, not here. etna's **own** live contracts are authoring and distribution ones, each with no static link between the two sides:
|
|
83
88
|
|
|
84
|
-
|
|
89
|
+
- a plugin `definition.md`'s `skills:` / `rules:` / `agents:` list ↔ the shared catalogs it resolves from (local-first);
|
|
90
|
+
- a component's **source ↔ `.claude/` dogfood ↔ shipped bundle** (three-way parity, per Authoring & Distribution);
|
|
91
|
+
- a hook script ↔ its `hooks.json` registration;
|
|
92
|
+
- the CLI's managed-block edits ↔ a consumer's `settings.json` / `.env`.
|
|
85
93
|
|
|
86
|
-
|
|
94
|
+
Invoke the `boundary` skill after a plan is approved and before its first implementation step — it parses the plan's Proposed Changes, reads the touched source fresh, and reports severity-ranked violations with a pass/block verdict, read-only. Fold the amendments in before coding. For a component etna ships, its boundaries also include whatever contracts that component asserts once installed in a consumer repo.
|
|
87
95
|
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
## Boundaries & Defaults
|
|
96
|
+
### Documentation — close the loop
|
|
91
97
|
|
|
92
|
-
|
|
98
|
+
- **[override]** Keep `docs/` updated when a change alters documented behaviour — creating and updating docs is part of the work.
|
|
99
|
+
- After plan completion **[override]**: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md`, no confirmation needed (include `Commits:` if multi-commit). Non-plan changes (refactors, fixes): prompt first.
|
|
100
|
+
- When you move or rename a component: update the `owns:` globs of the feature doc that owns it so the ownership index stays accurate. A new doc that owns code declares its paths in its own `owns:` frontmatter.
|
|
101
|
+
- `docs/structure.md` is the authority on what belongs where — read it before adding or moving a doc; one canonical source per topic, link don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
|
|
93
102
|
|
|
94
|
-
|
|
103
|
+
> Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
|
|
95
104
|
|
|
96
105
|
---
|
|
97
106
|
|
|
98
|
-
##
|
|
107
|
+
## Project Memory
|
|
108
|
+
|
|
109
|
+
Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in `~/.claude/` (untracked).
|
|
110
|
+
|
|
111
|
+
| File | Owner | Contents |
|
|
112
|
+
| --- | --- | --- |
|
|
113
|
+
| `docs/memory/main.md` | Main agent | Project-wide patterns, conventions confirmed in this repo, recurring failure modes, decisions whose rationale isn't obvious from the components |
|
|
114
|
+
| `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective here. Never user-centric. |
|
|
115
|
+
| `~/.claude/projects/...` | Auto-memory system | User preferences, role, communication style, cross-project habits |
|
|
99
116
|
|
|
100
|
-
-
|
|
101
|
-
- Add a 1-line function description as a comment above each function: `// Extract JWT token from request based on endpoint type`
|
|
102
|
-
- Keep related code together in a logical hierarchy.
|
|
103
|
-
- No inline comments that restate obvious code. No commented-out code. If a block of code needs a comment to be understandable, refactor for clarity instead.
|
|
117
|
+
Override the auto-memory default for project-relevant facts. When recording a learning, ask: _true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → `~/.claude/`. `docs/memory/main.md` is created on first write; append entries dated `## YYYY-MM-DD — {topic}`.
|
|
104
118
|
|
|
105
119
|
---
|
|
106
120
|
|
|
107
|
-
##
|
|
121
|
+
## Out-of-Scope Discovery
|
|
108
122
|
|
|
109
|
-
|
|
110
|
-
- Only `CLAUDE.md`, `AGENTS.md`, and `README.md` are allowed in the repository root
|
|
111
|
-
- One canonical source per topic — link, don't copy
|
|
123
|
+
When implementing a plan, if you discover work that is important but outside the current plan's scope:
|
|
112
124
|
|
|
113
|
-
|
|
125
|
+
- Append it to `docs/history/backlog.md` under the appropriate priority (P0-P3)
|
|
126
|
+
- Format: `- **[P1]** Description — discovered by [plan-name or agent-name]`
|
|
127
|
+
- Do NOT ask permission. Just append and mention it in your response.
|
|
114
128
|
|
|
115
|
-
|
|
129
|
+
---
|
|
116
130
|
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
| `docs/features/` | How implemented features work today | Living |
|
|
121
|
-
| `docs/operations/` | Setup, development, deployment | Living |
|
|
122
|
-
| `docs/history/` | Plans, changelogs, backlog | Frozen or append-only |
|
|
123
|
-
| `docs/memory/` | Project knowledge + agent state | Living |
|
|
124
|
-
| `docs/tests/` | Test plans and automation | Living |
|
|
131
|
+
## Guardrails & Defaults
|
|
132
|
+
|
|
133
|
+
❌ prohibitions hold unless the user explicitly asks otherwise; ✅ and ⚠️ items are standing policy:
|
|
125
134
|
|
|
126
|
-
|
|
135
|
+
- ❌ **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.)
|
|
136
|
+
- ❌ **Dependencies** — never upgrade frameworks, libraries, or dependencies.
|
|
137
|
+
- ❌ **Compatibility** — never maintain backward compatibility unless specified.
|
|
138
|
+
- ❌ **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.
|
|
139
|
+
- ❌ **Protected Files** — before editing, if `docs/operations/protected-files.md` exists, read it and never modify any path it lists; never modify `AGENTS.md` or that file itself.
|
|
140
|
+
- ✅ **Browser Automation** — Claude in Chrome / CDP browser tools only when the user explicitly asks.
|
|
141
|
+
- ✅ **Delegate at scale** — offload large, independent, or parallelizable work (broad research, audits, multi-file sweeps) to sub-agents with self-contained prompts; keep small, well-understood edits inline. Sub-agents can't run skills or spawn sub-agents — do that work in the main session.
|
|
142
|
+
- ⚠️ **Plans** — created directly in `docs/history/plans/` (see Workflows). Once `Status: Complete` or `Abandoned`, frozen — never edited. If scope changes after completion, write a new dated plan linking back.
|
|
143
|
+
- ⚠️ **Tool Issues** — if any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool, command, and error to the user so they can fix the underlying library.
|
|
127
144
|
|
|
128
|
-
|
|
129
|
-
- Plans: `YYYY-MM-DD-kebab-case.md` — frozen after `Complete` or `Abandoned`
|
|
130
|
-
- Changelogs: `YYYY-MM-DD-kebab-case.md` — append-only
|
|
131
|
-
- Memory: `{agent-name}.md` — agent-maintained
|
|
145
|
+
---
|
|
132
146
|
|
|
133
|
-
|
|
147
|
+
## Authoring Conventions
|
|
134
148
|
|
|
135
|
-
|
|
136
|
-
- After plan completion: create a `docs/history/changelog/YYYY-MM-DD-feature-name.md` entry + update the index in `docs/history/CHANGELOG.md` (no confirmation needed). Root-level `CHANGELOG.md` is not used — only `CLAUDE.md`, `AGENTS.md`, and `README.md` live in the repo root.
|
|
137
|
-
- Update related docs affected by the changes (use the injected ownership index — feature `owns:` globs — to find the right files)
|
|
138
|
-
- Non-plan changes (refactors, bug fixes, API changes): prompt user first
|
|
139
|
-
- Multi-commit changes: include `Commits: abc1234, def5678`
|
|
149
|
+
Most artifacts are markdown — skills, agents, rules, docs. Follow the conventions in `docs/architecture/skills/` and the `kb` / `nomenclature` rules; markdown has no file-path-comment rule. Keep the `.claude/rules/*` reference docs frontmatter-free.
|
|
140
150
|
|
|
141
|
-
|
|
151
|
+
For real code (the CLI under `packages/`, hook scripts):
|
|
142
152
|
|
|
143
|
-
|
|
153
|
+
- File-path header comment at the top, in the file's comment syntax: `// packages/cli/bin/etna.js - the installer entry`.
|
|
154
|
+
- A 1-line description above each function whose purpose isn't evident from its name and signature. A comment that restates the name is noise; no commented-out code — if a block needs a comment to be understandable, refactor instead.
|
|
144
155
|
|
|
145
|
-
|
|
146
|
-
- Verify its `owns:` globs don't overlap another feature doc's at equal specificity.
|
|
156
|
+
---
|
|
147
157
|
|
|
148
|
-
|
|
158
|
+
## Runtime Notes
|
|
149
159
|
|
|
150
|
-
-
|
|
160
|
+
etna runs in Claude Code. Sub-agent dispatch is the Agent tool; sub-agents can't run skills, spawn sub-agents, or hold the browser connection (browser work is Claude in Chrome, main session only). The user-level memory store is `~/.claude/` (auto-memory under `~/.claude/projects/...`). The ownership index and skill/agent descriptions are injected at session start; skills are invoked as slash commands (e.g. `/brainstorm start`). If pinning dispatch tiers: strong tier (opus-class) for judgment-heavy work, fast tier (sonnet-class) for mechanical fan-out — tier names go stale, re-check on model releases.
|
|
@@ -41,6 +41,7 @@ No alternatives. Just use these.
|
|
|
41
41
|
| @monaco-editor/react | ^4.7.0 | Code editor | codemirror, ace |
|
|
42
42
|
| localforage | ^1.10.0 | Client-side storage | idb, dexie |
|
|
43
43
|
| react-markdown | ^10.1.0 | Markdown rendering | marked, markdown-it |
|
|
44
|
+
| remark-gfm | ^4.0.1 | GFM (tables, tasklists) | remark-github, custom |
|
|
44
45
|
| fast-deep-equal | ^3.1.3 | Deep equality checks | lodash.isEqual |
|
|
45
46
|
| @ngneat/falso | latest | Fake data generation | @faker-js/faker, chance |
|
|
46
47
|
| pino | ^10.1.0 | Logging | winston |
|
|
@@ -49,7 +50,7 @@ No alternatives. Just use these.
|
|
|
49
50
|
|
|
50
51
|
Tailwind v4 + shadcn-based UI; conventions below.
|
|
51
52
|
|
|
52
|
-
- **Build every UI through the `
|
|
53
|
+
- **Build every UI through the `design` skill** — route the brief through it instead of hand-rolling layouts; it owns the archetype, personality tokens, and `@nurix/components` wiring.
|
|
53
54
|
- **Light mode is the default** — design for the light theme as the default; dark mode is opt-in, never the default.
|
|
54
55
|
- **@nurix/\* are restricted-scope npm packages** — installed from the npm registry, auto-authed by a read token in `~/.npmrc`. Just attempt the install; the token authenticates you automatically. Don't pre-empt or second-guess it. If the install actually fails, flag it to the user — never reach for alternatives, a substitute package, or `npm login`.
|
|
55
56
|
- **@nurix/components** — the UI component library (restricted-scope npm package, pre-built); import by subpath, e.g. `@nurix/components/button`.
|
|
@@ -41,6 +41,7 @@ No alternatives. Just use these.
|
|
|
41
41
|
| @monaco-editor/react | ^4.7.0 | Code editor | codemirror, ace |
|
|
42
42
|
| localforage | ^1.10.0 | Client-side storage | idb, dexie |
|
|
43
43
|
| react-markdown | ^10.1.0 | Markdown rendering | marked, markdown-it |
|
|
44
|
+
| remark-gfm | ^4.0.1 | GFM (tables, tasklists) | remark-github, custom |
|
|
44
45
|
| fast-deep-equal | ^3.1.3 | Deep equality checks | lodash.isEqual |
|
|
45
46
|
| @ngneat/falso | latest | Fake data generation | @faker-js/faker, chance |
|
|
46
47
|
| pino | ^10.1.0 | Logging | winston |
|
|
@@ -49,7 +50,7 @@ No alternatives. Just use these.
|
|
|
49
50
|
|
|
50
51
|
Tailwind v4 + shadcn-based UI; conventions below.
|
|
51
52
|
|
|
52
|
-
- **Build every UI through the `
|
|
53
|
+
- **Build every UI through the `design` skill** — route the brief through it instead of hand-rolling layouts; it owns the archetype, personality tokens, and `@nurix/components` wiring.
|
|
53
54
|
- **Light mode is the default** — design for the light theme as the default; dark mode is opt-in, never the default.
|
|
54
55
|
- **@nurix/\* are restricted-scope npm packages** — installed from the npm registry, auto-authed by a read token in `~/.npmrc`. Just attempt the install; the token authenticates you automatically. Don't pre-empt or second-guess it. If the install actually fails, flag it to the user — never reach for alternatives, a substitute package, or `npm login`.
|
|
55
56
|
- **@nurix/components** — the UI component library (restricted-scope npm package, pre-built); import by subpath, e.g. `@nurix/components/button`.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@nurix/etna",
|
|
3
|
-
"version": "0.18.
|
|
3
|
+
"version": "0.18.19",
|
|
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": {
|