Practically Paperless with Obsidian, Episode 25: Five Use Cases for Managing My Writing in Obsidian

shallow photoghrapy of black and gray type writer keys
Photo by mali maeder on

Welcome to my blog series, “Practically Paperless with Obsidian.” For an overview of this series, please see Episode 0: Series Overview.

Years before I began using Obsidian, I’d wanted to consolidate all of my writing into a single format–preferably text files. I wanted all of my old writing files accessible in plain text, and wanted to do all future writing in the same format. Ideally, I would use a single editor for all of this and would only have to know a single set of keyboard mappings. Once I started using Obsidian, and learned more and more of its features, I began to do what I’d I’d always wanted: centralize all of my writing–all of it–in a single place.

This episode, and the several that follow will describe how I’ve centralized all of my writing in Obsidian. I’ll begin with how I use Obsidian for my “professional” writing, illustrated through 5 use cases.

Professional writing?

In addition to this blog and my day job as an application developer and project manager, I also write stories and articles for publication. I began to write with the idea to sell stories almost 30 years ago, while still in college. It took 14 years of writing, submitting, and collecting rejections before I made my first professional story sale. Sales came quicker, and I branched out from writing stories to writing articles as well. Writing short fiction and nonfiction pieces was never going to take over from my day job as my primary source of income, but it was my avocation: something I’d always wanted to do and something that I really enjoyed doing.

Over the years, I’ve used all kinds of tools for my writing. When I began to write in college I was composing my stories in Microsoft Word 5.5 for DOS–still my favorite word processor to this day. I moved onto other tools. I was a long-time user of Scrivener, and later, Google Docs. When I began using Obsidian more than 15 months ago, I decided that I wanted to do all my writing there. Moreover my vault could serve as the repository for all of my writing.

Writing as a profession–even one as humble as mine–involves more than just typing words onto a page. I have identified 5 tasks I perform as part of the overall process of managing my writing. They are:

  1. Writing drafts
  2. Managing writing projects
  3. Tracking submissions
  4. Tracking sales and contracts
  5. Seeing the big picture


There are a couple of tools I use in conjunction with Obsidian to make the overall process smooth and seamless.

  • Templater plug-in. I use this to build a set of writing-related templates so that I am not re-inventing the wheel every time I create a new draft manuscript note, or a new submissions note.
  • Quick Add plug-in. I use this to speed up the process of creation and to populate some of the meta-data in my templates.
  • Dataview plug-in. I use this in my “writing project” notes for collecting together related information about the project in one place. Because the dataview plug-in does not actually link notes together, I have, as you will see, taken additional steps to ensure that all of my writing notes have links within them to keep them related to their projects. This serves as a kind of backup to the dataview plug-in.
  • Pandoc. I use this to automate compiling a draft note into standard manuscript format. Standard manuscript format is used by most of the professional publications that I have worked with. It is a simple set of guidelines for formatting a manuscript that takes the job of figuring out how to format a document out of the writer’s hand. This is a good thing since getting bogged down in formatting is a good way to avoid writing.

Use Case 1: Writing Drafts

My process for actually sitting down to write in Obsidian is straight-forward:

  1. Create a new note using a New Manuscript Draft template via the Quick Add plug-in. This creates a note with the appropriate meta-data at the top (the YAML frontmatter) and a callout footer with a link to the project. It also automatically files the note into my “Working Drafts” folder.
  2. Write. This is the activity where I try to spend the bulk of my time.

There isn’t much formatting involved in the types of manuscripts I produce. I use simple markdown for things like italicized text. I use markdown headings for sections or parts of a story or article. Otherwise, I just write. I do, however, have a process for working through my drafts that has evolved over the years and I have built that process into my workflow in Obsidian.

1st draft and 2 second drafts

When I create a new note using my New Manscript Draft template via the Quick Add plug-in, I am prompted for several pieces of information:

  • Draft title. This is often a working title. My first published story was called “When I Kissed the Learned Astronomer,” for instance.
  • Project title. A name of the project that this piece is associated with. This is often an abbreviated version of the title. In the case of my first published story, the project name was “Learned Astronomer”
  • Draft: The draft version, 1st draft, 2nd draft, etc.

