Spawn Version Notice (does not block spawn): First read

agents_version

from

.story-deployed

at the project root. When it does not match the current version

agents_version: 25

(marked as missing, field missing/non-integer, less than or greater than 25), proceed with file existence check and spawn as usual, while reporting

Notice: agents bundle version mismatch (project {N}, current version 25)

and prompting to restart the session after running

/story-setup

; if the version is greater than 25, additionally prompt to update oh-story-claudecode first, do not use local old setup to downgrade and overwrite. Degrade to solo/direct mode only when agent files are missing or custom agents are not exposed at runtime, and report

Fallback: ... -> solo

.

• /story-review

  or

  /story-review full

  → Prioritize spawning all 4 Agents; automatically degrade to solo mode if already within a sub-agent, core Agents are not deployed/abnormal, or spawn fails.

• /story-review lean

  → Prioritize spawning

  story-architect

  +

  consistency-checker

  ; automatically degrade to solo mode if already within a sub-agent, any required Agent is not deployed/abnormal, or spawn fails.

• /story-review solo

  → Do not spawn Agents; perform basic review in the current session.
• Unspecified → Default to full mode, and clearly state the final actual execution mode in the report.

1. Determine Request Mode: Parse

   full

   ,

   lean

   ,

   solo

   from user input; target mode is

   full

   if unspecified.
2. Confirm Spawn Permission: If currently executing within a sub-agent/Agent, do not recursively spawn, directly degrade to

   solo

   .
3. Identify ZCode Capability Boundaries: If running on ZCode and the project uses

   .zcode/

   , ZCode 3.3.4 does not execute project/plugin custom agents; do not attempt to spawn agents with the same name just because agent files for other endpoints exist on disk, directly degrade to

   solo

   and report

   Fallback: project custom agents unavailable -> solo

   .
4. Check Core Agent Deployment Status (Check project agents, compatible with Claude Code, OpenCode, and Codex):
   • Prioritize checking

     .claude/agents/

     , then

     .opencode/agents/

     , then

     .codex/agents/

     ; any of the three directories existing is considered deployed
   • Required for full mode: For Claude/OpenCode:

     story-architect.md

     ,

     character-designer.md

     ,

     narrative-writer.md

     ,

     consistency-checker.md

     ; for Codex: same names with

     .toml

     extension
   • Required for lean mode: For Claude/OpenCode:

     story-architect.md

     ,

     consistency-checker.md

     ; for Codex: same names with

     .toml

     extension
   • For each required Agent file:
     • Claude Code agent (

       .claude/agents/

       ): Read frontmatter, confirm

       name:

       matches subagent_type exactly; consider as malformed agent if frontmatter is missing, unparseable, or name does not match.
     • OpenCode agent (

       .opencode/agents/

       ): File name is the agent name (OpenCode does not require writing

       name:

       in frontmatter); read frontmatter to confirm

       mode: subagent

       and

       permission

       fields exist and are parseable; consider as malformed if frontmatter is missing or unparseable.
     • Codex agent (

       .codex/agents/

       ): File name is

       {agent}.toml

       , TOML must be parseable and contain

       name

       ,

       description

       ,

       developer_instructions

       ;

       name

       must match the target agent exactly.
   • If any required file for the target mode is missing or malformed, do not attempt to spawn missing/abnormal Agents; automatically degrade to

     solo

     , and clearly state at the beginning of the report:

     Fallback: missing agents -> solo

     or

     Fallback: malformed agents -> solo

     , list problematic files, and suggest the user run

     /story-setup

     .
5. Confirm Agent/Task Tool Availability: If no sub-Agent/Task calling capability is available in the current environment, directly degrade to

   solo

   , report

   Fallback: agent tool unavailable -> solo

   .
6. Runtime Failure Degradation: If any Agent spawn returns failure,

   subagent_type

   /

   agent_type

   is unavailable, frontmatter/TOML parsing fails at runtime, or sub-Agent cannot start, stop continuing to spawn, switch to

   solo

   for re-review, and report

   Fallback: spawn failed -> solo

   along with the failed subagent_type/agent_type; do not treat results from partially successful Agents as full/lean conclusions.
