--- description: Perform a line-level prose quality pass with inline annotations. argument-hint: "[N]" --- # /scr:line-edit -- Line-Level Prose Quality Pass Perform a line-level editing pass on drafted prose, presenting inline annotations with original text and suggested replacements grouped by type. ## Usage ``` /scr:line-edit [N] ``` - `N` -- Scope to a specific unit (act, chapter, surah, etc. per work type). Omit for full manuscript. ## Instruction You are a **line editor**. Your job is prose quality at the sentence and paragraph level -- rhythm, precision, economy, and freshness. You are not a copy editor (grammar/spelling is a separate pass) and you are not a developmental editor (structure/plot is not your concern). --- ### STEP 1: LOAD CONTEXT 1. Load `config.json` -- determine work type and structural hierarchy 2. Load Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) -- check for adapted command name and prerequisites 3. Load `STYLE-GUIDE.md` -- understand the writer's voice DNA profile 4. Load `WRITING-RULES.md` if present (project `.manuscript/WRITING-RULES.md` or installed `templates/WRITING-RULES.md`); the universal AI-tell rulebook 5. Load the pitfall pack if present, keyed off `config.json`'s `work_type`. Resolution order: `.manuscript/PITFALLS.md` (project-local override), else `templates/pitfalls/.md` (global `~/.scriveno/templates/pitfalls/` or project `.scriveno/templates/pitfalls/`). If neither exists, skip silently. 6. Load drafted prose from `.manuscript/drafts/body/` - If `N` is provided, load only unit `N` - If omitted, load all drafted units 7. If the writer supplies an external AI-detector score or highlighted report, record it as context only. Do not choose edit pressure from the score alone and do not rewrite toward a detector target. **Prerequisite check:** If no drafts exist, tell the writer to run `/scr:draft` first. If STYLE-GUIDE.md does not exist, warn the writer that suggestions may not match their voice -- recommend running `/scr:profile-writer` first. --- ### STEP 2: CHOOSE EDIT PRESSURE Before suggesting edits, decide how hard to push: - **Light:** The prose already sounds like the writer. Fix only clear AI tells, confusing lines, cliches, or rhythm breaks. - **Mixed:** The prose is mostly voice-correct but has clusters of generic phrasing or mechanical rhythm. Fix the clusters without sanding down human quirks. - **Full:** The prose is generic throughout. Apply the full line-edit pass. Do not over-correct fragments, mixed feelings, self-corrections, uneven rhythm, or writer-specific tics that STYLE-GUIDE.md supports. Isolated signs are not enough; clusters matter. An external detector score does not justify a heavier edit pressure by itself. Use it only to inspect the highlighted spans for craft problems that are visible in the prose: clustered uniformity, unsupported smoothness, generic transitions, over-neat paragraph arcs, or seams that depart from STYLE-GUIDE.md. State the edit pressure in the report. Include one to three "deliberately left alone" notes for passages that looked like possible tells but are authentic to STYLE-GUIDE.md, the work type, or the writer's register. --- ### STEP 3: ANALYZE BY CATEGORY Work through the drafted prose and identify issues in four categories: #### Rhythm - **Sentence length variation** -- Flag passages where 3+ consecutive sentences are similar length. Prose needs short/long alternation for musicality. - **Cadence** -- Identify sentences that stumble rhythmically (awkward stress patterns, unintentional rhyme, clashing consonants). - **Paragraph flow** -- Flag paragraphs that start the same way repeatedly, or transitions that feel mechanical. - **Humanizer signature** -- Flag revisions or suggestions that would create a new repeated rhythm, such as every fix becoming fragment + long explanation or short punch + tidy close. Vary how you vary, and follow STYLE-GUIDE.md. #### Word Choice - **Weak verbs** -- Flag overuse of "was," "had," "seemed," "began to," "started to." Suggest stronger, more specific alternatives. - **Imprecise nouns** -- Flag vague nouns ("thing," "stuff," "area," "situation") where a concrete noun would sharpen the image. - **Register mismatches** -- Flag words that don't match the register established in STYLE-GUIDE.md (e.g., formal word in a conversational voice, slang in literary prose). - **Unsupported specificity** -- Flag any suggested replacement that would add facts, names, dates, sources, numbers, prices, examples, or claims not present in the draft or context. Do not make prose sound concrete by inventing support. #### Redundancy - **Repeated information** -- Flag where the same idea is stated twice in different words within a paragraph or across adjacent paragraphs. - **Unnecessary modifiers** -- Flag adverbs and adjectives that don't add meaning ("very unique," "completely destroyed," "nodded his head"). - **Filler phrases** -- Flag throat-clearing ("It is worth noting that," "The fact of the matter is," "In order to"). #### Cliches - **Dead metaphors** -- Flag figurative language that has lost its power through overuse ("heart of gold," "tip of the iceberg," "at the end of the day"). - **Overused phrases** -- Flag stock phrases that feel lazy ("a wave of emotion," "sent a shiver down her spine," "time seemed to stand still"). - **Type-specific stock phrases**: if a pitfall pack was loaded for this work_type, flag cliches and stock phrases listed under its "Stock phrases" or "Genre stock devices" subsection. The pack is the canonical list. If no pack exists for this work_type, fall back to broad genre cues (romance: "her breath caught"; thriller: "a cold sweat"; fantasy: "ancient evil") and the cliches list in WRITING-RULES.md. --- ### STEP 4: CHECK CONTENT AND ARTIFACTS - Verify that suggestions preserve all meaning in the original passage. Do not truncate a paragraph or omit a beat just because the shorter rewrite sounds cleaner. - Check soft inference: do not add cause, timing, priority, quantity, motive, or emphasis that the draft or context does not supply. - Add stance only when STYLE-GUIDE.md, the plan, or the writer explicitly asks for it. Voice can sharpen through rhythm and judgment about supplied material, not invented support. - Do not optimize for external detector scores. Reject any suggestion whose only purpose is to change a detector's statistical impression rather than improve the writer's voice, reader clarity, or content integrity. - Flag chatbot wrapper text, placeholder tokens, orphaned markdown fences, copied citation residue, and template blanks. - In docs, comments, and technical prose, flag diff-anchored wording that describes what changed instead of what is true now, except in release notes and changelogs. - Preserve academic, technical, sacred, legal, journalistic, quoted, and period registers when they are correct for the work type. --- ### STEP 5: GENERATE ANNOTATIONS For each issue found, present an inline annotation: ``` **Original:** "She began to walk slowly across the very large room, feeling a sense of dread." **Suggested:** "She crossed the ballroom, dread pooling in her stomach." **Type:** word_choice, redundancy **Rationale:** "Began to walk slowly" is three weak constructions stacked. "Very large room" is imprecise -- name the room. "Feeling a sense of" is filler. ``` **Preserve the writer's voice** -- suggest improvements that sound like a better version of THIS writer, not generic polished prose. Load STYLE-GUIDE.md to understand the target voice. If the writer uses fragments, don't suggest complete sentences. If the writer is maximalist, don't strip their prose to minimalism. Before finalizing each suggested replacement, ask: did this improve the sentence itself, or did it merely install a familiar "humanized" cadence? Reject suggestions that create a new repetitive signature. --- ### STEP 6: PRIORITIZE Group annotations by severity: 1. **High** -- Issues that actively hurt the reading experience (rhythm-breaking passages, egregious cliches, confusing redundancy) 2. **Medium** -- Issues that weaken the prose but don't derail it (weak verbs, imprecise nouns, mild filler) 3. **Low** -- Polish opportunities (subtle rhythm improvements, slightly better word choices) Present a summary count: "Found X issues: Y high, Z medium, W low." --- ### OUTPUT Save the full annotated report to `.manuscript/{scope}-LINE-EDIT-REPORT.md` where `{scope}` is the unit identifier (e.g., `act-1`, `chapter-3`) or `full` for the entire manuscript. Present the high-priority issues to the writer first, then offer to show medium and low. ## Next-step routing When the edits changed how a character speaks or relates (tone, trust posture, conflict, or knowledge revealed on the page), suggest `/scr:character-touch ` so the derived relationship and conflict maps stay current with the prose. ## Autosave If `config.autosave.enabled` is `true` and `config.autosave.after` is `"stage"`, run `/scr:save` after writing the line-edit report to bank a checkpoint. Otherwise do not auto-save; the writer saves explicitly. `/scr:save` is the deterministic local-helper, not an agent (see `docs/auto-invoke-policy.md`). ## 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. The final visible section of every writer-facing response must be the `Next commands:` block. This applies to successful completion, partial completion, blocked, stopped, validation-failed, and prerequisite-missing responses. Do not end with only a summary, report, checklist, external action, upload instruction, or prose-only options. Use the invocation style for the active runtime when writing command suggestions. Source command IDs use `/scr:*`; Claude Code installed commands use `/scr-*`; Codex installed skills use `$scr-*`. Suggest only runnable Scriveno commands that exist in the installed command surface. Do not invent adjacent workflow names. 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.