Build a Local Execution Engine

Turn your Obsidian vault into a work command center with Claude Code.

Introduction

30 Second Summary

You have a system that stores what you know. But knowing things and actually getting things done are two separate challenges.

In this project, you will build an execution engine inside your Obsidian vault that turns your AI Second Brain from a knowledge base into a work command center. Claude Code tracks your deliverables, blockers, and daily progress as interlinked Markdown files.

What You'll Build

You type "plan my day" and Claude Code reads your deliverables backlog, checks for blockers, cross-references your wiki pages about each project, and generates a focused daily plan right inside your vault.

By the end of this project, you'll have:

  • A daily planning workflow where you ask "what should I work on today?" and get a prioritized plan grounded in your actual backlog and project context.
  • Four new slash commands (/plan, /done, /blocked, /status) that orchestrate your work alongside natural language instructions.
  • An Obsidian graph view where execution data connects to your knowledge wiki, showing tasks and blockers linked to projects and concepts.
  • Secret Mission: A /retro command that generates weekly retrospectives from your daily logs.

Are there any prerequisites?

This project is Part 2 of the AI Second Brain series. You need a working vault from Part 1 containing raw/, wiki/, CLAUDE.md, and the original four slash commands (/ingest, /query, /lint, /log).

Before We Start

Before We Start...

Before we dive in, let's get clear on what you're building in this project and why it changes how you manage your work day-to-day.

Set Up the Execution Folder Structure

Your Part 1 vault stores what you know across raw/ and wiki/. But it has no system for tracking what you're actively doing.

In this step, you'll create a dedicated execution/ folder that keeps task data separate from knowledge data. This mirrors the same separation pattern from Part 1, where raw/ stays separate from wiki/.

In this step, get ready to:
  • Confirm your Part 1 vault structure is intact.
  • Create the execution/ folder with template files for your backlog, daily focus, blocker log, and daily logs.
  • Verify the new structure appears in Obsidian.
Navigate to your vault and start Claude Code

Your Part 1 vault already has the knowledge layer you built. Before creating anything new, you need to confirm everything is still in place.

  • Press Cmd+Space (macOS) to open your search bar.
  • Type Terminal and press Enter to open it.
  • Navigate to your Part 1 vault folder by running this command:
cd ~/Desktop/[[VAULT_FOLDER="your-vault-folder-name"]]
  • Confirm your existing vault structure by running:
ls

You should see CLAUDE.md, raw/, wiki/, and .claude/ in the output.

Don't see these folders?

Make sure you navigated to your Part 1 vault root (the folder containing CLAUDE.md). If you renamed or moved your vault since Part 1, adjust the cd path accordingly.

Help me find my Part 1 vault folder on my Mac.

  • Start a Claude Code session by running:
claude
  • Once Claude Code starts, confirm it loaded your vault's memory file by checking that it greets you or references your project context.

How does Claude Code know your vault?

Claude Code reads CLAUDE.md files by walking up the directory tree from your current working directory. Since you started Claude Code inside your vault root, it automatically loaded the CLAUDE.md you created in Part 1.

Ask Claude Code to create the execution folder

Your vault needs a new top-level folder called execution/ that holds four components: a deliverables backlog, a daily focus file, a blocker log, and a subfolder for daily log snapshots.

  • Ask Claude Code to create the full execution structure by typing this message:
Create an execution/ folder in my vault root with these template files:

1. execution/backlog.md - master list of all deliverables with YAML frontmatter (title: Deliverables Backlog, type: execution, created and last-updated dates). Include an Active section with a template showing the format for each deliverable (Status, Priority, Project wiki-link, Due date, Context, and Next Actions checkboxes), and a Completed section.

2. execution/active.md - today's focus file with YAML frontmatter (title: Today's Focus, type: execution). Include placeholder sections for Priority Tasks, Blockers to Resolve, and Context. Note that this file gets regenerated each morning by /plan.

3. execution/blockers.md - append-only blocker log with YAML frontmatter (title: Blocker Log, type: execution). Include Open Blockers and Resolved Blockers sections, both starting with (none yet).

4. execution/log/ subfolder with a README.md explaining that daily logs use YYYY-MM-DD.md naming and capture morning plans, completions, new blockers, and status snapshots.

What does this create?

You're giving Claude Code a detailed specification so it creates files with the right structure from the start. Each template uses YAML frontmatter (the metadata between --- markers) to stay consistent with your Part 1 wiki pages.

The backlog.md file tracks all your deliverables. active.md holds your daily plan. blockers.md captures anything blocking progress. The log/ folder stores one snapshot per day so you have a history of your work.

  • Claude Code will ask for permission to create these files. Approve the file creation when prompted.

