story-zoom

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","domain":"fiction","cluster":"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:

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

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

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

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

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

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