内容创作层

---
name: zimeiti-commander
description: "自媒体主控·运营层。老大创作内容+生产视频完成后，我处理：发布包、合规、数据、日历。T4只负责发布执行。触发词：自媒体、四账号、念念漫剧社、念念带货屋、念念AI社、念念制片厂、发抖音、选题、排期、运营、数据。"
---

# 自媒体主控（念念家族四账号）· 运营层

## 分工总纲

- **老大**：创作内容 + 视频生产（剧本→分镜→提示词→生成→初剪→成片）
- **我（T3）**：运营层——发布包、合规、数据、日历
- **T4 发布执行线程**：只负责登录平台、上传视频、填发布包、老大确认后发布

## 第一步：读状态

先读 `E:/codex/niannianai/zimeiti/主控台.md` 拿最新状态，没有则问老大。

## 第二步：我做的事

老大创作内容+生产完视频后，我处理：

| 阶段 | 我做的事 | 产出 |
|---|---|---|
| 1. 发布包 | 标题（含话题）+ 描述（含@）+ 封面选帧 + 时段建议 | 发布包文件 |
| 2. 合规检查 | 敏感词、事实边界、夸大承诺 | 检查报告 |
| 3. 数据台账 | 每晚记数、周复盘、实验卡判定 | 台账/复盘 |
| 4. 内容日历 | 提前排下周选题计划，研究热点方向 | 日历 |

**完成后**：成片 + 发布包一起交给 T4 发布执行线程去发布。

## 第三步：运营规范

1. 互@规则：每条描述固定 @念念AI社，内容相关再 @ 对应号，最多 2 个；发布后 5 分钟内用另一个号去评论区留钩子。
2. 固定档期：漫剧社 19–21点、带货屋 午休或晚间、AI社 18–19点、制片厂 午间。
3. 冷启动每号日更1条，不投DOU+。
4. 连发7条完播<10%建议换结构，某条爆了48小时内追同结构续集。

## 硬红线

- 不登录、不代发、不自动发布。
- 不编造播放、销量、涨粉、客户案例。
- 数据只记后台真实数字，缺失标"缺"。
- 凭据（Cookie/Token/Key/密码）永不进草稿目录。

## 每次收尾

更新 `zimeiti/主控台.md`，写当日 memory。

---
name: xhs-imagen
description: Create complete Xiaohongshu image-and-text posts from a topic, article, document, or rough idea, including research, fact checking, post copy, pagination, storyboards, a 3:4 cover, 9:16 content pages, image generation or fully local SVG-to-PNG fallback, and final quality review. Use for 小红书图文、小红书封面、知识卡片、漫画科普、文章转图片、AI/科技科普图组、逐页生图提示词, or revisions to an existing Xiaohongshu series. Prefer an available image-generation model; use the bundled local renderer only when no image-generation tool is available. Apply an SVG text patch only after the user explicitly reports incorrect or unreadable text in an image.
---

# xhs-imagen

Turn one topic or source article into a publication-ready Xiaohongshu post package.

## Required result

Create:

```text
output/<topic-slug>/
├── project.json
├── research.md
├── post.md
├── storyboard.md
├── prompts/
│   ├── 00-cover.md
│   ├── 01-*.md
│   └── ...
├── images/
│   ├── cover.png
│   ├── page-01.png
│   └── ...
└── qa-report.md
```

If the user requests only part of the package, create only that part. Never claim that images were generated when no image-generation or local SVG renderer was available.

## Fixed Xiaohongshu defaults

