القائمة
Use when authoring or reviewing specs, requirements, design docs, ADRs, tasks, glossary entries, domain terms, technical terms, or wording consistency across artifacts
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | glossary |
| description | Use when authoring or reviewing specs, requirements, design docs, ADRs, tasks, glossary entries, domain terms, technical terms, or wording consistency across artifacts |
Use existing repository terms before creating new ones.
glossary/business.md and/or glossary/technical.md when present.Do not add generic dictionary words or one-off implementation details.
glossary/business.md: domain, product, workflow, and business terms.glossary/technical.md: architecture, implementation, platform, and protocol terms.If a needed glossary file is missing, create it with this table:
| Term | Definition | Use When | Avoid |
| --- | --- | --- | --- |
New entries use the same table format. Keep definitions to one concise sentence.
Ask before creating a new term when existing terms may fit:
These glossary terms look close to "<concept>":
- `<existing-term>`: <why it may fit>
- `<another-term>`: <why it may fit>
Do you want to use one of these existing terms, or define a new term?
Do not proceed with a new term until the user answers, unless no plausible existing term exists.
In non-glossary artifacts, such as proposals, designs, specs, ADRs, and tasks, bold glossary terms that appear in the artifact's companion glossary reference.
Apply bolding in prose only. Do not bold terms in code blocks, frontmatter, links, or places where markdown formatting would make the artifact harder to read.
Every authored or edited non-glossary artifact gets a companion file in the same directory.
Do not create companion glossary reference files for glossary source files themselves, such as glossary/business.md or glossary/technical.md.
Name: remove .md, then append -glossary-reference.md.
Examples: proposal-glossary-reference.md, design-glossary-reference.md, spec-glossary-reference.md, adr-glossary-reference.md, tasks-glossary-reference.md.
Format:
# Glossary Reference
| Term | Source Glossary | Context |
| --- | --- | --- |
| <Term> | `glossary/business.md` | <Short context for how the artifact uses this glossary term.> |
Source Glossary is the glossary file the term came from or was added to, such as glossary/business.md or glossary/technical.md.
If no glossary terms are used, write:
# Glossary Reference
No glossary terms referenced.
Do not copy definitions into companion files.
Use when rules or instructions mention "adversarial-authoring", "adversarial authoring", "must use adversarial-authoring skill", "model council", "cross-model review", or "mixture of models"; coordinates adversarial authoring and review subagents and records council notes.
Use when documenting, drafting, reviewing, or updating architectural decisions, ADRs, decision logs, tradeoffs, rationale, consequences, alternatives, or architecture decision history.
Use when explaining existing code architecture, visualizing a new system before detailed design, mapping software boundaries, or creating C4-style diagrams in ASCII or Mermaid.
Use when drafting, reviewing, or improving Gherkin, Cucumber scenarios, BDD acceptance criteria, feature examples, Scenario Outlines, Backgrounds, Rules, Doc Strings, Data Tables, tags, or Gherkin embedded in Markdown.
Use when running OpenSpec propose, continue, apply, verify, archive, or worktree workflows where proposal artifacts, branches, merges, or archive timing affect git history.
Use when multiple active OpenSpec changes should be applied concurrently in isolated worktrees with delegated verification and no merge.