After Claude finishes, you should see confirmation messages listing each file it created.

Verify the structure in Obsidian

The files now exist on disk. Before moving on, confirm they show up correctly in Obsidian and match the expected structure.

  • Before you run the verification command, predict what you expect to see inside execution/.
  • Verify the folder structure from within Claude Code by typing:
ls execution/

You should see backlog.md, active.md, blockers.md, and a log/ subfolder.

  • Switch to Obsidian. Look at the left sidebar and confirm you see the execution folder with all four files nested inside it.
  • Click on backlog.md in the Obsidian sidebar. Confirm it has YAML frontmatter at the top (between --- markers) and contains an Active section with a deliverable template and a Completed section.
  • Click on active.md. Confirm it has sections for Priority Tasks, Blockers to Resolve, and Context.
  • Click on blockers.md. Confirm it has Open Blockers and Resolved Blockers sections.

Don't see the execution folder in Obsidian?

Obsidian may take a moment to detect new files. Try clicking anywhere in Obsidian or switching to another app and back. If the folder still doesn't appear, make sure you're looking at the same vault folder that Claude Code is running in.

Help me get my new execution/ files showing in Obsidian.

✔️ Awesome, I've got everything!

Great. Double check you see all four files in Obsidian's sidebar and that each one opens without errors.

ⓧ I'd like to double check the full code

Here's what each file should contain. Compare yours against these templates.

Your execution/backlog.md should match:

---
title: Deliverables Backlog
type: execution
created: 2026-07-24
last-updated: 2026-07-24
---

# Deliverables Backlog

All active and completed deliverables. Each entry uses the format below.

## Active

### [Deliverable Name]

- **Status:** not-started | in-progress | blocked | done
- **Priority:** p0 | p1 | p2
- **Project:** [[project-page-name]]
- **Due:** YYYY-MM-DD
- **Context:** Brief description of what this deliverable is and why it matters.

#### Next Actions

- [ ] First concrete step
- [ ] Second concrete step

---

## Completed

Deliverables moved here when marked done via /done or natural language.

Your execution/active.md should match:

---
title: Today's Focus
type: execution
created: 2026-07-24
last-updated: 2026-07-24
---

# Today's Focus

Generated by /plan or natural language. Regenerated each morning.

## Priority Tasks

(populated by /plan)

## Blockers to Resolve

(populated by /plan from blockers.md)

## Context

(populated by /plan from relevant wiki/ pages)

Your execution/blockers.md should match:

---
title: Blocker Log
type: execution
created: 2026-07-24
last-updated: 2026-07-24
---

# Blocker Log

Append-only log of blockers. Each entry includes timestamp, description, linked project, and resolution status.

## Open Blockers

(none yet)

## Resolved Blockers

(none yet)

Your execution/log/README.md should match:

# Daily Execution Logs

One file per day: YYYY-MM-DD.md

Each daily log captures:
- Morning plan (from /plan)
- Completions (from /done or natural language)
- New blockers (from /blocked or natural language)
- Status snapshots (from /status)

These logs are the raw material for /retro weekly retrospectives.

Dates may differ

The created and last-updated dates in your frontmatter will reflect the day you ran the command. That's expected. The structure and content are what matter.

Why a separate execution/ folder?

Keeping execution data in its own folder means your knowledge wiki (wiki/) stays clean. You can browse concepts and projects without wading through task logs. It also means you could archive or reset your execution layer without touching your knowledge base.

Your execution folder structure is in place. Next up, you'll fill your backlog with real deliverables and see them light up in Obsidian's Graph View.

Populate Your Backlog with Real Deliverables

Your execution folder is in place with its template files. Now you need something real inside them.

An empty system teaches nothing. By adding your actual deliverables and linking them to existing wiki pages, you get the first visible payoff: your tasks appear in Obsidian's graph view connected to the projects and concepts you already captured in Part 1.

In this step, get ready to:
  • Populate your backlog with real deliverables linked to wiki pages.
  • Verify connections between execution and wiki data in Obsidian's Graph View.
  • Test a natural language task query and observe the gap it reveals.
Ask Claude Code to populate your backlog

Claude Code can read your existing wiki/projects/ folder to understand what you're working on. It uses that context to help you create deliverables that link back to those pages.

  • In your Claude Code session, ask Claude to read your wiki and help populate the backlog by typing this message:
