sulthan
3ea96e49b2
Adds docs/agents/{issue-tracker,triage-labels,domain}.md so the engineering
skills know where issues live (Gitea via tea, not gh), which triage labels to
apply, and that domain docs are single-context.
Every CLAUDE.md was a stale subset of the AGENTS.md beside it, so each is now
a symlink and AGENTS.md is the single source of truth.
1.8 KiB
Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the
codebase. Layout: single-context — one CONTEXT.md plus docs/adr/ at the repo root.
Before exploring, read these
CONTEXT.mdat the repo root — the glossary / ubiquitous language.docs/adr/— read ADRs that touch the area you're about to work in.
If any of these files don't exist, proceed silently. Don't flag their absence; don't suggest
creating them upfront. The /domain-modeling skill (reached via /grill-with-docs and
/improve-codebase-architecture) creates them lazily when terms or decisions actually get resolved.
Neither exists yet in this repo. The existing AGENTS.md / CLAUDE.md and docs/design-system.md
carry the current architecture and design law — read those regardless.
File structure
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-....md
│ └── 0002-....md
├── backend/
└── userscript/
If this repo ever splits into genuinely separate contexts, add a root CONTEXT-MAP.md pointing at
one CONTEXT.md per context and update this file.
Use the glossary's vocabulary
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a
test name), use the term as defined in CONTEXT.md. Don't drift to synonyms the glossary
explicitly avoids.
If the concept you need isn't in the glossary yet, that's a signal — either you're inventing
language the project doesn't use (reconsider) or there's a real gap (note it for
/domain-modeling).
Flag ADR conflicts
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
Contradicts ADR-0002 (…) — but worth reopening because…