After providing this information, a new note is available to me with the meta-data in the YAML frontmatter of the note file, and a footer containing a hard Obsidian link to the project note. Now I can begin writing. Here is what it looks like in action:

My New Manuscript Draft template in action
My New Manuscript Draft template in action

At the bottom of my template, you’ll notice a callout section called “Note” which contains a link to the project name. Many of these notes are surfaced through the dataview plug-in, as you will see. However, the dataview plug-in does not create actual links between notes. The “footer” in my templates create links between the note and the project: in this case, between the draft and the project. This serves as a way to see the relationships in backlinks, or the graph view. It also serves as a kind of backup to the dataview itself.

The footer of my template, which creates a relationship between the draft and the project note.

For me, a typical story or article goes through two drafts. On rare occasions, I’ll have a third draft. Each draft gets its own note so I can see the evolution of the piece from one draft to another. These drafts are accessible from the project note, as I will demonstrate in Use Case 2.

Submitted and publication drafts

In addition to “1st”, “2nd”, and “3rd” draft, my template also provides me with two additional options: “Submitted draft” and “Publication draft.”

  • Submitted draft. This is a version of a piece that is formally submitted to a specific market. There can sometimes be several submitted drafts, each one tied to a specific market, slightly different based on feedback I have received, or changes I have made between submissions.
  • Publication draft. This is a version a piece that is ultimately published. This may differ slightly from the submitted draft. Some magazines and publishers provide authors with “galleys” of their piece set in type from which minor corrections can be introduced prior to publication. Changes I make on a galley get reflected in the publication draft.


Ultimately the creation of the new manuscript draft note takes just a few seconds. The templates and plug-ins help speed that process along and keep everything standardized so that I can get to the writing itself, which is what matters.

These templates and plug-ins eliminate a lot of overhead and allow me to focus on writing.

Compiling a manuscript with Pandoc

When I have a submission draft locked down, I will compile a manscript using Pandoc. Pandoc, for those who aren’t familiar with it, is a tool that takes one format of text and converts it to another format. For my purposes, it takes a plain text markdown file and generates a Word document (or sometimes, a PDF) in standard manuscript format.

I have a simple command I run at the command line to do this. Because I’ve already set up a “standard manuscript” template in Pandoc, I run my command against a given note in Obsidian, and out comes a properly formatted Word document ready for submission. After running my command, Pandoc generates the manuscript. Here is an example of the first page of a manuscript that is produced (header information is made up for this purpose):

sample first page of "compiled" manuscript draft via Pandoc
Sample first page of a manuscript compiled from a text file using Pandoc.

Once again, this saves me time. I want to spend as much of my available “writing” time actually writing.

Use Case 2: Managing writing projects

If I manage to complete a draft, I create a “Writing Project” note. (If I give up, I trunk the draft.) I have a “New Writing Project” template that I use to create the project. Like the “New Manuscript Draft” template, it prompts me for a bunch of information, and the resulting project file gets places in a project folder.

animated gif showing how I create a new writing project
Creating a new writing project.

There are five sections to my New Writing Project template:

  1. Drafts: a dataview table listing all of the drafts associated with the project.
  2. Submissions: a dataview table listing all of the submissions associated with the project.
  3. Contracts: a dataview table listing all of the contracts associated with the project.
  4. Appearances: currently, a manually maintained list of places the piece has appeared, with links if available.
  5. Notes: notes and other items related to the project.

Here is an example of a Writing Project note from my first published story from back in 2007:

Writing Project note for my first published story, showing four of the five sections
Writing project note for my first published story.

Everything on the template, with the exception of the “Appearances” is automated so long as I use the same project name throughout the process. Below is what my actual Writing Project template looks like in source mode so that you can see the dataview queries:

a sample of my new writing project template
Template for my New Writing Project.

Once again, because the “footer” in my Manuscript Draft, Submission, and Contract templates contains a link to the project note, there are hard links between the notes, in addition to surfacing the related notes through the dataview plug-in. For instance, from the project note, I can see the backlinks to all of the related notes (drafts, submissions, etc.):

