// Audit terminology consistency across documentation against the codebase UI labels and the glossary. Covers full files, not just diffs; excludes env var docs. Use after finalizing a draft, or when the user says "check terminology", "check terms", "verify glossary", or "terminology audit".
Use when editing, auditing, or creating OpenAPI specs for the Dify documentation repo. Applies to files in en/api-reference/. Covers formatting rules, error code conventions, example standards, operationId patterns.
Use when writing, rewriting, or auditing environment variable documentation for Dify self-hosted deployment. Applies to en/self-host/configuration/environments.mdx. Covers the full process from codebase tracing to user-facing descriptions.
Use when preparing documentation updates for a Dify release. User provides two version references to compare (e.g., v1.13.2 and v1.13.3, or v1.13.2 and main). Covers API reference, help documentation, environment variable changes, and UI i18n glossary impact.
Check formatting compliance in changed Chinese and Japanese documentation against writing-guides/formatting-guide.md, tools/translate/formatting-zh.md, and tools/translate/formatting-ja.md. Use after finalizing a translation batch, or when the user says "check formatting (zh/ja)", "check CJK formatting", or "format audit" on translated content.
Check formatting compliance in changed English documentation against writing-guides/formatting-guide.md. Use after finalizing a draft, or when the user says "check formatting", "format audit", "format check" on English content.
Research a Dify feature before writing or optimizing documentation. Use when starting any doc task that requires understanding a feature's implementation, user pain points, or community feedback. Triggers: 'research this feature', 'investigate the code for', 'what do users say about', 'let's understand how X works before writing', or any documentation task where the current docs are being rewritten or significantly expanded.
| name | dify-docs-terminology-check |
| description | Audit terminology consistency across documentation against the codebase UI labels and the glossary. Covers full files, not just diffs; excludes env var docs. Use after finalizing a draft, or when the user says "check terminology", "check terms", "verify glossary", or "terminology audit". |
Verify that documentation uses terms consistently with the codebase i18n (source of truth for UI labels) and the glossary (source of truth for general terms). Covers the whole file, not just the diff.
Ask the user: "Which branch in the Dify codebase should I check UI labels
against?" (e.g., main, feat/support-agent-sandbox). If the Dify
codebase is available as an additional working directory, use that. Otherwise,
ask the user for the local filesystem path to their Dify repo and use it for
reading i18n files.
Pull the latest code before checking. In the Dify codebase directory:
git fetch origin && git checkout <branch> && git pull origin <branch>
Determine the audit scope. Default to the whole file(s) currently under review (not just the diff), plus their zh/ja siblings when they exist. Expand to a directory or the full docs tree if the user specifies. Always exclude:
en/self-host/configuration/environments.mdxzh/self-host/configuration/environments.mdxja/self-host/configuration/environments.mdxEnvironment variable names are not UI labels and do not belong in the terminology check.
Read writing-guides/glossary.md — General Terms section.
For each file in scope, verify:
Skip zh/ja checks if the corresponding translation files don't exist locally (they may not have been generated yet for new documents).
For each file in scope, collect:
**...**) that refers to a UI element.##, ###) that names a product feature.Use judgment to skip bolds that are pure emphasis (e.g., **semantically**).
Verify every collected term against the codebase i18n as the source of truth:
web/i18n/en-US/, web/i18n/zh-Hans/, web/i18n/ja-JP/. Read files with
git show <branch>:<path> so you don't need to switch branches. The
glossary (writing-guides/glossary.md) is a convenience lookup; the
codebase wins when they disagree.
When the audit surfaces a UI label that is new, renamed, or inconsistent
with the codebase, propose an update to writing-guides/glossary.md in the
report. Note that tools/translate/derive-termbase.py should be run
afterward so tools/translate/termbase_i18n.md stays in sync.
## Terminology Check Results
### File: {path}
**General Terms**
- ✅ No issues found
OR
- ⚠️ Line {n}: "{found}" should be "{expected}" per glossary
**UI Labels**
- ✅ All UI labels (bolded terms and feature section headings) match codebase
OR
- ⚠️ Line {n}: **{label}** — codebase says "{expected}"
**Glossary Gaps**
- Terms used in docs but missing from glossary: {list}
- Glossary entries outdated compared to codebase: {list}