Read wiki/projects/ and wiki/index.md to understand my current projects. Then help me populate execution/backlog.md with 2-3 real deliverables I'm working on. For each one, use the template format already in backlog.md: YAML frontmatter with status, priority, project link (as a [[wiki-link]] to the relevant wiki page), and due date. Include a Context line and Next Actions checkboxes.

What does this prompt do?

You're asking Claude to cross-reference your existing wiki knowledge with new task data. Each deliverable it creates will include a [[wiki-link]] pointing to a project page in your wiki, which is how Obsidian connects nodes in its graph.

Claude will ask you clarifying questions about what you're actually working on. Answer with real projects and tasks. The more genuine your deliverables are, the more useful this system becomes.

  • Answer Claude's follow-up questions about your current projects and priorities.
  • Once Claude finishes writing, confirm it saved to execution/backlog.md by asking Claude to show the file contents.

You should see 2-3 deliverables under the ## Active heading, each with frontmatter fields and at least one [[wiki-link]] pointing to a page in your wiki.

Deliverables missing wiki-links?

If Claude created deliverables without [[wiki-links]], ask it to re-read wiki/projects/ and match each deliverable to an existing project page. The links must use the exact filename of a wiki page for Obsidian to recognize the connection.

If you don't have project pages in your wiki yet, ask Claude to create one in wiki/projects/ for each deliverable first, then link to it.

Help me fix my wiki-links in the backlog

Verify connections in Obsidian's Graph View

The real payoff of wiki-linking your deliverables is seeing them connected to your knowledge base visually. Graph View draws lines between any files that reference each other.

  • Switch to Obsidian and open your vault.
  • Open execution/backlog.md from the sidebar and confirm your deliverables appear with their frontmatter and wiki-links.
  • Open Graph View by pressing Cmd+P to open the Command Palette, then typing Graph view and selecting Open graph view.

You should see nodes for your execution/backlog.md file connected via lines to your wiki/ project pages. Each [[wiki-link]] in your backlog creates a visible edge in the graph.

What am I seeing in Graph View?

Each dot is a file in your vault. Lines between dots represent [[wiki-links]]. Your execution data (tasks and deliverables) is now visually connected to your knowledge wiki (project pages, concepts, people).

This is what makes this system more powerful than a standalone task app. Your tasks live alongside the context that informs them.

Not seeing connections in Graph View?

Make sure the [[wiki-links]] in your backlog use the exact filename of the target wiki page (without the .md extension). Obsidian only draws edges when filenames match exactly.

Also check that the Graph View filter isn't hiding the execution/ folder. Click the filter icon in Graph View and ensure no path exclusions are active.

Help me troubleshoot my Graph View connections

Test a natural language query about your backlog

Your backlog has real deliverables linked to your wiki. Claude Code can read those files and give you an answer about priorities. But how structured is that answer?

  • Switch back to your Claude Code session in the terminal.
  • Before you type anything, predict: do you think Claude will just answer your question, or will it also update files like active.md and create a daily log entry?
  • Ask Claude this question:
Based on my backlog, what should I focus on today?

Read Claude's response carefully. It gives you a reasonable answer about priorities based on what it sees in execution/backlog.md.

  • Now check: did Claude write anything to execution/active.md? Ask Claude to show you the contents of that file.
  • Check execution/blockers.md too. Did Claude consult it before answering?
  • Check execution/log/ for a daily log file. Did Claude log anything?

The answer is no to all three. active.md still has placeholder text. blockers.md was never checked. No daily log was created. Claude gave you an ad-hoc answer without following any execution system.

Why did Claude skip the execution system?

Claude Code reads files when you ask, but it has no rules telling it to treat execution/ as a structured system. Without execution rules in CLAUDE.md, Claude treats your folder as just more files rather than a workflow it actively maintains.

This is the gap. A good answer about priorities is not the same as a systematic execution engine that updates your active focus, checks blockers, and logs every action. That gap is exactly what the next step fixes.

You've seen the gap firsthand. Claude can read your backlog and answer questions, but it doesn't maintain your execution system. Next up, you'll teach Claude the rules that turn ad-hoc answers into structured, logged execution actions.

Teach Claude the Execution Rules

In the previous step, you asked Claude Code about your priorities and got a reasonable answer. But Claude did not write anything to active.md, did not check blockers.md, and did not log a thing. It treated your execution folder as just more files to read, not a system it maintains.

The fix is encoding execution rules into CLAUDE.md. Since Claude Code loads this file at session start, adding a dedicated "Execution Engine" section teaches Claude how to handle both natural language triggers and slash commands with structured, logged behavior.