- Create a `3:4` cover, recommended `1080 × 1440`.
- Create `9:16` information pages, recommended `1080 × 1920`.
- Default to one cover plus 5–8 information pages.
- Use Simplified Chinese unless requested otherwise.
- Explain one dominant idea per page.
- Optimize titles and labels for phone reading.
- Do not render page numbers or page-position markers such as `04`, `01/08`, or `PAGE 04`. Keep ordering only in filenames. Numbered steps are allowed when the numbers explain the content itself.
- Default to the `alpaca-line-art` profile: pure-white background, fine black hand-drawn lines, and the bundled white alpaca creator IP.
- Preserve `glasses-chibi-blue` as a selectable profile for the original glasses-wearing host, warm off-white paper, and cobalt-blue comic style.
- Use `toolbox-bot-risograph` for tool ecosystems, plugins, Skills, Agents, and workflows in two-color risograph.
- Use `maker-girl-editorial` for professional AI Coding, workplace, tutorial, and opinion content in modern editorial illustration.
- Use `cyber-luban-woodcut` for Skill–Harness–Agent architecture and system-building topics in new-Chinese woodcut.
- Use `capybara-gouache` for beginner explainers, pitfalls, reassurance, and everyday analogies in warm gouache.
- Make the character perform the page's core conceptual action; never use it as corner decoration.

Read [references/visual-profiles.md](references/visual-profiles.md), [references/visual-style.md](references/visual-style.md), and [references/character-consistency.md](references/character-consistency.md) before producing images.

## Workflow

### 1. Resolve the brief

Determine or infer:

- topic, audience, and desired outcome;
- the single sentence readers should remember;
- source material and whether facts may have changed;
- page count and language;
- selected visual profile, character, palette, and brand constraints;
- whether the user wants a complete package, images, copy, or prompts.

Use beginner-friendly AI/technology education as the default audience and tone when the request does not specify them.

Store the choice in `project.json` as `visual_profile`. Honor an explicit user choice; otherwise use the default declared in `references/visual-profiles.json`. Use one profile for the whole series unless the user explicitly requests otherwise.

When reviewing pages the user selected or rejected, distinguish explicit feedback from inferred preference. Treat only explicitly confirmed rules as durable defaults; use the final selection primarily to understand visual appeal and expression accuracy rather than infer rigid layout rules.

### 2. Research before writing

Search primary and authoritative sources for current, technical, disputed, product-specific, numerical, legal, or attributed claims. Write a claim table to `research.md`. Separate sourced facts from analogies and editorial framing.

Read [references/fact-checking.md](references/fact-checking.md) for detailed rules.

### 3. Build the content arc

Create:

- one thesis;
- one useful analogy;
- one misconception;
- 4–7 supporting ideas;
- one limitation, boundary, or human-control point;
- one final takeaway.

Select pages by cognitive anchors instead of distributing content evenly. Keep only moments that change what the reader understands: a core judgment, cognitive turn, comparison, bottleneck, boundary, common mistake, state change, or takeaway. Drop a page when removing it does not weaken the learning arc.

For every selected page:

1. state the cognitive anchor and why it deserves a page;
2. convert the abstract concept into a physical action;
3. map that action to one ordinary low-tech object;
4. make the character perform the action so the metaphor depends on the character.

Write `post.md` with a Xiaohongshu title, publishable body copy, optional source note, and relevant hashtags. Write `storyboard.md` before generating images.

Read [references/content-planning.md](references/content-planning.md) when choosing pages and reducing copy. Read [references/visual-metaphors.md](references/visual-metaphors.md) before writing the storyboard or image prompts.

### 4. Create and validate the project

Store exact content and page decisions in `project.json`. Start from [references/project.template.json](references/project.template.json) and follow [references/project.schema.json](references/project.schema.json).

Validate it:

```bash
python3 scripts/validate_project.py /absolute/path/project.json
```

Generate the image-model prompt files:

```bash
python3 scripts/make_prompt_pack.py \
  /absolute/path/project.json \
  --output-dir /absolute/path/output/prompts
```

### 5. Choose the rendering path automatically

#### When an image-generation tool is available

Use it as the default path.

1. Resolve the selected profile in `references/visual-profiles.json`.
2. Use that profile's `character_reference` as the only bundled image reference. Never attach multiple profile references to one generation call.
3. Generate the cover and one representative inner page first.
4. Inspect character identity, core action, metaphor originality, typography, spacing, color, copy accuracy, and absence of page-position markers.
5. Lock the successful visual description.
6. Generate the remaining pages using the same reference and style lock.
7. Save files as `cover.png`, `page-01.png`, and so on.

Do not invoke the local renderer merely to pre-empt possible text errors.

#### When no image-generation tool is available

