<h2>The itch</h2><p>You know the moment. You come back to a project you haven't touched in three weeks. There's something you need to run to get the dev server up — was it <code>pnpm dev</code>? Was there a flag? Did you need to start the database first?</p><p>So you go hunting. Maybe it's in a Notion page. Maybe an Obsidian vault. Maybe a <code>NOTES.md</code> you opened once and never again. You find the command, you select it, you ⌘C, you switch to your terminal, you ⌘V, you press enter… and it's the wrong command, because the note was from two refactors ago.</p><p>The knowledge was there. It just lived a world away from the place you actually do the work.</p><p>That's the itch Runbooks scratches. Notes shouldn't sit in a separate app, behind a separate window, describing your project from the outside. They should live next to the terminal, in the project, and the commands in them should just run.</p><h2>The philosophy: notes that <em>do</em>, not notes that <em>think</em></h2><p>Conductor has one hard rule it never breaks: <strong>it orchestrates, it doesn't reason.</strong> It launches terminals, splits panes, opens editors, runs your tasks — but it never calls a model, never holds an API key, never invents a prompt. All the thinking lives in external tools (like the Elyra CLI). Conductor is the cockpit, not the pilot's brain.</p><p>Runbooks fit that rule perfectly. They don't summarize your project with AI. They don't auto-generate anything. They're just plain markdown files — on disk, in your repo, readable in any editor — with one superpower: the things written in them are clickable and runnable.</p><p>No server. No account. No magic. Just:</p><pre><code>your-project/.conductor/notes/dev.md
</code></pre><p>Commit it and your whole team gets the same runbook. Add <code>.conductor/</code> to <code>.gitignore</code> and it stays yours. Your call.</p><h2>How it works, with examples</h2><p>A runbook is markdown. You write it like you'd write any note:</p><pre><code class="language-markdown"># Onboarding

Welcome! Here's everything you need to get going.

## 1. Install
```bash
pnpm install
```

## 2. Start the app
```bash
pnpm dev
```
</code></pre><p>Open it in Conductor (⌘K → <strong>Open project runbook</strong>, or right-click a folder → <strong>Open runbook here</strong>), and those code blocks aren't just pretty — each one grows a <strong>▶ Run</strong> button. Click it, and the command goes straight into the project's terminal. No copy. No paste. No tab-juggling. It even reuses the terminal you already have open for that project.</p><p>That alone would be enough. But two more touches make it feel like a real cockpit.</p><h3><code>[[file]]</code> — jump to the code</h3><p>Runbooks love to reference files. So link them, Obsidian-style:</p><pre><code class="language-markdown">## Where things live
- [[src/App.svelte|The main UI]]
- [[src-tauri/src/projects.rs]]   ← git scanning
- [[README.md]]
</code></pre><p>Click one and it opens right there in the inline editor. Relative paths resolve against the project root; the label after <code>|</code> is optional. Your onboarding doc becomes a guided tour of the codebase.</p><h3><code>[[task:name]]</code> — run the things you already defined</h3><p>If your <code>package.json</code>, <code>Makefile</code>, <code>justfile</code>, or <code>composer.json</code> already declares scripts, you don't need to repeat the commands. Just reference them:</p><pre><code class="language-markdown">## Common tasks
[[task:dev]]  ·  [[task:build]]  ·  [[task:test]]
</code></pre><p>Each becomes a little <strong>▶</strong> chip. Click it and Conductor finds that task and runs its real command in the terminal. If the name doesn't match a known task, the text runs literally — so <code>[[task:npm run lint]]</code> works too, ad hoc.</p><h3>Put it together</h3><pre><code class="language-markdown"># Deploy runbook

## Pre-flight
- [ ] Bump version in [[package.json]]
- [ ] Update [[CHANGELOG.md]]

## Build &amp; ship
[[task:build]]

```bash
./scripts/release-build.sh
```

&gt; Stored in `.conductor/notes/` — versioned with git.
</code></pre><p>Checklists you tick, files you open, tasks you run, raw commands you fire — all in one calm, readable page that lives with the project.</p><h2>Why this beats a wiki tab</h2><p>It's not that Notion or Obsidian are bad — they're wonderful for sprawling knowledge. But a runbook isn't knowledge you <em>browse</em>; it's knowledge you <em>do</em>. And the distance between "reading the step" and "running the step" is exactly where projects rot.</p><p>By keeping runbooks as local markdown, you get the best of both worlds: the file is greppable, diffable, reviewable in a PR, and readable on GitHub — but inside Conductor it comes alive. No lock-in, no export dance. It's just a <code>.md</code> file that happens to have a play button.</p><h2>The cozy part</h2><p>Here's the feeling we were chasing: you open a project, hit ⌘K, open its runbook, and everything you need is right there — install, run, the files that matter, the tasks you forgot. One click and you're working. The project remembers how to be worked on, so you don't have to.</p><p>That's the whole idea. Notes that meet you where you already are — next to the terminal — and quietly do the boring parts for you.</p><p>Go write one. Start with three lines:</p><pre><code class="language-markdown"># Dev
```bash
pnpm dev
```
</code></pre><p>Then click <strong>▶</strong>. Welcome home. 🪵🔥</p><hr><p><em>Runbooks shipped in Elyra Conductor v0.2.0. Like everything in Conductor, they only run and display — the thinking stays in your tools, not your cockpit.</em></p>