К основному содержанию
скилл CX Codex

story-zoom — скилл для Claude Code: синхронизация уровней истории

Скилл следит за тем, чтобы правка на одном уровне рукописи не разошлась с остальными: питч, структура, сцены, сущности, текст.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add jwynia/agent-skills --skill story-zoom -a claude-code
Открыть на GitHub

Что делает story-zoom

Скилл работает с пятью уровнями абстракции: питч (pitch/), структура (structure/), сцены (scenes/), сущности (entities/) и сам текст (manuscript/). Когда вы меняете что-то на одном уровне, он читает журнал изменений, находит связанные файлы по wiki-ссылкам и структуре каталогов и показывает, что теперь противоречит друг другу. Решения остаются за вами: скилл предлагает варианты, а не переписывает рукопись сам.

Устроено так: простой демон-наблюдатель пишет в журнал, какие файлы изменились, и не пытается понять смысл. Всю смысловую работу делает модель при вызове. Поэтому «ложь» персонажа из арки, его реплика в сцене и строка в синопсисе связываются между собой, а не живут отдельно.

Скилл разбирает шесть состояний проекта, от холодного старта без каталога story-state/ до накопленного дрейфа, когда всё вроде бы на месте, но история не сходится. Для холодного старта нужен init.ts, который создаёт story-state/ и фиксирует текущее состояние как синхронное. При конфликтах скилл смотрит на уровень с наибольшим авторитетом — структуру, потом сущности, потом текст, — потому что правка в прозе не должна ломать каркас.

Какие задачи решает

  • найти, какие сцены разошлись с обновлённым описанием персонажа
  • разобрать очередь правок после смены мотивации героя
  • развязать конфликт, где финал требует одной мотивации, а середина — другой
  • проверить, совпадает ли синопсис с тем, что реально написано
  • восстановить заброшенный учёт состояния истории

Примеры запросов агенту

  • /story-zoom
  • /story-zoom review
  • Проверь, что изменилось с прошлого просмотра, и покажи расхождения между уровнями

Как установить story-zoom

1Через Skills CLI (Vercel)

npx skills add jwynia/agent-skills --skill story-zoom -a claude-code

2Вручную: положить файлы

~/.claude/skills/story-zoom/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/story-zoom/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора77

context-retrospective Разбирает логи работы агента и показывает, каких знаний в контекстной сети не хватало и какие правила стоит поправить. CX Codex +1 448установок governance-systems Помогает придумать королевства, империи и федерации с внутренней сложностью и правдоподобными связями между ними. CX Codex +1 448установок voice-analysis Скилл разбирает тексты автора по восьми фазам и собирает voice guide, по которому ИИ пишет в его манере. CX Codex +1 445установок drafting Диагностирует, почему черновик не пишется, и вытаскивает текст на страницу. Полезен, когда план готов, а дело стоит. CX Codex +1 445установок belief-systems Помогает придумать религию для вымышленного мира: пантеон, обряды, институты и то, как вера двигает персонажей. CX Codex +1 439установок reverse-outliner Разбирает готовую книгу на сцены и собирает структурный план: видно, как устроен текст и какие приёмы держат читателя. CX Codex +1 439установок pwa-development Скилл для React и Svelte: помогает добавить service worker, офлайн-режим и установку приложения. Пригодится, когда PWA нужен, а не прикручен в конце. CX Codex +1 437установок chapter-drafter Оркестратор скиллов: пишет сцены главы по готовому плану и сам правит их, пока текст не пройдёт пять редакторских проверок. CX Codex +1 434установок

Похожие

story-init danjdewhurst Создаёт файловую структуру литературного проекта в Markdown: библию истории, реестры персонажей, трекер глав и таймлайн. CX Codex +1 773установок story-memory haowjy Скилл для ИИ-кодинга и письма: хранит канон, факты и контекст между главами. Пригодится, когда проект растёт и агент теряет детали. CX Codex +1 527установок fiction-workshop rhavekost Скилл ведёт рукопись в три этапа: Story Bible, работа над главами и проверка на свежем читателе. Для романов и сборников рассказов. CX Codex +1 2 100установок story-maintenance danjdewhurst Скилл запускает CLI для проверки ссылок, переиндексации реестров и поиска сюжетных несостыковок в Markdown-проектах. Помогает следить за структурой книги без ручной правки таблиц. CX Codex +1 694установок story-planning haowjy Помогает спланировать структуру сюжета, арки персонажей и сцены перед написанием текста. Переключает агента в режим подготовки и архитектуры истории. CX Codex +1 664установок sepia-hemingway Nanako0129 Скилл для написания и правки художественной прозы с голосом Хемингуэя. Работает только вместе с плагином Sepia. CX Codex +1 754установок

Рядом в теме «Тексты и документация»

Всё по теме «Тексты и документация» →

Вопросы о story-zoom