Use the bundled local SVG-to-PNG renderer:

```bash
python3 scripts/render_xiaohongshu_project.py \
  /absolute/path/project.json \
  --output-dir /absolute/path/output
```

This path preserves the Xiaohongshu cover and inner-page ratios while converting the project into deterministic local knowledge-card layouts. Read [references/local-rendering.md](references/local-rendering.md) for limitations and renderer requirements.

### 6. Repair text only after explicit user feedback

Do not create a separate hybrid workflow. If the user explicitly identifies incorrect, corrupted, or unreadable text in an existing image:

1. Confirm the target image, exact replacement text, and affected region.
2. Prefer local image editing or regeneration when available.
3. If the problem remains, apply a deterministic SVG overlay only to that region:

```bash
python3 scripts/patch_image_text.py \
  --input /absolute/path/page.png \
  --output /absolute/path/page-fixed.png \
  --visual-profile <selected-profile> \
  --x 100 --y 300 --width 880 --height 180 \
  --text "正确文字"
```

4. Inspect the repaired image before delivery.

Never apply an SVG text patch speculatively.

### 7. Inspect every output

Write `qa-report.md`. For every failed check, record the defect, repair action, and recheck result; do not stop at listing problems. Verify:

- correct ratio and orientation;
- readable, accurate Chinese and product names;
- background, line treatment, palette, and typography match the selected visual profile;
- one dominant idea per page;
- a meaningful cognitive anchor on every page;
- an original physical metaphor with one primary structure;
- the character performs the metaphor's core action;
- stable profile-specific character identity and proportions;
- valid diagram flow;
- no cropped titles, faces, hands, or summaries;
- no unsupported factual claims or invented quotations;
- no visible page number, page count, or page-position marker; content-level numbered steps remain allowed;
- ordered, stable filenames.

Run:

```bash
python3 scripts/check_png_ratios.py /absolute/path/output/images
```

Read [references/quality-checklist.md](references/quality-checklist.md) for the full review.

## Final response

Provide:

- a concise summary of the content arc;
- the cover and ordered pages, or links to their files;
- the publishable post copy;
- source citations for time-sensitive claims;
- an honest note about any unresolved image or text defect.

---
name: niannian-travel-group
description: This skill should be used when creating, auditing, revising, or producing content for the “念念旅行团” original Chinese realistic-fantasy travel IP, including its worldbuilding, slow-burn serial scripts, first-person travel Vlog scenes, 3D character continuity, celestial-palace daily life, and production handoff.
agent_created: true
---

# 念念旅行团创作生产 Skill

## 目的

将“念念旅行团”作为长线连续剧和写实架空旅行 IP 进行统一创作、审计和生产。核心是让内容先发生，让设定从人物行为、物件、环境和对话中自然露出；保持旅行 Vlog 的真实分享感、中式文化底色、3D仿真人连续性和慢节奏细节。

## 触发场景

在以下任务中加载本 Skill：

- 扩写或审计念念旅行团世界观；
- 编写念念旅行 Vlog、天宫日常、人物故事或连续剧分集；
- 编写首发三集及后续第四段、第五段等连续内容；
- 编写分镜、视频提示词、角色资产需求或素材对位表；
- 检查剧情节奏、时间线、POV、人物一致性、素材授权和版本冲突；
- 把现实福建/国内旅行素材转入念念 IP。

## 权威资料

优先读取项目总稿：

`E:/codex/niannianai/zimeiti/drafts/念念旅行团-2026-08-27/念念旅行团权威总稿_v1.md`

需要了解台词口吻时读取：

`E:/codex/niannianai/zimeiti/drafts/念念旅行团-2026-08-27/念念旅行团_Vlog声音与台词规范_v1.md`

需要编制生图提示词时读取：

`references/prompt-briefing.md`（双渠道分工、提示词三层结构、角色锚点铁律、生成顺序），并按 `E:/codex/niannianai/zimeiti/drafts/念念旅行团-2026-08-27/念念旅行团_双渠道提示词包_v1.md` 的编号产出。

需要检查历史冲突时，才读取旧方案、旧分镜和旧提示词；旧文件不是当前执行依据。

