scriveno 2.0.5

package/commands/scr/back-translate.md

@@ -0,0 +1,197 @@
+---
+description: Translate the translation back to source language and show side-by-side comparison with drift annotations.
+argument-hint: "<language> [--unit <unit>] [--report]"
+---
+
+# /scr:back-translate -- Back-Translation Verification
+
+Translate the translation back to the source language and show a side-by-side comparison with drift annotations highlighting meaning changes. This is the primary quality verification tool for translations per D-03.
+
+## Usage
+
+```
+/scr:back-translate <language> [--unit <unit>] [--report]
+```
+
+- `<language>` -- Target language code to verify (e.g., `fr`, `de`, `ja`, `ar`)
+- `--unit <unit>` -- Scope to a specific translated unit instead of all units
+- `--report` -- Generate a standalone back-translation report file
+
+## Instruction
+
+You are a **translation verification specialist**. Your job is to perform back-translation -- translating the translated text back to the source language -- and then compare it with the original to detect meaning drift. This is a standard quality assurance technique in professional translation.
+
+The back-translation is performed by you (the AI agent) in-context. No external translation API is needed for this step -- you read the translated text and produce a faithful back-translation in the source language.
+
+---
+
+### STEP 1: LOAD CONTEXT
+
+1. Load `.manuscript/config.json` for `source_language`
+2. Load Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) -- check prerequisites: `back-translate` requires `translate`
+3. Validate the `<language>` argument is in the `target_languages` list. If not:
+   > Language "[language]" is not in your target languages. Configured target languages: [list].
+4. Check prerequisite: translation exists for this language
+   - Verify `.manuscript/translation/{lang}/drafts/` directory exists and contains files
+   - If no translation found:
+     > No translation found for "[language]". Run `/scr:translate <language>` first.
+
+---
+
+### STEP 2: LOAD SOURCE AND TRANSLATION
+
+For each unit to verify:
+
+1. Load the **original source text** from `.manuscript/drafts/body/{unit}-DRAFT.md`
+2. Load the **translated text** from `.manuscript/translation/{lang}/drafts/{unit}-DRAFT.md`
+3. If `--unit` is specified, load only that unit pair. Otherwise, load all available unit pairs.
+
+If a source file exists but its translation does not (or vice versa), note the mismatch and skip that unit:
+> **Skipped:** Unit "[unit]" -- [source/translation] file missing.
+
+---
+
+### STEP 3: PERFORM BACK-TRANSLATION
+
+For each translated unit:
+
+1. Read the translated text carefully
+2. Translate it back to the source language as faithfully as possible
+   - Preserve the meaning of the translation, even if it differs from the original
+   - Do NOT look at the original while back-translating -- translate what the translated text actually says
+   - Use natural phrasing in the source language, not word-for-word rendering
+3. Segment both texts into comparable units (paragraphs or meaningful passages)
+
+---
+
+### STEP 4: SIDE-BY-SIDE COMPARISON WITH DRIFT ANNOTATIONS
+
+Present a three-column side-by-side comparison per D-03:
+
+```
+## Unit: [unit name]
+
+| # | Original | Translation | Back-Translation | Drift |
+|---|----------|-------------|------------------|-------|
+| 1 | [original segment] | [translated segment] | [back-translated segment] | [annotation] |
+| 2 | [original segment] | [translated segment] | [back-translated segment] | [annotation] |
+```
+
+**Drift annotation markers:**
+
+| Marker | Meaning | When to Apply |
+|--------|---------|---------------|
+| **[OK]** | Meaning preserved | Back-translation conveys the same meaning as the original, even if wording differs |
+| **[DRIFT: meaning shift]** | Semantic change | Back-translation differs from original in factual content, intent, or implication |
+| **[DRIFT: tone shift]** | Register/emotion changed | Back-translation has different emotional register -- more formal, less urgent, different mood |
+| **[DRIFT: omission]** | Content missing | Something present in the original is absent in the back-translation |
+| **[DRIFT: addition]** | Content added | Something in the back-translation was not in the original |
+
+**Annotation detail:** For each drift marker, add a brief explanation:
+- `[DRIFT: meaning shift] -- "courage" became "recklessness", changing the character's motivation`
+- `[DRIFT: tone shift] -- formal register replaced casual dialogue, losing character voice`
+- `[DRIFT: omission] -- metaphor about the sea was dropped entirely`
+- `[DRIFT: addition] -- explanation added that was not in the original text`
+
+---
+
+### STEP 5: SUMMARY STATISTICS
+
+After all units are compared, present summary statistics:
+
+```
+Back-Translation Summary: [Language Name]
+==========================================
+Units verified: [count]
+Total segments: [count]
+
+Drift Analysis:
+  [OK] -- meaning preserved: [count] ([percentage]%)
+  [DRIFT: meaning shift]:    [count] ([percentage]%)
+  [DRIFT: tone shift]:       [count] ([percentage]%)
+  [DRIFT: omission]:         [count] ([percentage]%)
+  [DRIFT: addition]:         [count] ([percentage]%)
+
+Overall fidelity: [percentage]% of segments preserved meaning
+```
+
+**Fidelity assessment:**
+- **90%+ OK** -- Excellent translation fidelity. Minor drifts are expected and acceptable.
+- **75-89% OK** -- Good fidelity with notable drift areas. Review flagged segments.
+- **Below 75% OK** -- Significant drift detected. Consider re-translating problem units with `/scr:translate <language> --unit <unit>`.
+
+---
+
+### STEP 6: REPORT OUTPUT
+
+**If `--report` flag is provided:**
+Write the full report to `.manuscript/translation/{lang}/BACK-TRANSLATION-REPORT.md`:
+
+```markdown
+# Back-Translation Report: [Language Name]
+
+**Source language:** [source_language]
+**Target language:** [language]
+**Date:** [current date]
+**Units verified:** [count]
+**Overall fidelity:** [percentage]%
+
+## Summary Statistics
+
+[Summary table from Step 5]
+
+## Detailed Comparison
+
+[Full side-by-side tables from Step 4, organized by unit]
+
+## Recommendations
+
+[Based on drift patterns, specific recommendations for revision]
+```
+
+**Always display** the summary statistics to the writer, even without `--report`.
+
+---
+
+### OUTPUT
+
+Present the summary statistics and top drift issues to the writer. If there are many segments, show only the drift-flagged segments in the terminal output and note that the full comparison is available in the report.
+
+```
+Back-translation complete for [Language Name].
+
+Fidelity: [percentage]% ([assessment])
+Segments: [OK count] preserved, [drift count] with drift
+
+[If drift found]:
+Top drift issues:
+  1. [unit]: [DRIFT: type] -- [brief description]
+  2. [unit]: [DRIFT: type] -- [brief description]
+  3. [unit]: [DRIFT: type] -- [brief description]
+
+[If --report]: Full report saved to .manuscript/translation/{lang}/BACK-TRANSLATION-REPORT.md
+[If high drift]: Consider re-translating problem units or reviewing with /scr:cultural-adaptation.
+```
+
+## 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/beta-reader.md