In this step, get ready to:
  • Add an "Execution Engine" section to CLAUDE.md with folder rules, schema, and natural language triggers.
  • Restart Claude Code and verify "plan my day" now produces structured, logged output.
  • Test the "I finished X" trigger and confirm it updates your backlog and logs the action.
Add execution rules to CLAUDE.md

CLAUDE.md is Claude Code's project memory. It gets loaded at session start and shapes every response. Right now, your CLAUDE.md from Part 1 only has rules about the wiki layer (page conventions, style guide, domain context). It knows nothing about execution tracking.

  • In your Claude Code session, ask Claude to add an "Execution Engine" section to your existing CLAUDE.md. Tell it the section should define:
  • The execution/ folder structure and ownership rules (co-owned by user and Claude, unlike the strict raw=user / wiki=Claude split).
  • The backlog schema: YAML frontmatter fields including title, status (not-started, in-progress, blocked, done), priority (p0, p1, p2), project ([[wiki-link]]), and due date.
  • Natural language trigger phrases and their corresponding execution behaviors. Phrases like "I finished X", "I'm blocked on Y", and "what should I work on" should trigger structured execution actions.
  • The logging rule: every execution action appends a timestamped entry to execution/log/YYYY-MM-DD.md.

Why put these rules in CLAUDE.md?

CLAUDE.md is delivered as context, not enforced configuration. Specific, concise, well-structured instructions work best for adherence. By encoding execution rules here, both natural language conversations and slash commands inherit the same structured behavior.

This is the difference between Claude "seeing" your files and Claude "maintaining" them as a system.

  • After Claude finishes writing, open CLAUDE.md in Obsidian and verify the new "Execution Engine" section is present.
  • Confirm it includes all four elements: folder structure rules, backlog schema, natural language triggers, and the daily logging rule.

Keep CLAUDE.md concise

If your CLAUDE.md is growing long, ask Claude to keep the Execution Engine section under 50 lines. Concise, well-structured rules get better adherence than verbose ones.

Claude didn't add the section?

If Claude asks for clarification or adds the rules to a different file, be explicit: "Add a new section called Execution Engine to my existing CLAUDE.md file at the vault root." Claude sometimes creates new files instead of editing existing ones when the instruction is ambiguous.

help me add execution rules to my CLAUDE.md file

Restart Claude Code and test "plan my day"

Claude Code reads CLAUDE.md when a session starts. Your current session loaded the old version without execution rules. You need to restart for the new rules to take effect.

  • Exit your Claude Code session by running:
/exit
  • Start a fresh session by running:
claude
  • Confirm the updated CLAUDE.md is loaded by running /context in your session. Check the "Memory files" list includes your vault's CLAUDE.md.

