arda/skills
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Removed relationships, example dialogue, and flagged ambiguities from CONTEXT.md template

Browse source
This commit is contained in:
Matt Pocock 2026-05-19 14:40:27 +01:00
parent bc32841b2e
commit e7df78bb81
1 changed files with 2 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

18
skills/engineering/grill-with-docs/CONTEXT-FORMAT.md
View file

@ -10,7 +10,7 @@
## Language ## Language
**Order**: **Order**:
{A concise description of the term} {A one or two sentence description of the term}
_Avoid_: Purchase, transaction _Avoid_: Purchase, transaction
**Invoice**: **Invoice**:
@ -20,27 +20,13 @@ _Avoid_: Bill, payment request
**Customer**: **Customer**:
A person or organization that places orders. A person or organization that places orders.
_Avoid_: Client, buyer, account _Avoid_: Client, buyer, account
## Relationships
- An **Order** produces one or more **Invoices**
- An **Invoice** belongs to exactly one **Customer**
## Example dialogue
> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed."
## Flagged ambiguities
- "account" was used to mean both **Customer** and **User** — resolved: these are distinct concepts.
``` ```
## Rules ## Rules
- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid. - **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution. - **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
- **Keep definitions tight.** One sentence max. Define what it IS, not what it does. - **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
- **Show relationships.** Use bold term names and express cardinality where obvious. - **Show relationships.** Use bold term names and express cardinality where obvious.
- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs. - **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine. - **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.