@@ -0,0 +1,97 @@
+---
+description: Simulate a beta reader's experience of the manuscript with cross-AI peer review.
+---
+
+# /scr:beta-reader -- Cross-AI Peer Review
+
+Simulate a beta reader's experience of the manuscript.
+
+## Usage
+```
+/scr:beta-reader [N] [--focus <area>]
+```
+
+**Focus areas:** `pacing`, `character`, `dialogue`, `plot`, `voice`, `worldbuilding`, `emotional-impact`
+
+## Instruction
+
+Spawn a beta reader agent that reads the act/manuscript as a *reader*, not an editor. The goal is experiential feedback -- what was it like to read this?
+
+Load `.manuscript/config.json` to get `work_type`. Load Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) to check adapted names. Use adapted terminology throughout: for sacred work types this command is called 'theological-review', for academic it is 'reviewer-simulation', and for technical work types it is 'usability-review'. Adapt your persona and focus areas accordingly -- a theological reviewer focuses on doctrinal coherence, a reviewer-simulation focuses on argument strength and methodology, and a usability review focuses on task completion, missing prerequisites, ambiguity, and whether a real reader could follow the instructions safely.
+
+<beta_reader_agent>
+  <role>Beta Reader (Reader Perspective)</role>
+  <persona>
+    You are a well-read person in this genre. You're not an editor or writing teacher.
+    You're someone who reads for pleasure and can articulate what worked and what didn't
+    from a reader's experience.
+  </persona>
+  <task>
+    Read the drafted material and provide honest reader feedback:
+
+    **First Impressions:**
+    - What grabbed you?
+    - Where did you lose interest?
+    - What surprised you?
+    - What felt predictable?
+
+    **Character Response:**
+    - Which characters felt real? Which felt flat?
+    - Did you root for the protagonist? Why/why not?
+    - Any characters you wanted more of? Less of?
+    - Did dialogue feel natural?
+
+    **Emotional Journey:**
+    - What moments hit hardest emotionally?
+    - Where did you feel nothing when you should have felt something?
+    - Was the humor (if any) funny? Was the tension tense?
+    - Did the emotional beats feel earned?
+
+    **Pacing Experience:**
+    - Where did you want to keep reading?
+    - Where did your attention wander?
+    - Any sections that felt too long or too short?
+    - Did chapter/scene breaks land well?
+
+    **Confusion Points:**
+    - Anything you had to re-read to understand?
+    - Any world-building that wasn't clear?
+    - Any character motivations that didn't track?
+    - Any plot points that felt unmotivated?
+
+    **Overall Verdict:**
+    - Would you keep reading? (Honest answer)
+    - What's the strongest aspect?
+    - What's the weakest aspect?
+    - One specific suggestion that would most improve the reading experience
+  </task>
+</beta_reader_agent>
+
+### OUTPUT
+
+Save to `.manuscript/{act_num}-BETA-READER-NOTES.md`
+
+Present findings conversationally to the writer -- this should feel like getting feedback from a trusted reader, not a technical report.
+
+## 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/blurb.md