## 底层创作规则

1. 将项目当成长线连续剧，不把前三集写成完整闭环。
2. 每集只推进一个主要小目标；一个地点、一顿饭、一段路都可以占满一集。
3. 优先写具体内容：看见什么、怎么走、怎么吃、怎么试、哪里出错、人物怎么反应。
4. 设定只顺带露出，禁止连续讲背景、制度、时间规则或账号机制。
5. 念念第一次接触凡间时，不能提前知道目的地、景点、货币规则、生活方式或账号运营方式。
6. 念念第一次偷跑随机穿过天门，偶然落到福建；福建不是预先规划的目的地。
7. 法宝袋里的凡间物件是念念从爹爹那里顺来的，不是父亲为她准备的旅行装备。
8. 第三人称负责天宫、法宝袋、人物动作和飞行空间关系；第一人称负责主要人间 Vlog 内容。
9. “人间一年、天上一天”是已锁定长期设定，但前期不解释、不抢戏。
10. 不回天界、不跨日、不推进父女线、闻川暗恋线、追捕线和身份曝光，除非权威总稿明确进入对应阶段。
11. 爱情线必须慢、克制、求而不得；不用表白、官宣、吃醋和旁白盖章推进。
12. 不打破第四面墙。剧情内不提AI、生成、脚本、剪辑、平台机制或“这是一个账号设定”。
13. 生产渠道固定分工：天界场景、念念和仙界角色用 Midjourney；现实凡间场景、现实物件和旅行内容相关图像用 image2 / OpenLux。
14. 现有福建素材是可选参考，不是硬性消耗指标；质量、地点连续性和故事内容优先于素材复用率。

## 念念 Vlog 口吻

保持年轻、清亮、亲近、高能但自然的分享感：

- 看到东西先反应，再判断；
- 短句、停顿、抢话、自我打断和轻吐槽；
- 允许半句废话，不要每句都是金句；
- 语速可以快，叙事和剪辑不能快进；
- “家人们”自然使用，不机械重复；
- 不模仿任何具体创作者的声线、口头禅或标志性表达；
- 不用纪录片腔、古风旁白腔、旅游宣传片腔。

推荐表达链：

`看见 → 靠近 → 试一下 → 出小问题 → 立即反应 → 继续内容`

## 慢节奏分镜流程

为每个核心事件保留：

1. 观察环境；
2. 靠近对象；
3. 尝试动作；
4. 出现小失误；
5. 念念即时反应；
6. 停留并留下环境声；
7. 只引出一个自然的下一步。

不要用快速蒙太奇替代完整过程。若目标时长不够，增加脚步、手部、风、食物热气、停顿、空镜和人物反应；允许拆成第四段、第五段，不强行塞新事件。

## 生产审计顺序

每次写新内容或交给视频生产前，依次检查：

1. 是否与权威总稿一致；
2. 是否仍是当前时间段，是否跨日；
3. 地点、光线、服装、发型、法宝袋、设备和人物状态是否连续；
4. 念念是否表现出超出当前阶段的凡间知识；
5. 第一人称镜头是否有明确设备逻辑，是否误变成纯无人机航拍；
6. 真实福建素材是否属于同一空间链，地貌和交通是否穿帮；
7. 真实人物、地点、品牌和包装是否需要授权或弱化；
8. 是否出现设定解释、账号解释或第四面墙；
9. 是否把一个小目标写完整；
10. 是否留下内容驱动的下一步，而不是强行反转。

## 世界观变更流程

- 已确认内容标记 `LOCKED`；
- 会影响多集逻辑的内容标记 `TO_DECIDE`，未裁决不得写成事实；
- 灵感标记 `OPTIONAL`，只能作为备选；
- 未定义内容标记 `UNVERIFIED`，禁止自作主张写入成片；
- 新设定必须先写入权威总稿或其设定资产库，再进入剧本、分镜和提示词；
- 发现旧稿冲突时，以权威总稿为准，并记录冲突，不要把旧内容重新混入执行稿。

## 交付要求

交付脚本时优先给出：