Now for the real test. In Step 2, you asked Claude about your priorities and got an ad-hoc answer with no file updates. Before you try again, predict: what should happen differently this time?

  • Type "plan my day" into your Claude Code session and press Enter.
  • Watch Claude's output. This time it should read backlog.md, check blockers.md, write a prioritized plan to execution/active.md, and create a log entry in execution/log/.
  • Open execution/active.md in Obsidian. It should now have a prioritized task list instead of the placeholder text.
  • Open the execution/log/ folder. You should see a new daily log file (today's date in YYYY-MM-DD.md format) with a timestamped plan entry.

The same question that produced an ad-hoc answer in Step 2 now produces structured, logged output. That is the power of CLAUDE.md rules.

Claude still giving ad-hoc answers?

Run /context to confirm your CLAUDE.md is listed in the loaded memory files. If it is not listed, make sure you restarted from the vault root directory (where CLAUDE.md lives).

If CLAUDE.md is loaded but Claude still gives unstructured answers, check that the Execution Engine section includes explicit trigger phrases. Ask Claude to read its own CLAUDE.md and explain what execution rules it sees.

help me debug why Claude isn't following execution rules

Test the completion trigger

Planning works. Now test the second natural language trigger: marking a deliverable as done.

  • Pick one of the deliverables you added to your backlog in Step 2. Type "I finished [that deliverable's name]" into Claude Code.
  • Watch Claude's response. It should update execution/backlog.md (marking it done), log the completion to today's daily log, and offer to update the linked wiki page.
  • Open execution/backlog.md in Obsidian. Confirm that your deliverable has moved from the "Active" section to "Completed" with its status set to done.
  • Open today's daily log in execution/log/. Confirm there is a new timestamped completion entry alongside the earlier plan entry.

Why does Claude offer to update the wiki page?

Each backlog deliverable links to a wiki page via [[wiki-links]]. When you complete a deliverable, that project's wiki page is now out of date. Claude recognizes this and offers to update it. This is where the execution layer and your knowledge wiki connect.

You can accept or decline the wiki update. Either way, the completion is logged.

Claude didn't find your deliverable?

If Claude says it cannot find the deliverable, try using the exact heading text from your backlog.md file. Claude matches your input against the deliverable headings in the Active section. A partial match should still work, but an exact heading is most reliable.

help me mark a deliverable as done

Your execution engine now responds to natural language. Claude reads your backlog, checks for blockers, writes structured plans, logs every action, and keeps your wiki connected. Next up, you will turn these behaviors into fast, predictable slash commands.

Build the Slash Commands

In the last step, you proved that natural language triggers work. Claude Code now updates your execution files when you say things like "I finished X" or "plan my day." But typing a full sentence every time you want a structured action is slower than it needs to be.

Slash commands give you fast, predictable entry points. Typing /plan is quicker than explaining what you want. The commands also serve as documentation of exactly what each workflow does, so you can read them later and remember the system's behavior.

In this step, get ready to:
  • Create four new slash command files in .claude/commands/.
  • Restart Claude Code and test /plan to generate a prioritized daily focus.
  • Test /done and /status to confirm the full workflow.
Ask Claude Code to create the slash commands

Each slash command is a Markdown file in .claude/commands/ that tells Claude Code exactly what to do when you invoke it. You already have four commands from Part 1. Now you need four more for execution workflows.

  • In your Claude Code session, ask Claude to create the four execution slash commands. Tell it to create these files in .claude/commands/:
  • plan.md - reads backlog, blockers, and wiki context to generate today's prioritized focus. Writes the plan to execution/active.md and logs it. Accepts an optional focus area via $ARGUMENTS.
  • done.md - takes a deliverable name via $ARGUMENTS, marks it complete in execution/backlog.md, logs the completion, and offers to update the linked wiki page.
  • blocked.md - takes a blocker description via $ARGUMENTS, appends it to execution/blockers.md with a timestamp and wiki-links, and updates affected backlog items.
  • status.md - synthesizes a progress report from backlog, blockers, and recent daily logs. Displays in the conversation. Accepts an optional project name via $ARGUMENTS.

Give Claude the full picture

The more specific you are about each command's behavior, the better Claude Code will write them. Mention the frontmatter fields (description and argument-hint), the files each command should read and write, and the logging rule.

  • After Claude creates the files, confirm they exist by running this in your terminal:
ls .claude/commands/

You should see your four original Part 1 commands (ingest.md, query.md, lint.md, log.md) plus the four new ones (plan.md, done.md, blocked.md, status.md).

  • Open each new file in Obsidian to confirm it has YAML frontmatter with description and argument-hint fields, followed by numbered instructions for Claude.

Claude only created some of the files?

If Claude created fewer than four files, ask it to create the missing ones specifically by name. For example: "You're missing blocked.md and status.md in .claude/commands/ - please create those too."

Help me get Claude Code to create all four slash commands

✔️ Awesome, I've got everything!

Great. Double check that each file has a description and argument-hint in its frontmatter, then move on to testing.

ⓧ I'd like to double check the full code

Here is what each slash command file should contain. Compare yours against these references.

plan.md:

---
description: Generate today's prioritized focus from backlog, blockers, and wiki context.
argument-hint: [optional focus area]
---

Read execution/backlog.md and execution/blockers.md. Also read wiki/index.md to understand the full project landscape.

Generate today's prioritized daily plan:

1. Identify the highest-priority non-blocked deliverables from the backlog.
2. Check blockers.md for any open blockers that could be resolved today.
3. For each priority task, read the linked wiki page (the [[project]] link in the backlog entry) to pull in relevant context: who is involved, what decisions were made, what the current state is.
4. If $ARGUMENTS is provided, weight the plan toward that focus area.

Write the plan to execution/active.md (overwrite previous content). Include:
- Priority Tasks: the 2-4 things to focus on today, with brief context from wiki
- Blockers to Resolve: any open blockers that might be clearable today
- Context: key information from wiki pages relevant to today's tasks

Then append a timestamped entry to execution/log/YYYY-MM-DD.md (create the file if it does not exist) recording that a plan was generated and listing the priority tasks.

Keep the plan concise and actionable. Do not copy entire wiki pages into active.md. Summarize relevant context in 1-2 sentences per task.

done.md:

---
description: Mark a deliverable as complete and log the achievement.
argument-hint: deliverable name or description
---

Find the deliverable matching $ARGUMENTS in execution/backlog.md.

1. Update its status to "done" and move it from the Active section to the Completed section. Add a completion date.
2. Check off any remaining next-action checkboxes for that deliverable.
3. Append a timestamped completion entry to execution/log/YYYY-MM-DD.md (create the file if it does not exist).
4. If the deliverable links to a wiki page via [[project-name]], read that wiki page and offer to update it with the completion (e.g., update project status, note the milestone). Ask before writing to wiki/.
5. Update the last-updated field in execution/backlog.md frontmatter.

If no matching deliverable is found, list the current active deliverables and ask the user to clarify which one they mean.

blocked.md:

---
description: Log a blocker with context and project links.
argument-hint: description of the blocker
---

Capture a new blocker from $ARGUMENTS:

1. Parse the blocker description. Identify any project, person, or concept that has a wiki page and create [[wiki-links]] to them.
2. Append a new entry to the "Open Blockers" section of execution/blockers.md with:
   - Timestamp (ISO 8601)
   - Description (from $ARGUMENTS, with wiki-links added)
   - Linked project (from context or ask if unclear)
   - Impact: which backlog deliverables this blocks
3. Append a timestamped blocker entry to execution/log/YYYY-MM-DD.md (create the file if it does not exist).
4. If any deliverables in backlog.md depend on what is now blocked, update their status to "blocked".
5. Suggest one concrete unblocking action if possible (e.g., "ping @person", "try alternative approach from [[concept-page]]").

Keep the blocker entry concise. One blocker per invocation.

status.md:

---
description: Synthesize progress across backlog, blockers, and recent logs.
argument-hint: [optional project name to focus on]
---

Generate a status report by reading:
- execution/backlog.md (all deliverables and their current states)
- execution/blockers.md (open and recently resolved blockers)
- execution/log/ (the last 3 daily log files for recent activity)
- If $ARGUMENTS names a project, also read that project's wiki page for deeper context.

Produce a status report covering:

1. Summary: one paragraph on overall progress.
2. Completed Recently: deliverables marked done in the last 3 days.
3. In Progress: what is actively being worked on and current state.
4. Blocked: open blockers and their impact on deliverables.
5. Needs Attention: deliverables with no activity in 3+ days, or projects with no next action defined.
6. Suggested Next Steps: based on priority, blockers, and wiki context.

If $ARGUMENTS focuses on a specific project, scope the report to deliverables linked to that project only.

Do not write this report to a file unless the user asks. Display it in the conversation. If the user says "save it" or "log it", append to today's daily log.
Restart Claude Code and test /plan

New slash commands require restarting the Claude Code session to be discovered. Until you restart, Claude won't recognize the new /plan, /done, /blocked, or /status commands.

  • Exit your current Claude Code session by typing /exit.
  • Start a new session by running:
claude
  • Once Claude Code loads, test the new planning command by typing:
/plan

Watch Claude Code read your backlog, check blockers, and pull wiki context. It writes a prioritized plan to execution/active.md and appends a log entry to today's daily file.

  • Open execution/active.md in Obsidian. Confirm it now contains a prioritized plan with your actual deliverables listed under Priority Tasks, not the placeholder text from before.
  • Check execution/log/ in Obsidian's sidebar. You should see a new daily file (today's date) with a log entry recording that a plan was generated.