7. Determine Effective Mode: The report must list both

   Requested Mode

   and

   Effective Mode

   .

1. {Project Root}/.claude/skills/{Specification Path}

   (Installed within Claude Code project)

2. {Project Root}/.opencode/skills/{Specification Path}

   (Installed within OpenCode project)

3. {Project Root}/.codex/skills/{Specification Path}

   (Installed within Codex project)

4. {Project Root}/.zcode/skills/{Specification Path}

   (Installed within ZCode project)

5. {Project Root}/skills/{Specification Path}

   (OpenClaw / Reasonix / generic deployment, also the development environment of this repository)

6. {Project Root}/.agents/skills/{Specification Path}

   (Codex / Reasonix scanned project skill root, usually a symlink pointing to

   skills/

   )
7. The directory of the current runtime loading this skill, or the same-named

   {skill-name}/...

   directory in the accessible global skill search path

It is normal for the top few layers not to exist, not a deployment corruption.

/story-setup

only copies the entire skill to

.zcode/skills/

for ZCode and

skills/

for OpenClaw / Reasonix / generic; Codex project deployment does not copy the skill itself, this skill is loaded by Codex from the skill root, references are included in it, usually hitting layer 6 or 7. Do not manually copy

references/

into

.codex/skills/

— manual copies are not managed by story-setup and will silently become outdated after upgrades.

story-review/references/quality-checklist.md

story-review/references/quality-rubric.md

story-review/references/anti-ai-writing.md

story-review/references/plot-core-methods.md

story-review/references/character-relations.md

story-review/references/dialogue-mastery.md

story-review/references/banned-words.md

story-review/references/rubrics/{fanqie,qidian,zhihu}.md

story-review/scripts/normalize-punctuation.js

story-review/scripts/check-ai-patterns.js

Rubric Source: embedded fallback

• Core Selling Point: Does this chapter advance around a clear selling point; at least S2 if no selling point is discernible.
• Conflict Progression: Does this chapter have obstacles, choices, costs, or relationship changes; at least S2 if only explanation/chitchat/summary.
• Task Blockage: When a character is blocked from completing a task, does the blockage lead to changes in information, relationships, costs, choices, or foreshadowing; at least S3 if the blockage only has process details and can be deleted without affecting the story.
• Emotional Curve: Is there foreshadowing, escalation, release, or reversal; at least S2/S3 if emotions are flat or abrupt.
• Hooks and Expectations: Does the beginning or end create subsequent problems; at least S2 if no suspense or unfulfilled expectations.
• Opening Freshness (Only for opening/first 3 chapters): Does the opening have a specific character/situation entry, or is it the default routine of the same genre (can be directly applied to any similar book)? "Having a hook/not starting with weather" does not exempt homogenization; even if a routine opening has a hook, it is at least S3, and overall collision with the genre template is S2.
• Character Motivation: Does behavior align with goals, personality, situation, and relationship pressure; S1/S2 if distorted to serve the plot.
• Dialogue Quality: Is there subtext, information control, and character differences; at least S2 for instruction-manual style dialogue.
• Setting Consistency: Does not violate written rules, timeline, or character attributes; explicit factual conflicts are usually S1.
• Linguistic Naturalness: Specific, perceptible, actions carry information; AI tone, clichés, summary style are rated S2/S3 based on impact.
• Sentence Length Rhythm: Narration defaults to long comma-separated sentences (one sentence connects 2-4 events with commas before ending with a period); fragmented sentences and telegraph style (commas separating ≤5 words, full of ultra-short sentences like outlines) are treated at the same level as AI tone, rated S3/S2 based on impact, not allowed just because "short = web fiction rhythm".
• Punctuation Rhythm: Does punctuation serve tone/character voice; full-stop-only throughout, random stacking of question marks/exclamation marks, or residual

  ……

  /

  ——

  for forced pauses are rated S3/S2 based on impact.
