SikongJueluo
fba79504ac
- add AGENTS.md and docs for issue tracker, triage labels, and domain docs - add CONTEXT.md glossary for the permission authorization domain - add research report on context ownership for forwarded bash asks - ignore .pi-subagents and .codegraph directories - remove pi-permission-ai-judge from settings packages
1.6 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.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.
File structure
Single-context repo (this repo):
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-<decision>.md
│ └── 0002-<decision>.md
└── packages/
(If this repo ever grows into a genuinely large multi-package monorepo, switch to the multi-context layout: a root CONTEXT-MAP.md pointing at a CONTEXT.md per package, with docs/adr/ for system-wide decisions and per-package ADR dirs. For now one context covers everything.)
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-0001 () — but worth reopening because…