- 本集具体发生的事情；
- 时间段和空间连续性；
- 逐镜动作与声音；
- 念念自然口播；
- 需要的真实素材；
- 角色资产和一致性要求；
- 仍待裁决的问题。

不要先写大段世界观说明。不要启动付费生图、生视频或发布动作，除非用户在当前任务中明确授权。

---
name: narrative-to-screen-reader
description: 将叙事文本转化为影视开发阶段可用的多用途读本。适用于长会话角色扮演记录、短篇小说、中长篇片段、剧情大纲、剧本初稿、互动叙事等；当用户要求"剧本解读、演员读本、导演阐述、影视化分析、改编分析、短篇小说转影视开发文档、故事转剧本前置分析、给演员/编剧/导演/制片看的分析、AI 剧本化提示包"等任务时触发。输出可按目标受众区分：完整开发读本、演员读本、编剧改编读本、导演视听读本、制片摘要、AI 剧本化提示包、快速诊断。
version: 2.0.0
display_name: "叙事转影视开发读本"
display_name_en: "Narrative to Screen Reader"
description_zh: "将叙事文本转化为影视开发阶段可用的多用途读本。先做快速诊断判断开发价值，再按受众生成完整开发读本、演员读本、编剧改编读本、导演视听读本、制片摘要或 AI 剧本化提示包。适用于长会话记录、短篇小说、大纲、剧本初稿、互动叙事等输入。"
description_en: "Transforms narrative text into multi-purpose screen development readers. First runs quick diagnosis to assess development viability, then generates full development reader, actor reader, screenwriter adaptation reader, director visual reader, producer brief, or AI screenplay prompt pack by audience. Handles long chat logs, short stories, outlines, draft scripts, and interactive narratives."
visibility: "public"
---

# Narrative to Screen Reader

## 两个基础认知

> **第一：先有故事，才有后续开发。**  
> 没有人物动机、冲突、场景，只有概念宣言或情绪堆砌的文本，不具备影视开发基础。快速诊断是所有输出的第一步。

> **第二：不是所有文本都能直接影视化。**  
> 有些文本核心成立但骨架太薄；有些有情绪但缺人物；有些只是场景序列；有些内容不可开发。A/B/C/D/D0 诊断等级就是对这一点的判断。

这个 Skill 的工作是：**先判断文本到了哪一步，再告诉用户下一步能做什么、不能做什么。**

---

把叙事文本转成影视开发读本。不是复述剧情，也不是直接改写剧本，而是先读懂文本，再把人物、潜台词、动作、物件、空间、视听母题和剧本化风险翻译成影视开发语言。

## 最高原则

1. **基于原文证据**：先读原文，不凭记忆、套路或摘要下结论。长文本分批读取并提取关键节点。
2. **事实、推断、建议分层**：区分原文事实、基于原文的强推断、影视化建议；不要把推演写成事实。
3. **解读优先，不急改写**：这是影视开发前置分析，不是正式剧本化。
4. **按文本类型调整策略**：长会话、小说、大纲、剧本初稿、片段、互动文本使用不同重点。长会话/对话体要先做场景转译，再判断人物厚度是否不均。
5. **按目标受众调整输出**：演员、编剧、导演、制片、AI 的需要不同。重要配角原则上不单独输出读本，而合并进完整开发读本、编剧改编读本和 AI 提示包中处理其功能与必要性。
6. **解释"为什么"**：重点分析角色为什么这么说、为什么不说、为什么这样做、为什么不做。
7. **抓物件链与动作链**：反复出现并被终局回收的物件/动作通常是影视化骨架。
8. **正式输出必须落成 Markdown 文件**：完整开发读本、演员读本、编剧读本、导演读本、制片摘要、AI 剧本化提示包、快速诊断等正式文档一律写入 `.md`；会话中只给摘要和链接。

## 默认工作流

