Personal Project Management System Using Claude Code and Obsidian: Architecture and Questions

System Architecture Overview

A developer is designing a personal project management system using Claude Code and Obsidian to bring professional PM practices to personal life. The system has three layers:

• File system (OneDrive): Stores files of record only—PDFs, attachments, receipts. Nothing executable lives here.
• Obsidian vault: Acts as the knowledge and tracking layer. All project logs, plans, dashboards, and daily notes reside here.
• Claude Code: Serves as the ingestion engine that reads, routes, and writes content. Most of this layer operates without manual intervention.

Two-Claude Setup and Handoff

The developer uses Claude Code on a laptop for building and Claude.ai on a phone for planning, drafting, and mobile capture. To bridge the context gap, a handoff document—a single markdown file in the vault—describes the full architecture, including folder structure, routing rules, naming conventions, active project status, and build phase progress. Claude.ai loads this document at the start of every session to maintain consistency, ensuring it never proposes folder paths or file names outside the documented conventions. Claude.ai acts as the architect's office, while Claude Code functions as the construction crew.

Daily Log and Command Structure

All inputs flow through a single daily log file written in plain language. Claude Code processes this log and routes entries to appropriate locations: risks to the risk register, decisions to the decision log, actions to a running action list, and blockers get flagged. Two slash commands drive the system:

• /daily: Processes the day's log, routes entries, updates project files, and updates the action list. No slides or emails—just routing.
• /pm-sync: Performs heavier tasks—reads all project files, writes updates, drafts status emails, generates weekly slide content, and updates a master dashboard.

Project Structure and Governance

Each project includes a suite of files based on complexity, with three tiers: Light (index.md and milestones.md), Mid (adds risks.md and decisions.md), and Heavy (full suite). Claude determines the tier through intake questions when a new project is logged. Key files include:

• index.md: Current state snapshot with health, stage, exit criteria, and stakeholders.
• log.md: Chronological journal for day-by-day tracking, serving as an ADHD accommodation for context recovery.
• Structured logs: milestones.md, risks.md, decisions.md, issues.md, assumptions.md, lessons-learned.md.

Governance features include: Claude never auto-closes a milestone—it flags it and waits for explicit approval via "I Approve [ID]". Scope creep is flagged automatically if work expands beyond a project's exit criteria, with suggestions to spin it off as a separate project. New project ideas captured in the daily log trigger a five-question intake process before building begins.

Domain vs. Project Distinction

The system distinguishes between projects and ongoing domains (e.g., budgeting, fitness tracking, home maintenance). Domains get tracker files and notes instead of project logs, ensuring no risk registers are created for routine tasks like espresso machine descaling schedules.

Developer Questions for Feedback

The developer seeks input on:

1. Whether the two-command structure (/daily and /pm-sync) makes sense or overcomplicates routing.
2. The use of log.md as a chronological journal separate from structured logs—does it hold up over time or become noise?
3. The control gate pattern requiring explicit approval to close milestones—is it useful friction or just friction?
4. The two-Claude setup with a shared handoff doc as a bridge for mobile/desktop context—are others solving this gap similarly?
5. Experiences running Obsidian + Claude Code together—what broke?