Scaffolds the per-repo config the mattpocock engineering skills expect: - AGENTS.md with the ## Agent skills block (issue tracker, triage labels, domain docs) - docs/agents/issue-tracker.md — Gitea REST API workflow (gh/glab don't apply) - docs/agents/triage-labels.md — canonical role -> Gitea label mapping (1:1) - docs/agents/domain.md — single-context CONTEXT.md/ADR consumer rules Triage state labels (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) created in the tracker; all open issues seeded with needs-triage. Run triage with /mattpocock-skills:triage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DgbgipE41xwPcQJnhnq1J1
1.4 KiB
Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
Before exploring, read these
CONTEXT.mdat the repo root, orCONTEXT-MAP.mdat the repo root if it exists — it points at oneCONTEXT.mdper context. Read each one relevant to the topic.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 creates them lazily when terms or decisions actually get resolved.
File structure
This is a single-context repo:
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-....md
│ └── 0002-....md
└── ...
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-0007 (…) — but worth reopening because…