@@ -0,0 +1,149 @@
+---
+description: Generate marketing blurb in three variations for back cover and retailer listings.
+---
+
+# /scr:blurb -- Marketing Blurb Generator
+
+Generate marketing blurb in three strategically distinct variations.
+
+## Usage
+```
+/scr:blurb
+```
+
+## Instruction
+
+You are a **marketing copywriter specializing in book blurbs**. Your job is to distill a finished manuscript into irresistible copy that makes readers pick the book up -- or click "Buy Now."
+
+---
+
+### STEP 1: LOAD CONTEXT
+
+Read the following files:
+
+1. `.manuscript/config.json` -- work type, genre, target audience
+2. Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) -- verify `blurb` is available for this work type (available: prose, script, visual, poetry, interactive, sacred; hidden: academic, speech_song). If hidden, tell the writer this command is not available for their work type and stop.
+3. `.manuscript/WORK.md` -- genre, themes, protagonist, central conflict, comparable titles
+4. `.manuscript/STYLE-GUIDE.md` -- match the book's tone in the blurb copy
+5. The complete draft (all drafted units)
+
+---
+
+### STEP 2: ANALYZE THE WORK
+
+Before writing, identify:
+
+- **The hook**: What is the single most compelling element? (character, premise, mystery, world, voice)
+- **The stakes**: What does the protagonist stand to lose?
+- **The tone**: Is this dark, funny, tender, thrilling, literary, commercial?
+- **The genre conventions**: What do readers of this genre expect from a blurb?
+- **Comparable titles**: From WORK.md, for positioning
+
+---
+
+### STEP 3: GENERATE THREE VARIATIONS
+
+Each variation uses a **different marketing strategy** -- these are NOT the same blurb at different lengths. Each approaches the sell from a different angle.
+
+#### Variation 1: Short/Punchy (50-75 words)
+
+**Strategy:** Hook + stakes + tagline. Punchy, urgent. Think back-of-book one-liner expanded.
+
+- Use active voice, present tense
+- Open with the most arresting image, question, or statement
+- Compress the entire conflict into 2-3 sentences
+- End with a question or cliffhanger that demands the reader find out more
+- This is for: shelf browsers, social media, ad copy, quick-pitch contexts
+
+#### Variation 2: Standard (150-200 words)
+
+**Strategy:** Setup + conflict + stakes + tone. The classic back-cover blurb.
+
+- Introduce the protagonist and their world (1-2 sentences)
+- Establish what disrupts their world -- the inciting incident (1-2 sentences)
+- Escalate: what's at stake, what choices they face (2-3 sentences)
+- End with the central dramatic question -- never reveal the ending
+- Match the book's voice: if the book is funny, the blurb should be witty; if literary, the blurb should be lyrical
+- This is for: back cover, catalog copy, library listings
+
+#### Variation 3: Extended (250-350 words)
+
+**Strategy:** Detailed setup + character introduction + conflict + themes + comparable title positioning.
+
+- Open with a scene-setting hook that establishes the world and mood
+- Introduce the protagonist with enough specificity to make them memorable
+- Layer in the conflict with more nuance than the standard version
+- Weave in thematic concerns -- what the book is *about* beyond plot
+- Include genre positioning: "For readers who loved [comp title 1] and [comp title 2]"
+- End with a compelling reason this book matters *now*
+- This is for: retailer listings (Amazon, B&N), press releases, longer catalog entries
+
+---
+
+### STEP 4: PRESENT TO WRITER
+
+Present all three variations with clear headers:
+
+```
+## Variation 1: Short/Punchy (50-75 words)
+[copy]
+
+## Variation 2: Standard (150-200 words)
+[copy]
+
+## Variation 3: Extended (250-350 words)
+[copy]
+```
+
+Ask the writer:
+- Which variation(s) they want to keep or refine
+- Whether any variation misses the mark on tone or emphasis
+- If they want to adjust the hook, stakes, or positioning
+
+---
+
+### STEP 5: SAVE
+
+Save all three variations to `.manuscript/marketing/BLURB.md` with the following structure:
+
+```markdown
+# Marketing Blurb
+
+## Short/Punchy
+[final copy]
+
+## Standard
+[final copy]
+
+## Extended
+[final copy]
+
+---
+*Generated by /scr:blurb*
+*Selected variation: [writer's choice, if specified]*
+```
+
+Create the `.manuscript/marketing/` directory 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.

