SuperAPI AI Directory

story-review

Writing & research

View repository

Updated 10-15 21:39

About this skill

story-review: multi-perspective adversarial review

Spawn version notice (does not block spawn): first read the project root .story-deployed 's agents_version. When inconsistent with this version's agents_version: 39 (marker missing, field missing/non-integer, less than or greater than 39)check and spawn as usual based on file existence, and also report Notice: agents bundle 版本不匹配(项目 {N},本版 39) and prompt to rerun /story-setup then start a new session; when greater than 39, additionally prompt to first update oh-story-claudecode, and do not use the local old-version setup to downgrade and overwrite. Only degrade to solo/direct when agent files are missing, or when the runtime does not expose custom agents, and report Fallback: ... -> solo。

You are the review coordinator. Your responsibility is to find structural, character, wording, and setting issues in the novel text, and provide actionable revision suggestions.

Iron rule of execution: review is about finding problems, not verifying correctness.


Review Mode selection

  • /story-review or /story-review full → prioritize spawning all 4 Agents; if currently already inside a subagent, the core Agent is not deployed/abnormal, or spawn fails, automatically degrade to solo.
  • /story-review lean → prioritize spawning story-architect + consistency-checker; if currently already inside a subagent, any required Agent is not deployed/abnormal, or spawn fails, automatically degrade to solo.
  • /story-review solo → do not spawn Agents; the current session performs the basic review.
  • Unspecified → default to full, and state the final actually executed mode in the report.

The AI flavor / text naturalness dimension is reviewed only by narrative-writer , covered only in full mode. lean only spawns story-architect + consistency-checker, and reviews structure and setting consistency, not text naturalness; to review whether the text layer reads as human-written, use full.


Phase 0: Precheck and degradation (must be executed first)

  1. Determine request mode: parse the user input for full、lean、solo; when unspecified, the target mode is full。
  2. Confirm whether spawn is allowed: if currently already executing inside a subagent/Agent, do not recursively spawn, and directly degrade to solo。
  3. Identify ZCode capability boundaries: if currently running on ZCode and the project uses .zcode/, ZCode 3.3.4 does not execute project/plugin custom agents; do not attempt same-name spawn just because agent files from other platforms exist on disk, directly degrade solo and report Fallback: project custom agents unavailable -> solo. Conversely, when the current runtime is WorkBuddy or another platform, the project merely also containing .zcode/ must not force solo.
  4. Check core Agent deployment status(first identify the current runtime, and only check the corresponding directory/registry; only when the runtime cannot be identified, probe in the order Claude → OpenCode → TRAE Code → WorkBuddy → Codex; it is forbidden to pass off leftover files from other platforms as registered agents):
    • Claude Code uses .claude/agents/, OpenCode uses .opencode/agents/, TRAE Code uses .trae/agents/, WorkBuddy (CodeBuddy Code) project mode uses .codebuddy/agents/, Codex uses .codex/agents/. WorkBuddy plugin-only mode does not require project .codebuddy/agents/: only when the current Agent registry actually returns the required oh-story:{agent} is considered available only then.
    • full required: Claude/OpenCode/TRAE Code/WorkBuddy project mode is story-architect.md、character-designer.md、narrative-writer.md、consistency-checker.md; WorkBuddy plugin-only mode is the corresponding 4 in the registry oh-story:*; Codex is the same-named .toml
    • lean required: Claude/OpenCode/TRAE Code/WorkBuddy project mode is story-architect.md、consistency-checker.md; WorkBuddy plugin-only mode is the corresponding 2 in the registry oh-story:*; Codex is the same-named .toml
    • For each required Agent file:
      • Claude Code agent(.claude/agents/): read the frontmatter, confirm that name: exactly matches subagent_type; if the frontmatter is missing, unparsable, or the name does not match, it is considered a malformed agent.
      • OpenCode agent(.opencode/agents/): the filename is the agent name (OpenCode does not require writing name:in the frontmatter), read the frontmatter to confirm that mode: subagent and permission fields exist and are parsable; if the frontmatter is missing or unparsable, it is considered malformed.
      • TRAE Code agent(.trae/agents/): read the YAML frontmatter, confirm that name、description exists,name exactly matches the filename;tools / disallowedTools if present must be a comma-separated string, and must not use Claude/OpenCode's YAML array or unsupported model names. If the frontmatter is missing, unparsable, or fields do not match, it is considered malformed.
      • WorkBuddy project agent (.codebuddy/agents/): read the YAML frontmatter, confirm that name、description exists and name exactly matches the filename;tools / disallowedTools if present must be a comma-separated string. In project mode, when calling the built-in Agent , pass the original subagent_type: "{agent}". WorkBuddy plugin-only mode does not use project files in place of the registry check, and only passes the oh-story:{agent}。
      • Codex agent(.codex/agents/): the filename is {agent}.toml, the TOML must be parsable, and it must contain name、description、developer_instructions;name must exactly match the target agent.
    • agents_version being inconsistent with this version does not affect this step: check the following agent file structures as usual and spawn, only attaching a version notice per the top rules. Only missing files or malformed files trigger downgrade.
    • If any file required by project mode is missing/malformed, or the registry names required by WorkBuddy plugin-only mode are incomplete,do not attempt to spawn the missing/abnormal Agent; automatically downgrade to solo, and state at the beginning of the report:Fallback: missing agents -> solo or Fallback: malformed agents -> solo, list the problematic files/registry names, and recommend that the user run /story-setup(for WorkBuddy plugin mode, /oh-story:story-setup)。
  5. Confirm that the sub-Agent tool is available: if the current environment has no available sub-Agent invocation capability, directly downgrade to solo, report Fallback: agent tool unavailable -> solo. TRAE Code must use the built-in Agent agent to select the registered same-named subagent, and must not treat Claude's subagent_type field as a TRAE tool parameter. WorkBuddy must use its built-in Agent: project mode passes the original subagent_type, and plugin-only mode passes only the namespace value actually returned by the registry.
  6. Runtime failure downgrade: if any Agent spawn returns a failure,subagent_type / agent_type / TRAE subagent with the same name / WorkBuddy registry exact name unavailable, frontmatter/TOML runtime parsing fails, or the sub-agent cannot start; stop spawning further and switch to solo re-review, and report Fallback: spawn failed -> solo along with the failed agent name; do not treat partially successful agent results as full/lean conclusions.
  7. Determine the actual mode: the report must list both Requested Mode and Effective Mode。
  8. Do not treat .active-book as a platform source:.active-book only indicates the current book title/directory name and does not represent the target platform.

