docs: sync App Toolkit with dify#35442 follow-up settings (#757)

* docs: sync App Toolkit page with follow-up settings PR and UI labels

* fix: correct CJK format linter false positives

* chore: broaden post-writing audit scope to whole documents

* docs: address Copilot review on PR #754

Restore the Tab titles rule in formatting-zh.md, which had been trimmed
to a stub. Drop the First-Mention Rule entry from the terminology-check
skill's Output Format so the report sections match the Checks to
Perform sections (the corresponding check was removed earlier).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: RiskeyL

.claude/skills/dify-docs-format-check-cjk/SKILL.md

@@ -12,7 +12,7 @@ description: >
 
 ## Purpose
 
-Verify changed Chinese (`zh/`) and Japanese (`ja/`) documentation against every rule in:
+Verify Chinese (`zh/`) and Japanese (`ja/`) documentation against every rule in:
 
 - `writing-guides/formatting-guide.md` — general rules
 - `tools/translate/formatting-zh.md` — Chinese-specific rules
@@ -22,13 +22,13 @@ Mechanical rules are enforced by the linter script (`check-format-cjk.py`); judg
 
 ## Before Starting
 
-Detect changed documentation files by combining:
+Audit the entire file, not just the diff. Default to files currently under review, detected via:
 
 - `git diff --name-only`
 - `git diff --cached --name-only`
 - Untracked files from `git status --porcelain` (lines starting with `??`)
 
-Filter for `.mdx` and `.md` files under `zh/` or `ja/`. If no changed files are detected, ask the user which files to check.
+Filter for `.mdx` and `.md` files under `zh/` or `ja/`. If no files are detected, ask the user which files to check.
 
 Because translations are typically produced as a zh/ja pair from the same English source, it is natural to audit both languages in a single session.
 

.claude/skills/dify-docs-format-check-cjk/check-format-cjk.py

@@ -57,6 +57,9 @@ def _strip_inline_code(line: str) -> str:
 
 def _strip_code_and_urls(line: str) -> str:
     s = INLINE_CODE_RE.sub('', line)
+    # collapse markdown image syntax ![alt](url) -> alt first so the leading
+    # `!` doesn't survive as prose punctuation adjacent to the alt text
+    s = re.sub(r'!\[([^\]\n]+)\]\([^)\n]+\)', r'\1', s)
     # collapse markdown link syntax [text](url) -> text so the bracket and
     # paren characters don't count as prose punctuation
     s = re.sub(r'\[([^\]\n]+)\]\([^)\n]+\)', r'\1', s)
@@ -500,17 +503,28 @@ def check_cjk_bold_spacing(lines: list[str]) -> list[Violation]:
     vs: list[Violation] = []
     in_fence = False
     # Bold adjacent to CJK without space: X**bold** or **bold**X where X is
-    # CJK and no space between.
-    pat_after = re.compile(rf'{CJK}\*\*[^*\n]+?\*\*')
-    pat_before = re.compile(rf'\*\*[^*\n]+?\*\*{CJK}')
+    # CJK and no space between. Match each complete **bold** span first, then
+    # inspect its outer neighbors so the closing `**` of one bold is never
+    # mistaken for the opening `**` of a later bold on the same line.
+    bold_pat = re.compile(r'\*\*[^*\n]+?\*\*')
+    cjk_re = re.compile(CJK)
     for i, line in enumerate(lines, 1):
         if FENCE_RE.match(line):
             in_fence = not in_fence
             continue
         if in_fence:
             continue
         s = _strip_inline_code(line)
-        if pat_after.search(s) or pat_before.search(s):
+        flagged = False
+        for m in bold_pat.finditer(s):
+            start, end = m.span()
+            if start > 0 and cjk_re.match(s[start - 1]):
+                flagged = True
+                break
+            if end < len(s) and cjk_re.match(s[end]):
+                flagged = True
+                break
+        if flagged:
             vs.append(Violation(
                 i, 'CJK-bold-no-space',
                 'Bold adjacent to CJK without space on that side.'))

.claude/skills/dify-docs-format-check-en/SKILL.md

@@ -11,17 +11,17 @@ description: >
 
 ## Purpose
 
-Verify changed English documentation against every rule in `writing-guides/formatting-guide.md`. Mechanical rules are enforced by a linter script (`check-format-en.py`); judgment-call rules are checked by reading the file.
+Verify English documentation against every rule in `writing-guides/formatting-guide.md`. Mechanical rules are enforced by a linter script (`check-format-en.py`); judgment-call rules are checked by reading the file.
 
 ## Before Starting
 
