--- description: Import an existing manuscript (docx, markdown, txt, or directory) and structure it into a Scriveno .manuscript/ directory. argument-hint: " [--type ]" --- # Import You are importing an existing manuscript into Scriveno. The writer has content -- in a Google Doc, a Scrivenoer project, a folder of markdown files, a Word document, or similar -- and wants Scriveno's tooling without starting from scratch. Resolve all variable context surfaces through `docs/surface-resolution-protocol.md` before creating files, skipping files, or naming adapted outputs. ## What to do 1. **Locate the file or directory.** Accept: .docx, .md, .txt, .rtf, a directory of any of these. 2. **Read the content.** For docx, use pandoc or similar to extract text. For markdown, read directly. For a directory, concatenate files in order. 3. **Detect the work type.** If `--type` was passed, use it. Otherwise analyze the content and make a best guess: - Scene headers (`INT./EXT.`) -> screenplay - Chapter markers with prose -> novel or memoir - Section headers with citations -> academic paper - Verse and chapter numbers -> scripture - Panel descriptions -> comic - Poem titles separated by breaks -> poetry collection - Ask the writer to confirm. 4. **Parse structure.** Identify the unit boundaries based on the work type's `command_unit` from CONSTRAINTS.json. For a novel, find chapter breaks. For a screenplay, find act breaks or scene headers. For a research paper, find section headers. 5. **Run voice analysis.** Take a 2000-word sample from the imported text and extract the writer's voice DNA: sentence architecture, vocabulary register, figurative density, POV, tense, dialogue style. Populate STYLE-GUIDE.md with the detected values. Flag anything uncertain for the writer to confirm. 6. **Detect cast entries.** Scan for proper nouns that appear as speakers in dialogue or as recurring agents in narration. Build a draft adapted cast surface for canonical `CHARACTERS.md` (for example `CHARACTERS.md`, `CONCEPTS.md`, `AUDIENCE.md`, or `FIGURES.md` via `file_adaptations`) with name, estimated role, and detected voice or role patterns. Flag for writer review. 7. **Generate the .manuscript/ directory.** Create all context files marked `required` or `optional` by `surface_applicability`, using `file_adaptations` for the confirmed work type (WORK.md, BRIEF.md or adapted equivalent, OUTLINE.md, RECORD.md, STYLE-GUIDE.md, the adapted cast surface where applicable, and so on). Skip every surface marked `not_applicable`. Create `config.json` from the installed `templates/config.json` so the shared `authenticity` policy, draft settings, voice settings, export defaults, and collaboration defaults are present. Also copy `WRITING-RULES.md` verbatim from the installed Scriveno templates (`templates/WRITING-RULES.md`) into `.manuscript/` so the drafter, voice-checker, and originality-check have the canonical universal rules available. Save the actual drafted text as `.manuscript/drafts/body/{N}-{A}-DRAFT.md` files, one per atomic unit. **Populate book identity on the resulting `config.json`** the same way `/scr:new-work` does, so an imported project arrives with a machine-readable identity (`docs/naming-conventions.md` section 2 is the identity contract). On the `config.json` produced above, without disturbing any other keys: - `title`: the imported work's title (its WORK.md H1). - `slug`: derive from that title with the slug helper, `node "/lib/slug.js" ""` -> `{"slug":"..."}` (`<data-dir>` resolves to `.scriveno/lib`, `$HOME/.scriveno/lib`, or `lib/` in the source repo). Do not invent a second slugifier. - `author`: set it if the imported material clearly discloses an author, else leave it empty (never invent one). - `subtitle`: leave empty unless the source clearly carries one. - `series` and `book_number`: leave `null`. **If importing into an EXISTING project** whose `config.json` already carries a non-empty `title` or `slug`, do not overwrite them. Only fill identity fields that are currently blank, and leave a stable existing `slug` in place (section 2 treats `slug` as written-once). Once the adapted cast surface is populated with two or more entries, generate the adapted relationship surface for canonical `RELATIONSHIPS.md` (per `docs/relationships-protocol.md`) and `.manuscript/CONFLICTS.md` (per `docs/conflict-protocol.md`) where those surfaces apply, so an imported project arrives with the same derived maps a new project gets. If `PEOPLES.md` applies and imported material clearly identifies peoples or factions, create starter entries marked "needs writer confirmation"; if two or more peoples are defined, generate `.manuscript/PEOPLE-DYNAMICS.md` per `docs/people-dynamics-protocol.md`. Populate `RECORD.md` from the imported manuscript, not from speculation. Extract established on-page facts, open threads, promises, continuity facts, reader expectations, and visible character, subject, argument, procedure, image, object, or relationship movement. Mark uncertain discoveries as "needs writer confirmation" instead of treating them as settled truth. 8. **Set STATE.md** to reflect that all imported units are drafted but not yet reviewed. This lets the writer pick up with `/scr:editor-review` or `/scr:next`. 9. **Generate a report.** Tell the writer: ``` Imported [filename] as a [work_type]. Structure detected: X chapters, Y scenes total Word count: 65,432 Voice profile: extracted from 2000-word sample (review in STYLE-GUIDE.md) Cast entries detected: 7 (review in the adapted cast file) Record initialized: established facts and open threads extracted into RECORD.md Some things I wasn't sure about: - [specific flags: uncertain chapter breaks, possible POV shifts, etc.] Next steps: - Review STYLE-GUIDE.md and the adapted cast file -- confirm or adjust - Run /scr:next to start working on the imported manuscript ``` ## Edge cases - **Messy source.** If the import has weird formatting, OCR errors, or inconsistent structure, do your best and flag the issues. Don't refuse the import. - **Huge manuscript.** For texts over 200k words, warn about import time but proceed. Split voice analysis across multiple samples. - **Mixed work types.** A Google Doc with both prose and outline notes -- import as primary work type, save notes to `.manuscript/notes/`. - **Source in a different language.** Detect it. Ask if the writer wants to work in the source language or translate first. - **No clear structure.** If you can't find chapter or scene breaks, ask the writer how they want the text divided before creating draft files. ## What NOT to do - Don't "improve" the writer's text during import. Preserve it exactly. They'll revise via normal commands. - Don't rename files without asking. - Don't skip voice analysis -- it's the highest-value part of import. - Don't assume character roles without evidence. Mark uncertain roles as such. ## 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. ## Tone Respectful. The writer has worked on this text. You're bringing it into a new system, not judging it. Report what you found clearly, flag your uncertainties honestly, and make clear the writer is in charge of confirming.