scriveno 2.0.5

package/commands/scr/pacing-analysis.md

@@ -0,0 +1,170 @@
+---
+description: Generate a structure-aware pacing report analyzing scene tempo and narrative flow.
+---
+
+# /scr:pacing-analysis -- Structure-Aware Pacing Report
+
+Generate a pacing report that analyzes scene tempo, narrative flow, and structural rhythm.
+
+## Usage
+```
+/scr:pacing-analysis [N]
+```
+
+Where `N` is the scope (act, chapter, or section number depending on work type). Omit `N` to analyze the entire manuscript.
+
+## Instruction
+
+You are a **pacing analyst**. Your job is to map the narrative rhythm, identify pacing problems, and ensure the story's tempo serves its structure.
+
+---
+
+### STEP 0: LOAD CONTEXT
+
+1. Load `config.json` to determine work type and hierarchy
+2. Load `CONSTRAINTS.json` -- this command is **hidden** from poetry and speech_song work types. If the current work type is in a hidden group, inform the writer and exit gracefully
+3. Load `OUTLINE.md` -- extract structural context: which scenes are intended as climaxes, which are transitions or breathers, the overall arc shape, and any pacing notes the writer included during planning
+4. Load the drafted prose for scope `N` (or full manuscript if `N` is omitted)
+
+---
+
+### STEP 1: SCENE LENGTH DISTRIBUTION
+
+<scene_length_analysis>
+  For each scene/chapter in scope:
+  - Count word length
+  - Calculate mean and median scene length
+  - Identify **outliers**: scenes more than 1.5x the median (unusually long) or less than 0.5x the median (unusually short)
+  - Note whether outlier length is intentional (a climax scene being longer is expected; a transition being long is suspicious)
+
+  Present as a distribution chart:
+  ```
+  Ch 1  ████████████████████ 3,200w
+  Ch 2  ████████████ 1,900w
+  Ch 3  ████████████████████████████ 4,500w  [LONG]
+  Ch 4  ████████ 1,200w
+  Ch 5  ██████████████ 2,100w
+  ```
+</scene_length_analysis>
+
+---
+
+### STEP 2: TEMPO MAPPING
+
+<tempo_classification>
+  Classify each scene's dominant tempo:
+  - **Action**: Physical conflict, chase, fight, urgent movement
+  - **Tension**: Psychological conflict, suspense, dread, anticipation
+  - **Revelation**: Discovery, plot twist, secret revealed, realization
+  - **Transition**: Travel, time passage, setup for next sequence
+  - **Reflection**: Internal processing, emotional aftermath, quiet character moment
+
+  Map the resulting rhythm across the narrative:
+  ```
+  Ch 1  [Tension]     ▓▓▓▓▓▓▓▓
+  Ch 2  [Reflection]  ░░░░░░
+  Ch 3  [Action]      ████████████
+  Ch 4  [Revelation]  ▒▒▒▒▒▒▒▒▒
+  Ch 5  [Transition]  ░░░░
+  Ch 6  [Action]      ██████████████
+  Ch 7  [Tension]     ▓▓▓▓▓▓▓▓▓▓
+  ```
+
+  Flag patterns:
+  - **Monotone**: 3+ consecutive scenes at the same tempo
+  - **Whiplash**: Jarring tempo shifts without transition
+  - **Missing type**: If no reflection scenes exist in a character-driven story, or no action in a thriller
+</tempo_classification>
+
+---
+
+### STEP 3: CLIMAX VS BREATHER BALANCE
+
+<climax_breather_analysis>
+  Cross-reference tempo map with OUTLINE.md structural intentions:
+  - Are scenes marked as climaxes actually written at high intensity?
+  - Is there a breather scene (reflection or transition) after each high-intensity sequence?
+  - Are there too many consecutive scenes at the same intensity level?
+  - Does the intensity generally build toward structural climax points?
+
+  Flag:
+  - **Missing breather**: High-intensity scene followed immediately by another high-intensity scene without relief (reader fatigue risk)
+  - **Missing escalation**: Breather followed by breather followed by breather (momentum loss)
+  - **Structural mismatch**: A scene marked as climax in the outline that reads at low intensity in the draft, or vice versa
+</climax_breather_analysis>
+
+---
+
+### STEP 4: OPENING AND CLOSING ENERGY
+
+<energy_analysis>
+  For each chapter/scene:
+  - **Opening hook**: Does the first paragraph create a question, conflict, or sensory pull that makes the reader want to continue? Rate: Strong / Adequate / Weak
+  - **Closing propulsion**: Does the final paragraph create forward momentum -- a cliffhanger, question, emotional charge, or promise of what's next? Rate: Strong / Adequate / Weak
+
+  Flag:
+  - Chapters that open with exposition or backstory (energy drain)
+  - Chapters that close without forward pull (reader puts the book down)
+  - Consecutive weak openings or closings (pattern problem)
+</energy_analysis>
+
+---
+
+### STEP 5: SAGGY MIDDLE DETECTION
+
+<saggy_middle_check>
+  Examine the 40-60% mark of the manuscript (by word count):
+  - Does the pacing drop noticeably compared to the first and third acts?
+  - Are there scenes in this section that lack clear stakes or forward momentum?
+  - Does this section contain an unusual concentration of transition or reflection scenes?
+  - Is the protagonist reactive rather than proactive in this stretch?
+
+  If pacing drops in the middle:
+  - Check whether it's **intentional** (the outline marks this as a breathing space, a slow burn, or a deliberate structural choice)
+  - If unintentional, suggest specific interventions: raise stakes, add a midpoint reversal, cut or compress low-energy scenes, add a ticking clock
+</saggy_middle_check>
+
+---
+
+### OUTPUT
+
+Present findings in this order:
+
+1. **Visual Tempo Map**: The combined scene length + tempo visualization showing the full narrative rhythm at a glance
+
+2. **Pacing Health Summary**:
+   - Overall pacing assessment (well-paced / front-loaded / back-loaded / saggy middle / monotone)
+   - Strongest pacing section and why
+   - Weakest pacing section and why
+
+3. **Findings by Dimension**: Detailed findings for each analysis dimension, grouped by severity:
+   - High: Structural pacing problems that affect reader engagement
+   - Medium: Missed opportunities for better rhythm
+   - Low: Fine-tuning suggestions
+
+4. **Recommendations**: Prioritized list of specific changes, from most impactful to least
+
+Save to `.manuscript/{scope}-PACING-REPORT.md` where `{scope}` is the act/chapter identifier or `full` for the entire manuscript.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.

package/commands/scr/panel-layout.md

@@ -0,0 +1,225 @@
+---
+description: Generate comic panel layouts with composition notes and balloon placement.
+argument-hint: "<page-number> [--panels <count>] [--style <style>]"
+---
+
+# /scr:panel-layout -- Comic Panel Layout
+
+Generate comic and graphic novel panel layouts with ASCII grid visualization, composition notes, gutter specifications, and dialogue balloon/caption placement zones.
+
+## Usage
+```
+/scr:panel-layout <page-number> [--panels <count>] [--style <style>]
+```
+
+## Instruction
+
+You are generating a comic panel layout. Load:
+- `.manuscript/config.json` (to get `work_type` -- must be comic or graphic_novel per comic_only constraint)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to check `commands.panel-layout.available` and `constraint: comic_only`)
+- `.manuscript/illustrations/ART-DIRECTION.md` if it exists (for visual style consistency)
+- `.manuscript/OUTLINE.md` (to get page content / beat assignments)
+- Drafted page content if it exists
+
+**Check availability:**
+
+Look up the current work type's group in CONSTRAINTS.json. This command has a `comic_only` constraint -- only available for comic and graphic_novel work types within the visual group.
+
+If the work type is not comic or graphic_novel:
+
+> Panel-layout is designed for comics and graphic novels only. Your [work_type] project uses different layout tools.
+> Try `/scr:spread-layout` for picture books or `/scr:illustrate-scene` for scene illustrations.
+
+Then **stop**.
+
+---
+
+### Page Content Analysis
+
+<page_analysis>
+  Read the content assigned to page `<page-number>` from OUTLINE.md and any drafted content.
+
+  Determine:
+  - **Number of beats/moments:** How many distinct visual moments need panels
+  - **Dialogue density:** How much dialogue appears (affects balloon placement)
+  - **Action level:** Is this a dialogue scene, action sequence, or atmospheric page
+  - **Pacing intent:** Fast (many small panels, quick cuts) or slow (fewer large panels, lingering)
+  - **Key visual moment:** Which panel is the "money shot" -- the one that should be largest
+</page_analysis>
+
+---
+
+### Panel Layout Generation
+
+<panel_generation>
+  **Panel Count:**
+  - Default: 6 panels per page (classic grid)
+  - Override with `--panels <count>` (range: 1-9)
+  - 1 panel = splash page (full page single image)
+  - 2-3 panels = cinematic, slow pacing
+  - 4-6 panels = standard storytelling
+  - 7-9 panels = fast pacing, montage, rapid action
+
+  **Panel Sizes:**
+  - `SPLASH` -- Full page, single image (1 panel)
+  - `HALF-PAGE` -- Takes up half the page height or width
+  - `QUARTER` -- Standard quarter-page panel
+  - `STRIP` -- Full width, reduced height (widescreen cinematic)
+  - `INSET` -- Small panel overlapping a larger one
+  - `BLEED` -- Panel extends to page edge (no border on bleed sides)
+
+  **Gutter Width:**
+  - Standard: 0.125" (1/8 inch) between panels
+  - Wide gutter: 0.25" for scene/time transitions within page
+  - No gutter: Panels share border for rapid action
+
+  **Style Presets** (via `--style`):
+  - `traditional-grid` (default) -- Even, rectangular panels in a grid. Classic Western comics.
+  - `dynamic` -- Varied panel sizes, diagonal borders, overlapping panels. Action-oriented.
+  - `manga` -- Right-to-left reading order, speed lines, varied panel shapes, emphasis on expression.
+  - `european` -- Larger panels, more detail, tier-based layout (horizontal strips). Franco-Belgian tradition.
+  - `splash-heavy` -- One dominant splash panel with smaller supporting panels. Impact-driven.
+
+  **ASCII Panel Layout Format:**
+
+  ```markdown
+  # Page [N] Panel Layout
+
+  **Style:** [preset name]
+  **Panels:** [count]
+  **Page dimensions:** [standard comic: 6.625" x 10.25" | manga: 5" x 7.5" | european: 8.5" x 11"]
+  **Gutter:** [width]
+
+  ## Layout Grid
+
+  PAGE [N]
+  +-------------------------------+
+  |           PANEL 1             |  [Shot type] - [composition note]
+  |         (half-page)           |  [Content description]
+  |                               |  [BALLOON: top-right]
+  +---------------+---------------+
+  |    PANEL 2    |    PANEL 3    |  P2: [shot] - [note]
+  |               |               |  P3: [shot] - [note]
+  |  [BALLOON:    |               |  P2: [BALLOON: bottom-left]
+  |   bottom]     |  [CAPTION:    |  P3: [CAPTION: top]
+  |               |   top]        |
+  +---------------+---------------+
+  |    PANEL 4    |    PANEL 5    |  P4: [shot] - [note]
+  |               |               |  P5: [shot] - [note]
+  +---------------+---------------+
+
+  ## Panel Details
+
+  ### Panel 1 (half-page, top)
+  - **Content:** [Characters, action, dialogue -- what happens in this panel]
+  - **Composition:** [Angle: eye-level/low/high/Dutch. Depth: shallow/deep. Focus: foreground/mid/background]
+  - **Balloons/Captions:**
+    - [SPEECH BALLOON] top-right: "[dialogue excerpt]"
+    - [THOUGHT BUBBLE] center: "[thought]"
+    - [CAPTION BOX] top-left: "[narration]"
+  - **SFX:** [Sound effects text and placement, if any]
+  - **Notes:** [Special rendering notes -- motion lines, focus blur, etc.]
+
+  ### Panel 2 (quarter, middle-left)
+  ...
+
+  ### Panel 3 (quarter, middle-right)
+  ...
+  ```
+
+  **Balloon/Caption Placement Zones:**
+  Mark placement zones in the ASCII grid and detail in panel descriptions:
+  - `[BALLOON: position]` -- Speech balloon (tail points to speaker)
+  - `[THOUGHT: position]` -- Thought bubble (cloud border)
+  - `[CAPTION: position]` -- Narration caption box (rectangular, usually top or bottom)
+  - `[SFX: position]` -- Sound effect text (integrated into art)
+  - Positions: top-left, top-center, top-right, center-left, center, center-right, bottom-left, bottom-center, bottom-right
+
+  **Reading Order:**
+  - Western (default): Left-to-right, top-to-bottom (Z-pattern)
+  - Manga (`--style manga`): Right-to-left, top-to-bottom
+  - Mark reading order with numbered arrows if layout is non-standard
+
+  **Composition Notes per Panel:**
+  Include for each panel:
+  - Camera angle (eye-level, low angle, high angle, Dutch angle, bird's-eye, worm's-eye)
+  - Depth (foreground/midground/background elements)
+  - Focus (what draws the eye, depth of field)
+  - Character staging (positions, poses, expressions)
+</panel_generation>
+
+---
+
+### Page Pacing Context
+
+<pacing_context>
+  Include a brief pacing analysis at the end:
+
+  ```markdown
+  ## Pacing Analysis
+
+  - **Page rhythm:** [fast/medium/slow -- based on panel count and sizes]
+  - **Visual beats:** [N action beats, N dialogue beats, N transition beats]
+  - **Previous page ended:** [description -- for flow continuity]
+  - **Next page should:** [suggested opening -- match or contrast current page energy]
+  - **Page turn reveal:** [Is this a left (verso) or right (recto) page? Right pages are reveals on page turn.]
+  ```
+</pacing_context>
+
+---
+
+### Output
+
+Create the output directory if needed:
+```bash
+mkdir -p .manuscript/illustrations/panels/
+```
+
+Save to `.manuscript/illustrations/panels/page-{number}-layout.md`
+
+Commit: `illustration: generate panel layout for page {number}`
+
+After saving, tell the writer:
+> Panel layout saved to `.manuscript/illustrations/panels/page-{number}-layout.md`.
+>
+> Layout uses [style] style with [N] panels and [gutter width] gutters.
+> Share with your artist or use as reference for panel composition.
+>
+> Adjacent pages: `/scr:panel-layout {prev}` | `/scr:panel-layout {next}`
+> Change panel count: `/scr:panel-layout {number} --panels 4`
+> Try a different style: `/scr:panel-layout {number} --style dynamic`
+
+---
+
+### Edge Cases
+
+- **Non-comic work type:** Hard stop per comic_only constraint in CONSTRAINTS.json
+- **Page not in outline:** "Page {number} is not in your outline. Your comic has {N} pages planned. Check `/scr:progress` for the outline structure."
+- **Splash page request (--panels 1):** Generate single full-page panel with detailed composition. Confirm: "Splash page -- this panel carries the full page weight. Make it count."
+- **9+ panels requested:** Warn about readability: "9 panels per page is the practical maximum. Beyond that, panels become too small for detail. Consider splitting across pages."
+- **No drafted content:** Generate layout from OUTLINE.md beats. Note reduced dialogue/balloon detail.
+- **ART-DIRECTION.md missing:** Generate layout without style notes. Suggest running art-direction first.
+- **Manga style:** Automatically switch reading order to right-to-left and adjust page dimensions to manga standard (5" x 7.5").
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.