-Detect changed documentation files by combining:
+Audit the entire file, not just the diff. Default to files currently under review, detected via:
 
 - `git diff --name-only` (unstaged changes in tracked files)
 - `git diff --cached --name-only` (staged changes)
 - Untracked files from `git status --porcelain` (lines starting with `??`)
 
-Filter for `.mdx` and `.md` files under `en/`. If no changed files are detected, ask the user which files to check.
+Filter for `.mdx` and `.md` files under `en/`. If no files are detected, ask the user which files to check.
 
 ## Checks
 

.claude/skills/dify-docs-terminology-check/SKILL.md

@@ -1,18 +1,19 @@
 ---
 name: dify-docs-terminology-check
 description: >
-  Check terminology consistency in changed documentation against the glossary
-  and codebase UI labels. Use after finalizing a draft, or when the user says
-  "check terminology", "check terms", "verify glossary", or "terminology audit".
+  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".
 ---
 
 # Terminology Consistency Check
 
 ## Purpose
 
-Verify that changed documentation uses terms consistently with the glossary
-(`writing-guides/glossary.md`) and that bolded UI labels match the Dify
-codebase i18n files.
+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.
 
 ## Before Starting
 
@@ -27,69 +28,53 @@ codebase i18n files.
    git fetch origin && git checkout <branch> && git pull origin <branch>
    ```
 
-2. Detect changed documentation files by combining:
-   - `git diff --name-only` (unstaged changes in tracked files)
-   - `git diff --cached --name-only` (staged changes)
-   - Untracked files from `git status --porcelain` (lines starting with `??`)
+2. 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.mdx`
+   - `zh/self-host/configuration/environments.mdx`
+   - `ja/self-host/configuration/environments.mdx`
 
-   Filter for `.mdx` and `.md` files under doc content directories (`en/`, `zh/`,
-   `ja/`, `writing-guides/`). If no changed files are detected, ask the user
-   which files to check.
+   Environment variable names are not UI labels and do not belong in the
+   terminology check.
 
 ## Checks to Perform
 
 ### 1. General Term Consistency
 
 Read `writing-guides/glossary.md` — General Terms section.
 
-For each changed file, verify:
+For each file in scope, verify:
 
-- **English docs**: Terms match the English column. Flag any deviations
-  (e.g., "sandbox runtime" instead of "sandboxed runtime").
-- **Chinese docs**: Terms match the Chinese column. Flag mismatches
-  (e.g., 沙箱 instead of 沙盒).
+- **English docs**: Terms match the English column. Flag any deviations.
+- **Chinese docs**: Terms match the Chinese column. Flag mismatches.
 - **Japanese docs**: Terms match the Japanese column. Flag mismatches.
 
 Skip zh/ja checks if the corresponding translation files don't exist locally
 (they may not have been generated yet for new documents).
 
 ### 2. UI Label Consistency
 
-Read `writing-guides/glossary.md` — UI Labels section.
+For each file in scope, collect:
 
-For each changed file, find all **bolded terms** (text wrapped in `**...**`).
-Cross-reference against the UI Labels tables:
+- Every **bolded term** (text wrapped in `**...**`) that refers to a UI element.
+- Every section heading (`##`, `###`) that names a product feature.
 
-- The bolded text in English docs must match the English (UI) column.
-- The bolded text in Chinese docs must match the Chinese (UI) column.
-- The bolded text in Japanese docs must match the Japanese (UI) column.
+Use judgment to skip bolds that are pure emphasis (e.g., `**semantically**`).
 