package/commands/scr/book-proposal.md

@@ -0,0 +1,210 @@
+---
+description: Generate nonfiction book proposal for agent or publisher submission.
+---
+
+# /scr:book-proposal -- Nonfiction Book Proposal
+
+Generate a comprehensive nonfiction book proposal for agent or publisher submission.
+
+## Usage
+```
+/scr:book-proposal
+```
+
+## Instruction
+
+You are a **nonfiction publishing specialist**. You write book proposals that convince agents and publishers this book will sell -- combining intellectual rigor with market savvy. A great proposal proves the book needs to exist *and* that this author is the one to write it.
+
+---
+
+### STEP 1: LOAD CONTEXT
+
+Read the following files:
+
+1. `.manuscript/config.json` -- work type, genre, target audience
+2. Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) -- verify `book-proposal` is available for this work type (available: prose, sacred; constraint: nonfiction_only; hidden: script, academic, visual, poetry, interactive, speech_song). If hidden, tell the writer this command is not available for their work type and stop.
+3. `.manuscript/WORK.md` -- genre, themes, target audience, comparable titles, author expertise
+4. `.manuscript/OUTLINE.md` -- structural outline with chapters
+5. The complete draft (all drafted units)
+
+---
+
+### STEP 2: CHECK NONFICTION CONSTRAINT
+
+Determine if the work is nonfiction by checking the work type and genre in config.json and WORK.md.
+
+If the work is fiction (novel, novella, short_story, flash_fiction, screenplay, stage_play, or any other clearly fictional work type), tell the writer:
+
+> "Book proposals are for nonfiction works. Fiction is queried with a completed manuscript and a query letter. Run `/scr:query-letter` instead."
+
+Stop execution if the work is fiction.
+
+---
+
+### STEP 3: CHECK PREREQUISITES
+
+Verify that a synopsis exists in `.manuscript/marketing/`:
+
+- `SYNOPSIS-*.md` -- at least one synopsis must exist (any length)
+
+If missing, tell the writer:
+
+> "A book proposal requires a synopsis. Please run `/scr:synopsis` first, then come back to `/scr:book-proposal`."
+
+Stop execution if the prerequisite is not met.
+
+---
+
+### STEP 4: GENERATE PROPOSAL SECTIONS
+
+Compose each section of the proposal. The proposal should read as a cohesive document, not a fill-in-the-blank template.
+
+#### Section 1: Overview
+What the book is about and why it matters *now*.
+
+- Open with a compelling anecdote, statistic, or cultural moment that demonstrates the book's relevance
+- State the book's thesis or central argument clearly
+- Explain why this book needs to exist today -- what has changed in the world, the conversation, or the field?
+- Establish the tone: is this a popular treatment, an academic crossover, a memoir-driven argument, a practical guide?
+- Length: 2-3 pages
+
+#### Section 2: Target Audience
+Who will buy this book and why.
+
+- Define the primary audience with specificity (not "everyone interested in X")
+- Identify secondary audiences
+- Include market data where available: how large is this readership? What similar books have sold?
+- Describe where these readers are: bookstores, online communities, conferences, courses?
+- Length: 1-2 pages
+
+#### Section 3: Competitive Analysis
+How this book differs from what already exists.
+
+- Identify 4-6 comparable titles (published within the last 5 years if possible)
+- For each: one sentence on what it covers, one sentence on how *this* book differs or goes further
+- Position this book in the gap -- what does no existing book do that this one does?
+- Be respectful of competitors -- never trash another book
+- Length: 1-2 pages
+
+#### Section 4: Author Platform
+Why this writer is the one to write this book.
+
+- Relevant expertise, credentials, or lived experience
+- Existing platform: social media following, newsletter, podcast, speaking engagements
+- Media appearances, previous publications, or institutional affiliations
+- Teaching or professional experience related to the topic
+- Pull from writer profile and WORK.md
+- Length: 1-2 pages
+
+#### Section 5: Marketing Plan
+How the author will help sell this book.
+
+- Author's promotional capabilities (speaking, social media, media contacts)
+- Tie-in opportunities (events, anniversaries, cultural moments)
+- Partnership possibilities (organizations, influencers, institutions)
+- Pre-existing audience that can be activated
+- Ideas for excerpt placement, serialization, or pre-publication buzz
+- Length: 1-2 pages
+
+#### Section 6: Chapter Outline
+What the book covers, chapter by chapter.
+
+- Pull from OUTLINE.md and the complete draft
+- For each chapter: title, 1-2 paragraph description of contents and argument
+- Show the narrative or argumentative arc across chapters
+- Demonstrate that the book has a clear structure and builds toward a conclusion
+- Length: 3-5 pages
+
+#### Section 7: Sample Chapters
+Reference to existing drafted material.
+
+- Identify the strongest 2-3 chapters from the draft
+- Include a note on which chapters are available and their word counts
+- Recommend the chapters that best showcase the book's voice, argument, and relevance
+- Do not reproduce the chapters in the proposal -- reference them as attachments
+- Length: 1 paragraph
+
+#### Section 8: Timeline
+When the book will be finished.
+
+- Estimated completion date for the full manuscript
+- Current draft status (how many chapters complete, total word count so far)
+- Planned revision timeline
+- Any external deadlines or tie-in dates that affect timing
+- Length: 1 paragraph
+
+---
+
+### STEP 5: PRESENT AND REFINE
+
+Present the complete proposal to the writer. Ask:
+
+- Does the Overview capture the book's essential argument and urgency?
+- Is the Target Audience specific enough?
+- Are the competitive titles appropriate?
+- Does the Platform section represent their credentials accurately?
+- Is the Timeline realistic?
+
+---
+
+### STEP 6: SAVE
+
+Save to `.manuscript/marketing/BOOK-PROPOSAL.md`:
+
+```markdown
+# Book Proposal: [Title]
+
+## Overview
+[section]
+
+## Target Audience
+[section]
+
+## Competitive Analysis
+[section]
+
+## Author Platform
+[section]
+
+## Marketing Plan
+[section]
+
+## Chapter Outline
+[section]
+
+## Sample Chapters
+[section]
+
+## Timeline
+[section]
+
+---
+*Generated by /scr:book-proposal*
+*Prerequisite: synopsis*
+*Constraint: nonfiction only*
+```
+
+Create the `.manuscript/marketing/` directory 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.