rjminsha Use the grill-me skill to conduct the interview session, focused on domain terminology, system boundaries, and documentation decisions. If grill-me is not available, conduct the interview directly using the fallback instructions in REFERENCE.md.
Used skills
| Skill | If not available |
|---|---|
grill-me |
Interview the human directly: ask one relentless question at a time, walk each branch of the decision tree, provide a recommended answer for each, and explore the codebase when a question can be answered by it |
Domain awareness
This skill builds and maintains three living documents:
| File | Purpose |
|---|---|
LANGUAGE.md |
Canonical domain terms — what things mean. Glossary only, no implementation details. |
MAP.md |
Sparse system map — where things live and how they connect. Gives agents and developers with limited context a reference to the whole system. |
docs/decisions/ |
Hard-to-reverse, surprising, or genuine trade-off decisions. |
File structure
/
├── LANGUAGE.md ← domain glossary
├── MAP.md ← system map
├── docs/
│ └── decisions/
│ └── 0001-*.md
└── src/
Create files lazily — only when you have something to write. See REFERENCE.md for multi-context structure.
During the session
Challenge terms against LANGUAGE.md, sharpen fuzzy language, discuss concrete scenarios, and cross-reference claims with the code. See REFERENCE.md for detailed session behaviours.
Update LANGUAGE.md inline
When a term is resolved, update LANGUAGE.md right there. Don't batch these up — capture them as they happen. Use the format in LANGUAGE-FORMAT.md.
LANGUAGE.md is a glossary and nothing else — no implementation details, no decisions.
Validate new interfaces
Before any new component, module, UI, API surface, or CLI command is created:
- Check
MAP.mdfor an existing equivalent - Check the codebase for an existing equivalent
- If one exists: "This looks like it already exists as X — is creating a new one intentional?"
- If confirmed, ask what it does that the existing one does not, then update
MAP.md
Use the format in MAP-FORMAT.md.
Update MAP.md inline
Update MAP.md immediately when any of the following happen:
- A new component, UI, or related system is identified or confirmed
- A validation check reveals an entry in
MAP.mdneeds correcting - End of session — review
MAP.mdfor anything discussed but not yet captured
Offer decisions sparingly
Only offer a decision when it is hard to reverse, surprising without context, and the result of a real trade-off. See DECISIONS.md for the full criteria and format.
At the end of the session
Print the resulting file structure showing every file created or updated:
/
├── LANGUAGE.md ← updated
├── MAP.md ← updated
├── docs/
│ └── decisions/
│ └── 0001-example-decision.md ← created
└── src/