Claude says it doesn't recognize /plan?

Make sure you fully exited the previous session with /exit before starting a new one. If you just opened a new terminal tab, the old session might still be running.

Also confirm that plan.md is in .claude/commands/ (not a subfolder or typo). Run ls .claude/commands/plan.md to check.

Help me troubleshoot why /plan isn't recognized

Test /done and /status

The planning command works. Now test the two remaining commands that complete the daily workflow loop: marking things done and checking overall status.

  • Pick one deliverable from your backlog that you can realistically mark as complete (or pick one to test with). Run /done followed by the deliverable name. For example:
/done API documentation draft

What should happen?

Claude should find the matching deliverable in execution/backlog.md, move it to the Completed section, log the completion, and ask if you want to update the linked wiki page.

If no exact match is found, Claude should list your active deliverables and ask which one you meant.

  • Open execution/backlog.md in Obsidian. Confirm the deliverable moved from the Active section to the Completed section with a completion date.
  • Check today's daily log file in execution/log/. It should now have a completion entry in addition to the earlier plan entry.

Now for the final test. Before you run /status, think about what you expect to see. You have a backlog with deliverables, one item just marked done, and a daily log with today's activity. What would a useful status report include?

  • Run the status command:
/status

Claude displays a synthesized progress report right in the conversation. It covers what you completed recently, what is in progress, any blockers, and suggested next steps. The report references your backlog, blockers, and today's daily log together.