A view of a writing project with showing the backlinks to related notes
A view of a writing project with showing the backlinks to related notes

As indicated, the {{VALUE:Project Name}} comes from a Template configuration I have in the QuickAdd plug-in. That configuration looks as follows:

Quick Add plug-in configuration for my New Writing Project template
Quick Add plug-in configuration for my New Writing Project template

The result is that when I create a new draft, submission, or contract that uses the same project name in the meta-data, it will appear on the MOC for the project in question, surfaced in the dataview tables as well as the backlinks to the note.

I have a writing project MOC for every writing project for which I completed a first draft, even if the story or article was ultimately trunked. More on this in Use Case 5 below.

Use Case 3: Tracking submissions

When a story or article is ready for submission, I use my “New Submission” template. This prompts me for two pieces of information:

  • Project name
  • Market name

The market name is typically an abbreviated version of the market to which the piece is submitted (e.g., IGMS for InterGalactic Medicine Show, Daily Beast for The Daily Beast, etc.)

When the note is created, it is automatically filed in a Submissions folder. I then manually add a couple of additional pieces of information:

  • Submission date
  • A note link to the the submitted manuscript draft.

Recall that some projects may have multiple submission drafts. This link is what ties a specific draft to a specific market. Here is what a submission looks like:

animated gif showing how my New Submission template works
Creating a new submission.

When I hear back from a market, I will update the submission note. I’ll update the status, as necessary, and the status date. I will also make running notes in the note itself. For instance, if an editor requests changes, I’ll note the changes in the submission note that need to be incorporated into the published draft.

As I make these changes, or add new submissions, they are automatically captured on the Writing Project MOC for the project in question.

Here is a look at my New Submission template:

My New Submission template
My New Submission template

Use Case 4: Tracking sales and contracts

When a piece is sold, a contract usually follows that contains the terms of the sale, how much I am to be paid, and what rights I am selling. When this happens, I create Contract note using my New Contract template via the QuickAdd plug-in. The contract template collects information like:

  • project name
  • market
  • contract date
  • payment
  • contract terms/rights

This information goes into the meta-data of the note. I then manually add an embedded link to the PDF version of the contract. This note gets autmatically filed into my _documents folder. The contract is automatically listed in the “Contracts” section of the project MOC for the piece. For some projects, there may be more than one contract. This will happen for reprints or foreign sales, for instance.

Here is an example of what a contract note looks like. This one is for my story, “Take One For the Road” which appeared in the June 2010 issue of Analog Science Fiction:

Contract note for my story "Take One for the Road" (Analog SF, June 2011)
Contract note for my story “Take One for the Road” (Analog SF, June 2011)

The contract is automatically listed in the “Contract” section of the corresponding project note. Like my other templates, the contract template also has a “footer” with links to the project note and the corresponding market note, thus creating hard links in Obsidian between those notes.

Use Case 5: Seeing the big picture

Finally, I have a “Writing Projects MOC” note that lists all of my writing projects using the data view. It has three parts:

  • projects in progress
  • projects that have been complete/published
  • projects that have been trunked

This is the 50,000 foot view of my writing. It lets me see everything and then drill down into those project MOCs that I am interested in seeing in greater detail. Here is what my Writing Project MOC looks like today:

my master writing project note, listing all of my writing projects, active, completed, and trunked
Master “Writing Projects” note listing all of my writing projects, active, completed, and trunked.

The screen capture above cuts off after my first four “trunked” stories, but there are at least a hundred of them in that list, going back, as you can see to as early as January 1993, when I first began submitting.

There are other views I have as well. I can see tables showing me how much I was paid in a given year–useful for tax season. Or I can see a listing of publications by market. One thing I am working on is creating a template for appearances; this will essentially automate my bibliography.

Final thoughts

No solution is perfect for everyone. This one works well for me because it allows not only to do all of my writing in Obsidian (and in plain text files), but it allows me to manage my writing in plain text files as well. The dataviews are convenient for this, but not required. As I have shown, my templates also create hard links between projects and related notes so that I can see the relationships in backlinks, and graph view, in addition to the dataview tables.