Как установить story-zoom в Claude?

Выполните npx skills add jwynia/agent-skills --skill story-zoom -a claude-code. После этого файл скилла окажется в ~/.claude/skills/story-zoom/SKILL.md.

Что делает story-zoom?

Сопоставляет уровни истории между собой и показывает, где правка на одном уровне создала расхождение на другом. Дальше вы решаете, что обновлять.

Нужен ли отдельный демон для работы скилла?

Да, скилл рассчитан на файловый наблюдатель, который пишет журнал изменений. Сам он смысл не разбирает, только фиксирует, что и когда поменялось.

Исходный текст

SKILL.md · MIT
---
name: story-zoom
description: Manage multi-level story synchronization. Use when changes at one abstraction level (pitch, structure, scenes, entities, prose) need to propagate to others, or when story elements feel inconsistent across levels.
license: MIT
metadata:
  author: jwynia
  version: "1.0"
  type: diagnostic
  mode: diagnostic+assistive
  domain: fiction
---

# Story-Zoom: Multi-Level Fiction Synchronization

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.

## Core Principle

**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.

## The Abstraction Levels

| 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 |

## Architecture: Dumb Logger + Smart LLM

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:
1. Read the change log since last review
2. Read the changed files
3. Find related files (via wiki-links, directory structure, explicit references)
4. Use your understanding of narrative to identify what's now inconsistent
5. Propose resolutions for the writer to approve

### Why This Architecture?

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.

## The States

### State Z1: No Story State (Cold Start)

**Symptoms:** Writer has story files but no `story-state/` directory. No change tracking exists. Drift accumulates invisibly.

**Key Questions:**
- What story files exist and in which directories?
- Is there an existing outline, character sheets, manuscript?
- What's the current source of truth for each level?

**Interventions:**
1. Run `init.ts` to create `story-state/` directory
2. Inventory existing files by level
3. Start the watcher daemon
4. Establish baseline (everything currently "in sync" by definition)

---

### State Z2: Siloed Work (Level Isolation)

**Symptoms:** 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:**
- Which level have you been focused on?
- When did you last review other levels?
- Have any fundamental story decisions changed during this work?

**Interventions:**
1. Review change log to identify scope of changes
2. Read files at the worked level to understand what evolved
3. Compare against other levels for drift
4. Create prioritized list of potential inconsistencies
5. Work through most critical first (usually L2 structure, then L4 entities)

---

### State Z3: Cascade Overload (Too Many Pending Changes)

**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:**
- What was the root change?
- Which levels does it directly affect?
- What's the priority order for updates?

**Interventions:**
1. Identify the root change clearly
2. Triage affected files by impact:
   - **BLOCKING**: Must update before continuing (structural elements)
   - **HIGH**: Should update soon (character consistency)
   - **DEFERRABLE**: Can wait (prose polish)
3. Create a propagation plan with sequence
4. Work through one level at a time, not all at once
5. Mark each as resolved before moving to next

---

### State Z4: Conflict Deadlock

**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:**
- What are the conflicting constraints?
- Which level has authority (usually L2 structure > L4 entities > L5 prose)?
- Is there a higher-level decision that would resolve the conflict?

**Interventions:**
1. Map the conflict explicitly (A requires B, B requires not-A)
2. Identify if this is a genuine story problem or a perceived one
3. Look for the hidden assumption creating the deadlock
4. Often the resolution is at a higher level than where conflict appears
5. May need to escalate to story-sense for structural diagnosis

---

### State Z5: Drift Accumulation (Vague Incoherence)

**Symptoms:** No single glaring conflict, but "something feels off." Story doesn't hang together. Characters behave inconsistently. Timeline is fuzzy.

**Key Questions:**
- When was the last comprehensive review?
- Are wiki-links still accurate?
- Has the story evolved without the documentation?

**Interventions:**
1. Full audit across all levels
2. Re-read pitch-level documents - does synopsis still match the actual story?
3. Check entity definitions against their appearances in scenes
4. Look for implicit assumptions that were never documented
5. Update state.md with current understanding

---

### State Z6: Stale State (Document Rot)

**Symptoms:** `story-state/` exists but hasn't been maintained. Writer works around it. Dashboard shows green but story is clearly inconsistent.

**Key Questions:**
- Is active maintenance worth it for this project?
- What's preventing regular use?
- Should we refresh or archive?

**Interventions:**
1. Decide: refresh or abandon tracking
2. If refresh: treat as Z1 (re-initialize from current state)
3. If abandon: archive story-state, work without tracking
4. Address workflow friction that caused abandonment

---

## Diagnostic Process

When invoked (via `/story-zoom` or `/story-zoom review`):

### 1. Check for story-state directory
```
If no ./story-state/ exists:
  → State Z1: Offer to initialize
```