• Specific Word Count Expression Verification: When the main text uses specific word count expressions such as "these five words / just four words / three words fall / eight words hit" to evaluate lines, inscriptions, letters, thoughts, or bullet comments, must confirm the statistical caliber, machine verification results, and narrative necessity; if word count calculation correctness cannot be ensured, treat it as a linguistic naturalness issue and suggest changing to non-specific number expressions like "this sentence falls" "those words" "the voice falls".
• Format Readability: Short paragraphs, independent dialogue, no extra blank lines; format hindering reading is S3, severe chaos is S2.
• Plot Cycle: Goal → Obstacle → Action → Cost/Feedback → New Expectation; at least S2 if goal/obstacle/feedback is missing.
• Climax Construction: Energy Accumulation → False Victory → Collapse → Reversal/Fulfillment; climax directly presented flatly, no cost or fulfillment is usually S2/S3.
• Relationship Progression: Interaction scale must match the current relationship stage; overstepping intimacy, sudden trust, sudden hostility all require foreshadowing, otherwise rated S1/S2 based on impact.
• Foreshadowing Status: Foreshadowing status must be traceable; foreshadowing density is only a structural risk prompt, not upgraded to S2+ unless it directly causes comprehension confusion.

• High-Frequency Clichés:

  命运的齿轮开始转动

  ,

  心猛地一沉

  ,

  眼神复杂

  ,

  深刻变化

  ,

  踏上新的旅程

  .
• Chapter-End Summary Style:

  这一切都说明...

  ,

  他终于明白...

  ,

  新的篇章开始了...

  .
• Information Dump: Characters directly say "我要解释世界观/规则/关系变化".
• Essay Style/Universal Conclusions: Overuse of "然而, 与此同时, 不可否认, 这意味着".
• Handling Principle: Only output findings if there is original text evidence; provide actionable replacement directions, not just evaluate "strong AI tone". Repair directions do not default to "shorten / delete function words / remove punctuation": splitting normal long comma-separated sentences into fragmented sentences is the same problem as AI tone.

• Fanqie: Strong opening, strong conflict, high-frequency cool points/emotional feedback, low understanding threshold.
• Qidian: Self-consistent settings, upgrade paths, long-term expectations, world view carrying capacity.
• Zhiyan (Zhihu): Short story hooks, reversal density, emotional fulfillment, information gap progression.

1. The first batch determines the complete review scope and batch order for this time. After each batch's comprehensive ruling, atomically rewrite state.md using a temporary file in the same directory + rename, do not only leave results in the conversation.
2. state.md only records the complete review scope, completed scope, next batch, and "summary of unresolved findings from the previous batch". Summary items retain location, issue, and expected verification/fulfillment scope.
3. Before starting the next batch, read state.md and inject the unresolved summary into the reviewer prompt; resolved items or items explicitly not handled by the user are no longer inherited, but must be explained in this batch's output.
4. Only one cross-batch review is maintained per project at the same time; if a new round has a different scope from the unfinished scope in state.md, first explain the old progress to be discarded and obtain user confirmation, then overwrite when the first batch is completed. If state.md is missing, damaged, or this batch exceeds the established scope when continuing, clearly report and stop, do not guess old content; do not create it for non-batch review.

追踪/

1. Determine Review Scope:
   • User specified chapters/files → Only review the specified content.
   • User did not specify → Prioritize reviewing the most recently modified main text files (main text/setting/outline-related files in

     git diff --name-only

     ), otherwise review the current chapter of the current book.
2. Scope Delivery Strategy:
   • Prioritize passing file paths, chapter names, line number ranges to reviewers, do not copy entire books or large numbers of chapters into each prompt.
   • For single files or short fragments, attach key excerpts of 300-1200 words.
   • Multi-chapter/entire volume/entire book review must be batched: split by chapters or file groups, output independent findings for each batch, then synthesize.
   • Cross-Batch Continuity (Required for Batched Review): Before reviewing each batch, first read lines in

     追踪/伏笔.md

     with status

     已埋

     and planned recovery chapter ≤ the last chapter of this batch, then read relevant

     追踪/逐章记录/第NNN章.md

     to check change reasons; at the same time, read independent snapshots involving characters, and inject the summary of unresolved findings from state.md as "inherited open items" into the reviewer / consistency-checker prompt according to the above contract. Newly discovered but unregistered open hooks are first listed as maintenance candidates, and must have main text evidence to enter revision transactions when concluding.
   • Out-of-Order/Overlapping Review Reminder: If a later scope has been reviewed (e.g., first review 300-400), then reviewing an earlier scope (200-300) only needs to remind the user "Changes in 200-300 may affect the reviewed 300-400" when this batch adds/modifies an open item whose expected fulfillment chapter falls within the reviewed later scope, and let the user choose to re-review affected chapters / full re-review / only mark as to-do — default to marking as to-do, do not blindly re-run in full. Do not remind if there is no specific cross-scope dependency.