There is certainly room for some improvement in my process. But that comes with time. I should also point out that I use this process for my paid writing. I have a similar, process for how I managed my writing here on the blog — but that will be the subject of next week’s episode.

I know there is a lot in this post. I am happy to try to answer any questions, technical or otherwise about managing my writing in Obsidian in the comment thread.

Prev: Episode 24: Use Case: How I Capture Field Notes in Obsidian
Next: Episode 26: Use Case: How I Manage My Blog Writing in Obsidian (coming April 12, 2022)

Written on March 24-26 and April 1, 2022.

Did you enjoy this post?
If so, consider subscribing to the blog using the form below or clicking on the button below to follow the blog. And consider telling a friend about it. Already a reader or subscriber to the blog? Thanks for reading!

Follow Jamie Todd Rubin on


  1. This is a truly wonderful blog post. Thankyou for sharing, it really is a great combination of demonstrating a proven work process with the technical details of implementation. I have book-marked it to help me as I build my own similar system which I have on paper but want to transfer to digital format. Great stuff. 👍

    Looking forward to the next post on how you manage the “less formal” writing for your blog publications.

  2. Hi! Thanks for this description, it’s really useful. Quick question: I see that you create MOC’s for each project, but I’m wondering how you organize all the notes for each project as well—i.e. does every associated note go in a dedicated project folder or do you only use an MOC note to keep things organized?

    1. The writing project MOCs are all filed together in a single folder: “Writing/Business/Projects”. When I create a new manuscript draft, it goes automatically into my “Writing/Craft/Working Drafts” folder. Completed drafts get moved to “Writing/Craft/Draft”. Submission notes automatically get filed in my “Writing/Business/Submissions” folder. Contracts get filed in my _documents folder because they are really wrapper notes for the underlying PDFs.

      Bottom line: I use the MOC (and note links) to keep thinks organized. I don’t have dedicated project folders. This is useful when I start to move things around — as I have been doing this weekend.

  3. I noticed in your “My New Manuscript Draft template in action” animated screen grab that you cursor down from the top to get passed the YAML content. In the interest of avoiding these extra keystrokes, I recommend letting Templater position the cursor for you. Just add the following command after the second --- in your template:

    <% tp.file.cursor() %>

    Note: When I first applied this command in my templates, the cursor would not move as expected. Turns out I had set “Automatic jump to cursor” in the Templater settings to OFF. It needs to be ON.

    1. Rob, thanks for the tip. I did try that with one of my templates, but I must be doing something wrong because I can’t get it to work. I’ve checked to make sure that the Automatic Jump to Cursor is ON. In any case, I use Obsidian with Vim mode and so jumping to the starting point is as easy as hitting :linenumber (e.g. :12) in normal mode.

  4. On the shoulders of giants! But how did you get the pandoc bit to work? Are you using a template that automatically calculates the word count for you, or do you have to input it yourself each time? Are you manually filling in the header? I feel like you’ve found the missing key to replacing Scrivener and Ulysses—if I could just get the export function to play nice! Well done!

    1. Ian, to be clear, the Pandoc piece happens outside of Obsidian. My basic setup:

      1. I have a Word document formatted in Standard Manuscript Format. It already has the header information, including a place-holder for the word count.
      2. The Word document is stored in my ~/.pandoc/templates folder. In my case, I call it ~/.pandoc/templates/manuscript.docx

      When I am ready to compile a manuscript, I go to a Terminal window and run the following command:

      pandoc ~/Documents/Vault/Writing/Working Drafts/ -o ~/Documents/Vault/Writing/Working Drafts/draft.docx --from markdown --template manuscript.docx


      • ~/Documents/Vault/Writing/Working Drafts/ is the markdown version of my draft.
      • ~/Documents/Vault/Writing/Working Drafts/draft.doc is the destination file (the Word version)
      • --from markdown: tells Pandoc that my source file is a markdown file
      • --template manuscript.docx: tells Pandoc to use the template file manuscript.docx as the source file for formatting the output.

      While there is a way to use YAML frontmatter data in the draft file as variables for use in the output, I keep it simple. Other than the word count, the header information (Name, address, etc.) never changes for me, so it is part of the template file.

      I update the word count in the output file manually.

      There was some initial configuration and playing around with Pandoc to get this working, but it works just fine for me, and is quick and easy. Hope this helps.

      1. Thank you for clarifying! I know that there’s a Pandoc plugin for Obsidian now, but I’m struggling to get the template aspect working. Still, it’s great to see your workflow, especially since I’m on the opposite end of the publishing journey. If I overcome the template hurdles, I’ll update my comment.

  5. Thanks for this (and for the in depth series). It is interesting and helpful! I’m confused, though, when trying to work through the details by the way that you sometimes seem to imply that the project filename is the same as the project name (e.g., American Novel), but your templates give it a more complex name (e.g., Great American Novel MOC (M.202007040000)). But then the footer doesn’t really seem to connect to the project file, and the global Writing Project MOC entries don’t appear to connect to the individual MOCs. Is there something tricky going on with file aliases? Or is there an additional set of connector files that aren’t shown, together with some fancy Dataview code to strip the MOC and Zettelkasten cruft out of the displayed titles?

    1. Steve, yeah, I can see now how this is a little confusing, especially as there is a little magic happening on the Writing Project MOC as you suggest. Let me try to clarify.

      There are two pieces of information that the template/quick-add plug-ins ask for that relate to the name of the draft:

      1. Title: This is used to create the file name.
      2. Project: An abbreviated version that is ultimately used for the name of the Project MOC.

      With respect to the Title, the template appends a code to ensure uniqueness. So if I give the file a title of “The Great American Novel”, the template sets the filename of the note to “The Great American Novel (P.202204042000)” where the “P” is my designation for a “permanent” note and the number is just a date/time string.

      The footer in the file links to the project name (in this case, the abbreviated “American Novel”). This ties the file named “The Great American Novel (P.20220404200)” to the note named “American Novel” through an Obsidian link. If this is a first draft, the project note usually does not yet exist at this point, because I only create it if I manage to finish the draft. But since the name of the name of the project file will be the name of the project, the note will ultimately link to that project file.

      In the Writing Projects MOC, there is, as you suggest, some magic happening. When I create a project file, the template automatically appends a code to the end of the file name there, too. So “American Novel” becomes “American Novel MOC (M.202204101345)” or something like that. At the time I create the project file, I usually have a single draft completed. I will go back to the draft and update the link in the footer to point to the actual name of the project file. Thereafter, since the project MOC exists, any link to it uses that file name going forward.

      Finally, the magic: In the dataview query, I didn’t want to clutter it with the noise of the “coded” part of the title, so my table view removes it using a regular expression as follow:

      TABLE WITHOUT ID "[[" + + "|" + regexreplace(, "MOC \(.*\)", "") + "]]" as "Project", status-date as "Date", type as "Type", subtype as "Subtype"
      FROM "Writing/Business/Projects"
      WHERE status = "completed"
      SORT status-date DESC

      What that first line does is look for the pattern “MOC (code)” and removes it from the the display so that that I see is the name of the file. But it still links to the actual file name. That is what the “[[” + ” |…” part does.

      So I can see how this could be confusing. This particular post was one of the longer ones I’d done, and I thought I’d gone into enough detail, but hopefully this helps to better clarify what is going on behind the scenes for you. This is by no means a perfect solution and there are places that can be made more efficient, as I use it and learn new and better ways of doing things. But for me it is a good first attempt that allows me to manage this writing from cradle to grave in Obsidian.

      1. Thanks so much for taking the extra time to explain that! Both the process insights and the practical details are appreciated.

  6. Hello! Really enjoyed this post. A few points or questions. With pandoc you are not using the available pandoc plug-ins? I installed pandoc with brew and point in the plug-in config to its location on my Mac. Secondly, I am doing all my writing including a periodical series on travel as well as a work of fiction. The periodical series was first released as blog posts but this really limited the interactions I wished between stories. Turned out that linking in obsidian was what it really needed. I also am using the long form plug-in for the novel.

    I recently decided to use obsidian publish on my vault which has been very enlightening for me and my writing and travels as well as a few readers.

    Looking forward to reading the next parts. Thanks!


This site uses Akismet to reduce spam. Learn how your comment data is processed.