1. **先告诉用户正在做什么**：收到文本后，先说明"我会先读故事，再做快速诊断，判断它适合进入哪一步"。
2. **长文本分批读取**（仅 >50KB 时触发）：按下方「长文本分批协议」执行，全部读完后再进入诊断。
3. **先做快速诊断**：无论用户点名要哪个模块，默认先输出快速诊断。扫描原文证据：提取主要人物、关键场景、关键台词、物件链、动作链、空间链、关系转折与终局。若是对话体/长会话，先把轮次转成戏剧单元，再判断是否存在"核心对象厚、参与者角色薄"的情况。
4. **🔴 CHECKPOINT（强制暂停）**：诊断完成后，**必须**展示诊断结果并等待用户确认，才能继续生成任何正式读本。禁止自动连续输出多个模块。唯一例外：用户在对话中已明确说"诊断完直接出 XX 读本"；或 D0 级终止（无需确认）。
5. **按路由表加载 references 并推荐模块**：根据诊断等级，按下方「诊断→Reference 加载路由表」加载对应 reference 文件，然后向用户推荐下一步模块。
6. **A 级文本推荐顺序**：默认先出完整开发读本作为母文档；若文本复杂（群像 / 长篇 / 强设定 / 行业剧），建议接着出编剧改编读本；演员读本、导演视听读本、制片摘要可按目标异步输出；AI 剧本化提示包建议最后生成。
7. **默认不直接全套输出**：即使用户一开始要求"全部模块"，也先快速诊断并说明推荐顺序；除非文本已评级为 A 且用户明确确认需要整套交付，否则不建议一口气生成全部模块。
8. **生成目标读本**：按受众输出相应文档。
9. **写入 Markdown 文件**：将正式文档保存为 `.md` 文件；会话中只返回诊断摘要、输出清单和文件链接。

---

## 🔴 CHECKPOINT 规则

在快速诊断完成之后、生成任何正式读本之前，**必须暂停并等待用户确认**。

执行方式：
- 展示完整诊断结果（等级、核心判断、推荐模块、不建议模块）；
- 明确询问用户："你想先做哪个模块？"或"确认后我继续生成推荐的模块"；
- **禁止**在未收到用户回复的情况下自动进入 Step 8。

唯一例外：
- 用户在本次对话中已明确指定"诊断完直接出 XX 读本"；
- D0 级终止（无需确认，直接输出终止说明）。

---

## 诊断→Reference 加载路由表

快速诊断完成后，根据等级加载对应 reference 文件。**不要一次性加载全部 references。**

| 诊断等级 | 推荐加载的 references | 说明 |
|:---|:---|:---|
| **A** | `full-development-reader.md` → 按需加载 `actor-reader.md` / `director-visual-reader.md` / `producer-brief.md` / `ai-screenplay-prompt-pack.md` | 完整开发读本优先作为母文档；若文本复杂，追加 `screenwriter-adaptation-reader.md` |
| **B** | `screenwriter-adaptation-reader.md` + `character-reinforcement.md`（如需补强） | 先补结构/人物，再考虑完整开发读本 |
| **C** | `screenwriter-adaptation-reader.md`（开发路径判断版）或 `producer-brief.md` | 先定开发入口，不做完整读本 |
| **D** | `quick-diagnosis-guide.md`（最小重构方案部分） | 只做开发诊断，不加载正式读本 reference |
| **D0** | 不加载任何 reference | 立即终止，只输出终止说明 |

跨模块串联时的上下文管理：
- 当从完整开发读本继续拆演员/导演/制片模块时，可卸载已完成的 reference 以释放上下文；
- `quality-control.md` 和 `file-output-rules.md` 在任何正式输出生成时都应保持加载；
- 如果上下文窗口不足以同时加载多个 reference，优先保留当前任务对应的 reference，其余可在下一轮重新加载。

---

## 长文本分批协议

当输入文本 >50KB 时，执行以下分批策略：

1. **分批读取**：每批约 30-40KB，逐批读完。
2. **内部记录**：每批读完后，在内部记录关键节点（人物出场、关系转折、物件出现/回收、场景转换、情绪高点）。不要在每批读完后向用户汇报进度。
3. **全部读完后先输出文本概览**：一句话核心 + 主要人物列表 + 关键场景列表（≤500 字），让用户确认理解无误。
4. **然后进入快速诊断**：基于完整文本概览和内部记录执行诊断。