3. Read Relevant Supporting Materials: Main text, related settings, character profiles, outlines, tracking/context, foreshadowing files; mark insufficient evidence in the report if missing.
4. Identify Target Platform and Load Rubric:
   • Prioritize using the platform explicitly specified by the user.
   • Secondly, read the

     目标平台

     /

     平台

     field in project documents, such as

     设定/题材定位.md

     ,

     大纲/

     ,

     拆文报告

     , etc.
   • Do not treat

     .active-book

     as a platform source; it can only assist in locating the current book's directory.
   • Fanqie Novel → Prioritize reading

     story-review/references/rubrics/fanqie.md

     ; use built-in Fanqie fallback summary if unreadable.
   • Qidian → Prioritize reading

     story-review/references/rubrics/qidian.md

     ; use built-in Qidian fallback summary if unreadable.
   • Zhiyan (Zhihu) → Prioritize reading

     story-review/references/rubrics/zhihu.md

     ; use built-in Zhihu fallback summary if unreadable.
   • Unidentified platform → Prioritize reading

     story-review/references/quality-rubric.md

     ; use built-in general web fiction content rubric if unreadable, and report

     Rubric: generic web-fiction

     and

     Rubric Source: file | embedded fallback

     .
5. Form Review Benchmark Package Summary: Compress the loaded file content or built-in fallback summary into 5-12 review standards, which must be used by both subsequent solo and sub-Agents. The summary must retain one sentence length standard: narration defaults to long comma-separated sentences, fragmented sentences and telegraph style are treated at the same level as AI tone, not allowed just because "short".
6. Deterministic Pre-check (Report Only, No Modification): When the review scope includes local main text file paths, run the scripts included with this skill:
   bash

   node scripts/normalize-punctuation.js --check <main text files...>
   node scripts/check-ai-patterns.js --check --fail-on=blocking <main text files...>
   node scripts/check-degeneration.js --check <main text files...>

   • Merge

     ellipsis

     ,

     double-hyphen

     ,

     markdown-divider

     results into

     format

     findings in the report. For

     em-dash

     , only adopt semantic rewriting suggestions from

     check-ai-patterns.js

     ; duplicate

     em-dash

     at the same location reported by

     normalize-punctuation.js

     is deduplicated and discarded during merging to avoid two conflicting findings of "mechanical replacement" and "functional rewriting" appearing at the same place. Additionally, manually check if punctuation rhythm is full-stop-only throughout or randomly stacked, scripts do not replace tone judgment.
   • Merge findings from

     check-ai-patterns.js

     into

     prose

     : categories with severity=blocking are uniformly rated S2 (currently

     not-is-comparison

     /

     em-dash

     /

     voice-contrast

     /

     negation-parade

     /

     reverse-not-is

     /

     trailer-ending

     /

     trailer-summary

     ), directly adopt the detector's output suggestions for repair (delete negative foreshadowing/contrast tone/parallel negation/chapter-end preview tone/chapter-end status summary sentences, directly write the latter part or specific actions; rewrite em-dashes into actions/short sentences/commas/colons according to function).
   • Other prose findings are uniformly rated S4: only point out readability risks, do not replace manual judgment; functional writing is marked

     [需复核]

     and retained. Complete categories and repair methods are in

     anti-ai-writing.md

     .

   • check-degeneration.js

     reports model degeneration (word-for-word repetition/truncation/placeholders/engineering word leakage), each with

     severity: blocking|advisory

     : blocking (repetition/truncation/tier1 engineering words) are treated as S1/S2

     prose

     findings, repair suggestion is "Regenerate this section, do not rewrite"; advisory (tier2 chapter/ambiguous words) are treated as S4.
   • These three pre-check scripts are read-only;

     story-review

     does not modify main text, setting, or outline files, suggest switching to

     /story-deslop

     for automatic main text repair. Only the "Tracking File Maintenance" below allows modifying

     追踪/

     in full / lean modes; all modes for batched review can write .story-review/state.md according to the above contract, solo mode does not write project content except for this state.
   • Default

     --quote-mode keep

     , do not treat

     「」

     in Zhiyan short stories as problems; only check corresponding conversion suggestions when the project explicitly specifies quote style.