Why does /status display instead of saving?

Unlike /plan which writes to active.md, the status report stays in the conversation by default. This keeps your vault clean. If you want to save a snapshot, just tell Claude "log it" and it appends the report to today's daily log.

Status report seems incomplete?

If the report is missing sections (like "Completed Recently" is empty even though you just ran /done), Claude may not be reading the daily log files. Ask Claude to run /context to confirm your CLAUDE.md is loaded, then try /status again.

Help me figure out why /status is missing data

Your execution engine now has four fast entry points that formalize everything the natural language triggers do. Next up, you will run a complete daily workflow from start to finish to prove the whole system holds together.

Run Your Daily Workflow

Your slash commands work individually. You can plan, mark things done, log blockers, and check status. But individual commands are not the same as a daily workflow.

The real value of this execution engine shows up when you run a full work session: start the day with a plan, record progress as you work, and close with a status report. In this step, you will run through that complete cycle and see how wiki context makes your execution engine smarter than a standalone task list.

In this step, get ready to:
  • Run /plan and observe wiki context woven into your prioritized tasks.
  • Log completions and blockers using a mix of natural language and slash commands.
  • Run /status for a synthesized progress report across everything.
Generate today's plan with /plan

A daily planning session is where the execution engine earns its keep. Instead of scanning your backlog yourself and trying to remember what matters, Claude Code reads your deliverables, checks for blockers, and pulls in relevant context from your wiki pages.

  • In your Claude Code session, type /plan and press Enter.
/plan

Claude Code reads your execution/backlog.md, checks execution/blockers.md, and references your wiki pages to generate a prioritized plan.

  • Switch to Obsidian and open execution/active.md.

You should see a populated plan with 2-4 priority tasks. Each task includes a brief summary of context pulled from your linked wiki pages.

What makes this different from a plain task list?

Notice how each priority task references project background, people involved, or related concepts from your wiki. A plain task list only shows you the task name. Your execution engine pulls in the context you need to actually start working on each item.

  • Open execution/log/ in Obsidian's sidebar and confirm a new file named with today's date exists (e.g. 2026-07-24.md).
  • Open the daily log file. You should see a timestamped entry recording that a plan was generated, along with your priority tasks.

Don't see active.md updated?

If active.md still shows the template placeholders, Claude Code may not have had permission to write to the file. Check your Claude Code terminal for a permission prompt you may have missed.

If the daily log file was not created, confirm that execution/log/ folder exists. Run ls execution/log/ in a separate terminal tab to verify.

Help me troubleshoot why /plan did not update active.md or create a daily log file.

Log progress with completions and blockers

With your plan in place, the next phase of the daily cycle is recording what happens as you work. You can use either natural language or slash commands. Both produce the same structured result because your CLAUDE.md teaches Claude Code to recognize both.

  • Pick one of your active deliverables from the backlog and mark it done using natural language. Type something like the following (using your own deliverable name):
I just finished the auth endpoint docs

What should I see?

Claude Code should update execution/backlog.md (moving the deliverable from Active to Completed), append a timestamped completion entry to today's daily log, and offer to update the linked wiki page. Say yes when it asks about updating the wiki page.

  • Switch to Obsidian and open execution/backlog.md. Confirm the deliverable now appears under the ## Completed section with its status set to done.
  • Open today's daily log file in execution/log/. You should see the plan entry from earlier AND a new completion entry with a timestamp.

Now log a blocker using the slash command. This time you will use /blocked instead of natural language to see both interaction modes in action.

  • Type a /blocked command describing a real or plausible blocker. Use something relevant to your deliverables, like the following:
/blocked waiting on design team review for the dashboard mockups
  • Switch to Obsidian and open execution/blockers.md. Under ## Open Blockers, you should see a new entry with an ISO 8601 timestamp, your blocker description with [[wiki-links]] to relevant project pages, and an impact line naming which deliverables are affected.
  • Open today's daily log again. Confirm a new blocker entry now appears below the completion entry.

Blocker entry missing wiki-links?

If the blocker entry has no [[wiki-links]], Claude Code may not have found a matching wiki page for the project you mentioned. Check that the project name in your blocker description matches a page in your wiki/projects/ folder. You can re-run the command with a more specific project name.

Help me figure out why my /blocked command did not create wiki-links in the blocker entry.

Synthesize your progress with /status

The final phase of a daily workflow is stepping back to see the full picture. Your /status command reads across your backlog, blockers, and recent daily logs to synthesize a coherent progress report.