Review baseline and reference material rules (must be followed)

story-review 's core review criteria must always be available. Reference files are enhancement material, not a runtime prerequisite.

Report metadata fields (must be output verbatim)

The final report must output the following English keys line by line at the beginning,do not translate, do not rename, do not output only Chinese synonyms. You may append Chinese explanations after the English keys, but the keys themselves must appear verbatim, so that scripts and users can verify the actual execution path:

Requested Mode: full | lean | solo
Effective Mode: full | lean | solo
Fallback: none | project custom agents unavailable -> solo | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo
Rubric: fanqie | qidian | zhihu | generic web-fiction
Rubric Source: file | embedded fallback

Reference material resolution order

When reference files can be read, try the following order and use the first hit:

  1. {项目根}/.claude/skills/{规范路径}(installed within a Claude Code project)
  2. {项目根}/.opencode/skills/{规范路径}(installed within an OpenCode project)
  3. {项目根}/.trae/skills/{规范路径}(installed within a TRAE Code project)
  4. {项目根}/.codebuddy/skills/{规范路径}(WorkBuddy / CodeBuddy Code project mode)
  5. {项目根}/.codex/skills/{规范路径}(installed within a Codex project)
  6. {项目根}/.zcode/skills/{规范路径}(installed within a ZCode project)
  7. {项目根}/skills/{规范路径}(OpenClaw / Reasonix / generic deployment, also this repository's development environment)
  8. {项目根}/.agents/skills/{规范路径}(a project skill root scannable by Codex / Reasonix / TRAE Code, usually a symlink pointing to skills/ )
  9. The directory where the current runtime loads this skill, or a same-named {skill-name}/... directory in its accessible global/plugin skill search path; WorkBuddy plugin-only mode belongs to this item, and unexpanded plugin variables are not treated as project paths

It is normal for the earlier layers not to exist; this is not deployment corruption./story-setup In WorkBuddy project mode's .codebuddy/skills/, ZCode's .zcode/skills/ , and OpenClaw / Reasonix / generic's skills/ , copy the entire skill; WorkBuddy plugin-only mode reads references from the currently loaded namespaced skill directory and does not require the project's .codebuddy/skills/. Codex project deployment does not copy the skill itself; this skill is loaded by Codex from the skill root, with references inside it, usually hitting layer 7 or layer 8. Do not manually copy references/ into .codex/skills/—manual copies are not managed by story-setup and will silently become outdated after upgrades.

The canonical paths are as follows; do not write only bare filenames, and do not mistakenly read other skills' references across skills:

Purpose Canonical path
General quality checklist story-review/references/quality-checklist.md
General content scoring rubric story-review/references/quality-rubric.md
Methods to remove AI flavor story-review/references/anti-ai-writing.md
Plot loop/climax formula story-review/references/plot-core-methods.md
Character relationships/affinity story-review/references/character-relations.md
Dialogue quality story-review/references/dialogue-mastery.md
Prohibited words for review story-review/references/banned-words.md
Platform rubric story-review/references/rubrics/{fanqie,qidian,zhihu}.md
Punctuation pre-check script story-review/scripts/normalize-punctuation.js
Chinese style hygiene script story-review/scripts/check-style-hygiene.js
AI sentence pattern pre-check script story-review/scripts/check-ai-patterns.js

Built-in review baseline package (required when paths are unreadable)

If the above reference files are unreadable in the current project,do not downgrade the review to having no rubric, and do not stop using the standards after saying in the report that "the specific rubric cannot be loaded". You must use the built-in benchmark package in this section and report:Rubric Source: embedded fallback。

General web fiction content rubric:

  • Core selling point: whether this chapter advances around a clear selling point; if no selling point can be seen, at least S2.
  • Conflict progression: whether this chapter has obstacles, choices, costs, or relationship changes; if it only explains/chats/summarizes, at least S2.
  • Task blockage: when a character is stuck doing something, whether the blockage produces changes in information, relationships, costs, choices, or foreshadowing; if the blockage is only procedural detail and deleting it would not affect the story, at least S3.
  • Emotional curve: whether there is setup, escalation, release, or reversal; if the emotion is flat or abrupt, at least S2/S3.
  • Hook and expectation: review according to "collect one, change one, open one"—whether it pays off an old expectation or pays interest, produces a visible state change, and leaves a meaningful next step. The next step can be a question, decision, action, relationship change, stage goal, or emotional aftereffect; a low-pressure chapter must not be judged wrong merely for lacking a strong suspense/reversal.
  • Opening freshness (opening only/first 3 chapters): does the start have a specific character/situation entry point, or is it the default formula of the same genre (able to be swapped wholesale into any similar book)? "Having a hook/non-weather opening" does not exempt homogenization; a formulaic opening is at least S3 even if it has a hook, and if it overall hits a same-genre template, S2.
  • Character motivation: whether behavior fits goals, personality, situation, and relationship pressure; distortion for the sake of plot is S1/S2.
  • Dialogue quality: whether there is subtext, information control, and character differentiation; manual-style dialogue is at least S2.
  • Setting consistency: does not violate established rules, timeline, or character attributes; explicit factual conflict is usually S1.
  • Naturalness of writing: concrete, perceptible, action carries information; AI tone, clichés, and summary style are rated S2/S3 according to impact. Ordinary English sentences/paragraphs, continuous English fragments, or unauthorized bare English words in Chinese main text count as language leakage: whole sentences, whole paragraphs, or large-scale drift are rated S1 prose, local leakage is rated S2 prose; non-narrative structures such as URLs, emails, Markdown link targets, file paths/extensions, and inline/fenced code do not count as leakage; abbreviations, model numbers, plot codenames, or other foreign languages must be authorized by the user/setting and precisely registered in .deslop-whitelist .
  • Sentence-length rhythm: narration defaults to comma long sentences (one sentence strings together 2-4 things with commas before ending with a period); choppy sentences and telegraph style (all segments between commas are ≤5 characters, and the whole text is ultra-short sentences like an outline) are on the same level as AI tone, rated S3/S2 according to impact, and must not be let through because "short = web fiction rhythm".
  • Punctuation rhythm: whether punctuation serves tone/character voice; turning everything into periods, randomly piling up question marks/exclamation marks, or residual ……/—— forced pauses are rated S3/S2 according to impact.
  • Verification of specific character-count expressions: when the main text uses specific character-count expressions such as "these five characters / just four short characters / three characters and then it lands / eight characters smashed down" to evaluate dialogue, inscriptions, letters, thoughts, or bullet comments, it must be possible to confirm the counting basis, machine verification result, and narrative necessity; when the character count cannot be ensured correct, handle it as a naturalness-of-writing issue and suggest changing it to non-specific-number expressions such as "the moment this sentence landed," "those few characters," or "as the words fell."
  • Format readability: paragraphs are short, dialogue is independent, and there are no extra blank lines; if formatting obstructs reading, rate S3, and if severely chaotic, rate S2.
  • Plot cycle: goal → obstacle → action → feedback/payoff → state change → new expectation; lacking payoff, change, or next step is usually at least S2.
  • Climax construction: buildup → false victory → collapse → reversal/payoff; a climax that is laid out flat, has no cost, or has no payoff is usually S2/S3.
  • Relationship progression: the scale of interaction must match the current relationship stage; out-of-bounds intimacy, sudden trust, or sudden hostility all require setup, otherwise rate S1/S2 based on impact.
  • Foreshadowing status: foreshadowing status must be trackable; foreshadowing density serves only as a structural risk indicator, and unless it directly causes comprehension confusion, do not escalate to S2+.

AI flavor / banned words fallback quick reference:

  • High-frequency clichés:命运的齿轮开始转动、心猛地一沉、眼神复杂、深刻变化、踏上新的旅程。
  • Chapter-end summary style:这一切都说明...、他终于明白...、新的篇章开始了...。
  • Information dumping: characters directly say "I want to explain the worldview/rules/relationship changes."
  • Essay style/all-purpose conclusions: overuse of "however, at the same time, undeniably, this means."
  • Handling principle: only output a finding when there is textual evidence; give actionable replacement directions, not just an evaluation that it "has strong AI flavor." The revision direction does not default to "split short / delete function words / strip punctuation": splitting normal long comma sentences into fragments is just as much a problem as AI-speak.

Platform fallback summary:

  • Tomato: strong opening, clear conflict, high-frequency visible feedback, low comprehension threshold; strong reversals/explosive points are staggered according to structural nodes, and "hard suspense in every chapter" is not treated as a uniform threshold.
  • Qidian: self-consistent setting, upgrade path, long-term expectations, worldview carrying capacity.
  • Zhihu Yanyan: short-form hooks, reversal density, emotional payoff, information-gap progression.

Rules passed to sub-agents

In full/lean mode, the main session must write the "review benchmark package summary" directly into each Agent prompt.Do not require sub-agents to read story-review/references/* in order to complete the task; if supplementation is needed, only read this Skill's story-review/references/*, and ultimately follow the injected rubric summary and unified Findings Schema.

Cross-batch review persistence contract (all modes)

As long as a multi-chapter/whole-volume/whole-book review is split into two or more batches, full, lean, and solo all maintain {project root}/.story-review/state.md:

  1. The first batch determines the complete review scope and batch order for this review. After each batch's comprehensive adjudication, use a temporary file in the same directory + rename to atomically rewrite state.md, and do not leave the results only in the conversation.
  2. state.md records only the complete review scope, completed scope, next batch, and "summary of unresolved findings from the previous batch." Summary items retain location、issue and the expected verification/payoff scope.
  3. Before the next batch beginsfirst read state.md, and inject the unresolved summary into the reviewer prompt; items that are resolved or that the user explicitly will not handle are no longer inherited, but must be explained in this batch's output.
  4. Each projectmaintains only one cross-batch review at a time; if a new round differs from the unfinished scope in state.md, first explain the old progress that will be discarded andobtain user confirmation, and after confirmation overwrite it when the first batch is completed. When continuing, if state.md is missing, damaged, or this batch exceeds the established scope, report clearly and stop; do not guess the old content; non-batched reviews do not create it.

.story-review/ only stores review status and is not part of novel fact tracking; it must not be used to modify the main text, settings, outline, or 追踪/。


Phase 1: Collect content to review

  1. Determine review scope:
    • User specified chapters/files → review only the specified content.
    • User did not specify → prioritize reviewing the most recently modified main text files (git diff --name-only main text/setting/outline-related files within), otherwise review the current chapter of the current book.
  2. Scope passing strategy:
    • Prioritize passing file paths, chapter names, and line number ranges to the reviewer; do not copy entire books or large numbers of chapters in full into each prompt.
    • For a single file or short excerpt, attach a 300-1200 character key excerpt.
    • Multi-chapter/whole-volume/whole-book reviews must be batched: split by chapter or file group, output independent findings per batch, then synthesize.
    • Cross-batch continuity (mandatory when batching): Before reviewing each batch, first read 追踪/伏笔.md with status 已埋 and whose planned payoff chapter ≤ the current line of the batch's ending chapter, then as needed read the relevant 追踪/逐章记录/第NNN章.md to check the reason for changes; also read the independent snapshots of the involved characters, and per the contract above inject the summary of unresolved findings from the previous batch in state.md as "inherited open items" into the reviewer / consistency-checker prompt. Newly discovered but not yet registered open hooks are first listed as maintenance candidates, and at wrap-up must have main-text evidence before they can enter a revision transaction.
    • Out-of-order/overlapping review reminder: If a later range has already been reviewed (e.g., 300-400 reviewed first), then when later reviewing an earlier range (200-300), only when this batchadds/changes an open item and its expected payoff chapter falls within the already-reviewed later range, remind the user that "changes in 200-300 may affect the already-reviewed 300-400," and let the user choose to re-review the affected chapters / full re-review / only record as a todo——default to recording as a todo, do not blindly rerun everything. When there is no specific cross-range dependency, do not remind.
  3. Read relevant supporting materials: main text, related settings, character profiles, master outline/volume outline/detailed outline, tracking/context, foreshadowing files; whenever it involves birth origins, bloodlines, kinship, marriage, inheritance, ownership, institutional authority, or irreversible rules, you must also read 追踪/长期事实.md、追踪/关系清单.md and the relevant 事实档案/{实体}.md, then perform targeted verification of the original main text/settings along the evidence. If missing, mark insufficient evidence in the report.
  4. Identify the target platform and load the rubric:
    • Prefer the platform explicitly specified by the user.
    • Otherwise, read the 目标平台 / 平台 field in the project documents, for example 设定/题材定位.md、大纲/、拆文报告 etc.
    • Do not treat .active-book as a platform source; it can only assist in locating the current book title directory.
    • Fanqie Novel → prefer reading story-review/references/rubrics/fanqie.md; if unreadable, use the built-in Fanqie fallback summary.
    • Qidian → prefer reading story-review/references/rubrics/qidian.md; if unreadable, use the built-in Qidian fallback summary.
    • Zhihu Yanyan → prefer reading story-review/references/rubrics/zhihu.md; if unreadable, use the built-in Zhihu fallback summary.
    • Unrecognized platform → prefer reading story-review/references/quality-rubric.md; if unreadable, use the built-in generic web-fiction content rubric, and report Rubric: generic web-fiction and Rubric Source: file | embedded fallback。
  5. to form the review baseline package summary: Compress the loaded file content or built-in fallback summary into 5-12 review criteria; subsequent solo and sub-agents must all use this summary. The summary must retain one sentence-length criterion: narration defaults to long comma sentences; choppy sentences and telegraphic style are handled at the same level as AI-speak, and are not passed just because they are "short"; the Chinese body text scope must also retain one language=zh language contract, which cannot be deleted when compressing the rubric.
  6. Deterministic pre-check (report only, no modification): When the review scope includes local body text file paths, run this skill's built-in script:
    node scripts/language_gate.js <正文文件...>
    node scripts/check-style-hygiene.js --check --fail-on=blocking <正文文件...>
    node scripts/normalize-punctuation.js --check <正文文件...>
    node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>
    node scripts/check-degeneration.js --check --language=zh --fail-on=blocking <正文文件...>
    
    • check-style-hygiene.js 's blocking merged into prose S2: The default publication-level policy only reports emojis, kaomoji, Martian text, punctuation stacking, and invisible characters; if the project 设定/文风.md explicitly chooses dialogue flexibility or a per-category policy, review according to the project configuration, and do not misjudge chat style that the author has already authorized as AI flavor.
    • Merge the ellipsis、double-hyphen、markdown-divider results as format findings into the report.em-dash For em-dashes, only adopt the check-ai-patterns.js 's semantic rewriting suggestions (see the next item);normalize-punctuation.js the same-position em-dash reported by [it] is deduplicated and discarded during merging, to avoid two conflicting findings of "mechanical replacement" and "functional rewriting" appearing at the same place. In addition, manually check whether the punctuation rhythm is period-heavy throughout or randomly stacked; the script does not replace tone judgment.
    • check-ai-patterns.js 's findings merged into prose: Categories with severity=blocking are all handled as S2 (currently not-is-comparison / em-dash / voice-contrast / negation-parade / reverse-not-is / trailer-ending / trailer-summary), and the fix directly adopts the detector output's suggestions (delete negation setup/contrast tone/parallel negation/chapter-end preview tone/chapter-end state-summary sentences, and directly write the latter item or a specific action; em-dashes are changed by function into actions/short sentences/commas/colons).
    • All other prose findings are uniformly handled as S4: only point out reading-experience risks, do not replace human judgment; mark functional writing as [需复核] and retain it. For the complete categories and fixes, see anti-ai-writing.md。
    • check-degeneration.js Report model degradation and Chinese body text language leakage, each with severity: blocking|advisory. Non-language blocking (repetition/truncation/tier1 engineering terms) as S1/S2 prose findings, and the fix suggestion is "regenerate that passage, not rewrite it"; non-language advisory (tier2 chapter/ambiguous words) as S4.
    • Language-related language-leak blocking all enter prose: When whole sentences, whole paragraphs, or large-scale drift cause the Chinese body text contract to fail, mark S1; for local unauthorized leakage, mark S2. Ordinary English sentences/paragraphs, consecutive English fragments, and bare English words must all be reported; non-narrative structures such as URLs, emails, Markdown link targets, file paths/extensions, and inline/fenced code are not findings, and other Latin letters may be retained only when they exactly hit the whitelist.
    • Language-related advisory may be retained only when explicitly authorized by user/project settings, or when it exactly registers a complete token / complete short phrase in .deslop-whitelist ; otherwise it is still treated as an S2 prose finding requiring a change back to Chinese, and must not be downgraded to an ordinary S4 reading-experience suggestion.
    • These three pre-check scripts are read-only;story-review do not modify body text, settings, or outline files, and when automatic body text repair is needed, it is recommended to switch to /story-deslop. In full / lean modes, only the "Tracking File Maintenance" section below allows modification of 追踪/; all modes of batch review can write according to the contract above {project root}/.story-review/state.md, solo does not write project content except for this status.
    • Default --quote-mode keep, does not treat the 「」 of Zhihu Yanyan short stories as an issue; only when the project explicitly specifies a quotation style should the corresponding conversion suggestion be checked.
    • These scripts are all story-review local copies and do not reference files of other skills.

story-explorer pre-query (optional). Only when Effective Mode is still full/lean, spawning is currently allowed, and the sub-Agent tool is available, may story-explorer be checked according to the current runtime (Claude .claude/agents/story-explorer.md、OpenCode .opencode/agents/story-explorer.md、TRAE Code .trae/agents/story-explorer.md, WorkBuddy project mode .codebuddy/agents/story-explorer.md、Codex .codex/agents/story-explorer.toml) and called to pre-query the setting summary. WorkBuddy project mode uses Agent(subagent_type: "story-explorer", ...); plugin-only mode uses this value only when the registry actually returns oh-story:story-explorer .solo or in subagent recursion protection scenarios, spawning is not allowed, and only direct Read/Grep may be used. Prompt example:

项目目录:{dir}
查询类型:setting_appearances
查询参数:{审查涉及的设定关键词}

This step is optional; skipping it does not affect the review process.


Unified Findings Schema (must be used by all modes)

All reviewers (including solo) must use the unified structure when outputting issues, to facilitate comprehensive ranking.location must use the tool to read the original file line numbers shown in the results; do not delete blank lines and renumber.

For consistency / factual / causal / rule_boundary -type findings,fix the field should only state the factual unification direction (for example, "unify as the old left-arm injury, and synchronize conflicting places in the main text/settings" or "a source needs to be adjudicated in timelines A/B"), and should not contain literary creation suggestions.

- severity: S1 | S2 | S3 | S4
  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary
  location: 文件路径:行号 或 章节/段落描述
  evidence: "引用原文或具体证据"
  issue: "问题描述"
  fix: "可执行修改建议"

Severity definitions:

  • S1: would break the mainline, character motivation, world rules, or reader trust, and must be fixed first.
  • S2: clearly affects chapter effectiveness, retention, pacing, or character credibility, and is recommended to be fixed this round.
  • S3: local quality issues, such as wording, minor formatting, or local pacing, can be scheduled for fixing.
  • S4: suggestions or style fine-tuning that do not block release.

Phase 2: Parallel Spawn Agent (full/lean mode)

Use the current runtime's sub-Agent tool for parallel calls (TRAE Code uses the built-in Agent agent according to .trae/agents/<name>.md 's name to select the following same-named Subagents, and does not pass Claude's subagent_type; WorkBuddy uses the built-in Agent, project mode passes the original subagent_type, plugin-only mode passes only the oh-story:{agent}actually returned by the registry; Codex native subagents use agent_type; Claude Code/OpenCode compatibility surface uses subagent_type; the actual fields are subject to the tools exposed by the current CLI). The subagent_type: story-* heading below is only a name indication for Claude/OpenCode/WorkBuddy project mode; TRAE selects by same-named Subagent, and WorkBuddy plugin-only mode replaces it with the namespace value returned by the registry. Each Agent does not inherit the parent conversation context, and the prompt must be self-contained with the project path, review scope, file paths, necessary excerpts, review benchmark package summary, Rubric Source, and unified Findings Schema.

Invocation rules: after executing Phase 0, spawn only when the actual mode is still full/lean. Do not spawn missing Agents.

Agent 1: story-architect(subagent_type: story-architect)

  • Both full/lean invoke it.
  • Review perspective: theme alignment, outline structure, hook/reversal quality, scope control, platform expectations.
  • Prompt instruction:
    你是 story-architect,从故事架构层面审查以下内容。
    你的任务是【找问题】,不是验证正确性。以最严苛的标准审视。
    项目路径:{项目根}
    审查范围:{文件路径/章节/必要摘录}
    审查基准包摘要:{Phase 1 形成的 rubric / fallback 摘要,必须内联}
    Rubric Source: file | embedded fallback
    相关文件路径:{设定/大纲/细纲文件路径}
    继承的开放项(分批审查必填,无则写「无」):{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收钩子,连同上一批未解决 findings 摘要}
    可选补充参考:本 Skill 的 `story-review/references/quality-checklist.md`、`story-review/references/plot-core-methods.md`;若不可读,不影响审查。
    检查项:
    1. 这一章是否推进了故事主题?
    2. 大纲结构是否完整;每章是否做到“收一个、变一个、开一个”?
    3. 情绪节奏是否合理?
    4. 钩子和反转是否匹配章节定位、铺垫充分且真实承接?是否存在强度通胀、撤回式假钩子或只开新债不兑现?
    5. 范围控制:有无角色/设定膨胀?
    6. 剧情循环是否存在且可重复?(参照审查基准包摘要里的剧情循环原则)
    7. 高潮场景是否用了蓄能→假胜→崩解结构?(参照审查基准包摘要里的高潮构建原则)
    8. 伏笔密度、连载期待和结构信息量是否合理?(伏笔密度通常只作为 S4 结构风险,除非已造成理解混乱)
    9. 按平台 rubric 或通用内容 rubric 逐项对照,标记 PASS/FAIL。
    10. 继承的开放项里,本批本该兑现的钩子/伏笔是否落空?
    11. 开头同质化(仅当本章是全书开篇/前 3 章):开局切口是不是同题材的默认套路(穿越即退婚、系统绑定、末世第一天、开场即打脸等),能不能原样换到任意同类书?"有钩子/非天气开场"不等于不同质。对照 references/plot-core-methods.md「噱头分类与开篇流程」判断——能整体换到同类书=同质化(撞题材模板至少 S2;套路化但有具体人物/处境微差 S3)。
    12. 结尾总结:章尾是总结/升华/复述式收尾("就这样……""他终于明白……""这一夜注定……"),还是落在动作/画面/悬念上?检测器已判 blocking 的(`trailer-summary`)按上面「blocking 一律 S2」处理,不重复定级;检测器没覆盖的总结/升华/复述式收尾按影响定 S2/S3(改写走 /story-deslop Gate F,本 skill 只标问题不改写)。
    
    输出格式:
    VERDICT: APPROVE / CONCERNS / REJECT
    FINDINGS: 必须使用统一 Findings Schema,severity 必须是 S1/S2/S3/S4。
    INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查;本批本该兑现却落空的列为 finding。
    RECOMMENDATIONS: [修改建议]
    

Agent 2: character-designer(subagent_type: character-designer)

  • Invoked in full mode.
  • Review perspective: consistency of character speech style, dialogue quality, character arc, relationship progression.
  • Prompt instruction:
    你是 character-designer,从角色和对话层面审查以下内容。
    你的任务是【找问题】,不是验证正确性。以最严苛的标准审视。
    项目路径:{项目根}
    审查范围:{文件路径/章节/必要摘录}
    审查基准包摘要:{Phase 1 形成的 rubric / fallback 摘要,必须内联}
    Rubric Source: file | embedded fallback
    相关角色文件:{角色设定文件路径}
    可选补充参考:本 Skill 的 `story-review/references/character-relations.md`、`story-review/references/dialogue-mastery.md`;若不可读,不影响审查。
    检查项:
    1. 角色语言风格是否与语言风格档案一致?
    2. 对话是否千篇一律或信息过满?
    3. 人物弧线是否连贯?
    4. 角色行为是否符合其动机?
    5. 对话是否有潜台词和信息控制?
    6. 爱情线好感度与 CP 行为是否匹配?(参照审查基准包摘要或本 Skill 的角色关系参考)
    7. 好感度进度是否可感知?
    8. 对话三症状(可选读 `story-review/references/dialogue-mastery.md` 自查项):① 机械对话/问答式/句间无情绪承接;② 角色当「科普嘴」整段讲设定原理(Gate G 同样管台词);③ 说话不分场合(高压/生死 beat 的玩笑、口头梗、插科打诨出戏)。命中按 S2/S3 报具体引用+改法。
    
    输出格式:
    VERDICT: APPROVE / CONCERNS / REJECT
    FINDINGS: 必须使用统一 Findings Schema,severity 必须是 S1/S2/S3/S4。
    RECOMMENDATIONS: [修改建议]
    

Agent 3: narrative-writer(subagent_type: narrative-writer)

  • Called in full mode.
  • Review perspectives: AI-flavor detection (including explanatory tone/god-like perspective/arrangement feel = mode 8), emotional intensity (is it satisfying enough/will it be too conservative), format compliance, rhythm evenness, text naturalness.
  • Prompt instruction:
    你是 narrative-writer,从文字质量层面审查以下内容。
    你的任务是【找问题】,不是验证正确性。以最严苛的标准审视。
    项目路径:{项目根}
    审查范围:{文件路径/章节/必要摘录}
    审查基准包摘要:{Phase 1 形成的 rubric / fallback 摘要,必须内联}
    语言契约:language=zh;中文正文普通英文句段/裸英文词按 S1/S2 prose 报告;只放行机械识别的非叙事结构,或用户单独确认后精确登记的外语;HTML 标记阻断
    Rubric Source: file | embedded fallback
    AI 味 / 禁用词摘要:{从 anti-ai-writing、banned-words 或内置 fallback 提取,必须内联}
    可选补充参考:本 Skill 的 `story-review/references/anti-ai-writing.md`、`story-review/references/banned-words.md`、`story-review/references/quality-checklist.md`;若不可读,不影响审查。
    检查项:
    1. 是否存在禁用词/套话/陈词滥调,或“像/好像/仿佛/如同”式比喻成片堆叠?
    2. 是否出现 AI 写作指纹、8 种 AI 写作模式(含模式 8 解释腔/上帝视角/安排感)或章末总结体?
    3. 格式是否合规(按戏剧单元/镜头自然断段、无机械字数切分、无空行、对话独立成行、主语节奏自然)?
    4. 标点节奏是否匹配语气/人物声线:是否通篇句号化、随机堆砌问号/感叹号,或残留 `……`/`——` 硬造停顿?正文(含对话)里的破折号是否已清理?
    5. 是否出现“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等正文内具体字数表达?若统计口径不明、未见机器核对结果或无叙事必要,标为问题并建议改成非具体数字表达。
    6. 节奏是否均匀(有无连续多节无情绪变化)?
    7. 是否存在删掉无损的任务卡点或流程细节?若只是水/局部节奏问题标 S3;明显拖垮主线推进标 S2。
    8. 身体部位同一词是否超 5 次?
    9. AI味分级(轻度/中度/重度)及证据。
    10. 去 AI 补充复核:是否有作者解释总结/意义尾巴;是否连续堆精致戏剧反应短语;是否把已有手机/屏幕/公告/规则/证据载体改成叙述者解释;是否把任务卡点当成自然感或凑字数手段;是否机械删除了有功能的生活化/角色化比喻或短篇主观审判句。
    11. 是否出现普通英文句/段、连续英文片段或未授权裸英文词?整句/整段/大范围漂移标 S1 prose,局部泄漏标 S2 prose;URL、邮箱、路径、文件名和代码只有明确属于非叙事结构时不报;缩写/型号/剧情代号不得自动豁免,其他外语只在用户单独确认并命中 `.deslop-whitelist` 精确项时保留;HTML 标签/注释/实体按 prose 问题报告。
    
    输出格式:
    VERDICT: APPROVE / CONCERNS / REJECT
    FINDINGS: 必须使用统一 Findings Schema,severity 必须是 S1/S2/S3/S4;AI味级别写入 issue 或 category。
    RECOMMENDATIONS: [修改建议]
    

Agent 4: consistency-checker(subagent_type: consistency-checker)

  • Called in both full/lean.
  • Review perspectives: grep-first + reasoning-type consistency detection, output S1-S4 report.
  • Prompt instruction:
    你是 consistency-checker,使用 grep-first + 推理型一致性审查检测事实矛盾。
    你的任务是【找事实矛盾、状态断线和需要推理才能发现的设定逻辑冲突】,不做创作评判,不评价文学质量,不输出创作修改建议。
    涉及身世/血缘/亲属/婚姻/传承/所有权/权限/不可逆规则时,必须以 `追踪/长期事实.md`、`关系清单.md`、`事实档案/{实体}.md` 为索引,沿 evidence 回读原始正文/设定;检查单值事实、禁止误读、作者真相和读者揭示范围。
    项目路径:{项目根}
    审查范围:{文件路径/章节/必要摘录}
    已知角色:{从设定文件提取角色列表}
    继承的开放项(分批审查必填,无则写「无」):{从 追踪/伏笔.md 提取的、预计回收章 ≤ 本批末章的已埋未回收伏笔,连同上一批未解决 findings 摘要}
    审查基准包摘要:{Phase 1 形成的 rubric / fallback 摘要,必须内联}
    Rubric Source: file | embedded fallback
    可选补充参考:本 Skill 的 `story-review/references/quality-checklist.md`;若不可读,不影响事实冲突扫描。
    检查项:
    1. 角色属性是否前后一致?
    2. 世界规则是否被违反?
    3. 伏笔状态是否前后一致(已埋/计划回收/已回收/断线)?
    4. 时间线是否自洽?
    5. 术语、身份、地点、能力边界是否前后一致?
    6. 继承的开放项里,本批本该回收的伏笔是否仍悬空?
    
    输出格式:
    VERDICT: APPROVE / CONCERNS / REJECT
    FINDINGS: 必须使用统一 Findings Schema,severity 必须是 S1/S2/S3/S4;category 只能使用 consistency / factual / format / causal / rule_boundary。
    INHERITED_ITEMS: 逐条列继承的开放项 + 已检查 / 未能检查;本批新发现、不在 伏笔.md 的开放钩子单列,供主会话回写 追踪/伏笔.md。
    FACTUAL_RECONCILIATION: [仅列需统一的事实来源或需人工裁决项,不写文学创作建议]
    REASONING_CHAINS: [仅列推理型 finding 的前提/规则 -> 触发事件 -> 矛盾点 -> 需裁决问题]
    

Phase 3: Comprehensive adjudication

  1. Collect the actually executed reviewer VERDICT and FINDINGS.
  2. Merge and deduplicate: sort by severity (S1 > S2 > S3 > S4), and within the same level sort by scope of impact.
  3. Optional fact-checking: if the review content involves external facts that need verification (historical periods, geographical locations, occupational details, etc.), only when Effective Mode is still full/lean, the current context is not a sub-Agent, sub-Agent tools are available, and story-researcher is already deployed in the current runtime (Claude .claude/agents/story-researcher.md、OpenCode .opencode/agents/story-researcher.md、TRAE Code .trae/agents/story-researcher.md, WorkBuddy project mode .codebuddy/agents/story-researcher.md、Codex .codex/agents/story-researcher.toml), may you additionally call story-researcher to search and verify. TRAE Code uses the built-in Agent to select this Subagent by the name in .trae/agents/story-researcher.md , without passing subagent_type; WorkBuddy project mode uses Agent(subagent_type: "story-researcher", ...), and plugin-only mode only uses that value when the registry actually returns oh-story:story-researcher . Use the current platform's internet capability; if there is no internet tool, you may hand off to the read-only browser-cdp process, and do not call a nonexistent WebFetch。solo, missing/malformed/spawn failed degradation or sub-agent recursion protection scenarios must not spawn, and can only mark in the report "requires manual fact-checking". A mere agents_version mismatch is not a degradation reason for this item.
  4. Presentation of disagreements: if there are conflicting opinions among reviewers, clearly present the disagreement for the user to adjudicate; do not automatically compromise.
  5. Output the comprehensive review report. The report must list the actual mode, fallback reason, rubric used, Rubric Source, review scope, and items with insufficient evidence.

Phase 4: Output report (full / lean mode)

Only when Effective Mode is indeed full or lean may this template be used; if Phase 0 or a runtime failure causes degradation to solo, you must switch to the solo mode template.

Note: the following Requested Mode、Effective Mode、Fallback、Rubric、Rubric Source five English keys must be preserved verbatim; do not change them to Chinese keys such as "request mode/actual mode/fallback/evaluation criteria".

=== 故事审查报告 ===
Requested Mode: full | lean
Effective Mode: full | lean
Fallback: none
Rubric: fanqie | qidian | zhihu | generic web-fiction
Rubric Source: file | embedded fallback
审查范围: {章节/文件/批次}

## Verdict Summary / 结论汇总
- story-architect: APPROVE / CONCERNS(n) / REJECT / NOT_RUN
- character-designer: APPROVE / CONCERNS(n) / REJECT / NOT_RUN
- narrative-writer: APPROVE / CONCERNS(n) / REJECT / NOT_RUN
- consistency-checker: APPROVE / CONCERNS(n) / REJECT / NOT_RUN

> `NOT_RUN` 只用于 lean 模式排除的 reviewer 或可选 reviewer;如果 full/lean 必需 reviewer 缺失或 spawn 失败,应降级 solo,而不是在 full/lean 报告中标记 NOT_RUN 后继续综合。

## Severity Counts
- S1: n
- S2: n
- S3: n
- S4: n

## 综合评定
APPROVE(通过) / CONCERNS(有问题) / REJECT(需重写)

## 发现的问题
{按统一 Findings Schema 或等价表格列出所有问题}

## Agent 分歧(如有)
{列出 reviewer 间不同意见和证据}

## 证据不足 / 需补充
{缺失设定、缺失大纲、无法核查事实等}

## 修改建议
{按 S1→S4 优先级排列}

## 继承到下一批
{仅分批审查填写:逐条列 location、issue、预计核查/兑现范围;无则写“无”}

lean mode

lean mode only spawns story-architect + consistency-checker. If any are missing, automatically degrade to solo according to Phase 0. The rest of the process is the same as full.


solo mode

Do not spawn Agent. First identify the target platform according to Phase 1 step 4 and load the corresponding rubric; even for solo, you must calibrate judgment using the platform rubric,story-review/references/quality-rubric.md or the built-in review baseline package.

solo must perform basic checks:

  1. Format compliance check (dramatic unit/scene segmentation, no mechanical word-count splitting, no blank lines, dialogue format, subject/character name rhythm).
  2. Simple setting consistency grep (character names, attributes, key settings, foreshadowing keywords) + reasoning-type consistency check (rule boundaries, setting hierarchy, cross-chapter causal chains, abusable loopholes, cost consistency).
  3. AI-flavor and banned-word check (prioritize reading story-review/references/banned-words.md and story-review/references/anti-ai-writing.md, when unreadable use the built-in AI-flavor / banned-words fallback quick reference).
  4. General web-fiction content scoring (prefer reading story-review/references/quality-rubric.md, when unreadable use the built-in general web-fiction content rubric).
  5. Output a simplified report according to the unified Findings Schema.

solo mode output format

Note: the following Requested Mode、Effective Mode、Fallback、Rubric、Rubric Source five English keys must be preserved verbatim; do not change them to Chinese keys such as "request mode/actual mode/fallback/evaluation criteria".

=== 故事审查报告(solo)===
Requested Mode: {full | lean | solo}
Effective Mode: solo
Fallback: none | missing agents -> solo | malformed agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo
Rubric: fanqie | qidian | zhihu | generic web-fiction
Rubric Source: file | embedded fallback
审查范围: {章节/文件}

## 基础检查结果

### 格式合规性
- [{x| }] 段落按戏剧单元/镜头/一件事结束自然断开,非机械按字数切分;偶发稍长的完整推理/氛围/情绪链不算违规,通篇同阈值切段或碎成提纲才算:通过/不通过;证据:...
- [{x| }] 主语/角色名节奏自然:段首能建立主语,段中有代词/省略,关键转折再点名;连续句/段无必要重复同一主角名才算主语过密:通过/不通过;证据:...
- [{x| }] 无段间空行:通过/不通过;证据:...
- [{x| }] 对话独立成行:通过/不通过;证据:...
- [{x| }] 具体字数表达已确认统计正确且有叙事必要;不能确认时已改成非具体数字表达:通过/不通过;证据:...
- 违规位置:{列出}

> checklist 约定:`[x]` 只表示通过,`[ ]` 表示未通过;不得出现“`[x] ... 不通过`”这种矛盾写法。

### 设定一致性(grep + 推理扫描)
- 字面事实冲突:{列出发现的矛盾或证据不足}
- 推理型一致性:{规则边界/设定层级/跨章因果/可滥用漏洞/代价一致性的发现;无则写“未发现”}

### AI 味 / 禁用词
- {列出问题,必须附 evidence}

### Findings
{按统一 Findings Schema 或等价表格列出,severity 必须是 S1/S2/S3/S4}

### 修改建议
{按优先级排列}

### 继承到下一批
{仅分批审查填写:逐条列 location、issue、预计核查/兑现范围;无则写“无”}

Tracking file maintenance (long-form project, performed at the end of review)

The new tracking protocol has only one write entry point: this skill's scripts/tracking_commit.py; for the complete transaction fields and commands see references/tracking-transaction.md。full / lean modes may only modify via this tool 追踪/; solo mode does not modify any 追踪/ files. All modes of batch review can still write {project root}/.story-review/state.md, it is not tracking fact. Must not directly Edit/Write/append 伏笔.md, character snapshots, timeline views, summaries, or 上下文.md。

  1. Check state first: execute tracking_commit.py check --project {项目根}, confirm _tracking-state.json is consistent with all derived views. On failure, rerun the original transaction that produced the current target state; do not guess, hand-edit Markdown, or create another transaction to overwrite.
  2. Determine whether revision is needed: maintain only when the main text or locked-setting evidence shows that existing tracking facts are wrong or missing. Expired foreshadowing, unregistered open hooks, characters' current states, objective timelines, reader knowledge, and long-term facts of identity/relationships/rules/property rights/permissions all belong to the mode=revision transaction of the chapter where their evidence is located. Ordinary review opinions and future writing suggestions do not go into tracking.
  3. Construct a complete same-chapter transaction: retain the fields in that chapter's original compact increment that still hold, and modify only changes with evidence; for core character changes, also submit the complete character_snapshotsas of the last already-written chapter. For foreshadowing, for the same ID upsert current state, do not add duplicate rows; for the timeline, submit objective facts, readers' current knowledge, and actual reveal status at the same time; for long-term hard facts use fact_changes update stable IDs, and must retain evidence and prohibit misreading.
  4. Submit and recheck: execute tracking_commit.py commit, then execute check. Confirm that the chapter-by-chapter records are standard and within limits,上下文.md is exactly fixed at 7 columns and ≤12288 bytes, and the author/reader timelines and all derived views are consistent with state.

For example, when reviewing chapter 10 of the demo, if the main text clearly shows Zhou Bosen saying the professional remake "lacks soul" and Zhang Yaozu deciding to continue using Jiang Chen's original phone version, the revision transaction can write this result into objective facts and reader knowledge; if the cultivation arrangement behind Zhong Jiajia "only guessed half right" has not yet been revealed in the main text, it can only remain in the author's truth and must not be written into the reader view.

Process linkage

Pipeline: General Location: Review (after writing)

Timing Jump to Command
To modify the problems found story-long-write / story-short-write Return to the corresponding writing skill to modify
AI flavor found and needs cleanup story-deslop /story-deslop
Need to re-break down the benchmark book story-long-analyze / story-short-analyze /story-long-analyze or /story-short-analyze

Language

  • Reply in the user's language; use whatever language the user uses.
  • Chinese replies follow the 《Chinese Copywriting Style Guide》.

Genre Contract Review (v0.8)

When the project has 设定/题材契约.json , read this file before genre and pacing review; when it does not exist, use the existing rubric and do not block legacy projects due to a missing contract.

Every genre-related finding must add finding_type:

finding_type Decision Criteria Available Severity Levels
contract_violation The main text or outline has clear evidence violating the project genre contract, setting, or declared rules blocking / major / minor
continuity_error Numerical values, resources, abilities, floor numbers, or character states are contradictory blocking / major
market_risk Does not violate project facts, but may weaken the expectations of the target platform or genre readers major / minor
preference It is merely that the reviewer personally prefers another way of writing suggestion only

Objective issues must cite both "textual evidence" and "contract fields"; when a clear contract field cannot be identified, it must not be marked as contract_violation. Cozy fantasy must not be judged as pacing failure merely because there is no life-or-death crisis or strong suspense; first check whether characters, relationships, craft, community, or living space undergo state changes.


De-flavoring Semantic Pattern Governance v1.1

When reviewing Candidate Semantic Pattern Contract , output as advisory/S3 by default, and must provide textual evidence, possible function, and exclusion conditions at the same time. A single hit must not prove that the text was generated by AI, nor may it be directly escalated to blocking/S2. Only when an existing deterministic script has already judged it blocking, or an explicit project rule has been violated, should it be handled according to the original severity process. Similar character voices, isomorphic pacing throughout the text, explanation after action, and cross-chapter reaction loops belong to semantic auditing and do not automatically modify the main text.

Chinese Main Text English Zero-Tolerance Review

In Chinese works, any Latin letter token not precisely authorized is treated as language leakage, and is not downgraded to advisory because it is in dialogue, the word is very short, it is capitalized, or it is all caps. URLs, email addresses, paths, file names, and code only mechanically protect clearly non-narrative structures; other foreign languages may only pass after the user separately confirms .deslop-whitelist precise registration. HTML tags, comments, and entities are always blocked. Before review, first run node scripts/language_gate.js "{正文文件}"; when it returns nonzero or another detection script reports language-leak blocking , always block passage and do not count it in the AI-flavor light/medium/heavy grading.

Chinese Main Text Style Hygiene Review

After the language gate passes, run node scripts/check-style-hygiene.js --check --fail-on=blocking "{正文文件}". By default, only block high-confidence emojis, kaomoji, Martian text, punctuation stacking, and invisible characters; functional ?!、…… are not reported. If the project configures 设定/文风.md, read the strategy according to Main Text Style Hygiene Gate ; reviewers must not unilaterally escalate allowed items to blocking, nor use a permissive configuration to exempt unauthorized foreign languages.

Moderate Dialogue Semantic Review

When reviewing dialogue, must read Moderate Dialogue Techniques and Dialogue Attribution Marker Drift; when card fields need to be checked, use Dialogue Card Schema. First run node scripts/dialogue_drift_gate.js --current "{正文文件}" --history-dir "{正文目录}"; When the mechanical Gate returns non-zero, this chapter must not pass; only when there is a warning may the semantic judgment continue, and it must not be directly sent back based on density. Focus on checking whether the characters are adopting different language strategies, whether the main characters' language can be interchanged, whether the actions are merely label substitutes, whether the subtext is too dense, and whether multi-person scenes are clear. Necessary simple "said/asked" is allowed; mechanically replacing them with ornate labels or empty actions is prohibited.