### 2. Read change log
```
Read ./story-state/change-log.jsonl
Get last-review timestamp from ./story-state/last-review.json
Filter to changes since last review
```

### 3. Assess change scope
```
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)
```

### 4. Read changed files
For each changed file, read its current content.

### 5. Find related files
For each changed file:
- Extract wiki-links (`[[entity-name]]`)
- Check directory siblings (other files in same folder)
- Check files at adjacent levels (L2 structure ↔ L3 scenes)

### 6. Analyze for inconsistencies
This is where your narrative understanding matters. Look for:
- Character attributes that don't match their behavior
- Plot points in outline that don't appear in scenes
- Entity details that contradict prose descriptions
- Timeline inconsistencies
- Thematic drift from pitch documents

### 7. Report findings
Present findings organized by severity:
- **Conflicts**: Direct contradictions requiring resolution
- **Drift**: Potential inconsistencies worth checking
- **Updates**: Suggested propagations

### 8. Update tracking
After writer reviews:
- Update `last-review.json` with current timestamp
- Update `state.md` dashboard with current status

---

## Key Questions for Analysis

### When Reading Pitch (L1) Changes
- Does the logline still capture the story being written?
- Has the protagonist's core conflict shifted?
- Is the genre promise still being fulfilled?

### When Reading Structure (L2) Changes
- Do scene files still align with outline beats?
- Have act breaks shifted?
- Is the midpoint still the midpoint?

### When Reading Scene (L3) Changes
- Do scenes still accomplish their outlined purpose?
- Have character behaviors changed from their definitions?
- Does the timeline still work?

### When Reading Entity (L4) Changes
- Are character attributes consistent with their scenes?
- Do location details match their descriptions in prose?
- Have relationships changed?

### When Reading Manuscript (L5) Changes
- Does prose reflect current entity definitions?
- Does dialogue match character voice definitions?
- Are described settings consistent with location entities?

---

## Wiki-Link Convention

Files 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.md`

When you see a wiki-link, the linked file is semantically related. Changes to one may require review of the other.

---

## Frontmatter Convention

Files can declare explicit level and bindings:

```yaml
---
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.

---

## Available Tools

### watcher.ts
Simple file watcher daemon. Run in background to log changes.

```bash
# 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
```

### init.ts
Initialize story-state directory for a project.

```bash
# 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
```

### status.ts
Display current change log summary.

```bash
# 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
```

---

## Anti-Patterns

### The Obsessive Tracker
**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.

### The Stale Bible
**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.

### The Binding Explosion
**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.

### The Premature Zoom
**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.

### The False Conflict
**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.

---

## Example Interaction

**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:**

1. **Diagnose state:** This is Z2 (Siloed Work) - focused on one level without checking others.

2. **Read change log:** Identify which files in `manuscript/` changed over two weeks.

3. **Read changed files:** Understand what was written.

4. **Compare to structure:** Read `structure/outline.md` and relevant scene files.

5. **Identify drift:**
   - "Chapter 7 introduces a subplot that isn't in your outline"
   - "The midpoint in your outline (scene 24) is now at scene 28"
   - "Character Sarah has taken on a larger role than outlined"

6. **Propose resolution:**
   - "Option A: Update outline to reflect organic evolution"
   - "Option B: Revise manuscript to match original outline"
   - "Option C: Hybrid - keep Sarah's expanded role, update outline, but restore original midpoint"

7. **After writer decides:** Update `state.md` and `last-review.json`.

---

## Integration with Other Skills

### From story-sense
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.

### To story-sense
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.

### From character-arc
Changes to character lie/want/need should trigger story-zoom review. These propagate to scenes where the character appears.

### From scene-sequencing
Changes to scene goals should trigger story-zoom review. Scene purpose connects to structure.

### To revision
Before starting a revision pass, run story-zoom audit. Ensure structure is solid before polishing prose.

---

## Output Persistence

This skill has built-in persistence through a `story-state/` directory structure.

### Existing Persistence Mechanism

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 project
- `watcher.ts` - Daemon that logs file changes
- `status.ts` - Generates current state dashboard

### How It Differs from Standard Output Persistence

Story-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 use `context/output-config.md`** because:
- Location is determined by `init.ts` during project setup
- State files are operational (read/write continuously)
- The watcher daemon needs a fixed known location

### Conversation vs. File

| 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 |

## What You Do NOT Do

- You do not write the story for them
- You do not decide which resolution is "correct" - you present options
- You do not require perfection - some inconsistency is normal in drafts
- You do not create busywork - if tracking isn't helping, stop tracking
- You do not track trivial changes - focus on structural/semantic elements
- You do not replace the writer's judgment about their own story

---

## State Dashboard Template

After review, update `story-state/state.md`:

```markdown
# 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 Format

The watcher daemon produces `change-log.jsonl` with entries like:

```json
{"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.

© jwynia · MIT · jwynia/agent-skills

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой