scriveno 2.0.5

package/commands/scr/quick-write.md

@@ -0,0 +1,82 @@
+---
+description: Write a scene, passage, or chapter outside the full planning workflow.
+---
+
+# /scr:quick-write -- Ad-Hoc Writing Without Full Planning
+
+Write a scene, passage, or chapter outside the full planning workflow.
+
+## Usage
+```
+/scr:quick-write [--discuss] [--research] [--full]
+```
+
+**Flags:**
+- `--discuss` -- Brief discussion to capture creative direction first
+- `--research` -- Research craft techniques before drafting
+- `--full` -- Discussion + research + consistency check
+
+## Instruction
+
+Quick write gives you Scriveno guarantees (continuity tracking, voice consistency, atomic commits) with a faster path.
+
+### STEP 1: GATHER INTENT
+
+Ask: "What do you want to write?"
+
+Accept any of:
+- A specific scene ("The bar fight in chapter 12")
+- A character moment ("Marcus confronting his father")
+- An exploratory passage ("What it feels like when the magic fails")
+- A dialogue exchange ("The negotiation between Eva and the detective")
+- A transitional passage ("Getting from the apartment to the airport")
+
+### STEP 2: QUICK CONTEXT
+
+Load relevant files based on characters/settings mentioned:
+- `STYLE-GUIDE.md` (always)
+- `CHARACTERS.md` (relevant entries)
+- `WORLD.md` (relevant sections)
+- Previous relevant drafts (for continuity)
+
+If `--discuss`: Ask 3-5 targeted questions about tone, pacing, and purpose for this passage.
+
+If `--research`: Spawn a focused researcher for technique guidance.
+
+### STEP 3: DRAFT
+
+Write the passage following all established style guide constraints. Target whatever length feels natural unless the writer specified a target.
+
+### STEP 4: VERIFY (if --full)
+
+Run continuity and voice checks against existing manuscript.
+
+### OUTPUT
+
+Save to `.manuscript/quick/{NNN}-{slug}/DRAFT.md`
+Save plan (if generated) to `.manuscript/quick/{NNN}-{slug}/PLAN.md`
+
+Commit: `quick: {slug}`
+
+## 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/relationship-map.md

@@ -0,0 +1,129 @@
+---
+description: Generate an ASCII relationship graph between characters.
+argument-hint: "[--edit]"
+---
+
+# /scr:relationship-map -- Character Relationship Graph
+
+Generate an ASCII relationship graph showing connections between all characters.
+
+## Usage
+```
+/scr:relationship-map [--edit]
+```
+
+## Instruction
+
+You are generating a relationship map. Load:
+- `.manuscript/config.json` (to get `work_type`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to check `file_adaptations`, `commands.relationship-map.adapted`, and `feature_prerequisites`)
+- The adapted characters file (CHARACTERS.md / FIGURES.md per `file_adaptations`)
+
+**Prerequisites check** (from CONSTRAINTS.json `feature_prerequisites`):
+- The characters file must exist
+- At least 2 characters must be defined
+- If fewer than 2: "Relationship map requires at least 2 characters. You have {N}. Run `/scr:new-character <name>` to add more."
+
+Determine adapted terminology:
+- Default: "relationship map"
+- Sacred: "lineage map" (renamed via CONSTRAINTS.json); reads FIGURES.md and LINEAGES.md
+
+---
+
+### DISPLAY MODE (default)
+
+<relationship_map_display>
+  Parse the "Key Relationships" and "Relationship-Specific Interactions" sections from each character entry in the characters file.
+
+  Render an ASCII graph with labeled edges (D-02):
+
+  ```
+  Elias ----[father]----> Petra
+    |                       |
+  [husband]             [daughter]
+    |                       |
+  Maren                   Lena
+  (deceased)
+  ```
+
+  **Layout rules:**
+  - Keep edge labels short (max 15 characters) -- truncate with ellipsis if needed
+  - Truncate character names longer than 12 characters
+  - Use directional arrows for asymmetric relationships: `--[label]-->`
+  - Use undirected edges for mutual relationships: `--[label]--`
+  - Handle 2-10 characters gracefully; for more than 10, group by relationship clusters
+  - Indicate character status after name: `(deceased)`, `(mentioned)`, `(absent)`
+  - Place protagonists centrally in the layout
+
+  **Relationship types to extract:**
+  - Family: parent, child, sibling, spouse, cousin
+  - Romantic: partner, ex-partner, love interest
+  - Social: friend, rival, mentor, student, ally, enemy
+  - Professional: employer, colleague, subordinate
+  - Story-specific: foil, mirror, catalyst
+
+  After the graph, show a legend:
+  ```
+  ----> : directional relationship
+  ----- : mutual relationship
+  (deceased) : character is deceased
+  ```
+
+  After the legend, list any relationships mentioned in text but not visualized (if graph became too complex).
+
+  Then show a compact "Interaction notes" table for each important pairing:
+  ```
+  Pair | Trust posture | Conflict pattern | Speech shift | Hidden agenda/fear
+  Mara/Elias | guarded | deflects accusation | Mara gets terse | forged letter exposure
+  ```
+</relationship_map_display>
+
+---
+
+### EDIT MODE (--edit)
+
+<relationship_map_edit>
+  Show the current relationship graph, then offer:
+  1. **Add relationship:** Between two characters (name a type and direction)
+  2. **Change relationship:** Modify the label or direction of an existing edge
+  3. **Remove relationship:** Delete a connection
+  4. **Add character note:** Mark a character's status (active, deceased, mentioned)
+  5. **Edit interaction dynamic:** Update trust posture, conflict pattern, speech shift, or hidden agenda/fear for a specific pair
+
+  After edits, update the "Key Relationships" section in each affected character's entry in the characters file.
+  If interaction dynamics changed, also update the "Relationship-Specific Interactions" section for the affected character entries.
+
+  Commit: `character: update relationship map`
+</relationship_map_edit>
+
+---
+
+### Edge Cases
+
+- **Only 2 characters:** Show a simple single-edge graph
+- **No relationships defined:** Show characters as isolated nodes and suggest defining relationships
+- **Circular relationships:** Handle gracefully (A -> B -> C -> A)
+- **Sacred work type:** Use "lineage map" terminology; relationship types include "teacher-disciple", "prophetic succession", "covenant"
+
+## 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/remove-unit.md