-Not all bolded terms are UI labels — use judgment to distinguish UI references
-from emphasis. UI labels typically appear in instructional context ("click
-**Publish**", "enable **Agent Mode**").
+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.
 
-### 3. Codebase Verification (UI Labels Only)
+### 3. Glossary Updates
 
-For any UI label flagged as potentially inconsistent, or for new UI labels
-not yet in the glossary, verify against the codebase:
-
-1. Use `git show <branch>:<path>` to read i18n files from the user-specified
-   branch without switching branches. For example:
-   `git show feat/support-agent-sandbox:web/i18n/en-US/workflow.json`
-2. Search the relevant i18n JSON for the key.
-3. Report the actual codebase values.
-4. If the glossary is outdated compared to the codebase, flag it.
-
-### 4. First-Mention Rule (zh/ja Only)
-
-For Chinese and Japanese docs, check that general terms follow the
-first-mention parenthetical rule (defined in the glossary):
-
-- **Local term is primary**: First mention should be "本地术语（English term）"
-- **English term is primary**: First mention should be "English Term（本地术语）"
-- **Same across all languages**: No parenthetical needed
-
-Scope is per document — each page resets.
+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.
 
 ## Output Format
 
@@ -104,14 +89,9 @@ Scope is per document — each page resets.
 - ⚠️ Line {n}: "{found}" should be "{expected}" per glossary
 
 **UI Labels**
-- ✅ All bolded UI labels match glossary
-  OR
-- ⚠️ Line {n}: **{label}** — glossary says "{expected}", codebase says "{actual}"
-
-**First-Mention Rule** (zh/ja only)
-- ✅ All terms properly introduced
+- ✅ All UI labels (bolded terms and feature section headings) match codebase
   OR
-- ⚠️ Line {n}: "{term}" — missing first-mention parenthetical
+- ⚠️ Line {n}: **{label}** — codebase says "{expected}"
 
 **Glossary Gaps**
 - Terms used in docs but missing from glossary: {list}
@@ -122,5 +102,5 @@ Scope is per document — each page resets.
 
 - Do NOT modify any files. This is a read-only audit.
 - Report findings to the user for review.
-- If the glossary and codebase disagree, report both values and let the user
-  decide which to update.
+- Codebase i18n is the source of truth for UI labels. When the glossary
+  disagrees, update the glossary.

en/use-dify/build/additional-features.mdx

@@ -22,7 +22,7 @@ Dify apps come with optional features you can enable to improve the end-user exp
 
 Set an opening message that greets users at the start of each conversation, with optional suggested questions to guide them toward what the app does well.
 
-You can insert variables into the opening message and suggested questions to personalize the experience. 
+You can insert variables into the opening message and suggested questions to personalize the experience.
 
 - In the opening message, type `{` or `/` to insert variables from the picker.
 
@@ -43,18 +43,16 @@ You can insert variables into the opening message and suggested questions to per
 
 ## Follow-up
 
-When enabled, the LLM automatically suggests 3 follow-up questions after each response, helping users continue the conversation. This feature is a simple toggle—no additional configuration is needed.
+When enabled, follow-up questions are generated after each response to help users continue the conversation.
 
-<Info>
-Follow-up questions are generated by a separate LLM call using your workspace's system reasoning model (set in **Settings** > **Model Provider** > **Default Model Settings**), not the model configured in your app.
-</Info>
+Click **Settings** to pick the model that generates the questions, or write a custom prompt (up to 1,000 characters) to adjust the number, wording, or length of the questions.
 
 ## Text to Speech
 
 Convert AI responses to audio. You can configure the language and voice to match your app's audience, and enable **Auto Play** to stream audio automatically as the AI responds.
 
 <Info>
-**Text to Speech** uses your workspace's text-to-speech model (set in **Settings** > **Model Provider** > **Default Model Settings**). 
+**Text to Speech** uses your workspace's text-to-speech model (set in **Settings** > **Model Provider** > **Default Model Settings**).
 
 The feature only appears in the **Features** panel when a default TTS model is configured.
 </Info>
@@ -64,7 +62,7 @@ The feature only appears in the **Features** panel when a default TTS model is c
 Enable voice input for the chat interface. When enabled, your end users can dictate messages instead of typing by clicking the microphone button.
 
 <Info>
-**Speech to Text** uses your workspace's speech-to-text model (set in **Settings** > **Model Provider** > **Default Model Settings**). 
+**Speech to Text** uses your workspace's speech-to-text model (set in **Settings** > **Model Provider** > **Default Model Settings**).
 
 The feature only appears in the **Features** panel when a default STT model is configured.
 </Info>
@@ -112,7 +110,7 @@ You can configure the score threshold and the embedding model used for semantic
 
 To create and manage your annotations:
 
-- Convert existing conversations into annotations directly from **Debug & Preview** or **Logs** by clicking the **Add Annotation** icon on any LLM response. 
+- Convert existing conversations into annotations directly from **Debug & Preview** or **Logs** by clicking the **Add annotation** icon on any LLM response.
 
     Once a message is annotated, the icon changes to **Edit**, so you can modify the annotation in place.