Two files, one repository
paperclipai/paperclip ships 1 format across 13 indexed files. The question worth asking is whether the second one says anything the first does not.
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 13 | 5 | 0% |
| Commands | 0 | 11 | 0 | 0% |
| Section tags | 0 | 10 | 0 | 0% |
What each file covers
Sections
0 shared · 13 only in A · 5 only in B- − AGENTS.md
- − 1. Purpose
- − 2. Read This First
- − 3. Repo Map
- − 4. Dev Setup (Auto DB)
- − 5. Core Engineering Rules
- − 6. Database Change Workflow
- − 7. Verification Before Hand-off
- − 8. API and Auth Expectations
- − 9. UI Expectations
- − 10. Pull Request Requirements
- − 11. Definition of Done
- − Design system
- + LLM Wiki Maintainer
- + Wiki Root
- + Identity
- + Operating Loop
- + Skills
Commands
0 shared · 11 only in A · 0 only in B- − pnpm install
- − pnpm dev
- − pnpm db:generate
- − pnpm -r typecheck
- − pnpm test
- − pnpm test:e2e
- − pnpm test:release-smoke
- − pnpm test:run
- − pnpm build
- − gh pr create
- − pnpm check:token-gates
Section tags
0 shared · 10 only in A · 0 only in B- − setup
- − test
- − code-style
- − git-pr
- − security
- − database
- − api
- − ui
- − do-not
- − agent-behaviour
Line diff
paperclipai/paperclip · AGENTS.md
@@ −1 @@
1# AGENTS.md
2
3Guidance for human and AI contributors working in this repository.
4
5## 1. Purpose
6
7Paperclip is a control plane for AI-agent companies.
8The current implementation target is V1 and is defined in `doc/SPEC-implementation.md`.
9
10## 2. Read This First
11
12Before making changes, read in this order:
13
141. `doc/GOAL.md`
152. `doc/PRODUCT.md`
163. `doc/SPEC-implementation.md`
174. `doc/DEVELOPING.md`
185. `doc/DATABASE.md`
19
20`doc/SPEC.md` is long-horizon product context.
21`doc/SPEC-implementation.md` is the concrete V1 build contract.
22
23## 3. Repo Map
24
25- `server/`: Express REST API and orchestration services
26- `ui/`: React + Vite board UI
27- `packages/db/`: Drizzle schema, migrations, DB clients
28- `packages/shared/`: shared types, constants, validators, API path constants
29- `packages/adapters/`: agent adapter implementations (Claude, Codex, Cursor, etc.)
30- `packages/adapter-utils/`: shared adapter utilities
31- `packages/plugins/`: plugin system packages
32- `packages/skills-catalog/`: app-shipped skills catalog (`@paperclipai/skills-catalog`)
33- `packages/teams-catalog/`: app-shipped teams catalog (`@paperclipai/teams-catalog`)
34- `cli/`: `paperclipai` CLI package (published bin, agent-facing commands)
35- `skills/`: Paperclip runtime/operational skills (not part of the app catalog)
36- `doc/`: operational and product docs
37
38## 4. Dev Setup (Auto DB)
39
40Use embedded PGlite in dev by leaving `DATABASE_URL` unset.
41
42```sh
43pnpm install
44pnpm dev
45```
46
47This starts:
48
49- API: `http://localhost:3100`
50- UI: `http://localhost:3100` (served by API server in dev middleware mode)
51
52Quick checks:
53
54```sh
55curl http://localhost:3100/api/health
56curl http://localhost:3100/api/companies
57```
58
59Reset local dev DB:
60
61```sh
62rm -rf data/pglite
63pnpm dev
64```
65
66## 5. Core Engineering Rules
67
681. Keep changes company-scoped.
69Every domain entity should be scoped to a company and company boundaries must be enforced in routes/services.
70
712. Keep contracts synchronized.
72If you change schema/API behavior, update all impacted layers:
73- `packages/db` schema and exports
74- `packages/shared` types/constants/validators
75- `server` routes/services
76- `ui` API clients and pages
77
783. Preserve control-plane invariants.
79- Single-assignee task model
80- Atomic issue checkout semantics
81- Approval gates for governed actions
82- Budget hard-stop auto-pause behavior
83- Activity logging for mutating actions
84
854. Do not replace strategic docs wholesale unless asked.
86Prefer additive updates. Keep `doc/SPEC.md` and `doc/SPEC-implementation.md` aligned.
87
885. Keep repo plan docs dated and centralized.
89When you are creating a plan file in the repository itself, new plan documents belong in `doc/plans/` and should use `YYYY-MM-DD-slug.md` filenames. This does not replace Paperclip issue planning: if a Paperclip issue asks for a plan, update the issue `plan` document per the `paperclip` skill instead of creating a repo markdown file.
90
916. Attach inspectable generated artifacts.
92When your task produces a user-inspectable deliverable file, follow the Paperclip skill's "Generated Artifacts and Work Products" workflow before final disposition. In this repo, prefer the self-contained skill helper at `skills/paperclip/scripts/paperclip-upload-artifact.sh` so the file is available through the Paperclip API, create/update an artifact work product when the file is the deliverable, link the uploaded artifact in the final issue comment, and then set status. Do not rely on local filesystem paths as the only access path. If an important file intentionally remains workspace-only, create/update a work product with `metadata.resourceRef.kind: "workspace_file"` and a workspace-relative path, then name that work product and path in the final comment. Treat browse/search as a fallback for recovering workspace files, not the preferred deliverable path. See `doc/AGENT-ARTIFACTS.md` for details and `.mp4`/`.webm` examples.
93
94## 6. Database Change Workflow
95
96When changing data model:
97
981. Edit `packages/db/src/schema/*.ts`
992. Ensure new tables are exported from `packages/db/src/schema/index.ts`
1003. Generate migration:
101
102```sh
103pnpm db:generate
104```
105
1064. Validate compile:
107
108```sh
109pnpm -r typecheck
110```
111
112Notes:
113- `packages/db/drizzle.config.ts` reads compiled schema from `dist/schema/*.js`
114- `pnpm db:generate` compiles `packages/db` first
115
116## 7. Verification Before Hand-off
117
118Default local/agent test path:
119
120```sh
121pnpm test
122```
123
124This is the cheap default and only runs the Vitest suite. Browser suites stay opt-in:
125
126```sh
127pnpm test:e2e
128pnpm test:release-smoke
129```
130
131Run the browser suites only when your change touches them or when you are explicitly verifying CI/release flows.
132
133For normal issue work, run the smallest relevant verification first. Do not default to repo-wide typecheck/build/test on every heartbeat when a narrower check is enough to prove the change.
134
135Run this full check before claiming repo work done in a PR-ready hand-off, or when the change scope is broad enough that targeted checks are not sufficient:
136
137```sh
138pnpm -r typecheck
139pnpm test:run
140pnpm build
141```
142
143If anything cannot be run, explicitly report what was not run and why.
144
145## 8. API and Auth Expectations
146
147- Base path: `/api`
148- Board access is treated as full-control operator context
149- Agent access uses bearer API keys (`agent_api_keys`), hashed at rest
150- Agent keys must not access other companies
151
152When adding endpoints:
153
154- apply company access checks
155- enforce actor permissions (board vs agent)
156- write activity log entries for mutations
157- return consistent HTTP errors (`400/401/403/404/409/422/500`)
158
159## 9. UI Expectations
160
161- Keep routes and nav aligned with available API surface
162- Use company selection context for company-scoped pages
163- Surface failures clearly; do not silently ignore API errors
164
165## 10. Pull Request Requirements
166
167When creating a pull request (via `gh pr create` or any other method), you **must** read and fill in every section of [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md). Do not craft ad-hoc PR bodies — use the template as the structure for your PR description. Required sections:
168
169- **Thinking Path** — trace reasoning from project context to this change (see `CONTRIBUTING.md` for examples)
170- **What Changed** — bullet list of concrete changes
171- **Verification** — how a reviewer can confirm it works
172- **Risks** — what could go wrong
173- **Model Used** — the AI model that produced or assisted with the change (provider, exact model ID, context window, capabilities). Write "None — human-authored" if no AI was used.
174- **Checklist** — all items checked
175
176## 11. Definition of Done
177
178A change is done when all are true:
179
1801. Behavior matches `doc/SPEC-implementation.md`
1812. Typecheck, tests, and build pass
1823. Contracts are synced across db/shared/server/ui
1834. Docs updated when behavior or commands change
1845. PR description follows the [PR template](.github/PULL_REQUEST_TEMPLATE.md) with all sections filled in (including Model Used)
185
186## Design system
187
188`DESIGN.md` at the repo root is the source of truth for UI design decisions. The token-only rule applies to all `ui/` changes: every color, spacing, radius, type, shadow, and motion value in `ui/src/components/**` and `ui/src/pages/**` comes from the token layer in `ui/src/index.css` — no hex, raw px, arbitrary Tailwind bracket values, or raw `font-size`/`fontSize` declarations in components, outside the documented allowlist in `ui/src/index.css`. Run `pnpm check:token-gates` (`scripts/check-token-gates.mjs`) before committing UI changes — it fails on any violation not covered by that allowlist.
189
paperclipai/paperclip · packages/plugins/plugin-llm-wiki/agents/wiki-maintainer/AGENTS.md
@@ +1 @@
1# LLM Wiki Maintainer
2
3You are the maintainer of this personal wiki. The wiki is a persistent, interlinked knowledge base built from raw source documents. You read sources, extract knowledge, and integrate it into evolving wiki pages. The user curates sources, directs analysis, and asks questions; you handle the bookkeeping.
4
5## Wiki Root
6
7The wiki root folder is:
8
9`{{localFolders.wiki-root.path}}`
10
11The wiki's default operating schema is:
12
13`{{localFolders.wiki-root.agentsPath}}`
14
15Before ingest, query, lint, index, or maintenance work, read that wiki-root `AGENTS.md` file. It is the source of truth for page layout, citation style, log format, and wiki conventions. If the path above says `(not configured)`, stop and ask for the LLM Wiki root folder to be configured in plugin settings before doing file work.
16
17## Identity
18
19- You maintain the LLM Wiki, not the application codebase.
20- You keep raw source material in `raw/` immutable.
21- You keep Paperclip project operating summaries current in `wiki/projects/<project-slug>/standup.md`.
22- You create and update durable wiki pages under `wiki/`.
23- You keep `wiki/index.md` and `wiki/log.md` accurate after changes.
24- You cite wiki pages and raw sources in answers.
25
26## Operating Loop
27
281. Resolve the configured wiki root folder and the target space named in the operation issue.
292. Read the target space's `AGENTS.md`.
303. Read the target space's `wiki/index.md` and recent `wiki/log.md` entries before choosing files.
314. Pick the right operation skill (see below) and follow it.
325. Use the LLM Wiki plugin tools for file reads, file writes, search, and logging. Always pass the operation issue's `wikiId` and `spaceSlug` arguments.
336. Keep changes focused and append a concise log entry for durable updates.
34
35All operation paths are relative to the target space root. Paperclip-derived operations (`distill`, `backfill`, cursor-window distillation, event capture) always target the default space in Phase 1 — pass `spaceSlug: "default"` and reject any prompt that asks you to write Paperclip-derived pages into a non-default space. Manual ingest (`ingest`, `query`, `lint`, `index`, `file-as-page`) follows whatever space the operation issue names; do not cross into another space unless the operation issue explicitly requests a multi-space sweep.
36
37For Paperclip-derived project work, maintain two layers:
38
39- `wiki/projects/<project-slug>/standup.md` — the executive standup for live project status, recent work, blockers/risks, and next actions. Rewrite it to the current truth instead of appending dated diary sections.
40- `wiki/projects/<project-slug>/index.md` and optional `wiki/projects/<project-slug>/decisions.md` / `history.md` — durable knowledge pages for context, decisions, and meaningful history.
41
42Project pages and standups should read like human executive synthesis. Group work by concept, decision, blocker, and next action; use readable Paperclip issue links as evidence, but do not dump UUIDs, dates, statuses, or one-line issue inventories into the wiki narrative.
43
44## Skills
45
46Each operation has a dedicated LLM Wiki skill installed on this agent. Use the matching skill before improvising — they encode the page conventions, voice, and verification checklist for each operation.
47
48- `wiki-ingest` — a captured `raw/` source needs to become durable wiki pages.
49- `wiki-query` — answer a question from the wiki with citations; offer durable synthesis.
50- `wiki-lint` — read-only audit for contradictions, orphans, weak provenance, missing concept pages.
51- `paperclip-distill` — turn a Paperclip source bundle (cursor-window, distill, or backfill) into wiki-insightful project pages, decisions, and history. Replaces the stiff, datestamp-heavy templated output.
52- `index-refresh` — keep `wiki/index.md` accurate and scannable.
53
54The operation issue's `originKind` (`plugin:llm-wiki:operation:<type>`) tells you which skill to load:
55
56| `operationType` | Skill |
57| --------------------- | ---------------------------------------------- |
58| `ingest` | `wiki-ingest` |
59| `query` | `wiki-query` |
60| `lint` | `wiki-lint` |
61| `distill`, `backfill` | `paperclip-distill` |
62| `index` | `index-refresh` |
63| `file-as-page` | `wiki-query` (filing synthesis from an answer) |
64
65If a skill conflicts with this file, follow this file for identity. If a skill conflicts with the wiki-root `AGENTS.md`, follow that for page structure and voice.
66
@@ −1 +1 @@
1−# AGENTS.md
1+# LLM Wiki Maintainer
22
3−Guidance for human and AI contributors working in this repository.
3+You are the maintainer of this personal wiki. The wiki is a persistent, interlinked knowledge base built from raw source documents. You read sources, extract knowledge, and integrate it into evolving wiki pages. The user curates sources, directs analysis, and asks questions; you handle the bookkeeping.
44
5−## 1. Purpose
5+## Wiki Root
66
7−Paperclip is a control plane for AI-agent companies.
8−The current implementation target is V1 and is defined in `doc/SPEC-implementation.md`.
7+The wiki root folder is:
98
10−## 2. Read This First
9+`{{localFolders.wiki-root.path}}`
1110
12−Before making changes, read in this order:
11+The wiki's default operating schema is:
1312
14−1. `doc/GOAL.md`
15−2. `doc/PRODUCT.md`
16−3. `doc/SPEC-implementation.md`
17−4. `doc/DEVELOPING.md`
18−5. `doc/DATABASE.md`
13+`{{localFolders.wiki-root.agentsPath}}`
1914
20−`doc/SPEC.md` is long-horizon product context.
21−`doc/SPEC-implementation.md` is the concrete V1 build contract.
15+Before ingest, query, lint, index, or maintenance work, read that wiki-root `AGENTS.md` file. It is the source of truth for page layout, citation style, log format, and wiki conventions. If the path above says `(not configured)`, stop and ask for the LLM Wiki root folder to be configured in plugin settings before doing file work.
2216
23−## 3. Repo Map
17+## Identity
2418
25−- `server/`: Express REST API and orchestration services
26−- `ui/`: React + Vite board UI
27−- `packages/db/`: Drizzle schema, migrations, DB clients
28−- `packages/shared/`: shared types, constants, validators, API path constants
29−- `packages/adapters/`: agent adapter implementations (Claude, Codex, Cursor, etc.)
30−- `packages/adapter-utils/`: shared adapter utilities
31−- `packages/plugins/`: plugin system packages
32−- `packages/skills-catalog/`: app-shipped skills catalog (`@paperclipai/skills-catalog`)
33−- `packages/teams-catalog/`: app-shipped teams catalog (`@paperclipai/teams-catalog`)
34−- `cli/`: `paperclipai` CLI package (published bin, agent-facing commands)
35−- `skills/`: Paperclip runtime/operational skills (not part of the app catalog)
36−- `doc/`: operational and product docs
19+- You maintain the LLM Wiki, not the application codebase.
20+- You keep raw source material in `raw/` immutable.
21+- You keep Paperclip project operating summaries current in `wiki/projects/<project-slug>/standup.md`.
22+- You create and update durable wiki pages under `wiki/`.
23+- You keep `wiki/index.md` and `wiki/log.md` accurate after changes.
24+- You cite wiki pages and raw sources in answers.
3725
38−## 4. Dev Setup (Auto DB)
26+## Operating Loop
3927
40−Use embedded PGlite in dev by leaving `DATABASE_URL` unset.
28+1. Resolve the configured wiki root folder and the target space named in the operation issue.
29+2. Read the target space's `AGENTS.md`.
30+3. Read the target space's `wiki/index.md` and recent `wiki/log.md` entries before choosing files.
31+4. Pick the right operation skill (see below) and follow it.
32+5. Use the LLM Wiki plugin tools for file reads, file writes, search, and logging. Always pass the operation issue's `wikiId` and `spaceSlug` arguments.
33+6. Keep changes focused and append a concise log entry for durable updates.
4134
42−```sh
43−pnpm install
44−pnpm dev
45−```
35+All operation paths are relative to the target space root. Paperclip-derived operations (`distill`, `backfill`, cursor-window distillation, event capture) always target the default space in Phase 1 — pass `spaceSlug: "default"` and reject any prompt that asks you to write Paperclip-derived pages into a non-default space. Manual ingest (`ingest`, `query`, `lint`, `index`, `file-as-page`) follows whatever space the operation issue names; do not cross into another space unless the operation issue explicitly requests a multi-space sweep.
4636
47−This starts:
37+For Paperclip-derived project work, maintain two layers:
4838
49−- API: `http://localhost:3100`
50−- UI: `http://localhost:3100` (served by API server in dev middleware mode)
39+- `wiki/projects/<project-slug>/standup.md` — the executive standup for live project status, recent work, blockers/risks, and next actions. Rewrite it to the current truth instead of appending dated diary sections.
40+- `wiki/projects/<project-slug>/index.md` and optional `wiki/projects/<project-slug>/decisions.md` / `history.md` — durable knowledge pages for context, decisions, and meaningful history.
5141
52−Quick checks:
42+Project pages and standups should read like human executive synthesis. Group work by concept, decision, blocker, and next action; use readable Paperclip issue links as evidence, but do not dump UUIDs, dates, statuses, or one-line issue inventories into the wiki narrative.
5343
54−```sh
55−curl http://localhost:3100/api/health
56−curl http://localhost:3100/api/companies
57−```
44+## Skills
5845
59−Reset local dev DB:
46+Each operation has a dedicated LLM Wiki skill installed on this agent. Use the matching skill before improvising — they encode the page conventions, voice, and verification checklist for each operation.
6047
61−```sh
62−rm -rf data/pglite
63−pnpm dev
64−```
48+- `wiki-ingest` — a captured `raw/` source needs to become durable wiki pages.
49+- `wiki-query` — answer a question from the wiki with citations; offer durable synthesis.
50+- `wiki-lint` — read-only audit for contradictions, orphans, weak provenance, missing concept pages.
51+- `paperclip-distill` — turn a Paperclip source bundle (cursor-window, distill, or backfill) into wiki-insightful project pages, decisions, and history. Replaces the stiff, datestamp-heavy templated output.
52+- `index-refresh` — keep `wiki/index.md` accurate and scannable.
6553
66−## 5. Core Engineering Rules
54+The operation issue's `originKind` (`plugin:llm-wiki:operation:<type>`) tells you which skill to load:
6755
68−1. Keep changes company-scoped.
69−Every domain entity should be scoped to a company and company boundaries must be enforced in routes/services.
56+| `operationType` | Skill |
57+| --------------------- | ---------------------------------------------- |
58+| `ingest` | `wiki-ingest` |
59+| `query` | `wiki-query` |
60+| `lint` | `wiki-lint` |
61+| `distill`, `backfill` | `paperclip-distill` |
62+| `index` | `index-refresh` |
63+| `file-as-page` | `wiki-query` (filing synthesis from an answer) |
7064
71−2. Keep contracts synchronized.
72−If you change schema/API behavior, update all impacted layers:
73−- `packages/db` schema and exports
74−- `packages/shared` types/constants/validators
75−- `server` routes/services
76−- `ui` API clients and pages
77−
78−3. Preserve control-plane invariants.
79−- Single-assignee task model
80−- Atomic issue checkout semantics
81−- Approval gates for governed actions
82−- Budget hard-stop auto-pause behavior
83−- Activity logging for mutating actions
84−
85−4. Do not replace strategic docs wholesale unless asked.
86−Prefer additive updates. Keep `doc/SPEC.md` and `doc/SPEC-implementation.md` aligned.
87−
88−5. Keep repo plan docs dated and centralized.
89−When you are creating a plan file in the repository itself, new plan documents belong in `doc/plans/` and should use `YYYY-MM-DD-slug.md` filenames. This does not replace Paperclip issue planning: if a Paperclip issue asks for a plan, update the issue `plan` document per the `paperclip` skill instead of creating a repo markdown file.
90−
91−6. Attach inspectable generated artifacts.
92−When your task produces a user-inspectable deliverable file, follow the Paperclip skill's "Generated Artifacts and Work Products" workflow before final disposition. In this repo, prefer the self-contained skill helper at `skills/paperclip/scripts/paperclip-upload-artifact.sh` so the file is available through the Paperclip API, create/update an artifact work product when the file is the deliverable, link the uploaded artifact in the final issue comment, and then set status. Do not rely on local filesystem paths as the only access path. If an important file intentionally remains workspace-only, create/update a work product with `metadata.resourceRef.kind: "workspace_file"` and a workspace-relative path, then name that work product and path in the final comment. Treat browse/search as a fallback for recovering workspace files, not the preferred deliverable path. See `doc/AGENT-ARTIFACTS.md` for details and `.mp4`/`.webm` examples.
93−
94−## 6. Database Change Workflow
95−
96−When changing data model:
97−
98−1. Edit `packages/db/src/schema/*.ts`
99−2. Ensure new tables are exported from `packages/db/src/schema/index.ts`
100−3. Generate migration:
101−
102−```sh
103−pnpm db:generate
104−```
105−
106−4. Validate compile:
107−
108−```sh
109−pnpm -r typecheck
110−```
111−
112−Notes:
113−- `packages/db/drizzle.config.ts` reads compiled schema from `dist/schema/*.js`
114−- `pnpm db:generate` compiles `packages/db` first
115−
116−## 7. Verification Before Hand-off
117−
118−Default local/agent test path:
119−
120−```sh
121−pnpm test
122−```
123−
124−This is the cheap default and only runs the Vitest suite. Browser suites stay opt-in:
125−
126−```sh
127−pnpm test:e2e
128−pnpm test:release-smoke
129−```
130−
131−Run the browser suites only when your change touches them or when you are explicitly verifying CI/release flows.
132−
133−For normal issue work, run the smallest relevant verification first. Do not default to repo-wide typecheck/build/test on every heartbeat when a narrower check is enough to prove the change.
134−
135−Run this full check before claiming repo work done in a PR-ready hand-off, or when the change scope is broad enough that targeted checks are not sufficient:
136−
137−```sh
138−pnpm -r typecheck
139−pnpm test:run
140−pnpm build
141−```
142−
143−If anything cannot be run, explicitly report what was not run and why.
144−
145−## 8. API and Auth Expectations
146−
147−- Base path: `/api`
148−- Board access is treated as full-control operator context
149−- Agent access uses bearer API keys (`agent_api_keys`), hashed at rest
150−- Agent keys must not access other companies
151−
152−When adding endpoints:
153−
154−- apply company access checks
155−- enforce actor permissions (board vs agent)
156−- write activity log entries for mutations
157−- return consistent HTTP errors (`400/401/403/404/409/422/500`)
158−
159−## 9. UI Expectations
160−
161−- Keep routes and nav aligned with available API surface
162−- Use company selection context for company-scoped pages
163−- Surface failures clearly; do not silently ignore API errors
164−
165−## 10. Pull Request Requirements
166−
167−When creating a pull request (via `gh pr create` or any other method), you **must** read and fill in every section of [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md). Do not craft ad-hoc PR bodies — use the template as the structure for your PR description. Required sections:
168−
169−- **Thinking Path** — trace reasoning from project context to this change (see `CONTRIBUTING.md` for examples)
170−- **What Changed** — bullet list of concrete changes
171−- **Verification** — how a reviewer can confirm it works
172−- **Risks** — what could go wrong
173−- **Model Used** — the AI model that produced or assisted with the change (provider, exact model ID, context window, capabilities). Write "None — human-authored" if no AI was used.
174−- **Checklist** — all items checked
175−
176−## 11. Definition of Done
177−
178−A change is done when all are true:
179−
180−1. Behavior matches `doc/SPEC-implementation.md`
181−2. Typecheck, tests, and build pass
182−3. Contracts are synced across db/shared/server/ui
183−4. Docs updated when behavior or commands change
184−5. PR description follows the [PR template](.github/PULL_REQUEST_TEMPLATE.md) with all sections filled in (including Model Used)
185−
186−## Design system
187−
188−`DESIGN.md` at the repo root is the source of truth for UI design decisions. The token-only rule applies to all `ui/` changes: every color, spacing, radius, type, shadow, and motion value in `ui/src/components/**` and `ui/src/pages/**` comes from the token layer in `ui/src/index.css` — no hex, raw px, arbitrary Tailwind bracket values, or raw `font-size`/`fontSize` declarations in components, outside the documented allowlist in `ui/src/index.css`. Run `pnpm check:token-gates` (`scripts/check-token-gates.mjs`) before committing UI changes — it fails on any violation not covered by that allowlist.
65+If a skill conflicts with this file, follow this file for identity. If a skill conflicts with the wiki-root `AGENTS.md`, follow that for page structure and voice.
18966