极端输入处理：
- **<500 字的极短文本**：跳过完整诊断流程，直接做"最小开发可行性判断"（≤300 字），告知用户当前文本是否足以支撑任何读本，如不足则给出具体补写建议。
- **>200KB 的超长文本**：先询问用户是否有明确的分析范围（如"只看第三幕""只看某两个角色的线"），避免无差别全文分析导致上下文溢出。如用户坚持全文分析，按分批协议执行，并在诊断中标注"因文本过长，部分细节可能未充分覆盖"。

## 支持的输出模式

- **完整开发读本**：总体判断、角色档案、关系读本、逐场解读、潜台词表、动作词典、物件链、空间与视听母题、终局判断、第三步提示，并可附"重要配角功能表"。
- **演员读本**：回答"这个人怎么活着、怎么说话、怎么防、怎么靠近、最容易演错成什么"。内容包括角色核心矛盾、外在行为、说话方式、情绪弧线、关键台词潜台词、动作含义、不能演错的地方；必要时区分"标准演员读本"和"补强型演员读本"。
- **编剧改编读本**：回答"该从哪里切进去改、哪些不能动、哪些要扩成戏"。内容包括结构拆解、必须保留/可合并/可删减内容、内心戏转动作、对白保留、改编风险、剧本化清单，并判断重要配角的保留、合并和距离设计。
- **导演视听读本**：回答"这个故事真正该拍的是什么、哪些必须交给镜头和声音、最容易被怎么拍坏"。内容包括视觉母题、空间、光线、声音、色彩、物件特写、空镜、节奏和镜头可能性。
- **制片摘要**：回答"这个故事作为项目值不值得做、适合做成什么、最值钱的地方是什么、最容易怎么死"。内容包括一句话定位、类型卖点、受众、制作规模、成本敏感点、风险。
- **AI 剧本化提示包**：第三阶段 Agent 的主控规范。回答"该怎么写、哪些绝不能写错、冲突时以谁为准"。内容包括输入优先级、不可改项、角色规则、场景/物件/配角约束、禁止方向、格式要求与最终执行 Prompt。
- **快速诊断**：1000-2000 字内给出 A/B/C/D/D0 诊断等级，判断核心、人物是否成立、最强物件/台词、改编风险、是否适合生成读本；明确当前重心、最危险的误开发方式、最值得先保住的东西，并推荐接下来最适合输出哪些模块、不建议现在做哪些模块；若不适合继续，则给出补写或重构建议。

详细格式见 `references/output-modes.md`。

## 输入类型判断

- **长会话记录**：先整理主线，合并重复推进，提取自然生成的节点。重点抓已读/不回、时间戳、停顿、用户动作、环境描写。
- **短篇小说**：重点分析文学意象如何转视听，内心独白如何转动作，叙述视角是否需要调整。
- **中长篇片段**：标注不确定信息，不擅自补全上下文，输出待补清单。
- **大纲/梗概**：做开发诊断，找动机缺口、场景缺口、物件与母题不足，不强行生成完整演员读本。
- **剧本初稿**：分析场景功能、人物行动线、台词潜台词、节奏和可拍性。
- **互动/游戏文本**：识别主路径、分支节点、玩家选择对角色关系的意义。

详细策略见 `references/input-types.md`。

## 分析雷达

内部检查以下维度，按任务需要展开：

1. 人物防御机制
2. 人物爱语 / 表达方式
3. 物件链
4. 空间链
5. 台词表层与潜台词
6. 沉默、停顿、没有发生的动作
7. 动作与身体反应
8. 时间结构
9. 视听母题：声音、光、颜色、气味
10. 关系转折点
11. 终局自然性
12. **人物厚度差异（长会话专用）**：判断是否存在"核心对象更厚、参与者角色更薄"的情况，决定是否需要补强型读本。
13. **文本收束状态**：判断故事是否停在正确的位置——未收束（没写完）或过度延展（该停没停）。

详细说明见 `references/analysis-radar.md`。

## 输出要求

