Back to Skills

Compliance Review Skill

Defines product terms, feature names, technical terms, and unified explanations for internal and external use. Use whenever the user looks up, defines, standardizes, or validates a term — including for UX copy, documentation, onboarding materials, or internal communications. Also triggered by questions like 'What is the official feature name?', 'How do we explain X?', 'Is this phrasing correct?', or 'What does Y mean in our context?'

Purpose

This skill ensures that all product terminology — feature names, technical concepts, and unified explanations — is applied consistently across documentation, UX copy, onboarding, internal communications, and customer-facing content. It prevents synonym drift, misuse of technical terms, and inconsistent feature naming.

Use this skill whenever you need to:

  • Look up or validate a term before writing

  • Define a new term in a standardized format

  • Audit existing content for terminology inconsistencies

  • Translate internal jargon into user-friendly explanations

KB-Grounding

Before defining or validating any term, always check the knowledge base first. This ensures the response reflects the organization's current, approved product language — not general or invented definitions.

Run the following queries as needed:

  • "product glossary [term]" — look up the official entry

  • "feature name [feature area]" — retrieve canonical naming

  • "technical term [concept]" — find the approved technical explanation

  • "onboarding terminology" — retrieve user-facing definitions

If no KB result is found for a term, flag it explicitly as undefined / not yet standardized and offer to draft a new entry for review.

Tool Rules

  • Use retrieve_from_knowledge_base(query) to locate existing glossary entries before responding.

  • Use create_text_document(prompt) when the user requests a glossary document, a term sheet, or a batch of standardized definitions.

  • Use edit_text_document(artifact_id, prompt) when refining or expanding an existing glossary artifact.

  • Do not use web search to define product-specific terms — all definitions must be grounded in organizational sources or explicitly flagged as proposals pending approval.

Clarification — When to Ask

Ask before starting only when:

  • The user requests a new term definition and no context or description has been provided → "Can you describe what this feature or concept does in 1–2 sentences? I'll draft a standardized entry for review."

  • The user requests bulk terminology validation across a document → "Should I flag every deviation, or only terms that clearly conflict with established definitions?"

Never ask about:

  • General product knowledge — use KB retrieval first; flag gaps only if nothing is found

  • Preferred output format for single-term lookups — always use the standard entry format below

  • Whether to check the knowledge base — always check it first before responding

Process / Decision Flow

Step 1 — Identify the task type:

  • Term lookup → retrieve from KB → present in standard entry format

  • Term validation (is this phrasing correct?) → compare against KB entry → confirm or flag deviation with correct alternative

  • New term definition → draft entry in standard format → flag as Proposed / Pending Review

  • Bulk audit → scan content against KB entries → surface deviations with line-level findings

Step 2 — Retrieve:
Always query the knowledge base with the term name and relevant context. If multiple results appear, prefer the most specific match (feature-level > module-level > general category).

Step 3 — Respond:

  • If the term is found: Present the canonical entry. Note any usage restrictions, synonyms to avoid, or context-specific guidance.

  • If the term is not found: State that clearly. Offer to draft a new entry using the standard format, and mark it as Proposed — requires internal review before use.

  • If the term is used incorrectly in provided content: Quote the incorrect usage, state the correct term, explain the distinction briefly.

Step 4 — For new entries: Present the draft entry for user review. Do not treat it as approved until the user confirms.

Standard Entry Format

Use this format for every term — whether retrieved, validated, or newly drafted:

**[Term Name]**
Type: [Feature | Technical Term | UI Label | Concept | Process]
Status: [Approved | Proposed — Pending Review | Deprecated]

**Definition (internal):**
[Precise, technical explanation for internal teams and documentation. 1–3 sentences.]

**Definition (user-facing):**
[Plain-language explanation for help articles, onboarding, and customer communication. Avoid jargon. 1–2 sentences.]

**Canonical name:** [Exact spelling, capitalization, and punctuation as it must appear in all content]
**Do not use:** [List of synonyms, informal names, or deprecated terms to avoid]
**Used in:** [Product areas, modules, or surfaces where this term appears]
**Notes:** [Usage restrictions, regional variants, related terms, or open questions — leave blank if none]

Output Format Examples

Single Term Lookup

Workspace
Type: Feature
Status: Approved

Definition (internal):
A Workspace is the top-level organizational container in the platform. Each Workspace has its own members, settings, billing, and data isolation. Sub-structures (projects, teams, channels) exist within a Workspace.

Definition (user-facing):
Your Workspace is where your team works together. It holds all your projects, members, and settings in one place.

Canonical name: Workspace (always capitalized; never "workspace", "space", or "organisation")
Do not use: "organization", "account", "space", "environment"
Used in: Onboarding flow, Settings panel, Admin dashboard, Help Center
Notes: When referring to multiple, use "Workspaces" (capital W). The billing unit is the Workspace, not the user seat.

Incorrect Term — Validation Finding

"organisation" (found in provided content)
✓ Use "Workspace" instead.
Reason: "Organisation" is not a recognized product term. The official term for the top-level container is "Workspace" (see canonical entry above). Using "organisation" creates confusion with legal/corporate entity language.

New Term — Proposed Entry

No entry found for "Smart Summary"
The following is a proposed entry based on your description. It requires internal review before use in official materials.

Smart Summary (Proposed — Pending Review)
Type: Feature
Status: Proposed

Definition (internal):
Smart Summary is an AI-generated digest that condenses a meeting transcript or document into key decisions, action items, and open questions. It is generated automatically after a meeting ends or when manually triggered by a user.

Definition (user-facing):
Smart Summary gives you a quick overview of what was decided and what needs follow-up — no need to read through the full transcript.

Canonical name: Smart Summary (two words, both capitalized)
Do not use: "AI summary", "auto-summary", "meeting digest"
Used in: Meeting details view, notification emails, export templates
Notes: Proposed name — confirm with Product team before publishing.

Guardrails

  • Never invent or assume definitions for product-specific terms. If the KB contains no entry, say so and offer a draft marked as Proposed.

  • Canonical names are non-negotiable. Do not suggest alternatives to approved term names unless the user explicitly requests a terminology review.

  • Deprecated terms must be flagged — do not present a deprecated term as current without noting its status and the replacement term.

  • User-facing and internal definitions serve different audiences. Never use internal technical language in user-facing copy, and never oversimplify in internal documentation where precision matters.

  • Maintain consistent capitalization and punctuation. A feature named "Smart Summary" is never "smart summary" or "SmartSummary" in output.