Effective Mode

full

lean

story-explorer.md

story-explorer.toml

.claude/agents/

.opencode/agents/

.codex/agents/

story-explorer

solo

Project Directory: {dir}
Query Type: setting_appearances
Query Parameters: {setting keywords involved in review}

location

consistency

factual

causal

rule_boundary

fix

- severity: S1 | S2 | S3 | S4
  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary
  location: File path:line number or chapter/paragraph description
  evidence: "Quote original text or specific evidence"
  issue: "Problem description"
  fix: "Actionable modification suggestion"

• S1: Will destroy main plot, character motivation, world rules, or reader trust, must be fixed first.
• S2: Obviously affects chapter effect, retention, rhythm, character credibility, recommended to fix in this round.
• S3: Local quality issues, such as wording, minor format, local rhythm, can be scheduled for repair.
• S4: Suggestions or style fine-tuning, does not block release.

agent_type

subagent_type

• Called in both full/lean modes.
• Review Perspective: Theme alignment, outline structure, hook/reversal quality, scope control, platform expectations.
• Prompt Instructions:

  You are story-architect, reviewing the following content from a story architecture perspective.
  Your task is to【find problems】, not verify correctness. Examine with the strictest standards.
  Project Path: {Project Root}
  Review Scope: {File path/chapter/necessary excerpts}
  Review Benchmark Package Summary: {rubric / fallback summary formed in Phase 1, must be inline}
  Rubric Source: file | embedded fallback
  Related File Paths: {Setting/outline/detailed outline file paths}
  Inherited Open Items (Required for Batched Review, write "None" if none): {Buried unrecovered hooks extracted from `追踪/伏笔.md` with planned recovery chapter ≤ the last chapter of this batch, along with summary of unresolved findings from previous batch}
  Optional Supplementary Reference: This Skill's `story-review/references/quality-checklist.md`, `story-review/references/plot-core-methods.md`; if unreadable, does not affect review.
  Check Items:
  1. Does this chapter advance the story theme?
  2. Is the outline structure complete (hooks/cool points/suspense)?
  3. Is the emotional rhythm reasonable?
  4. What is the quality of hook and reversal design?
  5. Scope Control: Is there character/setting bloat?
  6. Does the plot cycle exist and is repeatable? (Refer to plot cycle principles in review benchmark package summary)
  7. Does the climax scene use the energy accumulation→false victory→collapse structure? (Refer to climax construction principles in review benchmark package summary)
  8. Is the foreshadowing density, serialization expectation, and structural information volume reasonable? (Foreshadowing density is usually only an S4 structural risk, unless it directly causes comprehension confusion)
  9. Compare item by item according to platform rubric or general content rubric, mark PASS/FAIL.
  10. Among inherited open items, are hooks/foreshadowing that should be fulfilled in this batch unfulfilled?
  11. Opening Homogenization (Only if this chapter is the opening/first 3 chapters of the book): Is the opening entry the default routine of the same genre (transmigration → annulment, system binding, first day of apocalypse, opening → slap in the face, etc.), can it be directly applied to any similar book? "Having a hook/not starting with weather" does not mean non-homogeneous. Judge by "Gimmick Classification and Opening Process" in references/plot-core-methods.md — can be directly applied to similar books = homogenization (colliding with genre template is at least S2; routine but with specific character/situation minor differences is S3).
  12. Ending Summary: Does the chapter end with a summary/sublimation/reiteration ("And so..." "He finally understood..." "This night was destined...") or on an action/scene/suspense? Those judged as blocking by the detector (`trailer-summary`) are treated as S2 according to the above "blocking uniformly S2", no repeated rating; summary/sublimation/reiteration endings not covered by the detector are rated S2/S3 based on impact (rewrite via /story-deslop Gate F, this skill only marks issues and does not rewrite).
  
  Output Format:
  VERDICT: APPROVE / CONCERNS / REJECT
  FINDINGS: Must use unified Findings Schema, severity must be S1/S2/S3/S4.
  INHERITED_ITEMS: List inherited open items one by one + checked / unable to check; unfulfilled hooks/foreshadowing that should be fulfilled in this batch are listed as findings.
  RECOMMENDATIONS: [Modification Suggestions]