Before you run it, think about what you expect the report to contain. You have generated a morning plan, marked one deliverable done, and logged one blocker. What should the status report say?

  • Type /status and press Enter.
/status

You should see a structured report displayed in your Claude Code session covering: a summary paragraph, recently completed deliverables (including the one you just marked done), in-progress items, open blockers (including the one you just logged), items needing attention, and suggested next steps drawn from wiki context.

Why is this better than checking files manually?

You could open backlog.md and blockers.md yourself. But /status cross-references everything: it spots deliverables with no recent activity, identifies blockers that impact high-priority work, and pulls in wiki context to suggest what to do next. That synthesis is the work a project manager does in their head.

Now verify the full daily cycle left a complete trail in your vault.

  • Open today's daily log file in execution/log/ one more time.

You should see at least four timestamped entries: the morning plan, your completion, your blocker, and a status snapshot. This single file is your complete record of the day.

  • In Obsidian, open Graph View by pressing Cmd+G (or clicking the graph icon in the left sidebar).
  • Locate today's daily log node in the graph. You should see it connected via wiki-links to your project pages in wiki/ and to your backlog and blockers files.

Your execution data is now part of the same knowledge graph as your wiki. Tasks, blockers, and daily logs sit alongside concepts, projects, and people.

Daily log not connected in Graph View?

If the daily log node appears isolated (no connections), the log entries may not contain [[wiki-links]]. Open the daily log file and check whether the entries reference project pages using the [[page-name]] syntax. If they use plain text instead, the CLAUDE.md execution rules may need a stronger instruction to always include wiki-links in log entries.

Help me fix my daily log so it shows connections in Obsidian's Graph View.

Secret mission

Build a Weekly Retrospective Command

Daily logs pile up but you never look back at them individually. What if Claude Code could synthesize an entire week of logs into patterns, showing what got done, what kept getting blocked, and what to focus next week? Build a /retro command that turns your daily noise into weekly signal.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally with no persistent paid resources. Claude Code API costs only accrue when you actively run commands.

Resources you used:

  • execution/ folder containing backlog.md, active.md, blockers.md, and daily log files.
  • Updated CLAUDE.md with the Execution Engine section.
  • Four new slash commands in .claude/commands/ (plan.md, done.md, blocked.md, status.md).
  • If you completed the Secret Mission: retro.md in .claude/commands/ and retro-YYYY-WXX.md files in execution/log/.

Keep everything running

No action needed. Choose this if you plan to use your execution engine daily.

  • Your vault stays on disk with zero ongoing cost when idle.
  • Start each day by opening your terminal, navigating to your vault root, running claude, and typing /plan.
  • Costs only accrue when you actively run commands. Each /plan or /status call uses tokens.

Pause - I'll come back to this later

Shut down your Claude Code session to free up terminal resources. All your files stay on disk ready to resume.

  • Type /exit to close Claude Code.
  • Your execution/ files, CLAUDE.md, and all slash commands stay on disk.
  • When you return, navigate to your vault folder, run claude, and pick up where you left off.

Delete - I don't want to use this again

Remove all execution engine resources to revert to your Part 1 vault state. Your wiki/ and raw/ folders are untouched.

  • Delete the entire execution folder by running:
rm -rf execution/
  • Remove the four new slash commands by running:
rm .claude/commands/plan.md .claude/commands/done.md .claude/commands/blocked.md .claude/commands/status.md
  • If you completed the Secret Mission, also remove the retro command:
rm .claude/commands/retro.md
  • Open CLAUDE.md in your editor and delete the entire "Execution Engine" section you added in Step 3. Save the file.
  • Confirm everything is removed by running:
ls execution/ 2>&1
ls .claude/commands/

You should see an error for the first command (folder not found) and only your original Part 1 commands (ingest.md, query.md, lint.md, log.md) in the second.

That's a Wrap!

That's a Wrap!

Nice work. You just turned your Obsidian vault from a passive knowledge base into a live work command center, powered entirely by local Markdown files and Claude Code.

You've learned how to:

  • Built a local-first execution engine that tracks deliverables, blockers, and daily progress as interlinked Markdown files inside your Obsidian vault.
  • Created four new slash commands (/plan, /done, /blocked, /status) that orchestrate your work with full wiki context and natural language triggers.
  • Ran a complete daily workflow cycle proving the system generates context-aware plans, logs completions and blockers, and synthesizes progress reports grounded in your knowledge wiki.
  • Built a /retro command in the Secret Mission that synthesizes weekly patterns from your daily logs into actionable retrospectives.

Ready to quiz yourself?