@nurix/etna 0.20.36 → 0.20.38
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/catalog/rules/frontend.md +5 -5
- package/data/catalog/rules/pnpm.md +2 -2
- package/data/catalog/skills/nustack/SKILL.md +2 -2
- package/data/catalog/skills/nustack/references/cli-design.md +35 -35
- package/data/catalog/skills/nustack/references/monorepo-master-list.md +6 -6
- package/data/catalog/skills/nustack/references/monorepo-setup.md +13 -13
- package/data/catalog/skills/nustack/references/publishing.md +40 -39
- package/data/harness-index.json +1 -1
- package/data/harnesses/code/harness.json +2 -2
- package/data/harnesses/code/hooks/approved-packages.md +1 -2
- package/data/harnesses/code/rules/frontend.md +5 -5
- package/data/harnesses/code/rules/pnpm.md +2 -2
- package/data/harnesses/code/skills/boundary/SKILL.md +33 -22
- package/data/harnesses/code/skills/boundary/references/index.md +2 -4
- package/data/harnesses/code/skills/boundary/references/mechanisms.md +3 -10
- package/data/harnesses/code/skills/boundary/references/packs/build-config-runtime.md +1 -1
- package/data/harnesses/code/skills/boundary/references/packs/frontend.md +17 -17
- package/data/harnesses/code/skills/boundary/references/packs/generic-tail.md +1 -1
- package/data/harnesses/code/skills/brainstorm/README.md +11 -13
- package/data/harnesses/code/skills/brainstorm/SKILL.md +150 -132
- package/data/harnesses/code/skills/brainstorm/references/doctrine.md +48 -51
- package/data/harnesses/code/skills/brainstorm/references/harvest.md +51 -56
- package/data/harnesses/code/skills/brainstorm/references/session-schema.md +48 -42
- package/data/harnesses/code/skills/design/SKILL.md +31 -35
- package/data/harnesses/code/skills/design/components/charts.md +121 -43
- package/data/harnesses/code/skills/design/components/collections.md +209 -41
- package/data/harnesses/code/skills/design/components/feedback.md +86 -25
- package/data/harnesses/code/skills/design/components/hooks.md +198 -12
- package/data/harnesses/code/skills/design/components/index.md +93 -71
- package/data/harnesses/code/skills/design/components/inputs.md +249 -157
- package/data/harnesses/code/skills/design/components/layout.md +98 -38
- package/data/harnesses/code/skills/design/components/media.md +46 -25
- package/data/harnesses/code/skills/design/components/motion.md +56 -46
- package/data/harnesses/code/skills/design/components/navigation.md +54 -15
- package/data/harnesses/code/skills/design/components/overlays.md +51 -41
- package/data/harnesses/code/skills/design/components/setup.md +84 -5
- package/data/harnesses/code/skills/design/components/typography.md +72 -22
- package/data/harnesses/code/skills/design/components/utils.md +47 -13
- package/data/harnesses/code/skills/design/data/chrome/board-column.md +12 -12
- package/data/harnesses/code/skills/design/data/chrome/data-table.md +6 -6
- package/data/harnesses/code/skills/design/data/chrome/side-panel.md +15 -15
- package/data/harnesses/code/skills/design/data/chrome/sidebar.md +25 -25
- package/data/harnesses/code/skills/design/data/chrome/stat-cards.md +22 -22
- package/data/harnesses/code/skills/design/data/chrome/topbar.md +12 -12
- package/data/harnesses/code/skills/design/data/iconography.md +2 -2
- package/data/harnesses/code/skills/design/references/compose.md +14 -16
- package/data/harnesses/code/skills/design/references/emission.md +6 -6
- package/data/harnesses/code/skills/design/references/foundations.md +5 -5
- package/data/harnesses/code/skills/design/references/intake.md +6 -6
- package/data/harnesses/code/skills/design/references/object-pass.md +1 -1
- package/data/harnesses/code/skills/design/references/ship-gate.md +5 -5
- package/data/harnesses/code/skills/design/references/ux-patterns/Readme.md +4 -4
- package/data/harnesses/code/skills/design/references/ux-patterns/ai-layer.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/container-choice.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/dashboards.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/modes.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/object-model.md +2 -2
- package/data/harnesses/code/skills/design/references/ux-patterns/promotion-demotion.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/settings.md +1 -1
- package/data/harnesses/code/skills/design/references/ux-patterns/standard-pages.md +1 -1
- package/data/harnesses/code/skills/design/scripts/README-validator.md +20 -8
- package/data/harnesses/code/skills/design/scripts/validate-design-md.mjs +15 -10
- package/data/harnesses/code/skills/documentation/SKILL.md +5 -5
- package/data/harnesses/code/skills/documentation/references/examples.md +22 -22
- package/data/harnesses/code/skills/documentation/references/frontmatter.md +3 -3
- package/data/harnesses/code/skills/documentation/references/instruction-style.md +3 -3
- package/data/harnesses/code/skills/documentation/references/source-comments.md +3 -3
- package/data/harnesses/code/skills/documentation/references/style-guide.md +5 -5
- package/data/harnesses/code/skills/documentation/references/untemplated.md +8 -8
- package/data/harnesses/code/skills/documentation/scripts/doc-lint.mjs +3 -2
- package/data/harnesses/code/skills/documentation/templates/Readme.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/acceptance-criteria.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/api-reference.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/architecture-decision.md +3 -7
- package/data/harnesses/code/skills/documentation/templates/behavioral-checklist.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/changelog-entry.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/changelog-index.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/docs-readme.md +3 -3
- package/data/harnesses/code/skills/documentation/templates/doctrine.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/domain-model.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/environment-registry.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/feature.md +3 -3
- package/data/harnesses/code/skills/documentation/templates/handover.md +2 -2
- package/data/harnesses/code/skills/documentation/templates/implementation-map.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/migration-runbook.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/non-goals.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/operations-procedure.md +2 -2
- package/data/harnesses/code/skills/documentation/templates/package.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/protected-files.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/root-readme.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/security-overview.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/system-overview.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/system.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/testing-strategy.md +1 -1
- package/data/harnesses/code/skills/documentation/templates/ux-behavior.md +3 -5
- package/data/harnesses/code/skills/issue-bridge/SKILL.md +51 -16
- package/data/harnesses/code/skills/issue-bridge/references/trackers/github.md +5 -5
- package/data/harnesses/code/skills/issue-bridge/references/trackers/jira.md +11 -8
- package/data/harnesses/code/skills/issue-bridge/references/trackers/linear.md +16 -11
- package/data/harnesses/code/skills/nustack-graph/SKILL.md +38 -29
- package/data/harnesses/code/skills/polygraph/references/dispatch.md +31 -18
- package/data/harnesses/code/skills/polygraph/references/rows.md +11 -6
- package/data/harnesses/code/skills/schema-design/SKILL.md +39 -41
- package/data/harnesses/code/skills/test/SKILL.md +38 -42
- package/data/harnesses/code/skills/testing/SKILL.md +83 -73
- package/data/harnesses/code/skills/workflow-mapper/SKILL.md +156 -193
- package/data/harnesses/code/skills/workflow-mapper/references/patterns.md +15 -15
- package/data/harnesses/delivery/harness.json +2 -2
- package/data/harnesses/delivery/skills/brainstorm/README.md +11 -13
- package/data/harnesses/delivery/skills/brainstorm/SKILL.md +150 -132
- package/data/harnesses/delivery/skills/brainstorm/references/doctrine.md +48 -51
- package/data/harnesses/delivery/skills/brainstorm/references/harvest.md +51 -56
- package/data/harnesses/delivery/skills/brainstorm/references/session-schema.md +48 -42
- package/data/harnesses/delivery/skills/cost-report/SKILL.md +10 -10
- package/data/harnesses/delivery/skills/documentation/SKILL.md +5 -5
- package/data/harnesses/delivery/skills/documentation/references/examples.md +22 -22
- package/data/harnesses/delivery/skills/documentation/references/frontmatter.md +3 -3
- package/data/harnesses/delivery/skills/documentation/references/instruction-style.md +3 -3
- package/data/harnesses/delivery/skills/documentation/references/source-comments.md +3 -3
- package/data/harnesses/delivery/skills/documentation/references/style-guide.md +5 -5
- package/data/harnesses/delivery/skills/documentation/references/untemplated.md +8 -8
- package/data/harnesses/delivery/skills/documentation/scripts/doc-lint.mjs +3 -2
- package/data/harnesses/delivery/skills/documentation/templates/Readme.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/acceptance-criteria.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/api-reference.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/architecture-decision.md +3 -7
- package/data/harnesses/delivery/skills/documentation/templates/behavioral-checklist.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/changelog-entry.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/changelog-index.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/docs-readme.md +3 -3
- package/data/harnesses/delivery/skills/documentation/templates/doctrine.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/domain-model.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/environment-registry.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/feature.md +3 -3
- package/data/harnesses/delivery/skills/documentation/templates/handover.md +2 -2
- package/data/harnesses/delivery/skills/documentation/templates/implementation-map.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/migration-runbook.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/non-goals.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/operations-procedure.md +2 -2
- package/data/harnesses/delivery/skills/documentation/templates/package.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/protected-files.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/root-readme.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/security-overview.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/system-overview.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/system.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/testing-strategy.md +1 -1
- package/data/harnesses/delivery/skills/documentation/templates/ux-behavior.md +3 -5
- package/data/harnesses/delivery/skills/escalate/SKILL.md +11 -11
- package/data/harnesses/delivery/skills/prompt-eval/SKILL.md +8 -8
- package/data/harnesses/delivery/skills/prompt-library/SKILL.md +30 -9
- package/data/harnesses/delivery/skills/route/SKILL.md +8 -8
- package/data/harnesses/etna/harness.json +2 -2
- package/data/harnesses/etna/skills/boundary/SKILL.md +33 -22
- package/data/harnesses/etna/skills/boundary/references/index.md +2 -4
- package/data/harnesses/etna/skills/boundary/references/mechanisms.md +3 -10
- package/data/harnesses/etna/skills/boundary/references/packs/build-config-runtime.md +1 -1
- package/data/harnesses/etna/skills/boundary/references/packs/frontend.md +17 -17
- package/data/harnesses/etna/skills/boundary/references/packs/generic-tail.md +1 -1
- package/data/harnesses/etna/skills/brainstorm/README.md +11 -13
- package/data/harnesses/etna/skills/brainstorm/SKILL.md +150 -132
- package/data/harnesses/etna/skills/brainstorm/references/doctrine.md +48 -51
- package/data/harnesses/etna/skills/brainstorm/references/harvest.md +51 -56
- package/data/harnesses/etna/skills/brainstorm/references/session-schema.md +48 -42
- package/data/harnesses/etna/skills/documentation/SKILL.md +5 -5
- package/data/harnesses/etna/skills/documentation/references/examples.md +22 -22
- package/data/harnesses/etna/skills/documentation/references/frontmatter.md +3 -3
- package/data/harnesses/etna/skills/documentation/references/instruction-style.md +3 -3
- package/data/harnesses/etna/skills/documentation/references/source-comments.md +3 -3
- package/data/harnesses/etna/skills/documentation/references/style-guide.md +5 -5
- package/data/harnesses/etna/skills/documentation/references/untemplated.md +8 -8
- package/data/harnesses/etna/skills/documentation/scripts/doc-lint.mjs +3 -2
- package/data/harnesses/etna/skills/documentation/templates/Readme.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/acceptance-criteria.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/api-reference.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/architecture-decision.md +3 -7
- package/data/harnesses/etna/skills/documentation/templates/behavioral-checklist.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/changelog-entry.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/changelog-index.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/docs-readme.md +3 -3
- package/data/harnesses/etna/skills/documentation/templates/doctrine.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/domain-model.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/environment-registry.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/feature.md +3 -3
- package/data/harnesses/etna/skills/documentation/templates/handover.md +2 -2
- package/data/harnesses/etna/skills/documentation/templates/implementation-map.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/migration-runbook.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/non-goals.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/operations-procedure.md +2 -2
- package/data/harnesses/etna/skills/documentation/templates/package.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/protected-files.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/root-readme.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/security-overview.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/system-overview.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/system.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/testing-strategy.md +1 -1
- package/data/harnesses/etna/skills/documentation/templates/ux-behavior.md +3 -5
- package/data/harnesses/etna/skills/workflow-mapper/SKILL.md +156 -193
- package/data/harnesses/etna/skills/workflow-mapper/references/patterns.md +15 -15
- package/data/harnesses/hr/harness.json +2 -2
- package/data/harnesses/hr/skills/evaluator/SKILL.md +71 -73
- package/data/harnesses/hr/skills/evaluator/criteria/code-quality.md +28 -47
- package/data/harnesses/hr/skills/evaluator/criteria/deployment-readiness.md +33 -43
- package/data/harnesses/hr/skills/evaluator/criteria/maintainability.md +34 -46
- package/data/harnesses/hr/skills/evaluator/criteria/mechanical-ambition.md +13 -13
- package/data/harnesses/hr/skills/evaluator/criteria/problem-substantiveness.md +7 -7
- package/data/harnesses/hr/skills/evaluator/criteria/testing.md +36 -41
- package/data/harnesses/hr/skills/evaluator/criteria/ux-mechanics.md +25 -11
- package/data/harnesses/hr/skills/evaluator/criteria/value-articulation.md +7 -7
- package/data/harnesses/hr/skills/evaluator/preflight.md +27 -46
- package/data/harnesses/hr/skills/interview-eval/SKILL.md +37 -42
- package/data/harnesses/hr/skills/interview-eval/rubric.md +21 -23
- package/package.json +2 -2
|
@@ -2,17 +2,17 @@
|
|
|
2
2
|
|
|
3
3
|
Load when: writing or sweeping source-file comments, or cutting a comment whose claim belongs in a document. Not needed to write a document.
|
|
4
4
|
|
|
5
|
-
**In `docs/`, never in the file's comments** — and this skill is the half of that rule that makes it safe. A source file carries a repo-relative path header of two or three present-tense sentences and one third-person sentence above each non-obvious function; the shape is the harness's `CLAUDE.md` § File Structure
|
|
5
|
+
**In `docs/`, never in the file's comments** — and this skill is the half of that rule that makes it safe. A source file carries a repo-relative path header of two or three present-tense sentences and one third-person sentence above each non-obvious function; the canonical shape is the harness's `CLAUDE.md` § File Structure. That header's `docs/…` path is also the file's edge into the knowledge graph: the header pointer names the document that speaks for the file, which is how ownership is computed ([`frontmatter.md`](frontmatter.md)). What lands **here** is everything that shape displaces: design rationale, the alternatives weighed, the measurement behind a constant, the reason an obvious-looking change is wrong.
|
|
6
6
|
|
|
7
7
|
**Cutting a comment is a move, not a deletion.** A claim taken out of a source file is owed one of two things before the cut is done, and the choice is per claim, not per file:
|
|
8
8
|
|
|
9
9
|
| The claim is | What it earns |
|
|
10
10
|
| --- | --- |
|
|
11
11
|
| Worth keeping, and its doc does not state it | A section in the **owning feature doc** (the ownership index resolves which), carrying the claim and the argument for why the codebase is worse without it — never the comment's wording, which was written for a reader holding the code |
|
|
12
|
-
| Already stated in its doc | Nothing
|
|
12
|
+
| Already stated in its doc | Nothing, once you **open that doc and find the sentence**. An assumed duplicate is how a claim is lost |
|
|
13
13
|
| History, a ticket or decision-record reference, a dated note, a divider, or narration of code that no longer exists | Nothing, and no record. A record lives in `docs/history/`; these are not claims about the present |
|
|
14
14
|
|
|
15
|
-
**Count what you cut, and prove the cut was only comments.** A comment sweep states comment lines before and after per file, so
|
|
15
|
+
**Count what you cut, and prove the cut was only comments.** A comment sweep states comment lines before and after per file, so an unaccounted drop shows as a number. [`scripts/comment-strip.mjs`](../scripts/comment-strip.mjs) turns that from a claim into a check: it strips comments from both revisions — honouring strings, template and character literals, regex literals, raw strings and JSX comment braces — and diffs what is left, so a sweep that quietly changed executable code cannot pass as a cleanup. `comment-strip.mjs --rev <before> --to <after> <paths…>` exits 0 for "no executable code changed" and 1 naming the file and the first diverging line. Run it over any pass that touches more than a handful of files; a sweep without it is an assertion.
|
|
16
16
|
|
|
17
17
|
**The mechanical half of the shape is checked, not remembered.** [`scripts/source-lint.mjs`](../scripts/source-lint.mjs) `--changed` reports a header that names another path or none, a change whose added lines are over a quarter comments, and the four shapes the convention deletes outright — narration, ALL-CAPS emphasis, an over-long header, a comment block that has become a document. Block-severity findings must be fixed; the escape hatch is a `source-lint-disable: <id>` comment with the reason in a second comment beside it, and the only finding that legitimately takes one is a booby trap. The harness detector raises a bookkeeping row for the same condition, so an unfixed breach outlives the session that wrote it.
|
|
18
18
|
|
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
<!-- doc-lint-disable: date-in-truth-doc, history-narration, stale-tripwire, progress-marker, temporal-hedge, predecessor-frame, status-glyph -->
|
|
2
2
|
<!-- reason: the style authority quotes the forbidden constructions verbatim in its ❌ columns; each match is an example of what not to write. -->
|
|
3
3
|
|
|
4
|
-
# Documentation
|
|
4
|
+
# Documentation style guide
|
|
5
5
|
|
|
6
|
-
This guide states how a document is written: every file under `docs/` and every README the `documentation` skill authors or edits. Two neighbouring authorities answer the questions beside it
|
|
6
|
+
This guide states how a document is written: every file under `docs/` and every README the `documentation` skill authors or edits. Two neighbouring authorities answer the questions beside it: [`instruction-style.md`](instruction-style.md) governs the files an agent obeys (`CLAUDE.md`, rules, agents, skill prose), which are paid for on every load and written lean, and each template in [`templates/`](../templates/Readme.md) governs its genre's sections and fields. The first two sections are enough to write a correct document; the sections after them are the detail each principle unfolds into, so a reader who stops early holds a coarse picture that is true.
|
|
7
7
|
|
|
8
8
|
## The model
|
|
9
9
|
|
|
@@ -75,7 +75,7 @@ The test (principle 3) decides what a sentence may say. These survive it:
|
|
|
75
75
|
|
|
76
76
|
Unbuilt work has one home per kind. Decided design the code does not do yet is an `UNBUILT` block where the design is stated; a shortfall in what is built (a promise the code does not keep, a case it mishandles) is one bullet under Gaps; the work that would close either is a backlog row, and the document never tracks that work's progress.
|
|
77
77
|
|
|
78
|
-
The authority split (principle 4) is stated once, where agents enter the docs (the root instruction file or `docs/README.md`), so a reader who finds the code and the document disagreeing knows which way to resolve it. A doctrine document restates it in its
|
|
78
|
+
The authority split (principle 4) is stated once, where agents enter the docs (the root instruction file or `docs/README.md`), so a reader who finds the code and the document disagreeing knows which way to resolve it. A doctrine document restates it in its opening, as the authority sentence (`templates/doctrine.md`), where its readers would otherwise not know; a feature, package or system document never does, because its opening is fixed to its goal.
|
|
79
79
|
|
|
80
80
|
### Diagrams and length by layer
|
|
81
81
|
|
|
@@ -131,7 +131,7 @@ A feature, package or system document is scanned more than read (principle 6). I
|
|
|
131
131
|
| System | Opening paragraph (the machine defined) · Scope · Flow · Decisions · Promises · Gaps · For the agent |
|
|
132
132
|
| Package | Identity line · Goal line · Scope · Ownership · Usage · Decisions · Promises · Gaps · For the agent |
|
|
133
133
|
|
|
134
|
-
Nothing else. "Why it exists"
|
|
134
|
+
Nothing else. A "Why it exists" section has no place; its content is Scope or Decisions. Mechanism sections (Architecture, Key Functions, State, Files, Schema, Routes, Wire, and their kin) are the graph's, and `doc-lint` blocks them as `mechanism-section`. The templates say when each section is required and how long each genre runs.
|
|
135
135
|
|
|
136
136
|
### The body
|
|
137
137
|
|
|
@@ -269,7 +269,7 @@ flowchart LR
|
|
|
269
269
|
|
|
270
270
|
## Reference documents
|
|
271
271
|
|
|
272
|
-
A reference document is the deepest genre: signatures, shapes and variables are its content, so the stability test does not apply to it (§ The genres). These rules bind only there, and in a procedure's appendix; an owning document names a symbol
|
|
272
|
+
A reference document is the deepest genre: signatures, shapes and variables are its content, so the stability test does not apply to it (§ The genres). These rules bind only there, and in a procedure's appendix; an owning document names a symbol only as a seam (§ Owning documents — the body and the footer).
|
|
273
273
|
|
|
274
274
|
### Function signatures
|
|
275
275
|
|
|
@@ -1,28 +1,28 @@
|
|
|
1
|
-
# Writing an
|
|
1
|
+
# Writing an untemplated document
|
|
2
2
|
|
|
3
3
|
Load when: no template in [`templates/`](../templates/Readme.md) matches the document being written — a design note, a comparison, an investigation writeup, an index, a reference sheet, anything the Routing table sends to "no template matches".
|
|
4
4
|
|
|
5
5
|
A template is a pre-made set of shape decisions. With no template, make the same decisions explicitly, in this order.
|
|
6
6
|
|
|
7
|
-
## 1. Decide the nature — truth or
|
|
7
|
+
## 1. Decide the nature — truth, record or queue
|
|
8
8
|
|
|
9
|
-
Every document is exactly one (`SKILL.md` § The three natures). Ask: *when reality changes, is this file rewritten, frozen, or does it lose a row?*
|
|
9
|
+
Every document is exactly one of the three (`SKILL.md` § The three natures). Ask: *when reality changes, is this file rewritten, frozen, or does it lose a row?*
|
|
10
10
|
|
|
11
|
-
- Rewritten in place → **truth document**. Topic-named (`kebab-case.md`), lives outside `docs/history/`, present tense throughout
|
|
12
|
-
- A list of open work whose rows are added and deleted → **queue**. A fixed name, one row per item; extend an existing queue before inventing one.
|
|
11
|
+
- Rewritten in place → **truth document**. Topic-named (`kebab-case.md`), lives outside `docs/history/`, present tense throughout.
|
|
13
12
|
- Frozen → **record**. Date-named (`YYYY-MM-DD-slug.md`), lives in `docs/history/` — inside an existing subfolder where it fits (an investigation or research writeup → `history/research/{topic}/`); a genuinely new category of record needs a `docs/structure.md` folder-rule row in the same change, never an invented folder.
|
|
13
|
+
- Loses a row when work is resolved → **queue**. A fixed name, one row per item; extend an existing queue before inventing one.
|
|
14
14
|
|
|
15
15
|
When a draft wants to be both — the current state *and* the story of getting there — split it: the state becomes a truth document, the story becomes a record that links to it. Never mix the natures in one body.
|
|
16
16
|
|
|
17
17
|
## 2. Place and name it
|
|
18
18
|
|
|
19
19
|
- `docs/structure.md` is the placement authority — match the document's topic to its folder map before inventing a location.
|
|
20
|
-
- **One canonical home per topic.** If a document on the topic already exists, extend it; a second document on the same topic is drift
|
|
20
|
+
- **One canonical home per topic.** If a document on the topic already exists, extend it; a second document on the same topic is drift. Link, don't copy.
|
|
21
21
|
- A new topic *folder* gets a `Readme.md` landing page that describes what the folder holds and how its files are named, never a row per file (`type: folder-index`).
|
|
22
22
|
|
|
23
23
|
## 3. Shape it
|
|
24
24
|
|
|
25
|
-
- **Open with the goal.** The first line under the H1 states what the document is for and who reads it
|
|
25
|
+
- **Open with the goal.** The first line under the H1 states what the document is for and who reads it, so a reader landing cold decides in one sentence whether to keep reading.
|
|
26
26
|
- **Headings are noun phrases** — no verb, no tense, no person (`references/style-guide.md` § Labels).
|
|
27
27
|
- **Headings are retrieval keys.** Sections get pulled out of context by search and agents; qualify generic headings with the topic (`## Merge rules — data sync`, not `## Rules`) so each stands alone.
|
|
28
28
|
- **Tables for enumerable facts, prose for judgment.** One row per item; anything needing a *because* lives in prose around the table, never inside a cell.
|
|
@@ -38,4 +38,4 @@ When a draft wants to be both — the current state *and* the story of getting t
|
|
|
38
38
|
|
|
39
39
|
**Stage 1 — context gathering.** Read what already exists on the topic, then draft the structure from §1–3 with sensible defaults for audience, purpose and format. Ask only the questions whose answer the repository cannot give and a default would get wrong (usually one to three), each with your recommended answer, in one message.
|
|
40
40
|
|
|
41
|
-
**Stage 2 — draft.** Show the structure with the questions, then draft the whole document on the answers or the defaults.
|
|
41
|
+
**Stage 2 — draft.** Show the structure with the questions, then draft the whole document on the answers or the defaults. Learn the user's style from the changes they make, and **never** silently rewrite their edits.
|
|
@@ -234,8 +234,9 @@ function lintFile(path, findings) {
|
|
|
234
234
|
findings.push({ path, n: 1, severity: 'block', id: 'record-type-in-truth-location', message: `\`type: ${declared}\` is a record genre declared in a truth location — move the file to \`docs/history/\` if it is a record, or give it its location's genre` });
|
|
235
235
|
}
|
|
236
236
|
|
|
237
|
-
// A folder index (Readme.md/README.md) is a browse page
|
|
238
|
-
|
|
237
|
+
// A folder index (Readme.md/README.md) is a browse page that owns no code; a Readme declaring an owning genre is
|
|
238
|
+
// that folder's landing document and is graded as its genre instead.
|
|
239
|
+
const isFolderIndex = /(^|\/)(readme)\.md$/i.test(path) && !['feature', 'package', 'system'].includes(declaredType(text));
|
|
239
240
|
|
|
240
241
|
// An index names folders, never files (SKILL.md § Indexes and descriptions). A link from a folder index or
|
|
241
242
|
// the authority map to an individual document is a row that must be edited on every add, rename
|
|
@@ -61,7 +61,7 @@ Every fact about a genre lives in one row of the table below: its template, its
|
|
|
61
61
|
|
|
62
62
|
## Ownership
|
|
63
63
|
|
|
64
|
-
Three genres speak for code — **feature**, **package**, **system** — and a **UX** document speaks for a surface's components where none of them does (`ux-behavior.md`). A document names the objects it designs in `objects:`; a source file names the document that speaks for it in its path header. The harness's ownership scan reads one edge
|
|
64
|
+
Three genres speak for code — **feature**, **package**, **system** — and a **UX** document speaks for a surface's components where none of them does (`ux-behavior.md`). A document names the objects it designs in `objects:`; a source file names the document that speaks for it in its path header. The harness's ownership scan reads one edge, the transitional `owns:` region glob on each owning document (`packages/{name}/**` on a package, a machine's subtrees on a system, a feature's own directory on a feature), and the narrower glob wins. The header pointer is written alongside it so the scan can switch to it and the object closure without a second pass over the code (`references/frontmatter.md`).
|
|
65
65
|
|
|
66
66
|
## Baseline scaffolds
|
|
67
67
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Acceptance
|
|
1
|
+
# Acceptance criteria
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the promises one capability must keep, stated as machine-parseable claims. Lives in `docs/acceptance/`, one `kebab-case.md` per capability. Written at specification time — before implementation — and read by verification surfaces, which parse each `AC-n` line as a claim to grade the built product against.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# API
|
|
1
|
+
# API reference (docs/architecture/api.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the consolidated catalog of the system's HTTP surface — every live route in one place. This is the **reference document** for the API surface: a route's shape lives here or in the generated spec, never in a feature doc, which states what the route promises and leaves its shape to this catalog. If the repo generates an OpenAPI spec, this doc points at it and carries only what the spec can't (auth model, conventions, ownership links).
|
|
4
4
|
|
|
@@ -24,7 +24,7 @@ Don't write an AD for:
|
|
|
24
24
|
|
|
25
25
|
`Proposed` → `Accepted` → `Deprecated`
|
|
26
26
|
|
|
27
|
-
Frontmatter `status:` is the single lifecycle source of truth. An AD stays `Accepted` for as long as its subject is live — revisions rewrite the body and never change the status, and there is **no `Superseded` state**: supersession is an edit plus a changelog entry, not a new document. Set `Deprecated` only when the subject itself is retired (the component is gone, the contract no longer exists); state where the replacement lives, if any.
|
|
27
|
+
Frontmatter `status:` is the single lifecycle source of truth; **never** also write "Status: Accepted" in the body. An AD stays `Accepted` for as long as its subject is live — revisions rewrite the body and never change the status, and there is **no `Superseded` state**: supersession is an edit plus a changelog entry, not a new document. Set `Deprecated` only when the subject itself is retired (the component is gone, the contract no longer exists); state where the replacement lives, if any.
|
|
28
28
|
|
|
29
29
|
### Naming
|
|
30
30
|
|
|
@@ -110,12 +110,8 @@ reviewers: [] # optional
|
|
|
110
110
|
|
|
111
111
|
### Rules
|
|
112
112
|
|
|
113
|
-
- **One subject per AD; all its revisions stay inside it.** Two genuinely different subjects means two ADs — a revision of an existing subject never does.
|
|
114
|
-
- **The body is always the current truth.** Rewrite affected sections on every revision; never leave a superseded choice narrated in the body — the Decision Changelog carries the journey, with each entry naming the old choice and the trigger.
|
|
115
|
-
- Decision-first. The first paragraph after the heading is the answer; readers should not need to scroll.
|
|
116
113
|
- **Consequences lists positives, negatives, AND risks.** Pros-only Consequences is the genre's classic failure — one AD's honest resulting context is the input context for the next.
|
|
117
114
|
- **Options Considered keeps every genuinely rejected alternative with the real reason.** Informed rejections are the most expensive knowledge to lose; a rejection made with strong prior art in view says so explicitly.
|
|
118
115
|
- **Keep it short — one to two pages.** Long decision docs don't get updated. How-it-works detail belongs in the owning feature doc; execution in a plan. Link, don't embed.
|
|
119
|
-
- No section numbering (`§5.1.1`)
|
|
120
|
-
-
|
|
121
|
-
- The Decision Changelog is append-only, newest first. Typo and formatting fixes don't get entries.
|
|
116
|
+
- **No section numbering** (`§5.1.1`); markdown headings only, so inserting a section renumbers nothing.
|
|
117
|
+
- **The Decision Changelog is append-only, newest first**, one entry per revision naming the old choice and the trigger. Typo and formatting fixes get no entry.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Behavioral
|
|
1
|
+
# Behavioral checklist (docs/tests/{feature}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: **how to verify one feature's promised behavior by driving the real product** — the browser, the CLI binary, HTTP against the running service. One file per feature, named for the feature doc that owns the code (`docs/features/auth.md` → `docs/tests/auth.md`).
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Changelog
|
|
1
|
+
# Changelog entry
|
|
2
2
|
|
|
3
3
|
Record. Use for: the per-unit-of-work journal of what changed and how it was refined — one file per entry under `docs/history/changelog/YYYY-MM-DD-{three-words}.md`, written by whoever does the work and frozen inside the commit it describes. The three words name the work, not the commit. Trigger and lifecycle policy: the `changelog` rule; distillation is the `retro` agent.
|
|
4
4
|
|
|
@@ -22,7 +22,7 @@ description: "How {Project Name}'s changelog works: one entry per unit of work u
|
|
|
22
22
|
## Owed entries
|
|
23
23
|
|
|
24
24
|
- **Plan completion:** a draft entry, written when the plan reaches `Status: Complete`.
|
|
25
|
-
- **Commit:** every non-exempt commit carries its entry inside it (the
|
|
25
|
+
- **Commit:** every non-exempt commit carries its entry inside it (the closed exemption list is the `documentation` skill's `templates/changelog-entry.md`).
|
|
26
26
|
|
|
27
27
|
## Reading the changelog
|
|
28
28
|
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
# docs/README.md (
|
|
1
|
+
# docs/README.md (documentation root)
|
|
2
2
|
|
|
3
|
-
Truth document. Use for: the entry point for all documentation in a repo
|
|
3
|
+
Truth document. Use for: the entry point for all documentation in a repo, created by the `maintenance` agent's baseline.
|
|
4
4
|
|
|
5
|
-
**This file describes directories, never files.** Each section names one folder under `docs/` and says what the folder holds, who reads it and how its files are named
|
|
5
|
+
**This file describes directories, never files.** Each section names one folder under `docs/` and says what the folder holds, who reads it and how its files are named. No per-file rows, no file tree, no `├──` block: the tree is `structure.md`'s, as the authority on placement, and `ls` is the roster. A row per file forces an index edit on every file added, renamed or retired, so the index's history records roster churn instead of what the index said. Naming a file without a link is the same row: no filename, no record ID (`AD-010`), no per-record table. The only files an index may name are the mandated scaffolds and the root instruction files (`SKILL.md` § Indexes and descriptions). Each file's own `description:` frontmatter is its account, read with `grep -m1 '^description:' <folder>/*.md`. `doc-lint` blocks a folder index that links an individual document (`index-lists-files`), names one (`index-names-records`) or draws a tree (`index-file-tree`). The repo-root `README.md` routes the team and agents in by intent and this file describes the folders of the docs tree; each links the other once and neither restates the other.
|
|
6
6
|
|
|
7
7
|
**Link only what exists.** Every row below is a placeholder — drop any whose target the repo does not have. Most `history/` and `architecture/` folders are created on first use, so linking them unconditionally ships a docs index with dead links on day one. An index is a browse page: a link that resolves to nothing is worse than an absent row.
|
|
8
8
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Doctrine
|
|
1
|
+
# Doctrine documentation (docs/architecture/common/{concern}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for **one concern the platform handles everywhere**: authentication, authorization, storage, the API protocol, credentials, telemetry. One file per concern, named for the concern. A doctrine document speaks for no code: no source header names it, and it carries no `owns:`. The surfaces bound by it are the documents that design or touch the objects it governs, computed through those objects, and each names it in its Scope.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Domain
|
|
1
|
+
# Domain model (docs/architecture/domain-model.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the entities the system is about — what they are, how they relate, and who owns their state. The vocabulary here must match the glossary and the code; when they disagree, fix the disagreement, don't document around it.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Feature
|
|
1
|
+
# Feature documentation (docs/features/{feature}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for every feature in `docs/features/`: something a person points at, such as an address, a command family or a named control. One file per feature, cut by the objects it designs, never by the code's routers, tables, plans or packages. The file persists from design (`status: draft`) to live reference (`status: active`).
|
|
4
4
|
|
|
@@ -8,9 +8,9 @@ Truth document. Use for every feature in `docs/features/`: something a person po
|
|
|
8
8
|
- **Each bullet is a bold label, then one or two third-person sentences** saying what happens: "**Organization user:** user lands in their existing organization", never "you land…".
|
|
9
9
|
- **Flows carry the journey; Decisions carry the reasons; Promises run deepest.**
|
|
10
10
|
|
|
11
|
-
The frontmatter names the objects the feature designs; which files it speaks for is never listed in the body. The ownership scan reads its transitional `owns:` region glob
|
|
11
|
+
The frontmatter names the objects the feature designs; which files it speaks for is never listed in the body. The ownership scan reads its transitional `owns:` region glob, and each owned source file's header names this document, ready for when the scan switches (`references/frontmatter.md`). Every computable fact (columns, vocabularies, foreign keys, writers, routes, guards, files) is the code graph's (`docs/architecture/systems/knowledge-layer.md`), and a hand-typed copy is the defect this genre removes. Code is named only where a person types or sees it (a page, a command, a flag, an environment variable) or at a cross-cutting seam the graph would not lead a reader to.
|
|
12
12
|
|
|
13
|
-
**A feature document runs deepest toward its end.** Scope and Flows are the model and the journey. **Promises** goes as deep as the behaviour does: every state the surface can be in, every edge case, what a refusal tells the person, and the exact wording wherever the wording itself is promised. That depth is earned because a person or a test checks it and the code cannot state it as intent. It
|
|
13
|
+
**A feature document runs deepest toward its end.** Scope and Flows are the model and the journey. **Promises** goes as deep as the behaviour does: every state the surface can be in, every edge case, what a refusal tells the person, and the exact wording wherever the wording itself is promised. That depth is earned because a person or a test checks it and the code cannot state it as intent. It stops before mechanism. A promise reads "a removed membership shows a panel, not a redirect", never which route answers it.
|
|
14
14
|
|
|
15
15
|
**Sections:**
|
|
16
16
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Record. Use for: the account an **unattended or multi-session build** leaves the person who owns it — written by the orchestrating session as its last act, before the owner's first decision, read in one sitting. It is a **decision queue, an undo manual and a resume file**, in that order: is it done · what must I decide today · what escaped the repository and how do I undo it · can I see it working · what was decided for me and how do I overturn it · what is red and whose it is. Everything below the divider is for the next session, not the owner. It is not a pull-request description (which argues for a diff), not a changelog entry (which carries refinement context) and not a plan (which is frozen). It is mutable while `status: open` — a successor that re-proves a state line corrects it in place and appends one Timeline row — and **freezes when the owner has acted on § 1 (`status: accepted`)**; a correction after that is a new dated hand-over linking back. Raw artefacts (plans, hand-offs, notes) live in a same-named folder beside it.
|
|
4
4
|
|
|
5
|
-
Required: **Verdict**, **Owner decisions due**, **Live-world ledger** (even when empty), **Ten-minute walkthrough**, **Rulings on the owner's behalf**, **Red board**, **What was built**, **Proof**, **State**, **Open loops**, **Artefacts & mandate**. Optional:
|
|
5
|
+
Required: **Verdict**, **Owner decisions due**, **Live-world ledger** (even when empty), **Ten-minute walkthrough**, **Rulings on the owner's behalf**, **Red board**, **What was built**, **Proof**, **State**, **Open loops**, **Artefacts & mandate**. Optional: Untouched scope, Discoveries, Deferrable debt, Cost, Timeline.
|
|
6
6
|
|
|
7
7
|
**Reading order is act → verify → understand.** Owner half, ~20 minutes: Verdict (1) · § 1 (2) · § 2 (2) · § 3 (10, at the product) · § 4 (3) · § 5–6 (2). Successor half, read when the job arrives: § 8–14 (~10).
|
|
8
8
|
|
|
@@ -168,7 +168,7 @@ Present tense; every row true of `as_of_commit`, and every row re-provable by it
|
|
|
168
168
|
- **§ 8 Proof.** **An unproven claim is an empty cell, never a sentence** — prose has no empty cell to scan for. `Independent?` reads `no` whenever one agent authored both the code and its pin, or found, fixed and pinned the same defect, and names who. Ledger counts are parsed from the plan, never quoted from an agent's summary, so `blocked` cannot hide inside "discharged". Every `G-n` names the command that would close it.
|
|
169
169
|
- **§ 9 State.** Present tense; a claim that cannot be re-proved by its `Re-prove` command does not belong here — it moves to § 15 as a dated event. Volatile things (`/tmp`, pid files, ports, tokens, browser connections) declare a lifetime and the command that makes them durable.
|
|
170
170
|
- **§ 10–12.** A loop is a runnable command or a named question, never a noun phrase and never "investigate"; one needing a person's judgment states the question and the default in force. A discovery is a present-tense fact with a guard — "Workers Builds does not fire on a `dev` merge", not "we found that it didn't"; `none — {what would hold it}` is an honest guard that feeds the backlog. Debt names where it now lives, so this file can be deleted without losing it.
|
|
171
|
-
- **§ 13–14.** Every uninstrumented number reads `unmeasured — {what would
|
|
171
|
+
- **§ 13–14.** Every uninstrumented number reads `unmeasured — {what would measure it}`; a blank reports a cheaper run than the one that happened. **State whether the run's own corpus is version-controlled** — an untracked corpus is one `rm -rf` from being three PR descriptions, and archiving it is a § 1 row.
|
|
172
172
|
- **Ids are stable and run-global** — `D-`, `G-`, `L-`, `X-`, `T-` — so a PR comment or a successor cites a row instead of re-describing it. A withdrawn row keeps its id and states what disproved it.
|
|
173
173
|
- **Evidence is an address that outlives the run** — `path:line`, a 7-char sha, a PR number, a URL, or a command. A branch name is not a pointer; a `/tmp` log is not evidence — copy it into the record folder first.
|
|
174
174
|
- **Blanket claims are banned.** "All suites green", "every ledger discharged", "nothing was deployed" carry a count and the sha they are true of, or they become a `G-n` row.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Implementation
|
|
1
|
+
# Implementation map (docs/operations/implementation-map.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: **the cold-start execution contract of a project being built from its documented design** — one per repo, at `docs/operations/implementation-map.md`. It is authored by the **executing session at build start**, never generated at design time: build order is derived from the repo's actual feature docs and their stated dependencies, and a design-time prediction of it goes stale the day reality disagrees. It lives in operations because it says *how to proceed*, not *what is true of the design*.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Migration
|
|
1
|
+
# Migration runbook (docs/history/migrations/YYYY-MM-DD-{slug}.md)
|
|
2
2
|
|
|
3
3
|
Record. Use for: a **one-shot** migration, upgrade, or data operation — authored before execution, executed once, then outcome-stamped and frozen. Supporting scripts live beside it in a same-named folder when needed (`YYYY-MM-DD-{slug}/`).
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Non-
|
|
1
|
+
# Non-goals (docs/architecture/non-goals.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: what the system deliberately does **not** do. A non-goal is a decision, not an omission — each entry carries the why and what would reopen it. Readers (and agents) use this to stop re-proposing settled exclusions.
|
|
4
4
|
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
# Operations
|
|
1
|
+
# Operations procedure (docs/operations/{procedure}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: any **recurring** procedure — development, deployment, maintenance. The one-time first run (prerequisites, install, env files, first commands, the stack) is not one of these: it has its own template and a fixed name, `templates/setup.md` → `docs/operations/setup.md`, one per repo. A procedure is consulted mid-task, not read: exact commands, copy-paste runnable, no narrative. Updated in place whenever the workflow changes.
|
|
4
4
|
|
|
5
|
-
A **one-shot** procedure (a migration, an upgrade, an incident response executed once) is not an operations doc — it is a **
|
|
5
|
+
A **one-shot** procedure (a migration, an upgrade, an incident response executed once) is not an operations doc — it is a **migration runbook** (record, `templates/migration-runbook.md`). The test: will someone run this again next month? Yes → operations. No → runbook.
|
|
6
6
|
|
|
7
7
|
Required: **Goal**, **Steps**, **Verification**. Optional: Preconditions, Troubleshooting, Rollback — include only when they carry real content.
|
|
8
8
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Package
|
|
1
|
+
# Package documentation (docs/architecture/packages/{package}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: **one workspace package** — one unit of distribution: a manifest, a build, a binary, a bundle, a Worker. One file per package, named for its folder.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Project
|
|
1
|
+
# Project root README (/README.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the repository root `/README.md`. It opens outward — what the product does, for whom, and where it runs, in a user's terms — then turns inward for the team and coding agents: what state the repo is in, how it works, what its parts are and what must not break, then routes every other question into `docs/`. The outward part comes first because it is what a stranger reads; the inward part is longer because it is what the team uses. **It hosts nothing it can link to.** It is distinct from `docs/README.md`, which describes the folders of the docs tree, and from `CLAUDE.md` / `AGENTS.md`, the standing rules an agent loads. It points at both and restates neither.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Security
|
|
1
|
+
# Security overview (docs/architecture/security.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the single place the system's security posture is stated — assets, trust boundaries, controls, and accepted risks. Controls link to the code that implements them; this doc asserts, the code proves.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# System
|
|
1
|
+
# System overview (docs/architecture/system-design.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the bird's-eye view — what the system is, its subsystems, and how they connect. The first doc a new reader opens after the README; austere and short (two screens max). Depth lives in feature docs — this doc maps, it doesn't explain.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# System
|
|
1
|
+
# System documentation (docs/architecture/systems/{system}.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: **one machine that spans packages**, which a person cannot point at — the walk, the egress, the ingest, the settlement, a gate, a sweep, a door an agent calls. One file per machine, named for the machine. A thing a person navigates to is a feature document, even when it owns tables; a unit of distribution is a package document.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Testing
|
|
1
|
+
# Testing strategy (docs/architecture/common/testing.md)
|
|
2
2
|
|
|
3
3
|
Truth document. Use for: the repo's test posture — what is tested at which level, how to run it, and what is deliberately untested. The framework choices come from the harness testing rule; this doc records how *this repo* applies them.
|
|
4
4
|
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# UX
|
|
1
|
+
# UX behavior (docs/features/{surface}-ux.md)
|
|
2
2
|
|
|
3
3
|
**Truth document.** States what a person sees and can do on a surface, and what the surface promises never to do. Present tense, like every truth document.
|
|
4
4
|
|
|
@@ -26,9 +26,7 @@ owns: # transitional, only when this document speaks
|
|
|
26
26
|
| One surface's — a panel, an editor, a dialog | `docs/features/{surface}-ux.md`; its component files' headers name it |
|
|
27
27
|
| Cross-cutting — routing, information architecture, the state vocabulary every surface obeys, presentation of streams | `docs/architecture/` — owns no code, like every architecture doc |
|
|
28
28
|
|
|
29
|
-
**Ownership: a component file names one document in its header.** A surface's components are frequently already spoken for — by the page's feature document, by the feature behind one panel — and a file's header names exactly one document. Where the header already names the feature document, this document is named in that feature document's **See also** line under For the agent instead, phrased as *different promises over the same files*, and the object closure links the two through the objects both name. Where no document speaks for the component
|
|
30
|
-
|
|
31
|
-
That matters because a doc nothing implicates is a doc that rots, and a surface rewritten under an unimplicated document is the failure this genre exists to prevent. The See also line is the weaker of the two bindings; prefer the header pointer wherever no document speaks for the component yet.
|
|
29
|
+
**Ownership: a component file names one document in its header.** A surface's components are frequently already spoken for — by the page's feature document, by the feature behind one panel — and a file's header names exactly one document. Where the header already names the feature document, this document is named in that feature document's **See also** line under For the agent instead, phrased as *different promises over the same files*, and the object closure links the two through the objects both name. Where no document speaks for the component, its header names this one; prefer that header pointer, because the See also line is the weaker binding. A document nothing implicates rots, and a surface rewritten under an unimplicated document is the failure this genre exists to prevent.
|
|
32
30
|
|
|
33
31
|
---
|
|
34
32
|
|
|
@@ -67,7 +65,7 @@ What moves the surface between states, and who causes each move — the person,
|
|
|
67
65
|
|
|
68
66
|
## Optional sections
|
|
69
67
|
|
|
70
|
-
**Copy** — the exact words, where the wording is load-bearing (a refusal, an irreversible confirmation). **Density and rhythm** — where a surface deliberately differs from the design system's default. **Open questions** — decisions deliberately
|
|
68
|
+
**Copy** — the exact words, where the wording is load-bearing (a refusal, an irreversible confirmation). **Density and rhythm** — where a surface deliberately differs from the design system's default. **Open questions** — decisions deliberately left open, so an implementer knows what to ask rather than guessing.
|
|
71
69
|
|
|
72
70
|
## Rules
|
|
73
71
|
|
|
@@ -5,21 +5,21 @@ description: Use when a task's routed tier isn't good enough — a prompt keeps
|
|
|
5
5
|
|
|
6
6
|
# Escalate — evidence-gated tier promotion
|
|
7
7
|
|
|
8
|
-
Promotion is earned by a failing eval, never by intuition. This skill is the only
|
|
8
|
+
Promotion is earned by a failing eval, never by intuition. This skill is the **only** path to running a task above its routed tier. The gate is one eval run and one entry — ask for no further approval.
|
|
9
9
|
|
|
10
10
|
## Procedure
|
|
11
11
|
|
|
12
|
-
1. **Demand the evidence
|
|
13
|
-
2. **Write the escalation entry
|
|
14
|
-
- File: `docs/history/changelog/YYYY-MM-DD-{three-words}.md`, standard changelog-entry template
|
|
15
|
-
-
|
|
16
|
-
- `Change:` names the task type, the family, the failing score vs. threshold, and the tier movement (`standard → frontier`).
|
|
17
|
-
- `Discovered:` what the failure teaches about the tier's capability ceiling —
|
|
18
|
-
3. **Record the promotion scope**: one-off (this task runs high once) or standing (the routing row itself is wrong).
|
|
12
|
+
1. **Demand the evidence**: a completed `prompt-eval` run at the routed tier, failing the family threshold, against the current prompt version — a run against an earlier version **never** counts. No such run ⇒ run it now.
|
|
13
|
+
2. **Write the escalation entry.** This skill owns its shape, and `cost-report` and `retro` parse it, so the shape is a contract:
|
|
14
|
+
- File: `docs/history/changelog/YYYY-MM-DD-{three-words}.md`, on the standard changelog-entry template.
|
|
15
|
+
- `Class:` carries `escalation`, spelled exactly — the keyword `cost-report` and `retro` match on.
|
|
16
|
+
- `Change:` names the task type, the family, the failing score vs. the threshold, and the tier movement (`standard → frontier`).
|
|
17
|
+
- `Discovered:` states what the failure teaches about the tier's capability ceiling — the routing table's tuning signal.
|
|
18
|
+
3. **Record the promotion scope**: one-off (this task runs high once) or standing (the routing row itself is wrong). For a standing promotion, also append an out-of-scope discovery proposing the routing-row change — **never** edit the routing table here; it is policy and moves by its own reviewed edit.
|
|
19
19
|
4. **Dispatch at the new tier** and finish the work.
|
|
20
20
|
|
|
21
21
|
## Rules
|
|
22
22
|
|
|
23
|
-
- **The entry precedes the dispatch.**
|
|
24
|
-
- **Escalation is symmetric.**
|
|
25
|
-
- **Frequency is signal, not failure.** Many escalations from one row mean the row is wrong
|
|
23
|
+
- **The entry precedes the dispatch.** A dispatch with no entry is an unevidenced promotion, which `CLAUDE.md`'s routing guardrails prohibit.
|
|
24
|
+
- **Escalation is symmetric.** A `regression-runner` demotion experiment that passes a tier down is recorded on the same format — `Class: escalation`, direction down.
|
|
25
|
+
- **Frequency is signal, not failure.** Many escalations from one row mean the row is wrong — `retro`'s finding to make from these entries. **Never** suppress an escalation to keep the table looking right.
|
|
@@ -5,18 +5,18 @@ description: Use when a prompt needs its quality measured — after drafting or
|
|
|
5
5
|
|
|
6
6
|
# Prompt Eval — the golden-set loop
|
|
7
7
|
|
|
8
|
-
A prompt's quality claim is its eval result, nothing else. This skill runs the loop;
|
|
8
|
+
A prompt's quality claim is its eval result, nothing else. This skill runs the loop; golden-set, rubric, and threshold conventions are `.claude/rules/evals.md`.
|
|
9
9
|
|
|
10
10
|
## Procedure
|
|
11
11
|
|
|
12
|
-
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
|
|
13
|
-
2. **Run the set** against the prompt via `eval-runner` — every item,
|
|
14
|
-
3. **Grade with the family's rubric.** Mechanical checks
|
|
15
|
-
4. **Gate
|
|
16
|
-
5. **Record
|
|
12
|
+
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**: dispatch `data-generator` to draft edge-case items, and have a human review them before they join the set.
|
|
13
|
+
2. **Run the full set** against the prompt via `eval-runner` — every item, never a sample. Batch all variants into one run so their scores are comparable.
|
|
14
|
+
3. **Grade with the family's rubric.** Mechanical checks 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.
|
|
15
|
+
4. **Gate.** A variant meeting the family threshold is a candidate, not certified. Certification for the library also requires one `judge` dispatch — the loop's only frontier-tier call.
|
|
16
|
+
5. **Record.** Write the certified variant's scores into its `prompt-library` entry; put the losing variants' deltas in the changelog entry's refinement context.
|
|
17
17
|
|
|
18
18
|
## Rules
|
|
19
19
|
|
|
20
|
-
- **Iteration stays
|
|
20
|
+
- **Iteration stays off the frontier tier.** The draft → eval → revise loop runs on economy (`eval-runner`) and standard (`prompt-iterator`); **never** dispatch `judge` inside the loop.
|
|
21
21
|
- **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.
|
|
22
|
-
- **A failing eval is a result, not an obstacle.** Report it
|
|
22
|
+
- **A failing eval is a result, not an obstacle.** Report it as it stands. When the family needs a stronger tier, that failing run is the `escalate` skill's evidence.
|
|
@@ -5,11 +5,11 @@ description: Use when creating, versioning, retrieving, or auditing a production
|
|
|
5
5
|
|
|
6
6
|
# Prompt Library — versioned, certified entries
|
|
7
7
|
|
|
8
|
-
`prompts/{family}/`
|
|
8
|
+
`prompts/{family}/` holds certified production prompts only. Every entry is versioned, eval-scored and tier-certified; scratch iterations stay outside `prompts/**` until they pass their family's evals.
|
|
9
9
|
|
|
10
10
|
## The entry format
|
|
11
11
|
|
|
12
|
-
Each prompt is one file at `prompts/{family}/{name}.md` with frontmatter:
|
|
12
|
+
Each prompt is one file at `prompts/{family}/{name}.md` with this frontmatter:
|
|
13
13
|
|
|
14
14
|
```yaml
|
|
15
15
|
---
|
|
@@ -21,16 +21,37 @@ status: active # active | candidate | retired
|
|
|
21
21
|
---
|
|
22
22
|
```
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
| `status` | Meaning |
|
|
25
|
+
| --- | --- |
|
|
26
|
+
| `active` | Certified — the only status a consumer loads |
|
|
27
|
+
| `candidate` | Met the family threshold in `prompt-eval`; not yet through the `judge` gate |
|
|
28
|
+
| `retired` | Kept in place for provenance; **never** loaded |
|
|
29
|
+
|
|
30
|
+
The body is the prompt verbatim — no narration, no history; the journey lives in changelog entries.
|
|
25
31
|
|
|
26
32
|
## Procedure
|
|
27
33
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
34
|
+
Before any write, read the family's owning feature doc — its `owns:` glob covers the family.
|
|
35
|
+
|
|
36
|
+
**Create or update:**
|
|
37
|
+
|
|
38
|
+
1. Iterate outside `prompts/**` with `prompt-eval` until the variant meets the family threshold.
|
|
39
|
+
2. Write the entry with `version` bumped and `status: candidate`.
|
|
40
|
+
3. Run the `judge` gate.
|
|
41
|
+
4. On a pass, set `status: active` with the certifying run's `eval-score` and `certified` date.
|
|
42
|
+
|
|
43
|
+
**Retrieve:**
|
|
44
|
+
|
|
45
|
+
1. Match by family and `status: active`.
|
|
46
|
+
2. Dispatch at the entry's `tier` — **never** stronger; running above the certified tier is an unevidenced promotion.
|
|
47
|
+
|
|
48
|
+
**Audit** — on demand, and by `regression-runner` after every model-generation change:
|
|
49
|
+
|
|
50
|
+
1. List every `active` entry whose `certified` date precedes the latest change to the `model-tiers` rule — each is stale.
|
|
51
|
+
2. Re-certify each stale entry, or flag it.
|
|
31
52
|
|
|
32
53
|
## Rules
|
|
33
54
|
|
|
34
|
-
- **Certification is per tier.** A prompt certified on standard says nothing about economy; a demotion experiment
|
|
35
|
-
- **One prompt, one entry.** Variants under comparison are `candidate` siblings; only one `active` per name.
|
|
36
|
-
- **Never hand-edit `eval-score`** —
|
|
55
|
+
- **Certification is per tier.** A prompt certified on standard says nothing about economy; a passing demotion experiment produces a *new* certification at the lower tier.
|
|
56
|
+
- **One prompt, one entry.** Variants under comparison are `candidate` siblings; only one is `active` per name.
|
|
57
|
+
- **Never hand-edit `eval-score`** — only the certifying run writes it.
|
|
@@ -5,17 +5,17 @@ description: Use when starting any piece of prompt work — drafting, evaluating
|
|
|
5
5
|
|
|
6
6
|
# Route — classify, look up, dispatch
|
|
7
7
|
|
|
8
|
-
The model decision belongs to the routing table in `CLAUDE.md` § The Routing Policy
|
|
8
|
+
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.
|
|
9
9
|
|
|
10
10
|
## Procedure
|
|
11
11
|
|
|
12
|
-
1. **Classify the task into exactly one task type** from the routing table's rows.
|
|
13
|
-
2. **Read the row**: task type → tier → executing agent.
|
|
14
|
-
3. **Dispatch the named agent.**
|
|
15
|
-
4. **Never route around a failing eval.**
|
|
12
|
+
1. **Classify the task into exactly one task type** from the routing table's rows. Classify inline — it is mechanical work, never worth a dispatch. When a task spans types ("draft a prompt and evaluate it"), decompose it and route each leg separately.
|
|
13
|
+
2. **Read the row**: task type → tier → executing agent. When no row matches, the task type is new: do the work provisionally at the standard tier and record the missing row as an out-of-scope discovery, so the table gains it.
|
|
14
|
+
3. **Dispatch the named agent.** Its `model:` pin enforces the tier — **never** override the model at dispatch time.
|
|
15
|
+
4. **Never route around a failing eval.** When the routed tier's output fails its evals, run the `escalate` skill (evidence-gated promotion) — never a quiet re-dispatch on a stronger agent.
|
|
16
16
|
|
|
17
17
|
## What this skill refuses
|
|
18
18
|
|
|
19
|
-
- Naming a model
|
|
20
|
-
- Frontier dispatch for mechanical work (eval runs, data generation, classification) — the routing guardrails in `CLAUDE.md` prohibit it
|
|
21
|
-
- Skipping the table because the task "obviously" needs the strongest model — that intuition is
|
|
19
|
+
- ❌ Naming a model — tiers only; the mapping lives in `.claude/rules/model-tiers.md` and the agents' `model:` pins.
|
|
20
|
+
- ❌ Frontier dispatch for mechanical work (eval runs, data generation, classification) — the routing guardrails in `CLAUDE.md` § The Routing Policy prohibit it whoever asks.
|
|
21
|
+
- ❌ Skipping the table because the task "obviously" needs the strongest model — that intuition is what the escalation ladder exists to test.
|