Establish the factual layer required for game design; do not evaluate prose style, and do not select a game genre at this stage.
Read gameability-protocol.md。
The output language is locked by PRODUCT_BRIEF.md ; when not locked, follow the language of the conversation, and do not default to producing Chinese.
The source text may be in any language. Quotations retain the original text; when the design language or interface language differs from the source text, attach necessary translations, and establish a unified glossary of character names, place names, objects, and rules; ritual systems, religion, and narrative conventions must not be replaced with approximate type labels from another culture.
Input
Prioritize reusing the existing writing project orfulldisassembly outputs, and only return to the source text to supplement key evidence; only for an original novel should the full-book pipeline of this skill be executed. If existing analysis only covers the golden three chapters or a quick preview, it can only help judge the opening and cannot prove an understanding of the entire book. Unless the user explicitly adapts only a certain volume or fragment, concept design must not begin when the source has not covered the full text.
If PRODUCT_BRIEF.mdexists, read it first: the rating, core fantasy, and 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, and this belongs to downstream invention," so that downstream adaptation boundaries can cite it truthfully.
Full-Book Pipeline
Establish boundaries → extract unit by unit → coverage gate → layered aggregation → trace back to the source text → compressed delivery. The methods for each step follow gameability-protocol.md; only the order is listed here and not restated. Verification of selected adaptation passages is done when entering a second time after concept selection, producing a fact-by-fact table (see "Output"). Work cards only serve coverage, recovery, and review, and do not package process logs as design deliverables.
Non-overlapping chapter batches may be processed in parallel at runtime, but each batch must use the same extraction contract, and aggregation and fact tracing must remain serial. When the environment does not support parallelism, complete batches serially and do not change to sampling.
Extraction Dimensions
Retain only content that affects 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, bases of player identity, turning points and endings, and iconic anchors. Ordinary candidate items need not 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 (if PRODUCT_BRIEF has locked an identity, replace with action-space validation for that identity), playable verbs, identity actions that can be issued/undertaken and their execution resistance, world model, spatial and character agency, cultural context, glossary (language conditions as above), visual anchors, risks, and design gaps. Full-book coverage lists key changes, strong and weak pacing, counterexamples, and gameability significance for the opening, middle, ending, and cross-segment callbacks by continuous range; 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 are preferred over repeated documents, structured data, and evidence indexes.
Adaptation boundaries must be a table:条目 | 边界类型 | 证据位置, and 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 (姓名 | 身份/次序 | 结局 | 证据回目),
serving as the roster baseline for downstream handoff gates to compare item by item.
After selecting the adaptation passages in the concept phase, enter this skill a second time to supplement a fact-by-fact table for those passages 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 explicitly stated in the original text"). This table is the paragraph-level comparison baseline for downstream handoff gates; downstream may still return to the original text to supplement evidence, and when discrepancies are found,
return upstream to correct this table, and must not rewrite 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 as
slice wording.
The source scope records only the version, coverage scope, and authorization boundaries that will affect review. Download dates, byte counts, checksum values, and local paths are written only when the reproduction contract truly requires them, and acquisition logs are not treated as planning content.
For the remaining completion gates, see the protocol "Fact Fidelity and Delivery".