-
Notifications
You must be signed in to change notification settings - Fork 2
FAQ
Common questions about Draft Bench. Add your own via GitHub Discussions.
Draft Bench and Longform share core ideas — scene-based writing, project structure in Obsidian. Draft Bench differs in:
- Per-scene versioned drafts as first-class files. Every "new draft" creates a real markdown file you can open, link, tag, and query.
-
Frontmatter-native data model. Membership and relationships live in
dbench-*properties. No index file, no parallel JSON store. Native Obsidian Bases compatibility. - Flexible folder structure. Scenes can live anywhere in your vault; the plugin identifies them by frontmatter, not folder location.
- Compile without JavaScript. A form-based Book Builder supports compile presets, scene selection, and multi-format export.
Draft Bench is narrow on purpose. It handles the manuscript spine — projects, chapters, scenes, drafts, compile — and stays out of the rest. If you want one plugin that also tracks characters, locations, plot grids, beat sheets, timelines, and stats, StoryLine is excellent at that and very actively shipping.
If you want a focused tool for organizing scenes, snapshotting drafts, and compiling a manuscript — with Bases for everything else and your own notes (or a sibling plugin like Charted Roots) for world-building — Draft Bench is built for that.
The two coexist fine: namespaces don't collide, and a vault can run both. Choose by which scope feels right for your workflow.
No. Chapters are optional. Short-story collections, novellas without chapter divisions, and any project you'd rather keep flat can stay chapter-less — scenes attach directly to the project as in earlier Draft Bench builds. Choose the shape that matches the work.
Yes, but the conversion is manual. The plugin enforces a no-mixed-children rule (a project's top-level children are either all chapters or all direct scenes, never both), so you'll need to:
- Create the chapter notes you want (New chapter in project is refused until step 2 below; you can stage them in a different folder first, or create the project's first chapter only after step 2).
- Move every direct scene into a chapter using Move to chapter (right-click a scene in a chapter-aware project), or by editing each scene's
dbench-chapteranddbench-chapter-idproperties manually.
Going the other direction (flattening a chapter-aware project) is the same in reverse: remove dbench-chapter from each scene, then delete the empty chapter notes. The integrity service (Repair project links) flags any mismatches along the way.
See Projects, Chapters, and Scenes § Converting between shapes.
A scene draft snapshots one scene's body. A chapter draft snapshots the chapter body plus every child scene's body, concatenated in order with HTML-comment scene boundaries. Use a scene draft before a major revision to one scene; use a chapter draft before a structural pass that touches multiple scenes (or when you want the planning sections of every file in the chapter preserved together).
Both share the same Drafts/ folder; their frontmatter parent ref disambiguates them. See Drafts and Versioning.
V1 is desktop-only. Mobile support is under post-V1 evaluation — the primary UX (Manuscript view, Manuscript Builder, reorder modal, Style Settings integration) was designed for a desktop form factor.
Yes. Right-click any note (or folder, or multi-selection) and use one of the retrofit actions: Set as project / scene / draft, Complete essential properties, or Add identifier. All are idempotent and never overwrite existing data.
In a Drafts/ folder. Default placement is inside each project folder; three options are configurable (project-local, per-scene, vault-wide). Draft files are plain markdown with frontmatter — you own them, and they're readable without the plugin.
Obsidian automatically updates wikilinks in all scenes' dbench-project properties. Draft Bench additionally carries a dbench-project-id stable identifier as a backup reference, so the relationship survives renames even in edge cases (non-Obsidian renames, sync races). If any inconsistency occurs, the Repair project links command reconciles forward and reverse references.
Nothing breaks. Draft Bench identifies scenes by their dbench-project frontmatter, not by folder location. You can reorganize your vault however you want — by date, by status, by part — and the plugin continues to work.
Yes. Every note is plain markdown with YAML frontmatter. Disabling or uninstalling the plugin doesn't alter your notes — they remain human-readable and editable in any markdown editor. Other frontmatter readers (Bases, Dataview) continue to see the dbench-* properties as normal frontmatter.
No. Draft Bench is deliberately not an AI writing assistant and does not call language models, generate prose, or rewrite your text. The plugin provides structural and workflow scaffolding; the words are yours. See the specification § Non-goals.
Story order is determined by the dbench-order frontmatter property, not by filename. This lets you reorder scenes cheaply (no file or folder renames, no wikilink cascade) and organize files by any other criterion (status, POV, date) without breaking manuscript order. The Manuscript view (the dockable pane in the right sidebar) is the canonical ordered view.
Yes. Draft Bench stays out of the way of other plugins: it uses namespaced properties (dbench-*), namespaced CSS classes (.dbench- / .draft-bench-), and does not modify Obsidian's editor behavior beyond applying CSS classes. Known-compatible plugins include Templater, Style Settings, Bases, Dataview, and any community sort-plugin that reads frontmatter.
More questions and answers will be added based on real user questions in GitHub Discussions.