package/commands/scr/pause-work.md

@@ -0,0 +1,88 @@
+---
+description: Pause your work session. Captures where you are and what you were thinking so you can pick up later.
+argument-hint: ""
+---
+
+# Pause Work
+
+You are helping the writer pause their session gracefully. Your job is to capture both the file state and the writer's mental state so resuming later is seamless.
+
+## What to do
+
+1. **Read STATE.md** for current position (unit, stage, progress).
+
+2. **Check for pre-existing uncommitted manuscript changes before mutating STATE.md.**
+   - Run `git status` for `.manuscript/` and remember whether there were already modified or untracked files.
+   - This check must happen before you update `STATE.md`, so the pause marker itself does not get mistaken for pre-existing unsaved writing work.
+
+3. **Ask the writer:** "Any notes for when you come back?" -- This captures their thinking, intentions, concerns. Wait for their response.
+
+4. **Handle the writer's response:**
+   - If the writer provides notes: store them in STATE.md "Session handoff" > "Resume context" along with the automated context.
+   - If the writer says nothing or declines: generate context automatically from STATE.md progress and last actions.
+
+5. **Update STATE.md "Session handoff" section and session boundary markers** with the current timestamp and combined context:
+   ```
+   **Last session ended:** {current timestamp, e.g., 2026-04-06 4:30 PM}
+   **Resume context:** {Automated: "Finished drafting chapter 3 (4 scenes, 1,247 words). Voice check passed. Was about to start discussing chapter 4."} {Writer's note: "I want chapter 4 to be shorter and more tense -- Marcus discovers the letter here."}
+   ```
+   Also append a row to the "Last actions" table with:
+   - Timestamp: current timestamp
+   - Command: `pause-work`
+   - Unit: current unit (or `--` if none)
+   - Outcome: `Paused session`
+   Keep this pause marker in the Last actions table because `/scr:session-report` and future resume logic use it as a session boundary.
+
+6. **Regenerate `.manuscript/CONTEXT.md`** using the `templates/CONTEXT.md` scaffold and the field set described in `/scr:save` step 7, with `{{LAST_COMMAND}}` set to `/scr:pause-work`. This is the file the next session reads first; refreshing it on pause means the writer (or a fresh AI session) returns to a current view without having to call `/scr:resume-work` to bootstrap.
+
+7. **Append one line to `.manuscript/HISTORY.log`** per `docs/history-protocol.md`:
+   ```
+   {ISO timestamp} | scr:pause-work | unit={current unit or --} | outcome=paused
+   ```
+   Create HISTORY.log if it does not exist.
+
+8. **Auto-save if there were pre-existing uncommitted changes.**
+   - Use the result from step 2, not a fresh post-update `git status` check.
+   - If the manuscript already had modified or untracked files before the pause-state update, run the `/scr:save` logic with the message "Saved before pausing" so both the writer's in-progress work and the pause metadata (CONTEXT.md and HISTORY.log included) are preserved together.
+   - Do not treat the pause-state update by itself as proof that the writer had unsaved manuscript work before pausing.
+
+9. **Tell the writer:** "Paused. When you're ready to come back, just run `/scr:resume-work`."
+
+## State capture
+
+When writing the Resume context, include all of the following that are available:
+
+- **Current unit and stage** -- e.g., "Working on chapter 4, planning stage"
+- **Last few actions** from the "Last actions" table -- what happened most recently
+- **Word count progress** -- total words written so far
+- **Pending flags** -- voice issues, continuity flags, open revisions, unresolved notes
+- **Writer's mental notes** -- the most important part. This is what makes resuming feel personal, not mechanical. Whatever the writer said when you asked for notes goes here verbatim.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.
+
+## Tone
+
+Warm, unhurried. "Take your time. Everything is saved. When you come back, I'll know exactly where we were."
+
+Do not rush the writer. Do not list technical details. Make them feel like they can walk away without worry.

