A Non-Coder's File System Project Management Setup for Claude Desktop

Project Architecture for Sustained Knowledge Work

A non-technical user has developed a system to overcome limitations in Claude's chat-based project work. The core problem addressed is the dilution of Claude's effectiveness in long chats and the lack of reliable continuity between sessions. The solution uses Claude Desktop's Filesystem access to create persistent project directories that Claude can read and write to directly.

Directory Structure and Key Components

The user maintains nine projects across different domains (personal admin, finance, health, legal, research, etc.), each following this standardized directory layout:

[Project]/
  WORKFLOW.txt ← the entry point, read at startup
  Inbox/ ← two-way file exchange
  Workflow Files/
    HANDOFF.txt ← state snapshot, overwritten constantly
    REFERENCE.txt ← on-demand detail, NOT read at startup
    TASKS.txt ← active items only, on-demand
    Clock/timestamp.txt ← temporal awareness
  Lessons/
    LESSONS_INDEX.txt ← card catalog for accumulated knowledge
    [topic].txt
  Session Logs/
    Session_XXX.txt
  [Sub-Project A]/ ← shaped by the domain
  [Sub-Project B]/

Project Instructions Template

The user pastes identical instructions into every Claude project (changing only the filepath):

Workspace: All project files live on the filesystem at [path]. 
At session startup, call Filesystem:list_allowed_directories to confirm filesystem access. 
Then call Filesystem:list_directory on the project path to confirm you can read it. 
These tools provide full read and write access to the project filesystem, including write_file, edit_file, move_file, and create_directory. 
When Filesystem is available, read WORKFLOW.txt and follow its procedures. 
When Filesystem is unavailable, let the user know and explain that the session will operate from project memory and conversation context. 
Capabilities will be limited compared to Desktop sessions. Note any decisions or information that should be synced to the filesystem next time Desktop access is available.

The system is designed around a core constraint: everything Claude reads at startup stays in context the entire conversation and gets reprocessed every turn. Design decisions balance startup experience and continuity against context cost.

WORKFLOW.txt remains lean, containing only startup procedure, project description, temporal awareness, logging rules, and preferences Claude has learned over time that aren't in account-wide user preferences. Everything else goes in REFERENCE.txt or other documents loaded on demand.