Domain Glossary
Build a consistent, accurate glossary for a domain: a planner sets the domain scope, the term-selection criteria, and the entry template, a researcher gathers the canonical definition and usage for each term with sources, and a copywriter writes the alphabetized glossary with cross-references and consistent entries. The ordering matters because terms picked ad hoc leave gaps and inconsistent entries confuse readers; locking the scope, what makes a term in-scope, and a fixed entry template first guarantees coverage and a uniform, cross-linked glossary. Use this for building a domain or product glossary, a terms/definitions reference, an acronym list, onboarding vocabulary, and 'define all the key terms in X' requests.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the glossaryplannerentry
domain, term-selection criteria, and entry template
Show working prompt
1. Define the domain and audience in one sentence (who reads this and at what level). 2. Set term-selection criteria (what makes a term in-scope) and produce the candidate term list (aim for the genuinely core terms, not every word). 3. Lock the entry template every term will follow: term, short definition (1-2 sentences), expanded explanation if needed, example/usage, related terms (cross-references), and source. 4. Decide ordering (alphabetical) and any grouping. 5. Write an acceptance-criteria checklist (e.g. 'every candidate term has an entry following the template', 'definitions are accurate and audience-appropriate', 'cross-referenced related terms exist as their own entries', 'entries are alphabetized', 'acronyms are expanded on first definition'). 6. Record decisions. Call write_task_note with the term list, entry template, and checklist; write the same to notes/scope.md.
- Gather definitionsresearcher
canonical definition + usage per term, with sources
Show working prompt
1. For each candidate term, gather the canonical definition into notes/terms.md following the entry template: term, accurate short definition, expanded note if the term is subtle, a real usage example, candidate related terms, and a source [n]. 2. Use authoritative sources (standards, official docs, reputable references) and reconcile conflicting definitions by noting the dominant usage in this domain. 3. Ensure every term named as a 'related term' is itself in the term list — add it if it is missing so cross-references resolve. 4. Expand every acronym and note common synonyms. 5. Flag any term whose meaning is contested or uncertain. Good looks like a complete, sourced entry per term with resolvable cross-references. Do not write the final glossary yet.
- Write the glossarycopywriter
alphabetized, cross-referenced glossary to the template
Show working prompt
1. Write glossary.md as an alphabetized list of entries, each following the locked template exactly (term as a heading, definition, optional expansion, example, related terms, source). 2. Make cross-references real: every 'related term' links to or names an entry that exists in the glossary. 3. Keep voice and depth uniform across entries — same level of detail and the same audience pitch throughout. 4. Expand acronyms on their defining entry. 5. Carry source references so definitions are traceable. 6. On a loop-back, fix only the named gaps. 7. Call write_task_note with the glossary path and term count.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open glossary.md and check EACH criterion PASS/FAIL: (1) every candidate term from notes/scope.md has an entry following the template; (2) entries are alphabetized; (3) every related-term cross-reference resolves to an actual entry (check 3 at random); (4) definitions are accurate and at the right audience level (spot-check 3 against notes/terms.md); (5) acronyms are expanded on first definition; (6) entry depth and voice are uniform. A glossary with missing terms, dangling cross-references, or inconsistent entry depth FAILS. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- build a glossary
- define the key terms
- domain terminology reference
- acronym list
- terms and definitions for
Source
View this craftbook on GitHub · MIT license