Corp v1 Glossary

This skill governs project terminology. It keeps term definitions out of architecture, scope, delivery, and other domain pages while preserving links from those pages to one authoritative project Glossary.

When to Use

Use this skill when:

a Corp v1 page explains what a domain or technical term means;
the same term may appear in more than one documentation area;
reviewers disagree about terminology or classification;
creating or restructuring a project's top-level Glossary area;
adding, changing, deprecating, or linking a project term.

Do not use it for ordinary narrative, requirements, architecture decisions, procedures, or API reference that does not define reusable terminology.

Documentation Contract

Every Corp v1 project documentation site has Glossary as its final top-level menu item with a dedicated sidebar. The minimum sidebar begins with Terms; projects may add alphabetical term pages beneath it when the registry becomes difficult to scan.

A glossary entry records:

Term | definition | scope | status | aliases | related terms | authoritative links

Rules:

Define a term once in Glossary and link to it from domain pages.
Keep the definition concise and project-specific; do not paste generic encyclopedia material.
State the operational distinction the reader needs. For example, distinguish a deployable C4 container from a code component.
Preserve domain evidence in its owning area. Glossary explains the term; Architecture owns architecture facts and decisions, Scope owns product definitions, and Delivery owns implementation procedures.
Use stable lowercase anchors or slugs and link every first material use where Docusaurus permits.
Record aliases and deprecated wording rather than silently deleting terms that remain in historical records.
Mark uncertain or proposed definitions as Proposed; only verified/approved definitions are Adopted.
Avoid circular definitions and definitions that rely on unexplained project jargon.

Procedure

Identify the reusable term and the exact sentence that currently explains it. Completion: the candidate is terminology rather than domain evidence or procedure.
Search the project's Glossary and domain pages for existing definitions or aliases. Completion: duplicates and contradictions are listed.
Add or update one canonical Glossary entry with scope, status, aliases, related terms, and authoritative links. Completion: one stable term anchor or page owns the definition.
Replace duplicated explanatory prose with a concise contextual statement and Glossary link. Completion: domain pages retain only facts needed for that page.
Validate dedicated navigation, links, Docusaurus build, and deployed rendering using the project's documentation skill. Completion: the Glossary is last in top-level navigation and every changed link resolves.
Publish through the project's review and verification workflow. Completion: immutable source readback and deployed-page evidence confirm the term and links.

Pitfalls

Turning Glossary into a catch-all reference manual.
Moving architecture evidence or decisions out of Architecture.
Treating a library as a deployable container because both use the word “package.”
Duplicating the same definition across several pages.
Adding generic definitions that do not clarify project usage.
Renaming historical terminology without aliases or deprecation notes.
Placing Glossary anywhere except last in top-level navigation.

Verification

Glossary is the final top-level menu item and has a dedicated sidebar.
Every changed term has one canonical definition and stable link.
Domain pages link rather than repeat glossary-style explanations.
Scope, status, aliases, related terms, and authoritative links are present where applicable.
Domain-owned evidence and decisions remain in their owning sections.
Navigation, links, production build, deployed rendering, and immutable source readback pass.

4.3 KiB Raw Blame History