@@ -0,0 +1,120 @@
+---
+description: Remove a unit from the outline with draft safety checks.
+argument-hint: "[unit-id]"
+---
+
+# /scr:remove-unit -- Remove Unit
+
+Remove a structural unit from the outline with comprehensive draft safety checks.
+
+## Usage
+```
+/scr:remove-unit [unit-id]
+```
+
+## Instruction
+
+You are a structure management assistant. Load:
+- `.manuscript/config.json` (to get `work_type`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to find `work_types[work_type].hierarchy` and determine unit terminology)
+- `.manuscript/OUTLINE.md` (current structural outline)
+- `.manuscript/STATE.md` (progress tracking)
+
+**Work-type adaptation:** Determine the correct unit name from CONSTRAINTS.json hierarchy:
+- Novel: "chapter" (hierarchy.mid)
+- Screenplay: "scene" (hierarchy.atomic) or "act" (hierarchy.top)
+- Short story: "section" (hierarchy.mid)
+- Scripture (Biblical): "chapter" (hierarchy.mid)
+- Use `command_unit` from CONSTRAINTS.json as the default unit level
+
+Use the adapted unit terminology throughout all output and prompts.
+
+---
+
+### REMOVE UNIT FLOW
+
+<remove_unit>
+1. **Resolve unit type** from CONSTRAINTS.json `work_types[work_type].hierarchy`
+   - Use `command_unit` to determine which level of the hierarchy this command operates on
+
+2. **Validate unit-id:**
+   - Parse OUTLINE.md and locate the specified unit
+   - If the unit-id does not exist, show available units and ask for correction
+
+3. **CRITICAL: Draft safety check** (D-07):
+   - Scan `.manuscript/drafts/body/` for a draft file matching this unit
+   - **If a draft file exists:**
+     - Show the word count of the draft
+     - Show the first 3 lines of the draft content
+     - Display a prominent warning:
+
+       **WARNING: This [chapter/scene/etc.] has drafted content.**
+
+       File: `.manuscript/drafts/body/[filename]`
+       Word count: [N] words
+       Preview:
+       > [first 3 lines]
+
+       **Options:**
+       1. **Archive** (recommended): Move to `.manuscript/archive/` -- content is preserved but removed from active outline
+       2. **Delete permanently**: Remove the draft file entirely -- THIS CANNOT BE UNDONE
+       3. **Cancel**: Abort the removal
+
+     - Require the writer to choose explicitly. Default to archive if ambiguous.
+   - **If no draft exists:** Proceed with a simple confirmation:
+     "Remove [unit_type] [N]: '[title]' from the outline? (yes/no)"
+
+4. **Execute removal:**
+   - Remove the unit entry from OUTLINE.md
+   - Renumber all subsequent units
+   - If archived: move draft file to `.manuscript/archive/` with original name preserved
+   - If deleted: remove the draft file
+   - Rename subsequent draft files in `.manuscript/drafts/body/` to match new numbering
+
+5. **Update related files:**
+   - Update `.manuscript/STATE.md` to remove the unit and adjust progress
+   - Update PLOT-GRAPH.md (or adapted equivalent) if arc positions reference the removed unit
+   - Update any cross-references in OUTLINE.md
+
+6. **Confirm result:**
+   - Show the updated outline structure
+   - If archived: confirm the archive location
+   - Show the renumbered units
+</remove_unit>
+
+Commit: `structure: remove {unit_type} {N} "{title}"`
+
+## Edge Cases
+
+- **Last remaining unit:** Warn that removing it will leave the outline empty. Suggest keeping at least one unit.
+- **Unit referenced by PLOT-GRAPH.md:** Warn that removing this unit will leave a gap in the arc. Suggest reassigning the arc position.
+- **No OUTLINE.md:** Prompt to run `/scr:plan` first.
+- **Invalid unit-id:** Show numbered list of current units for selection.
+- **Archive directory doesn't exist:** Create `.manuscript/archive/` automatically.
+
+## 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
+
+Cautious and protective. Removing content is a significant action. Be thorough in warnings without being patronizing. The writer's prose is valuable -- treat it that way.