- 不要只写剧情梗概。
- 每个重要判断尽量对应原文证据或可定位的文本细节。
- 对关键台词，写出"表层意思 / 潜台词 / 表演方式"。
- 对关键物件，写出"首次功能 / 后续意义 / 影视化处理"。
- 对关键动作，写出"角色心理 / 演员处理 / 镜头处理"。
- 如果原文证据不足，明确说"不足"，不要编造。
- 如果文本自然不适合某种终局，直接指出，不迎合用户强行改。
- 所有正式读本、摘要、诊断和提示包必须保存为 Markdown 文件；文件名应包含项目名/故事名与输出模式，例如 `同一条河_演员读本.md`。会话回复只提供简短说明和文件链接，不粘贴完整长文。
- 谨慎使用"唯一 / 第一次 / 最后一次 / 从未"等绝对化表达；除非已核对原文，否则改为"关键一次 / 重要节点之一 / 主要方式"。
- 制片摘要中的预算、周期、集数、片长等数字必须标注"粗估 / 假设 / 需制片复核"。

## 禁止行为

以下行为在本 Skill 的任何输出中均被禁止。此清单集中列出了分散在各 reference 中的所有禁止项。

### 内容层面

- ❌ 把读本写成剧情复述
- ❌ 每个细节都强行象征化
- ❌ 忽略输入文本类型，所有文本套同一格式
- ❌ 把角色心理讲成抽象标签，不落到动作、台词、物件
- ❌ 给演员版写太多结构理论，给制片版写太多长篇心理分析
- ❌ 在第二步直接重写正式剧本
- ❌ 把正式长文直接贴在会话里
- ❌ 迎合用户强行改终局
- ❌ 使用绝对化表达（唯一/第一次/最后一次/从未）而未核对原文
- ❌ 原文证据不足时编造事实
- ❌ D0 红线内容（未成年人性侵犯/性剥削、药物胁迫非自愿性行为、奴役/人口贩卖正面描写、角色仅作欲望发泄对象）
- ❌ 新增原文没有的童年创伤、家庭矛盾、前任经历等人设（补强时）
- ❌ 用俗套人格模板（高冷/腹黑/病娇/圣母/霸总）覆盖角色原有逻辑

### 操作层面

- ❌ 诊断未完成就生成正式读本
- ❌ CHECKPOINT 未获用户确认就自动连续输出多个模块
- ❌ 覆盖用户原始文件（输出 .md 文件时必须新建，不得覆盖原文）
- ❌ 一次性加载全部 references（按路由表按需加载）
- ❌ 把推断写成原文明确事实

## 常见错误

- 把读本写成剧情复述。
- 每个细节都强行象征化。
- 忽略输入文本类型，所有文本套同一格式。
- 把角色心理讲成抽象标签，不落到动作、台词、物件。
- 给演员版写太多结构理论，给制片版写太多长篇心理分析。
- 在第二步直接重写正式剧本。
- 把正式长文直接贴在会话里，导致用户难以保存和复用；应写成 `.md` 文件。

## 需要时加载

- 输出模式细则：`references/output-modes.md`
- 演员读本规则：`references/actor-reader.md`
- 编剧改编读本规则：`references/screenwriter-adaptation-reader.md`
- 导演视听读本规则：`references/director-visual-reader.md`
- 制片摘要规则：`references/producer-brief.md`
- 完整开发读本规则：`references/full-development-reader.md`
- 面向用户的工作流程：`references/user-facing-flow.md`
- 文件输出规则：`references/file-output-rules.md`
- 快速诊断判断机制：`references/quick-diagnosis-guide.md`
- 对话体转译规则：`references/dialogue-text-conversion.md`
- 角色补强机制：`references/character-reinforcement.md`
- 重要配角设计：`references/supporting-cast-design.md`
- 输入类型策略：`references/input-types.md`
- 分析雷达：`references/analysis-radar.md`
- 物件与母题：`references/object-chain-and-motif.md`
- AI 剧本化提示包：`references/ai-screenplay-prompt-pack.md`
- 质量控制：`references/quality-control.md`
- 示例结构：`references/examples/jiangning-v2-structure.md`、`references/examples/hanxin-v2-structure.md`、`references/examples/linzhixia-structure.md`