Turn an Obsidian Note Into a Claude Code Task You Can Ship Today

On a Friday night I dropped a single line into Obsidian: “The signup nudge feels weak. People probably don’t notice the free-PDF link unless they scroll.” Monday morning I pasted that whole note into Claude Code and said “fix this.” What came back was two screens of “here’s the current situation.” Not one line of code.

The note wasn’t bad. The problem was that I handed it over as-is. That morning I burned 30 minutes being read my own background notes.

Your Obsidian vault is full of knowledge, and yet every session you retype the same preamble for Claude Code. If that sounds familiar, what you’re missing isn’t a smarter AI. It’s a habit for trimming a note down into a request.

Key takeaways

• Paste a raw Obsidian note and Claude Code becomes a summarizer, which delays the build. Hand it one task that finishes today, not the full note.
• You only pull six things out of the note: purpose, no-touch zone, first move, proof, the next step you send readers to, and the rollback.
• Writing the “read this” scope and the “don’t touch” scope first kills the accident where the change creeps into payments or auth.
• Save the request as a template in Obsidian and you stop rewriting the preamble next time.
• Instead of trusting the completion report, judge by evidence: a screenshot, a build result, a diff.

Why you shouldn’t hand over the whole note

An Obsidian note is a letter to your future self. It holds the context and the second-guessing, all of it. That’s exactly why an AI tries to “read everything and understand it.”

A human colleague reads a long note and quietly cuts it down to “right, this is about where the nudge link sits.” Claude Code isn’t that considerate. It returns a polite summary in proportion to how much text you gave it. Helpful, sure, but a summary isn’t what you wanted.

So you trim on the human side, before you hand it over. From a 1,000-character note, keep the 30 characters the implementation actually needs. That trimming is the shortcut that ends the per-session preamble.

If you’d rather have Claude Code help organize the notes themselves first, read the basics of the Obsidian integration first and this workflow will click into place more easily.

The six fields to pull from a note

Here are the only six things I extract from a note every time. The note doesn’t have to contain all six already. For the blanks, I decide the value myself while I trim.

Field	What goes in it	Example
Purpose	The result the user gets, in one sentence	Visitors notice the free-PDF link before they scroll
No-touch zone	What you don’t want to break	Payment processing, login, mobile layout
First move	Where to start	Add one section to the first screen of the homepage
Proof	The evidence that says “done”	Build passes, the diff, the look of the live URL
Next step	Where you send the reader next	The free-PDF signup page
Rollback	The escape route if it fails	Just revert this one commit

The field that matters most is the no-touch zone. Leave it blank and you risk Claude Code “tidying up the payment code while it was in there” as it fixes the nudge link. Drawing the off-limits boundary first is the single most effective thing you can do.

What to delegate to the AI, and what you decide

Mix these up and you get accidents. Draw the line clearly.

• You decide: purpose, no-touch zone, rollback. These are business calls, so don’t hand them to the AI.
• Delegate to the AI: turning the first move into specifics, writing the code, running the proof commands.
• You check at the end: how the live URL looks, and whether the diff matches what you expected. This part you verify with your own eyes.

What you can delegate is “how to build it,” not “what to protect.” Deciding what to protect always stays on the human side.

A prompt template that turns a note into a request

Take the six fields you extracted and shape them into something you can hand straight to Claude Code. Copy the template below and paste your note at the end.

Convert the following Obsidian note into one request you can implement today.
Split the output into the six headings below. Do not write any code yet.

- Purpose (the result the user gets, in one sentence)
- No-touch zone (places you must not change)
- First move (one smallest change)
- Proof (build, diff, live URL, etc.)
- Next step (where you send the reader next)
- Rollback (how to revert if it fails)

[NOTE]
(paste your Obsidian note here)

The most important line is the last one: “Do not write any code yet.” Without it, Claude Code tries to do the conversion and the implementation in one go and skips over confirming the no-touch zone. Have it produce the request first, let the human check the off-limits boundary, then come back with “now implement exactly as written in this request.” This two-step setup is what cuts down accidents.

If you want to sharpen the template further, advanced prompt design for Claude Code collects the wording tricks in detail.

A copy-paste conversion script

If hand-assembling the prompt every time is a chore, write the note as an object and generate the request automatically. If you have Node.js, this runs as-is.

// Minimal script that turns a note into "a request you can implement today".
// Usage: node note-to-issue.mjs

const note = {
  purpose: "Visitors notice the free-PDF link before they scroll",
  noTouch: ["payment processing", "login", "mobile layout breakage"],
  firstMove: "Add one announcement section to the first screen of the homepage",
  proof: ["build passes", "the diff", "the look of the live URL"],
  nextStep: "The free-PDF signup page",
  rollback: "Reverting this one commit restores the previous state",
};