package/commands/scr/reorder-units.md

@@ -0,0 +1,126 @@
+---
+description: Reorder units in the outline by moving a unit to a new position.
+argument-hint: "[unit-id] [new-position]"
+---
+
+# /scr:reorder-units -- Reorder Outline Units
+
+Move a structural unit from its current position to a new position, renumbering all affected units.
+
+## Usage
+```
+/scr:reorder-units [unit-id] [new-position]
+```
+
+## Instruction
+
+You are a structure management assistant. Load:
+- `.manuscript/config.json` (to get `work_type`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to find `work_types[work_type].hierarchy` and determine unit terminology)
+- `.manuscript/OUTLINE.md` (current structural outline)
+- `.manuscript/STATE.md` (progress tracking)
+
+**Work-type adaptation:** Determine the correct unit name from CONSTRAINTS.json hierarchy:
+- Novel: "chapter" (hierarchy.mid)
+- Screenplay: "scene" (hierarchy.atomic) or "act" (hierarchy.top)
+- Short story: "section" (hierarchy.mid)
+- Scripture (Biblical): "chapter" (hierarchy.mid)
+- Use `command_unit` from CONSTRAINTS.json as the default unit level
+
+Use the adapted unit terminology throughout all output and prompts.
+
+---
+
+### REORDER UNITS FLOW
+
+<reorder_units>
+1. **Resolve unit type** from CONSTRAINTS.json `work_types[work_type].hierarchy`
+   - Use `command_unit` to determine which level this command operates on
+
+2. **Validate inputs:**
+   - Parse OUTLINE.md and locate the specified unit
+   - Verify the new position is valid (1 to total_units)
+   - If the unit is already at the requested position, inform the writer: "That [unit_type] is already at position [N]."
+
+3. **Draft safety check** (D-07):
+   - Scan `.manuscript/drafts/body/` for ALL draft files (not just the moved unit)
+   - Identify every draft file that will need to be renamed due to the reorder
+   - **If any drafted units are affected:**
+     - Show the complete renaming plan:
+
+       **Reordering will rename the following draft files:**
+
+       | Current | New | Title |
+       |---------|-----|-------|
+       | `03-the-chase-DRAFT.md` | `05-the-chase-DRAFT.md` | The Chase |
+       | `04-revelations-DRAFT.md` | `03-revelations-DRAFT.md` | Revelations |
+       | ... | ... | ... |
+
+     - Warn: "All draft file contents will be preserved. Only the file numbering will change."
+     - Require confirmation before proceeding
+
+   - **Show before/after comparison:**
+     ```
+     BEFORE:                    AFTER:
+     1. The Beginning           1. The Beginning
+     2. Rising Tension          2. The Chase        <-- moved from 3
+     3. The Chase       -->     3. Rising Tension    <-- was 2
+     4. Revelations             4. Revelations
+     ```
+
+4. **Execute reorder:**
+   - Remove the unit from its current position in OUTLINE.md
+   - Insert it at the new position
+   - Renumber all affected units
+   - Rename all affected draft files in `.manuscript/drafts/body/` to match new numbering
+     (use a temporary naming scheme to avoid conflicts: rename to `.tmp` first, then to final names)
+
+5. **Update related files:**
+   - Update `.manuscript/STATE.md` to reflect the new ordering
+   - Update PLOT-GRAPH.md (or adapted equivalent):
+     - If arc positions reference unit numbers, update them to new numbers
+     - Show which arc positions changed
+   - Update any cross-references in OUTLINE.md
+
+6. **Show result:**
+   - Display the full updated outline in new order
+   - Highlight the moved unit and any affected arc positions
+   - If PLOT-GRAPH.md was updated, show the arc position changes
+</reorder_units>
+
+Commit: `structure: reorder {unit_type} {old_position} to position {new_position}`
+
+## Edge Cases
+
+- **Moving to same position:** Inform the writer, no changes needed.
+- **Only 1 unit:** Nothing to reorder -- inform the writer.
+- **No OUTLINE.md:** Prompt to run `/scr:plan` first.
+- **Many draft files to rename:** Use temporary file names during rename to avoid naming collisions.
+- **Unit referenced in subplot-map or timeline:** Warn that cross-references in other files may also need updating.
+
+## 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
+
+Precise and visual. Reordering is a significant structural decision. The before/after comparison helps the writer see exactly what will change before committing.

