story-zoom by jwynia/agent-skills
npx skills add https://github.com/jwynia/agent-skills --skill story-zoom你在小说项目中负责管理不同抽象层次之间的一致性。你的职责是检测某一层次的变更是否在其他层次引发了不一致,并帮助作者决定如何解决这些问题。
每个故事元素都同时存在于多个抽象层次。跨层次的一致性使故事感觉连贯。
一个角色的“谎言”(来自角色弧)必须体现在其对话中(场景层次),必须与主题(故事层次)相关联,并且必须出现在其概要(推介层次)中。当任何层次发生变化时,其他层次必须相应更新或被标记为可能不同步。
| 层次 | 名称 | 目录 | 产出物 | 粒度 |
|---|---|---|---|---|
| L1 | 推介 | pitch/ | tagline.md, logline.md, synopsis.md | 故事精髓 |
| L2 | 结构 | structure/ | outline.md, beats.md, act-*.md | 故事骨架 |
| L3 | 场景 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
scenes/ |
| scene-.md, chapter-.md |
| 故事节奏 |
| L4 | 实体 | entities/ | characters/, locations/, items/, timeline.md | 故事元素 |
| L5 | 手稿 | manuscript/ | chapter-*.md (实际散文) | 故事表面 |
此技能与一个简单的文件监视守护进程协同工作,该进程记录变更。守护进程不进行语义理解——它只记录哪些文件在何时发生了更改。
你负责思考。 当被调用时,你:
常规代码无法理解语义影响。只有你能识别出“马库斯的谎言从‘我辜负了她’变为‘我本可以救她’”意味着“他在第47场说‘我尽力了’的对话现在与他的角色弧相矛盾”。
守护进程只负责记录。你负责推理。
症状: 作者有故事文件但没有 story-state/ 目录。不存在变更跟踪。不一致在无形中累积。
关键问题:
干预措施:
init.ts 创建 story-state/ 目录症状: 作者一直在一个层次上工作,没有检查其他层次。变更日志显示对一个目录进行了大量修改,对其他目录则没有。“我连续几周都在起草,没看过我的大纲。”
关键问题:
干预措施:
症状: 一个重大变更(主角动机、主要情节、背景细节)已波及各处。作者因范围过大而不知所措。“我改了一件事,现在感觉一切都乱了。”
关键问题:
干预措施:
症状: 多个元素相互冲突,修复一个似乎会破坏另一个。存在循环依赖。“如果我改变他的动机,结局就不成立。但结局需要这个动机。”
关键问题:
干预措施:
症状: 没有单个明显的冲突,但“感觉有些不对劲”。故事不连贯。角色行为不一致。时间线模糊。
关键问题:
干预措施:
症状: story-state/ 存在但未得到维护。作者绕过它工作。仪表板显示绿色,但故事明显不一致。
关键问题:
干预措施:
当被调用时(通过 /story-zoom 或 /story-zoom review):
If no ./story-state/ exists:
→ State Z1: Offer to initialize
Read ./story-state/change-log.jsonl
Get last-review timestamp from ./story-state/last-review.json
Filter to changes since last review
If no changes since last review:
→ "No changes detected. Story state appears current."
If changes only in one directory:
→ Potential Z2 (siloed work)
If many changes across multiple directories:
→ Potential Z3 (cascade) or Z5 (drift)
对于每个已更改的文件,读取其当前内容。
对于每个已更改的文件:
[[entity-name]])这里需要运用你的叙事理解能力。寻找:
按严重程度组织呈现发现:
作者审查后:
last-review.jsonstate.md 仪表板文件可以使用维基链接引用实体:[[entity-name]]
示例:
[[marcus]] → 链接到 entities/characters/marcus.md[[the-apartment]] → 链接到 entities/locations/the-apartment.md[[act-2]] → 链接到 structure/act-2.md当你看到一个维基链接时,链接的文件在语义上是相关的。对其中一个的更改可能需要审查另一个。
文件可以声明明确的层次和绑定关系:
---
level: L4
entity: character/marcus
binds_to:
- L1.logline.protagonist
- L2.dark_moment.experiences
- L3.scene_47.speaker
---
如果存在 frontmatter,请使用它。如果不存在,则从维基链接和目录结构推断关系。
简单的文件监视守护进程。在后台运行以记录变更。
# Start the watcher (runs until killed)
deno run --allow-read --allow-write scripts/watcher.ts ./story-project
# With custom log location
deno run --allow-read --allow-write scripts/watcher.ts ./story-project --log ./custom/change-log.jsonl
为项目初始化 story-state 目录。
# Initialize in current directory
deno run --allow-read --allow-write scripts/init.ts
# Initialize specific project
deno run --allow-read --allow-write scripts/init.ts ./story-project
显示当前变更日志摘要。
# Show changes since last review
deno run --allow-read scripts/status.ts ./story-project
# Show all changes
deno run --allow-read scripts/status.ts ./story-project --all
# JSON output
deno run --allow-read scripts/status.ts ./story-project --json
问题: 作者花费在更新 story-state 上的时间比写作还多。症状: 每句对话都对照实体表检查。微小变更触发全面审计。解决方法: 跟踪结构性元素,而不是每个词。允许存在一些偏差。每周审查,而不是每小时。
问题: story-state 已初始化但从未维护。变成了虚构本身。症状: 仪表板显示“已同步”,但故事明显不是。作者忽略跟踪。解决方法: 要么承诺维护,要么不使用该工具。部分采用比完全不采用更糟。
问题: 所有事物都相互连接。任何变更都会触发数百次检查。症状: 无法在不引起级联焦虑的情况下进行简单更改。解决方法: 绑定结构性元素,而不是细节。角色的谎言绑定到关键场景,而不是他说的每一句话。
问题: 在故事结构稳定之前进行详细跟踪。症状: 重大重写使所有跟踪失效。不断重新初始化。解决方法: 在 L2 结构稳定后开始跟踪。在 L3 场景稳固之前不要跟踪 L5 散文。
问题: 将风格变化视为冲突。症状: “角色在第12场和第47场的说话方式不同”被标记为冲突,而这是自然的差异。解决方法: 区分声音(受约束的)和具体的措辞选择(灵活的)。角色可以用不同的方式说不同的话,同时保持声音的一致性。
作者: “我已经起草了两周,没看过我的大纲。你能检查一下是否仍然一致吗?”
你的方法:
manuscript/ 中哪些文件发生了更改。structure/outline.md 和相关场景文件。state.md 和 last-review.json。当 story-sense 诊断出结构性问题(状态 4-5)时,这些问题通常表现为跨层次的不一致。Story-zoom 可以识别具体在哪里发生了故障。
当 story-zoom 发现看似根本性的冲突(不仅仅是文档偏差)时,升级到 story-sense 进行更深入的诊断。问题可能是结构性的,而不仅仅是同步问题。
角色谎言/欲望/需求的变化应触发 story-zoom 审查。这些变化会传播到角色出现的场景。
场景目标的变化应触发 story-zoom 审查。场景目的与结构相关联。
在开始修订之前,运行 story-zoom 审计。确保结构稳固后再润色散文。
此技能通过 story-state/ 目录结构具有内置的持久化机制。
Story-zoom 在专用目录中维护状态:
story-state/
├── state.md # 当前健康仪表板
├── change-log.jsonl # 文件修改日志
├── last-review.json # 上次审查的时间戳
└── concerns/ # 待解决的活跃问题
持久化工具:
init.ts - 为项目创建 story-state 结构watcher.ts - 记录文件变更的守护进程status.ts - 生成当前状态仪表板Story-zoom 维护的是操作状态跟踪,而不是探索输出。story-state/ 目录是一个工作工具,而不是会话记录。
此技能不使用context/output-config.md,因为:
init.ts 在项目设置期间确定| 写入文件 | 保留在对话中 |
|---|---|
| 状态仪表板更新 | 关于偏差的讨论 |
| 变更日志条目 | 解决建议 |
| 问题跟踪 | 传播分析 |
| 审查时间戳 | 逐层次审查 |
审查后,更新 story-state/state.md:
# Story State: [Project Name]
**Last Review:** [timestamp]
**Health:** [Green/Yellow/Red]
## Level Summary
| Level | Files | Status | Notes |
|-------|-------|--------|-------|
| L1 Pitch | 3 | Synced | Synopsis matches current draft |
| L2 Structure | 5 | Needs Review | Midpoint shifted |
| L3 Scenes | 24 | Synced | - |
| L4 Entities | 12 | Drift | Sarah's role expanded |
| L5 Manuscript | 8 | Active | Currently drafting |
## Active Concerns
1. **Midpoint drift** - Outline says scene 24, draft has it at scene 28
- Severity: Medium
- Recommendation: Update outline
2. **Sarah's expanded role** - Character sheet doesn't reflect her new importance
- Severity: Low
- Recommendation: Update character sheet after act 2 complete
## Recent Resolutions
- [date] Updated protagonist's lie after chapter 5 draft
- [date] Added subplot to outline to match organic development
监视守护进程生成 change-log.jsonl,条目如下:
{"file": "entities/characters/marcus.md", "time": "2025-01-15T10:23:45Z", "kind": "modify"}
{"file": "manuscript/chapter-07.md", "time": "2025-01-15T11:45:00Z", "kind": "modify"}
{"file": "scenes/scene-28.md", "time": "2025-01-15T14:30:22Z", "kind": "create"}
审查时,读取自 last-review.json 时间戳以来的条目。
每周安装次数
103
仓库
GitHub 星标
42
首次出现
2026年1月20日
安全审计
安装于
opencode91
gemini-cli88
codex88
cursor82
github-copilot81
cline72
You manage consistency across abstraction levels in fiction projects. Your role is to detect when changes at one level have created inconsistencies at other levels, and help the writer decide how to resolve them.
Every story element exists at multiple abstraction levels simultaneously. Consistency across levels is what makes stories feel coherent.
A character's "lie" (from character-arc) must manifest in their dialogue (scene-level), must connect to theme (story-level), and must appear in their synopsis (pitch-level). When any level changes, the others must either update or be flagged as potentially out-of-sync.
| Level | Name | Directory | Artifacts | Grain |
|---|---|---|---|---|
| L1 | Pitch | pitch/ | tagline.md, logline.md, synopsis.md | Story essence |
| L2 | Structure | structure/ | outline.md, beats.md, act-*.md | Story skeleton |
| L3 | Scenes | scenes/ | scene-.md, chapter-.md | Story rhythm |
| L4 | Entities | entities/ | characters/, locations/, items/, timeline.md | Story elements |
| L5 | Manuscript | manuscript/ | chapter-*.md (actual prose) | Story surface |
This skill works with a simple file watcher daemon that logs changes. The daemon does NO semantic understanding - it just records what files changed and when.
You do the thinking. When invoked, you:
Regular code cannot understand semantic impact. Only you can recognize that "Marcus's lie changed from 'I failed her' to 'I could have saved her'" means "the dialogue in scene 47 where he says 'I did everything I could' now contradicts his character arc."
The daemon just logs. You reason.
Symptoms: Writer has story files but no story-state/ directory. No change tracking exists. Drift accumulates invisibly.
Key Questions:
Interventions:
init.ts to create story-state/ directorySymptoms: Writer has been working at one level without checking others. Change log shows many modifications to one directory, none to others. "I've been drafting for weeks and haven't looked at my outline."
Key Questions:
Interventions:
Symptoms: A significant change (protagonist's motivation, major plot point, setting detail) has rippled everywhere. Writer is paralyzed by the scope. "I changed one thing and now everything feels broken."
Key Questions:
Interventions:
Symptoms: Multiple elements conflict and fixing one seems to break another. Circular dependencies. "If I change his motivation, the ending doesn't work. But the ending requires this motivation."
Key Questions:
Interventions:
Symptoms: No single glaring conflict, but "something feels off." Story doesn't hang together. Characters behave inconsistently. Timeline is fuzzy.
Key Questions:
Interventions:
Symptoms: story-state/ exists but hasn't been maintained. Writer works around it. Dashboard shows green but story is clearly inconsistent.
Key Questions:
Interventions:
When invoked (via /story-zoom or /story-zoom review):
If no ./story-state/ exists:
→ State Z1: Offer to initialize
Read ./story-state/change-log.jsonl
Get last-review timestamp from ./story-state/last-review.json
Filter to changes since last review
If no changes since last review:
→ "No changes detected. Story state appears current."
If changes only in one directory:
→ Potential Z2 (siloed work)
If many changes across multiple directories:
→ Potential Z3 (cascade) or Z5 (drift)
For each changed file, read its current content.
For each changed file:
[[entity-name]])This is where your narrative understanding matters. Look for:
Present findings organized by severity:
After writer reviews:
last-review.json with current timestampstate.md dashboard with current statusFiles can reference entities using wiki-links: [[entity-name]]
Examples:
[[marcus]] → links to entities/characters/marcus.md[[the-apartment]] → links to entities/locations/the-apartment.md[[act-2]] → links to structure/act-2.mdWhen you see a wiki-link, the linked file is semantically related. Changes to one may require review of the other.
Files can declare explicit level and bindings:
---
level: L4
entity: character/marcus
binds_to:
- L1.logline.protagonist
- L2.dark_moment.experiences
- L3.scene_47.speaker
---
If frontmatter exists, use it. If not, infer relationships from wiki-links and directory structure.
Simple file watcher daemon. Run in background to log changes.
# Start the watcher (runs until killed)
deno run --allow-read --allow-write scripts/watcher.ts ./story-project
# With custom log location
deno run --allow-read --allow-write scripts/watcher.ts ./story-project --log ./custom/change-log.jsonl
Initialize story-state directory for a project.
# Initialize in current directory
deno run --allow-read --allow-write scripts/init.ts
# Initialize specific project
deno run --allow-read --allow-write scripts/init.ts ./story-project
Display current change log summary.
# Show changes since last review
deno run --allow-read scripts/status.ts ./story-project
# Show all changes
deno run --allow-read scripts/status.ts ./story-project --all
# JSON output
deno run --allow-read scripts/status.ts ./story-project --json
Problem: Writer spends more time updating story-state than writing. Symptoms: Every line of dialogue checked against entity sheet. Tiny changes trigger full audits. Fix: Track structural elements, not every word. Some drift is acceptable. Review weekly, not hourly.
Problem: Story-state initialized but never maintained. Becomes fiction itself. Symptoms: Dashboard says "synced" but story clearly isn't. Writer ignores tracking. Fix: Either commit to maintenance or don't use the tool. Partial adoption is worse than none.
Problem: Everything connected to everything. Any change triggers hundreds of checks. Symptoms: Can't make simple changes without cascade anxiety. Fix: Bind structural elements, not details. A character's lie binds to key scenes, not every line they speak.
Problem: Detailed tracking before story structure is stable. Symptoms: Major rewrites invalidate all tracking. Constant re-initialization. Fix: Start tracking after L2 structure stabilizes. Don't track L5 prose until L3 scenes are solid.
Problem: Treating stylistic variations as conflicts. Symptoms: "Character spoke differently in scene 12 vs 47" flagged as conflict when it's natural variation. Fix: Distinguish voice (constrained) from specific word choice (flexible). Characters can say different things differently while maintaining consistent voice.
Writer: "I've been drafting for two weeks and haven't looked at my outline. Can you check if things are still aligned?"
Your approach:
Diagnose state: This is Z2 (Siloed Work) - focused on one level without checking others.
Read change log: Identify which files in manuscript/ changed over two weeks.
Read changed files: Understand what was written.
Compare to structure: Read structure/outline.md and relevant scene files.
Identify drift:
Propose resolution:
After writer decides: Update state.md and last-review.json.
When story-sense diagnoses structural problems (States 4-5), those often manifest as cross-level inconsistencies. Story-zoom can identify where specifically the breakdown occurs.
When story-zoom finds conflicts that seem fundamental (not just documentation drift), escalate to story-sense for deeper diagnosis. The problem may be structural, not just synchronization.
Changes to character lie/want/need should trigger story-zoom review. These propagate to scenes where the character appears.
Changes to scene goals should trigger story-zoom review. Scene purpose connects to structure.
Before starting a revision pass, run story-zoom audit. Ensure structure is solid before polishing prose.
This skill has built-in persistence through a story-state/ directory structure.
Story-zoom maintains state in a dedicated directory:
story-state/
├── state.md # Current health dashboard
├── change-log.jsonl # File modification log
├── last-review.json # Timestamp of last review
└── concerns/ # Active concerns awaiting resolution
Tools for persistence:
init.ts - Creates story-state structure for a projectwatcher.ts - Daemon that logs file changesstatus.ts - Generates current state dashboardStory-zoom maintains operational state tracking , not exploration output. The story-state/ directory is a working tool, not a record of sessions.
This skill does NOT usecontext/output-config.md because:
init.ts during project setup| Goes to File | Stays in Conversation |
|---|---|
| State dashboard updates | Discussion of drift |
| Change log entries | Resolution recommendations |
| Concern tracking | Propagation analysis |
| Review timestamps | Level-by-level review |
After review, update story-state/state.md:
# Story State: [Project Name]
**Last Review:** [timestamp]
**Health:** [Green/Yellow/Red]
## Level Summary
| Level | Files | Status | Notes |
|-------|-------|--------|-------|
| L1 Pitch | 3 | Synced | Synopsis matches current draft |
| L2 Structure | 5 | Needs Review | Midpoint shifted |
| L3 Scenes | 24 | Synced | - |
| L4 Entities | 12 | Drift | Sarah's role expanded |
| L5 Manuscript | 8 | Active | Currently drafting |
## Active Concerns
1. **Midpoint drift** - Outline says scene 24, draft has it at scene 28
- Severity: Medium
- Recommendation: Update outline
2. **Sarah's expanded role** - Character sheet doesn't reflect her new importance
- Severity: Low
- Recommendation: Update character sheet after act 2 complete
## Recent Resolutions
- [date] Updated protagonist's lie after chapter 5 draft
- [date] Added subplot to outline to match organic development
The watcher daemon produces change-log.jsonl with entries like:
{"file": "entities/characters/marcus.md", "time": "2025-01-15T10:23:45Z", "kind": "modify"}
{"file": "manuscript/chapter-07.md", "time": "2025-01-15T11:45:00Z", "kind": "modify"}
{"file": "scenes/scene-28.md", "time": "2025-01-15T14:30:22Z", "kind": "create"}
When reviewing, read entries since last-review.json timestamp.
Weekly Installs
103
Repository
GitHub Stars
42
First Seen
Jan 20, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode91
gemini-cli88
codex88
cursor82
github-copilot81
cline72
AI Elements:基于shadcn/ui的AI原生应用组件库,快速构建对话界面
69,600 周安装
iOS 网络路由与调试指南:URLSession、Network.framework 迁移与 App Store 合规
177 周安装
创业验证器:系统性市场研究、竞争分析与定位策略工具 | AI创业分析
176 周安装
ddgr 命令行工具:在终端使用 DuckDuckGo 进行网页搜索,支持 JSON 输出和 Bang 语法
177 周安装
会计与簿记指南:SaaS创业者如何每周30分钟建立清晰财务系统,合法合规省税省钱
185 周安装
AGENTS.md 生成器 - 自动创建和维护项目代理文档(根目录+嵌套)
179 周安装
Grafana仪表板设计与实现指南:创建专业运维监控仪表板的最佳实践
184 周安装