function toIssuePrompt(n) {
  // Notice missing required fields before the request goes out.
  const required = ["purpose", "noTouch", "firstMove", "proof"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`Request is missing required fields: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("Purpose", n.purpose),
    line("No-touch zone", n.noTouch),
    line("First move", n.firstMove),
    line("Proof", n.proof),
    line("Next step", n.nextStep),
    line("Rollback", n.rollback),
    "Do not write code yet. Return only a smallest implementation plan within this scope.",
  ].join("\n");
}

console.log(toIssuePrompt(note));

Run it and you get a six-line request plus the closing sentence. Set noTouch to an empty array and run it again, and it stops with “Request is missing required fields” before the request is ever produced. It’s a way to catch the “handed it over with a blank field” accident in code, up front.

Three situations where this actually works

1. The nudge-link improvement note Paste “the free-PDF link is weak” as-is and you get an endless explanation of improvement ideas. Trim it into a request and the First move narrows to the single point of “add one section to the first screen,” and payment code stays untouched. Compare before and after on the live URL and you judge the effect with your eyes, not a vibe.

2. The bug-investigation note “Sometimes the screen goes blank after login” is too much information. In the request, narrow First move to “share only the repro conditions and error logs first.” Don’t let it chase the root cause and the fix at once; make it concentrate on reproduction first, and you avoid an off-target fix.

3. The article-planning note Even a vague note like “next article, I want proper internal links” becomes implementable once you trim Purpose down to “lock in two internal links to related articles.” Set proof to “build passes” and you stop broken links before publishing. Before you delegate article work, it helps to warm up with Claude Code for non-engineers once.

Keep the request as a template

Once you’ve built a request, don’t throw it away. Put it back in Obsidian. The next time a similar note shows up, you can reuse the whole six-heading structure.

I keep one note called templates/issue-prompt.md with an empty template of the six headings. When a new note arrives, I copy that template and fill it in. The time spent writing the preamble every time is gone.

Go one step further and pin the rules Claude Code should read into the project itself, and the request gets even shorter. Push your project-wide agreements into how to write CLAUDE.md and you stop repeating them in every request.

Pitfalls and how to fix them

Here are the mistakes I made early on, each with the fix.

• Pasting the full note: Claude Code becomes a summarizer. Fix: trim to the six fields before pasting. A note you can’t trim isn’t a settled request yet, so write the one-sentence conclusion yourself first.
• Not writing the no-touch zone: it creeps into payments or auth. Fix: don’t allow a blank, and don’t write “none” either. Make a habit of naming at least one off-limits area.
• Proof is “works = OK”: you’re left trusting the completion report. Fix: always specify at least one of build result, diff, or live URL.
• Implementing in one shot: conversion and implementation blur together and the off-limits check gets skipped. Fix: always include “do not write any code yet,” and ask for implementation only after you’ve checked the request.

Every pitfall was the kind you could have prevented by deciding one line up front.

FAQ

Q. My note is fragmentary and I can’t fill in the six fields. You don’t have to fill them all. Decide just “Purpose” and “No-touch zone” at minimum and it becomes a request. You can fill the rest after the request is out, looking at Claude Code’s proposal, and still be on time.

Q. Do I need an integration that reads Obsidian notes directly into Claude Code? Not at first. Copying the note by hand into the template works fine. Once you find yourself repeating the same task again and again, considering automation isn’t too late.

Q. Even when I write “do not write any code yet,” it starts implementing. Stating “do not write code during request conversion” in your project’s CLAUDE.md makes it stable. A project-wide rule is followed more reliably than a one-off instruction in a prompt.

Q. How long should a request be? I aim for roughly 10 lines total across the six headings. Longer than that is a sign that multiple purposes are mixed into one task. Split the task.

Q. I don’t know what to put in proof. When in doubt, start with two: “build passes” and “the look of the live URL.” Those two alone get you out of swallowing the completion report whole.

What I found when I actually tried it

I took the nudge-link note from the opening, trimmed it with this six-field template, and handed it to Claude Code again. This time no summary came back. The first thing out was an implementation plan: “add one announcement section to the first screen.” The payment processing I’d listed in the no-touch zone wasn’t touched at all.

On the verification script side, I deliberately emptied noTouch and ran it, and it stopped with “missing required fields” before producing the request. I confirmed that the most common accident, handing it over with a blank field, gets prevented before execution.

Cranking out a clever instruction every time is slower than holding one habit for trimming a note. That’s my honest takeaway right now. If you want to extend the same approach to your team’s article production and inquiry handling, business training and consultation helps you build the habit around your actual operations. You can check the official baseline in Anthropic’s official documentation.