package/commands/scr/resume-work.md

@@ -0,0 +1,97 @@
+---
+description: Pick up where you left off. Reads your last session and tells you what's next.
+argument-hint: ""
+---
+
+# Resume Work
+
+You are welcoming the writer back and orienting them. Your job is to read the session state and produce one concise, contextual paragraph about where they left off.
+
+## What to do
+
+0. **Read `.manuscript/CONTEXT.md` first if it exists.** This is the auto-regenerated one-page bootstrap. Use it as the primary source for orientation -- it already summarizes recent activity, open items, and the suggested next step that the rest of this command would otherwise re-derive from raw STATE.md fields. If CONTEXT.md is present and its `Updated` timestamp is newer than STATE.md, skip steps 1 through 3 (you already have the synthesis) and go to step 4. If CONTEXT.md is missing, stale, or contradicts STATE.md, treat STATE.md as authoritative and continue with steps 1 through 3 (you will regenerate CONTEXT.md in step 6).
+
+1. **Read STATE.md "Session handoff" section** for:
+   - Last session end time
+   - Resume context (automated context + writer's notes)
+
+2. **Read STATE.md "Progress" section** for:
+   - Overall progress metrics (units total, discussed, planned, drafted, reviewed, submitted, word count)
+
+3. **Read STATE.md "Pending" section** for:
+   - Next step
+   - Open revisions
+   - Unresolved notes
+   - Voice-check issues
+   - Continuity flags
+
+4. **Record the new session boundary in STATE.md before responding.**
+   - Set `## Session metrics` -> `Current session started` to the current timestamp.
+   - Reset the per-session summary placeholders so this session starts fresh:
+     - `Units this session: 0`
+     - `Words this session: 0`
+     - `Quality passes: none yet`
+   - Append a row to the "Last actions" table with:
+     - Timestamp: current timestamp
+     - Command: `resume-work`
+     - Unit: current unit (or `--` if none)
+     - Outcome: `Resumed session`
+   `/scr:session-report` depends on these markers to separate the current session from older work, so always write them here.
+
+5. **Generate ONE paragraph** that covers three parts:
+   - **(a) What was done:** Summarize last session's accomplishments. Use concrete numbers -- words, units, quality passes.
+   - **(b) What was in progress + writer's notes:** Where they were when they stopped. Include the writer's own notes verbatim if they left any -- this is what makes it feel personal.
+   - **(c) Suggestion for next step:** Based on pending items and progress, suggest the logical next command.
+
+   Example:
+   > Last time you drafted chapter 3 (1,247 words across 4 scenes, voice check passed). You were working on chapter 4 -- you noted you wanted it shorter and more tense, with Marcus discovering the letter. I'd suggest starting with /scr:discuss 4 to shape the plan.
+
+6. **Regenerate `.manuscript/CONTEXT.md`** using the `templates/CONTEXT.md` scaffold and the same field set described in `/scr:save` step 7, with `{{LAST_COMMAND}}` set to `/scr:resume-work`. This refreshes the bootstrap file so the next session opens to a current view -- the act of resuming is itself a state event worth recording.
+
+7. **Append one line to `.manuscript/HISTORY.log`** per `docs/history-protocol.md`:
+   ```
+   {ISO timestamp} | scr:resume-work | unit={current unit or --} | outcome=resumed
+   ```
+   Create HISTORY.log if it does not exist.
+
+## Output format
+
+- **ONE paragraph**, not a bulleted list or table.
+- Include the writer's own notes if they left any (this is what makes it feel personal).
+- Suggest the logical next command.
+- End with: "Ready to continue? Run `/scr:next` or tell me what you'd like to do."
+
+## Edge cases
+
+- **No previous session:** If the Session handoff section is empty or has only template placeholders, say: "This looks like a fresh start. Run `/scr:next` to get going."
+
+- **Session handoff section empty but progress exists:** Generate context from the Progress and Last actions tables instead. Synthesize what you can from available data.
+
+- **Very old session (>7 days):** If the last session ended more than 7 days ago, acknowledge the gap: "It's been a while since your last session ([date]). Here's where things stand: ..."
+
+## 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 but efficient. The writer wants to get back to work -- orient them quickly, don't belabor the recap. One paragraph, then let them go.

package/commands/scr/sacred/annotation-layer.md

@@ -0,0 +1,105 @@
+---
+description: Add or manage a commentary/exegetical layer alongside the primary sacred text. Support multiple annotation traditions simultaneously.
+argument-hint: "[tradition_name] [--list] [--remove <tradition>]"
+---
+
+# Annotation layer
+
+You manage annotation layers -- commentary or exegetical notes attached to the primary text without altering it. Multiple annotation traditions can coexist (e.g., Catholic + Reformed + Orthodox annotations on the same Bible text, or Sunni + Shia annotations on the same Quran text).
+
+## Availability
+
+Sacred work types only. Requires at least one drafted unit.
+
+## What to do
+
+### No arguments (or tradition name)
+
+If a tradition name is passed, work within that tradition. If not, ask which tradition to annotate in. If this is the first annotation layer, the writer chooses a name (e.g., "catholic_tradition", "reformed_tradition", "critical_scholarship", "devotional_notes").
+
+Annotation layers live in `.manuscript/annotations/{tradition}/`. Each file corresponds to a primary draft file:
+
+```
+.manuscript/
+├── 1-1-DRAFT.md                        (primary text)
+├── annotations/
+│   ├── catholic_tradition/
+│   │   ├── 1-1-ANNOTATIONS.md          (Catholic commentary on 1-1)
+│   │   └── 1-2-ANNOTATIONS.md
+│   ├── reformed_tradition/
+│   │   ├── 1-1-ANNOTATIONS.md          (Reformed commentary on 1-1)
+│   │   └── 1-2-ANNOTATIONS.md
+│   └── critical_scholarship/
+│       └── 1-1-ANNOTATIONS.md          (Historical-critical notes)
+```
+
+For each verse/passage, produce annotations of:
+- **Interpretation** -- How this tradition reads this passage
+- **Theological significance** -- What doctrines this passage supports or shapes
+- **Historical/philological notes** -- Text-critical issues, original language nuances
+- **Cross-references** -- What other passages this tradition reads alongside this one
+- **Contested points** -- Where this tradition diverges from others
+
+### --list
+
+Show all annotation traditions currently in the project with annotation counts:
+
+```
+Annotation traditions:
+- catholic_tradition: 142 verses annotated
+- reformed_tradition: 89 verses annotated
+- critical_scholarship: 201 verses annotated (some differ from above)
+- devotional_notes: 45 verses annotated
+```
+
+### --remove <tradition>
+
+Remove an annotation layer entirely. Ask for confirmation -- this is destructive. Offer to archive instead.
+
+## Integration with export
+
+When exporting, the writer can choose which annotation layers to include:
+
+- **Clean text only** -- primary text, no annotations
+- **Single tradition** -- primary text with one annotation layer
+- **Comparative** -- primary text with multiple annotation layers side-by-side or as footnotes
+- **Full scholarly** -- every annotation layer + critical apparatus
+
+The `/scr:publish` wizard asks about annotation inclusion when building the publishing pipeline.
+
+## Integration with the drafter
+
+When drafting annotations, the drafter agent loads:
+- The primary text passage being annotated
+- The tradition's characteristic interpretive approach (from FRAMEWORK.md)
+- Any other annotations on the same passage in the same tradition (for consistency)
+- DOCTRINES.md entries relevant to this passage
+
+Annotations should sound like the tradition they represent. Catholic annotations should sound like Catholic scholarship; Reformed should sound like Reformed; critical should sound like critical.
+
+## 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
+
+Scholarly when annotating academic traditions, devotional when annotating devotional traditions, pastoral when annotating pastoral traditions. Match the voice to the annotation tradition, not to the primary text's voice.