• Called in full mode only.
• Review Perspective: Character language style consistency, dialogue quality, character arc, relationship progression.
• Prompt Instructions:

  You are character-designer, reviewing the following content from a character and dialogue perspective.
  Your task is to【find problems】, not verify correctness. Examine with the strictest standards.
  Project Path: {Project Root}
  Review Scope: {File path/chapter/necessary excerpts}
  Review Benchmark Package Summary: {rubric / fallback summary formed in Phase 1, must be inline}
  Rubric Source: file | embedded fallback
  Related Character Files: {Character setting file paths}
  Optional Supplementary Reference: This Skill's `story-review/references/character-relations.md`, `story-review/references/dialogue-mastery.md`; if unreadable, does not affect review.
  Check Items:
  1. Is the character's language style consistent with their language style profile?
  2. Is the dialogue uniform or overloaded with information?
  3. Is the character arc coherent?
  4. Does the character's behavior align with their motivation?
  5. Does the dialogue have subtext and information control?
  6. Does the love line favorability match CP behavior? (Refer to review benchmark package summary or this Skill's character relationship reference)
  7. Is the favorability progress perceivable?
  8. Three Dialogue Symptoms (Optional read self-check items in `story-review/references/dialogue-mastery.md`): ① Mechanical dialogue/Q&A style/no emotional connection between sentences; ② Characters act as "science popularization mouth" explaining setting principles in entire paragraphs; ③ Speaking regardless of occasion (jokes, catchphrases, buffoonery in high-pressure/life-or-death beats that break immersion). Report with specific quotes + modification methods if hit, rated S2/S3.
  
  Output Format:
  VERDICT: APPROVE / CONCERNS / REJECT
  FINDINGS: Must use unified Findings Schema, severity must be S1/S2/S3/S4.
  RECOMMENDATIONS: [Modification Suggestions]

• Called in full mode only.
• Review Perspective: AI tone detection (including explanatory tone/God's sense/arrangement sense = Mode 8), emotional intensity (cool enough/too conservative), format compliance, rhythm uniformity, linguistic naturalness.
• Prompt Instructions:

  You are narrative-writer, reviewing the following content from a linguistic quality perspective.
  Your task is to【find problems】, not verify correctness. Examine with the strictest standards.
  Project Path: {Project Root}
  Review Scope: {File path/chapter/necessary excerpts}
  Review Benchmark Package Summary: {rubric / fallback summary formed in Phase 1, must be inline}
  Rubric Source: file | embedded fallback
  AI Tone / Banned Words Summary: {Extracted from anti-ai-writing, banned-words or built-in fallback, must be inline}
  Optional Supplementary Reference: This Skill's `story-review/references/anti-ai-writing.md`, `story-review/references/banned-words.md`, `story-review/references/quality-checklist.md`; if unreadable, does not affect review.
  Check Items:
  1. Are there banned words/clichés/chestnuts, or stacked metaphors like "like/seem/as if/如同"?
  2. Are there AI writing fingerprints, 8 AI writing modes (including Mode 8 explanatory tone/God's perspective/arrangement sense) or chapter-end summary style?
  3. Is the format compliant (naturally segmented by dramatic unit/shot, no mechanical word count segmentation, no blank lines, dialogue on independent lines, natural subject rhythm)?
  4. Does punctuation rhythm match tone/character voice: Is it full-stop-only throughout, random stacking of question marks/exclamation marks, or residual `……`/`——` for forced pauses? Have em-dashes in main text (including dialogue) been cleaned up?
  5. Are there specific word count expressions in the main text such as "these five words / just four words / three words fall / eight words hit"? If statistical caliber is unclear, no machine verification results, or no narrative necessity, mark as a problem and suggest changing to non-specific number expressions.
  6. Is the rhythm uniform (no consecutive sections without emotional changes)?
  7. Are there task blockages or process details that can be deleted without loss? If only padding/local rhythm issue, mark S3; if obviously drags main plot progression, mark S2.
  8. Is the same body part word used more than 5 times?
  9. AI tone classification (mild/moderate/severe) and evidence.
  10. Anti-AI Supplementary Review: Are there author explanations/summaries/meaning tails; are there consecutive stacks of delicate dramatic reaction phrases; are existing mobile phone/screen/announcement/rule/evidence carriers changed to narrator explanations; are task blockages treated as naturalness or word count padding means; are functional life-like/characterized metaphors or short story subjective judgment sentences mechanically deleted?
  
  Output Format:
  VERDICT: APPROVE / CONCERNS / REJECT
  FINDINGS: Must use unified Findings Schema, severity must be S1/S2/S3/S4; AI tone level written into issue or category.
  RECOMMENDATIONS: [Modification Suggestions]

• Called in both full/lean modes.
• Review Perspective: grep-first + reasoning-based consistency detection, output S1-S4 report.
• Prompt Instructions:

  You are consistency-checker, using grep-first + reasoning-based consistency review to detect factual contradictions.
  Your task is to【find factual contradictions, state disconnections, and setting logic conflicts that require reasoning to discover】, do not make creative judgments, do not evaluate literary quality, do not output creative modification suggestions.
  Project Path: {Project Root}
  Review Scope: {File path/chapter/necessary excerpts}
  Known Characters: {Character list extracted from setting files}
  Inherited Open Items (Required for Batched Review, write "None" if none): {Buried unrecovered foreshadowing extracted from `追踪/伏笔.md` with planned recovery chapter ≤ the last chapter of this batch, along with summary of unresolved findings from previous batch}
  Review Benchmark Package Summary: {rubric / fallback summary formed in Phase 1, must be inline}
  Rubric Source: file | embedded fallback
  Optional Supplementary Reference: This Skill's `story-review/references/quality-checklist.md`; if unreadable, does not affect factual conflict scanning.
  Check Items:
  1. Are character attributes consistent throughout?
  2. Are world rules violated?
  3. Is foreshadowing status consistent throughout (buried/planned recovery/recovered/disconnected)?
  4. Is the timeline self-consistent?
  5. Are terms, identities, locations, ability boundaries consistent throughout?
  6. Among inherited open items, is foreshadowing that should be recovered in this batch still hanging?
  
  Output Format:
  VERDICT: APPROVE / CONCERNS / REJECT
  FINDINGS: Must use unified Findings Schema, severity must be S1/S2/S3/S4; category can only use consistency / factual / format / causal / rule_boundary.
  INHERITED_ITEMS: List inherited open items one by one + checked / unable to check; newly discovered open hooks not in `伏笔.md` are listed separately for the main session to write back to `追踪/伏笔.md`.
  FACTUAL_RECONCILIATION: [Only list factual sources to be unified or items requiring human ruling, do not write literary creation suggestions]
  REASONING_CHAINS: [Only list premise/rule -> triggering event -> contradiction -> ruling required for reasoning-based findings]

1. Collect reviewer VERDICT and FINDINGS from actual execution.
2. Merge and Deduplicate: Sort by

   severity

   (S1 > S2 > S3 > S4), sort by impact scope within the same level.
3. Optional Fact Verification: If the review content involves external facts that need verification (historical era, geographical location, professional details, etc.), only spawn

   story-researcher

   for search verification if

   Effective Mode

   is still

   full

   /

   lean

   , not currently a sub-Agent, Agent/Task tools are available, and

   story-researcher.md

   or

   story-researcher.toml

   is deployed in the agent directory (prioritize

   .claude/agents/

   , then

   .opencode/agents/

   , then

   .codex/agents/

   ); do not spawn in

   solo

   , missing/malformed/stale/spawn failed degradation, or sub-agent recursion protection scenarios, only mark "need human fact verification" in the report.
4. Present Discrepancies: If there are conflicting opinions among reviewers, clearly present the discrepancies for user ruling; do not compromise automatically.
5. Output comprehensive review report. The report must list effective mode, fallback reason, used rubric, Rubric Source, review scope, and items with insufficient evidence.

• 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

is only used for reviewers excluded in lean mode or optional reviewers; if required reviewers for full/lean are missing or spawn failed, should degrade to solo instead of marking NOT_RUN in full/lean report and continuing synthesis.

• S1: n
• S2: n
• S3: n
• S4: n

story-review/references/quality-rubric.md

1. Format compliance check (dramatic unit/shot segmentation, no mechanical word count segmentation, no blank lines, dialogue format, subject/character name rhythm).
2. Simple setting consistency grep (character names, attributes, key settings, foreshadowing keywords) + reasoning-based consistency check (rule boundaries, setting levels, cross-chapter causal chains, exploitable loopholes, cost consistency).
3. AI tone and banned words check (prioritize reading

   story-review/references/banned-words.md

   and

   story-review/references/anti-ai-writing.md

   , use built-in AI tone / banned words fallback quick reference if unreadable).
4. General web fiction content scoring (prioritize reading

   story-review/references/quality-rubric.md

   , use built-in general web fiction content rubric if unreadable).
5. Output simplified report according to unified Findings Schema.

• [{x| }] Paragraphs are naturally segmented by dramatic unit/shot/end of one event, not mechanically segmented by word count; occasional slightly long complete reasoning/atmosphere/emotion chains are not violations, only full-text segmentation with the same threshold or fragmented into outlines is considered violation: Pass/Fail; Evidence: ...
• [{x| }] Subject/character name rhythm is natural: Subject is established at the beginning of the paragraph, pronouns/omissions are used in the paragraph, and key turns are named again; consecutive sentences/paragraphs with unnecessary repetition of the same protagonist name are considered subject over-density: Pass/Fail; Evidence: ...
• [{x| }] No inter-paragraph blank lines: Pass/Fail; Evidence: ...
• [{x| }] Dialogue on independent lines: Pass/Fail; Evidence: ...
• [{x| }] Specific word count expressions have confirmed correct statistics and narrative necessity; changed to non-specific number expressions when confirmation is not possible: Pass/Fail; Evidence: ...
• Violation Locations: {List}

Checklist Convention:

[x]

only means Pass,

[ ]

means Fail; contradictory writing like

[x] ... Fail

is not allowed.

• Literal Factual Conflicts: {List discovered contradictions or insufficient evidence}
• Reasoning-Based Consistency: {Discoveries in rule boundaries/setting levels/cross-chapter causality/exploitable loopholes/cost consistency; write "None Found" if none}

• {List issues, must attach evidence}

scripts/tracking_commit.py

references/tracking-transaction.md

追踪/

追踪/

伏笔.md

上下文.md

1. Check Status First: Execute

   tracking_commit.py check --project {Project Root}

   , confirm

   _tracking-state.json

   is consistent with all derived views. If failed, re-run the original transaction that generated the current target state, do not guess, manually modify Markdown, or create another transaction to overwrite.
2. Determine if Revision is Needed: Only maintain when main text evidence shows existing tracking facts are wrong or missing. Expired foreshadowing, unregistered open hooks, current character status, objective timeline, reader cognition are all included in

   mode=revision

   transactions of the chapter where their evidence is located. Ordinary review opinions and future writing suggestions do not enter tracking.
3. Construct Complete Same-Chapter Transaction: Retain fields in the original compact increment of the chapter that are still valid, only modify changes with evidence; core character changes simultaneously submit complete

   character_snapshots

   up to the last written chapter. Foreshadowing

   upsert

   current state for the same ID, do not add duplicate lines; timeline simultaneously submits objective facts, current reader cognition, and actual revealed state.
4. Submit and Recheck: Execute

   tracking_commit.py commit

   , then execute

   check

   . Confirm chapter-by-chapter records are standardized and not exceeding limits,

   上下文.md

   exactly has 7 columns and ≤12288 bytes, author/reader timelines and all derived views are consistent with state.

• Respond in the user's language, use the same language as the user.
• Chinese responses follow Chinese Copywriting Guidelines. ",