Build the fact layer required for game design; do not evaluate prose style, and do not choose a game type at this stage.
Read gameability-protocol.md。
The output language is locked by PRODUCT_BRIEF.md ; when not locked, follow the conversation language and do not default to producing Chinese.
The source text may be in any language. Quotations retain the source language; when the design language or interface language differs from the source language, attach necessary translations, and establish a unified terminology glossary for character names, place names, objects, and rules; ritual systems, religions, and narrative conventions must not be replaced with approximate type labels from another culture.
Input
Prefer reusing an existing writing project or thefulltext breakdown output, returning to the source text only to supplement key evidence; only when it is a raw novel should the full-book pipeline of this skill be executed. If an existing analysis covers only the golden three chapters or a quick preview, it can only help judge the opening and cannot prove that the entire book is understood. Unless the user explicitly adapts only a single volume or fragment, concept design must not begin when the source does not cover the full text.
If PRODUCT_BRIEF.mdexists, read it first: the rating, core fantasy, and already-locked genre determine evidence-gathering priorities—prioritize gathering evidence for the actions, relationships, and scenes involved in the core fantasy; for systems required by the locked genre but not systematically provided by the original work (such as attribute counters or numerical progression), state in the design gaps that "the original work has no systematized corresponding system; this is a downstream invention," so that downstream adaptation boundaries can cite it truthfully.
Full-Book Pipeline
Establish boundaries → extract unit by unit → coverage gate → layered aggregation → fact-check against the source text → compress and deliver. The methods for each step follow gameability-protocol.md; only the order is listed here and not restated. Verification of the selected adaptation passage is done when re-entering after concept selection, producing a fact-by-fact table (see "Output"). Work cards only serve coverage, recovery, and review; do not package process logs as design deliverables.
Non-overlapping chapter batches may be processed in parallel at runtime, but every batch must use the same extraction contract, and aggregation and fact-checking remain serial. When the environment does not support parallelism, complete batches serially one by one; do not switch to sampling.
Extraction Dimensions
Keep only content that would affect player actions, world responses, or audiovisual identity; the dimensions, coverage status, and recording method for commands/commissions follow the protocol's "unit-by-unit evidence gathering" and "deriving system candidates from facts."
Record chapter or file locations for hard rules, key character goals, the basis of player identity, turning points and endings, and signature anchors. Ordinary candidate items do not need to mechanically carry a confidence object; inferences must be explicitly marked as inferences or open design space.
Output
Generate a analysis/SOURCE_BIBLE.md, including source scope,full-book coverage, world identity, original-work facts and evidence, adaptation boundaries, player identity candidates (when PRODUCT_BRIEF has locked an identity, replace this with action-space verification for that identity), playable verbs, identity actions that can be issued/accepted and the execution resistance against them, world model, spatial and character agency, cultural context, terminology glossary (language conditions see above), visual anchors, risks, and design gaps. Full-book coverage lists the opening, middle, ending, and key changes recovered across segments by continuous ranges, strong and weak pacing, counterexamples, and gamification significance; the header states the number of source units and the number of successes, and the coverage set must match the source unit set. Short tables take precedence over repeated documents, structured data, and evidence indexes.
Adaptation boundaries must be a table:条目 | 边界类型 | 证据位置; boundary types use only the protocol's four labels; works involving status, seating order, official rank, or team sequence must be accompanied by a character roster row (姓名 | 身份/次序 | 结局 | 证据回目), as the roster baseline for item-by-item comparison by each downstream handoff gate.
After the concept stage selects the adapted passage, enter this skill a second time to add a per-fact table for that passage and append it to SOURCE_BIBLE:
事实 | 证据位置 | 边界类型, including appearance key points of characters appearing on screen (clothing, weapons, size, and position; if the original text has no description, write "not specified in the original text"). This table is the passage-level comparison baseline for downstream handoff gates; downstream may still go back to the original text to supplement evidence, and when discrepancies are found, return upstream to correct this table rather than each rewriting it independently. After the concept is selected, only supplement or correct original-work facts that have a basis—SOURCE_BIBLE must not contain downstream inventions; game state key names, turn or schedule numbers, scene_id, Hub/interface structure, QA, and scope plans belong only to GAME_DESIGN, and existing facts must not be rewritten into slice talking points.
The source scope records only the version, coverage scope, and authorization boundaries that will affect review. Download dates, byte counts, checksums, and local paths are written only when the reproduction contract truly requires them; acquisition logs are not treated as planning content.
For the remaining completion gates, see the protocol "Fact Fidelity and Delivery".