القائمة
在 Git 仓库中分阶段孵化长篇小说项目：先落整体大纲、人物、分卷表、幕后准备、结构拆借，再试写正文；若 gh/Issues 不可用，则回退为 repo 内管理文档。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/Undermybelt/hermes-skills --skill repo-managed-fiction-incيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Use when retiring old logic, collapsing duplicate owners, removing fallbacks, or touching schema, persistence, or source-of-truth boundaries while deciding whether to delete old paths, retain compatibility, or stop for confirmation.
Use when defining new features, product behavior, UI/component design, architecture choices, contract changes, or ambiguous medium/high-complexity work before implementation.
Use when the user asks for caveman mode, fewer tokens, brief responses, compressed communication, or otherwise explicitly requests a much shorter answer.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | repo-managed-fiction-inc |
| description | 在 Git 仓库中分阶段孵化长篇小说项目：先落整体大纲、人物、分卷表、幕后准备、结构拆借，再试写正文；若 gh/Issues 不可用，则回退为 repo 内管理文档。 |
| triggers | ["把小说/网文项目落实到一个 github repo","用 gh 管理写作项目","先别试写，先补幕后准备","先做整体大纲、人物、分卷、结构骨架","在仓库里管理长篇创作材料"] |
适用：用户要把长篇小说/网文项目做成“版本化写作工程”，且要求先搭骨架，再写正文。
把写作任务从聊天产物，变成仓库内可持续维护的项目结构。
优先顺序：
不要一上来就试写第一章，除非用户明确要求且前置材料已足够。
在目标仓库下创建：
projects/<project-slug>/
├── README.md
├── outline/
│ ├── overall-outline.md
│ ├── 500k-volume-plan.md
│ ├── architecture-borrowing-map.md
│ └── opening-30-chapter-outline.md
├── characters/
│ ├── README.md
│ └── <角色名>.md
├── prep/
│ ├── README.md
│ ├── world-rules.md
│ ├── compensation-ledger.md
│ ├── city-factions.md
│ ├── disaster-domain-library.md
│ ├── foreshadow-payoff-map.md
│ ├── relationship-ledger.md
│ ├── fame-progression-map.md
│ ├── opening-30chap-plan.md
│ └── voice-and-style-guide.md
├── draft/
│ └── chapter-001.md
└── notes/
└── gh-management.md
用终端检查：
git status --shortgit remote -vgh auth status若用户只给了 repo 名，不知本地路径，先在常见目录找本地 clone。
在 projects/<slug>/README.md 记录：
让后续所有新增文档都能被索引到。
输出顺序固定：
outline/overall-outline.mdcharacters/*.mdoutline/ending-design-options.mdoutline/500k-volume-plan.md（或按目标体量改名）outline/reverse-volume-outline.md / 主卷纲文件（从终局卷倒推到第一卷）outline/volume-outline-score.md（卷纲量化评估 + 自迭代结论）prep/*.mdoutline/architecture-borrowing-map.mdoutline/opening-30-chapter-outline.mddraft/chapter-001.md在进入大规模细纲或正文前，默认先补两类核心文档：
outline/reverse-volume-outline.md（或项目现有主卷纲文件）outline/volume-outline-score.md要求：
在 prep/ 中先钉死：
若用户已进入开篇打磨阶段，可再加四份高价值补充稿，直接服务前30章落地：
prep/13hao-building-rule-sheet.md
prep/foreshadow-payoff-map.md
prep/relationship-ledger.md
prep/fame-progression-map.md
若用户已从“开篇能写”推进到“整本长篇能撑住”，还应补四份卷级总纲文件：
outline/500k-volume-plan.md（或按目标体量改名为 outline/200w-volume-plan.md / outline/300w-volume-plan.md）
outline/overall-outline.md
outline/ending-design-options.md
outline/opening-30-chapter-outline.md
prep/opening-30chap-plan.md 正式化为开篇30章母稿；按阶段整理章节提要、阶段产出、前30章完成后读者必须得到什么、以及故意不说透什么名著结构拆借表不要写成“这本像什么”。 应写：
先尝试：
gh issue create ...若失败且提示仓库禁用 Issues：
notes/gh-management.md这条很重要： 仓库禁用 Issues 时，不要继续空谈“可以用 gh 管理”；应改为 repo 内管理文档 + 后续 commit/PR 跟踪。
每新增一批文档，都同步更新：
projects/<slug>/README.mdprojects/<slug>/notes/gh-management.md避免仓库里文件越来越多却无入口地图。
当项目已进入“骨架齐套、准备进正文”阶段，至少再补两个目录级入口：
characters/README.md
prep/ / outline/ 的跳转关系prep/README.md
outline/ / characters/ 的跳转关系目的：
至少检查：
git status --short若用户明确表示：
则默认优先补这三层，而不是继续写章节正文：
prep/compensation-ledger.md
prep/foreshadow-payoff-map.md
outline/500k-volume-plan.md
prep/relationship-ledger.md
prep/fame-progression-map.md
outline/500k-volume-plan.md
核心判断：
当用户说以下任一类话时，优先落到本技能，而不是直接试写正文：
尤其当任务发生在已有小说 repo 内，应先读现有：
README.mdoutline/*.mdprep/*.mdcharacters/*.md再决定补哪一层骨架，避免脱离现有工程结构另起一套。
若 repo 已存在：
则默认不要新起一套孤立文档。 优先做三件事：
大纲/细纲.md 或 outline/master-outline.md）默认判断：
前三十章细纲.md，而用户已进入中后段结构推进，应升级为全书统一总稿 细纲.md当细纲进入全书级总稿时，默认结构建议为：
# 细纲逐章字段至少保留：
若用户明确要求“写得更细”，优先补这七栏，而不是盲目增加散文解释。
若用户已完成前30章或前80章细纲，并要求继续完善到终局，默认按这个顺序扩：
核心原则：
如果正文已写到某一章号（如 030 章左右），继续补细纲时默认遵守：
因此，当用户说“把正文外的都读一遍，再直接写细纲”，默认就包括：
如果 repo 已经出现以下任一情况：
outline/500k-volume-plan.md 一类文件仍在被 README / notes / 子目录 README 引用则不要急着把所有扩细版和正文暴力重编号。
先做“三层章号”治理：
正文现行章号
draft/chapter-XXX.md 的真实文件号单卷扩细工作章号
outline/volume-*-expanded-outline.md 内部使用的章号全书最终映射章号
默认处理顺序：
volume-5 以后的单卷扩细版加一个短的“口径说明”区块，明确：这是工作章号，不等于最终章号；最终映射只认总卷表默认原则：
最值得补的文件通常是：
README.mdcharacters/README.mdprep/README.mdnotes/gh-management.mdoutline/2m-volume-plan.md）outline/volume-5-*.md 到 outline/volume-12-*.md验证时至少做三件事：
这样做的收益是：
当用户不是要试写正文，而是要把某一卷从“卷名 + 卷简介 + 模块摘要”扩成可执行细纲时，默认产物应单独落成：
outline/volume-<n>-<slug>-expanded-outline.md当用户要求“把总纲/总纲.md 也同步回修到同一口径”“统一口径”“回刷总纲/卷纲/伏笔表”时，也走本技能，不要只改一份文件。 先并读并对齐至少三层：
默认同步检查项：
若发现旧文件仍写“待补”但实际上已补完，需顺手把状态口径改成当前完成态，避免总纲落后于卷纲与细纲。
默认先并读三类材料：
outline/500k-volume-plan.md（或总体分卷表）中的原始定位推荐结构：
若继续细拆到章节级，默认每章使用这些字段：
卷级扩细时还应默认守六条：
对用户回报时，优先给：
少谈创作理论，多给落地进度。
若用户是要项目文稿、卷纲、细纲、终章、尾声、回收清单这类可版本化写作产物，默认不要只在对话/TUI里直接输出正文给用户看。 优先做法：
只有当用户明确要求“先在对话里看一版”时，才先走聊天草稿；否则仓库落盘优先。
gh 可登录不代表仓库开了 Issues；先试，失败即回退。当项目已经完成骨架层（总体大纲 / 分卷表 / 世界规则 / 角色 / 前30章纲）并进入正文试写后，继续写后续章节时不要只凭上轮聊天记忆硬写。
每次续写下一章前，至少先做这三步：
outline/opening-30-chapter-outline.md 中对应章节条目prep/*.md 规则或文风文件正文续写时默认遵守：
当某一卷正文完成，或至少连续写完该卷一个完整章节群（如 10-20 章大段）后，不要直接无脑续写下一卷。
必须先做一次卷级复盘，至少检查：
outline/volume-*-expanded-outline.md 里的主任务、场景重心、规则推进、关系推进、章尾钩复盘输出建议至少包含四块：
若发现问题：
核心原则：
当用户不是要“续写下一章”，而是要：
则默认进入“局部精修”而非“重写”。
先做这几步：
精修时优先改这些位置：
边界：
若用户连续多次只说“写吧”或“继续写吧”，默认解释为：
当用户明确说：
则默认解释为：
prep/*.md当正文进入“规则发现 / 规则利用 / 社会传播”这类高连续性段落时，one-shot 多章还应额外守八条：
当正文已进入“名望/吉祥物经济/被社区消费”的中段推进时，续写还应额外守十条：
至少满足以下才算进入可写阶段：
此后再写前30章逐章细纲，最后才试写第一章。