package/commands/scr/plan.md

@@ -0,0 +1,112 @@
+---
+description: Research and plan the next unit. Produces a structured plan file the drafter agent uses.
+argument-hint: "[unit number, optional]"
+---
+
+# Plan {unit}
+
+You are in the **plan phase**. Your job is to turn the discuss-phase decisions into a concrete, actionable plan that the drafter agent can execute.
+
+## Adaptive naming
+
+Load `.manuscript/config.json` for `command_unit`. The runnable command stays `/scr:plan`; adapt the unit terminology in prompts and summaries.
+
+## Prerequisites
+
+Require `{N}-CONTEXT.md` to exist (from discuss phase). If it doesn't, offer to run `/scr:discuss N` first. If the writer says "skip discuss", use defaults from STYLE-GUIDE.md and a brief read of OUTLINE.md.
+
+## What to do
+
+0. **Bootstrap (context-cost protocol).** Read `.manuscript/CONTEXT.md` first if it exists. If its `Updated` timestamp is newer than `.manuscript/STATE.md` and newer than the newest file in `.manuscript/drafts/body/`, use it for orientation (project title, work type, current unit, recent activity, open items). The plan phase still needs the full creative inputs in step 1 (WORK.md, OUTLINE.md, RECORD.md, STYLE-GUIDE.md, characters, plot, themes, the discuss-phase context file, prior drafts) -- those are source material for the plan, not orientation. The bootstrap saves the redundant orientation reads. If CONTEXT.md is missing or stale, run step 1 unchanged. See `docs/context-protocol.md`.
+
+1. **Load Creative Context:** WORK.md, OUTLINE.md, RECORD.md, STYLE-GUIDE.md, CHARACTERS.md (or adapted), PLOT-GRAPH.md (or adapted), THEMES.md, {N}-CONTEXT.md, and any previously drafted units for continuity. If RECORD.md is missing in an older project, continue and add a non-blocking plan note to initialize it after drafting. If files include `creative_pillar` frontmatter, use it only as a routing hint. Existing projects without metadata are valid. STYLE-GUIDE.md remains sovereign for any voice decision.
+
+   From `{N}-CONTEXT.md`, extract `CHOICE`, `HUNCH`, `QUESTION`, and `WATCHPOINT` craft notes. Blocking questions must be resolved before drafting. Non-blocking questions can travel into the plan as watchpoints.
+   From RECORD.md, extract established facts, open threads, promises, payoffs, continuity facts, movement, and next-unit obligations that apply to this unit.
+   From REFERENCES.md, SYSTEM.md, PROCEDURES.md, DOCTRINES.md, QUESTIONS.md, WORLD.md, THEMES.md, CHARACTERS.md, FIGURES.md, or adapted equivalents, extract any canonical terminology, source-of-truth notes, operating rules, doctrine, world rules, subject definitions, character knowledge boundaries, or procedure constraints that apply to this unit.
+
+2. **Research (if enabled).** If the work type is academic, research the literature. If it's sacred, check canonical sources and traditional commentaries. If it's historical, verify period details. For fiction, research anything the writer flagged in {N}-CONTEXT.md (e.g., "I need to know how 18th century sailing worked").
+
+3. **Build the plan.** Structure depends on work type:
+   - **Prose/Script** -- Scene-by-scene breakdown. Each scene: POV, location, time, characters present, emotional arc start/end, beat list, voice notes, continuity anchors to previous units.
+   - **Academic** -- Argument structure. Each subsection: claim, evidence, citations to integrate, transition to next.
+   - **Sacred** -- Passage structure. For each section: voice register, register transitions, key concepts, cross-references to other passages, doctrinal framing, source traditions if historical.
+   - **Poetry** -- Stanza plan, meter/form, volta placement, image schedule, sound-pattern notes.
+
+   Each plan file must include a `## Craft Notes` section. Carry forward confirmed `CHOICE` items as plan constraints, turn `HUNCH` items into draftable tests, keep non-blocking `QUESTION` items visible, and list `WATCHPOINT` items the drafter and editor should preserve or check.
+
+   When named characters drive the unit, each plan file should also include `## Character Persona Notes`. Pull from CHARACTERS.md and `{N}-CONTEXT.md`:
+   - active characters and current state
+   - pressure behavior to dramatize
+   - relationship-specific interaction notes for the pairings in the scene
+   - dialogue constraints and speech shifts by relationship
+   - persona or relationship watchpoints for editor-review
+
+   When the unit carries an idea, subject, theme, object, setting, process, doctrine, argument, reader problem, or image pattern, each plan file should include `## Subject Dynamics Notes`. This can stand alone for non-character work or sit beside `## Character Persona Notes` in character-based scenes. Pull from BRIEF.md, WORK.md, THEMES.md or adapted equivalents, OUTLINE.md, PLOT-GRAPH.md or adapted equivalents, and `{N}-CONTEXT.md`:
+   - active subject, idea, claim, procedure, place, object, doctrine, image pattern, or reader problem
+   - reader state at the start and desired shift by the end
+   - pressure or friction to make clear
+   - interaction to preserve, such as claim vs. counterclaim, rule vs. exception, step vs. failure mode, doctrine vs. practice, evidence vs. objection, or image vs. meaning
+   - evidence, example, sequence, rhythm, structure, safety, or theme watchpoints for editor-review
+
+   Use this detection test before omitting subject dynamics: if the unit changes what the reader understands, feels, fears, believes, can do, can verify, or notices, add `## Subject Dynamics Notes`. A character scene can still need subject dynamics when a theme, object, place, doctrine, argument, or reader understanding shifts.
+
+   If both note sections appear, keep their jobs distinct: character notes govern behavior, speech, relationship posture, and state; subject dynamics govern meaning, theme movement, reader-state movement, object significance, setting pressure, evidence, procedure, doctrine, or argument. If the two sections conflict, revise the plan or mark a blocking question before drafting.
+
+   Each plan file should include `## Record Notes` when this unit touches established content. Use it to list:
+   - established RECORD.md items this unit must honor
+   - open threads or reader promises this unit handles
+   - expected new record entries after drafting
+   - facts, claims, objects, procedures, images, or relationship states that must remain stable
+
+   Each plan file should include `## Domain Model Notes` when domain grilling resolved a term, source-of-truth question, procedure boundary, doctrine boundary, world rule, character knowledge rule, or subject definition. Use it to list:
+   - canonical terms the drafter must use
+   - terms to avoid or distinguish
+   - source files or external sources the plan is relying on
+   - boundary scenarios that clarify what the term or rule does and does not cover
+   - any durable updates needed for RECORD.md, REFERENCES.md, or an adapted source file
+
+   Before writing the plan, compare all domain-sensitive language against the loaded source files. If the plan uses a term differently than the project does, revise it or mark a `QUESTION: Blocking` item before drafting. Do not leave a contradiction for the drafter to guess through.
+
+4. **Save as `.manuscript/plans/{N}-{A}-PLAN.md`** where {A} is the atomic unit (scene, subsection, passage, stanza). One plan file per atomic unit. The drafter will read each one in a fresh context to stay focused.
+
+   For older projects, if root-level `.manuscript/{N}-{A}-PLAN.md` files already exist, read them as legacy input, but write new and revised plans to `.manuscript/plans/`.
+
+5. **Run the plan check.** For each `{N}-{A}-PLAN.md` you just wrote, invoke the installed `plan-checker.md` agent for the writer's active Scriveno runtime (for example the runtime's global or project-scoped `agents/plan-checker.md`) in a fresh context. Pass the plan file plus WORK.md, OUTLINE.md, RECORD.md, the relevant arc file (PLOT-GRAPH.md or THEOLOGICAL-ARC.md), CHARACTERS.md (or FIGURES.md), STYLE-GUIDE.md, `{N}-CONTEXT.md`, REFERENCES.md, SYSTEM.md, PROCEDURES.md, DOCTRINES.md, QUESTIONS.md, WORLD.md, THEMES.md, or adapted equivalents when present, and any previously drafted units. The agent returns a PLAN CHECK report with status READY or NEEDS REVISION plus specific completeness, alignment, record, domain model, character, voice, pacing, and craft-note findings. Surface its recommendations to the writer before suggesting the draft step. If the agent flags NEEDS REVISION on any plan, hold the draft suggestion and offer to fix the flagged items first.
+
+6. **Write a short summary** for the writer: "Planned {unit} {N}: X {atomic_units}, main arc goes from Y to Z, voice notes applied from STYLE-GUIDE.md. Plan check: {READY | N items flagged}."
+
+7. **Update STATE.md** and suggest: "Ready to draft? Run `/scr:draft N`." (Suppress the draft suggestion if any plan came back NEEDS REVISION; suggest addressing the flagged items first.)
+
+8. **Append one line to `.manuscript/HISTORY.log`** per `docs/history-protocol.md`:
+   ```
+   {ISO timestamp} | scr:plan | unit={N} | atomic-units={count} | check={READY|N-flagged} | outcome=ok
+   ```
+   If the run failed, use `outcome=failed:<short-reason>` instead. Create HISTORY.log if it does not exist.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.
+
+## Tone
+
+Focused. This is craft work. Don't pad with commentary -- the writer wants to see a concrete plan fast.

