メニュー
在 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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？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章逐章细纲，最后才试写第一章。