package/commands/scr/plant-seed.md

@@ -0,0 +1,57 @@
+---
+description: Plant a creative seed -- an idea, image, or fragment for future use.
+argument-hint: "<idea>"
+---
+
+# Plant Seed
+
+You are capturing a creative seed -- a fragment of an idea that the writer wants to remember for later.
+
+## What to do
+
+1. Take the idea from the argument
+2. Auto-detect a category tag based on content:
+   - **character** -- mentions a person, name, trait, or backstory idea
+   - **scene** -- describes a moment, setting, or event
+   - **dialogue** -- contains speech, a line, or conversation idea
+   - **theme** -- abstract concept, message, or motif
+   - **world** -- setting detail, rule, place, or system
+   - **other** -- anything that doesn't fit the above
+3. Open `.manuscript/SEEDS.md` (create if it doesn't exist)
+4. If creating: add header `# Creative Seeds\n\nIdeas, fragments, and sparks for future use.\n\n`
+5. Append the seed:
+   ```
+   - [2026-04-07 14:30] [character] What if the detective's partner is secretly related to the victim?
+   ```
+6. Confirm: "Seed planted. [category]"
+
+## How seeds get used
+
+Seeds can be referenced during the discuss phase. When running `/scr:discuss`, check SEEDS.md for planted ideas that relate to the upcoming unit. Mention relevant seeds: "You planted a seed about X -- want to work it in here?"
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.
+
+## Tone
+
+Encouraging. Planting seeds is a creative act -- acknowledge it briefly and let the writer keep flowing.