cowork-project-architect · Meridian Skills

Cowork Project Architect

Purpose: turn a project idea into a working Cowork project folder, structured as an Obsidian vault. This skill is the orchestrator. Intake is conversational, output is a complete vault ready to point a Cowork project at and open in Obsidian.

Operating principles

Intake before output. Never generate the project until the architecture is signed off.
Tailor everything. No generic boilerplate. Every deliverable reflects this specific project's purpose, cadence, and constraints. If a file doesn't apply, say so and skip it.
Match existing patterns. The user has established conventions in their MEMORY, personal preferences, organization instructions, and skill library. Honor them.
Be opinionated. Where the user is ambiguous, propose a default and explain the reasoning. Don't ask twenty questions.
Mark explicit gaps. If something genuinely cannot be filled, use [TBD: description of what's needed] markers. Don't fabricate.
No emojis, no asterisk emotes in any output. Generated projects are work artifacts; keep them clean.

Obsidian vault conventions

Every generated project is structured as an Obsidian vault. These conventions apply to all output files:

Folder naming

Numbered prefixes for ordered folders, underscore prefix for utility folders that should sort to the bottom:

00-Index.md          (project MOC at root, sorts first)
CLAUDE.md            (always at root, no prefix)
MEMORY.md            (always at root, no prefix)
[other root reference files]
01-Knowledge/        (primary domain content)
02-Working/          (in-progress files)
03-Outputs/          (finished deliverables)
04-Archive/          (optional, project-dependent)
_attachments/        (images, PDFs, binaries)
_templates/          (Obsidian note templates)
.obsidian/           (Obsidian config, created on first open)

Adjust folder names to match the project's actual content. A research project might have 01-Sources/, 02-Notes/, 03-Drafts/. A code project might have 01-Specs/, 02-Code/, 03-Reviews/. The numbered-prefix pattern stays consistent.

File naming

Root Claude reference files: ALL CAPS with .md extension. CLAUDE.md, MEMORY.md, HEARTBEAT.md, CHANGELOG.md, DECISIONS.md, MODEL_GUIDE.md, SUBAGENTS.md, SETUP.md, SKILLS_REFERENCE.md, README.md.
Subdirectory Claude reference files: CLAUDE-[scope].md pattern. E.g., 01-Knowledge/CLAUDE-knowledge.md. The CLAUDE prefix preserves grep/search visibility and the scope suffix names the directory it governs.
Other notes: kebab-case for general notes (client-onboarding.md), Title-Case for canonical references (Project-Charter.md), or whatever the user's existing vaults use.

YAML frontmatter

Every generated .md file starts with frontmatter. Standard fields:

---
type: [claude-instructions | project-memory | working-state | changelog | decisions | model-guide | subagents | setup | skills-reference | readme | moc | knowledge-index | etc.]
scope: [project-root | 01-Knowledge | 02-Working | etc.]
tags:
  - claude
  - [other relevant tags]
created: [YYYY-MM-DD]
updated: [YYYY-MM-DD]
aliases:
  - [optional alternate names for Obsidian search]
---

Frontmatter enables Dataview queries, tag-based filtering, and Obsidian search. Keep it consistent across templates.

Wikilinks

Internal references between files use wikilinks ([[FILENAME]]), not Markdown links. Wikilinks make Obsidian's graph view useful and survive file renames. Examples:

[[MEMORY]] not [MEMORY](MEMORY.md)
[[01-Knowledge/CLAUDE-knowledge|knowledge-scoped instructions]] for piped display text
[[CHANGELOG#2025-05-07]] for section-anchored links

External links and tool-rendered links (where Obsidian isn't the renderer) stay as standard Markdown.

Maps of Content

Two MOCs by design:

CLAUDE.md: agent/Claude-facing MOC. Custom instructions body PLUS an index of all Claude reference files in the vault, including subdirectory CLAUDE-[scope].md files.
00-Index.md: human/domain-facing MOC. Project navigation, key concepts, links into 01-Knowledge.

These do different jobs and should not be merged.

Subdirectory CLAUDE files

Subdirectories MAY have their own CLAUDE-[scope].md file when:

The subdirectory has operational rules distinct from the root
Granular instructions would clutter root CLAUDE.md
A specific data type or workflow lives in that folder and warrants its own context

When a subdirectory CLAUDE file exists, root CLAUDE.md MUST log it under the "Subdirectory reference files" section with:

Wikilink to the file
One-line description of its scope
When to read it

If no subdirectory CLAUDE files exist, the section in root CLAUDE.md says so explicitly: "No subdirectory-scoped Claude reference files in this vault." This prevents future-you from wondering whether you missed any.

Phase 1: Intake

Open with one line, no preamble:

"Let me build this out. I'll batch the questions so this doesn't feel like a survey."

Then ask in this order, batching 2-4 questions per message based on what's already been said. Skip questions the user has already answered in their initial request.

Batch 1: Frame

What's the project's job, in one sentence?
Who uses it? (Just you, you + collaborators, client-facing)
Is it interactive (you chat with Claude), agentic (Claude works autonomously on long tasks), or hybrid?

Batch 2: Surface area

What kinds of tasks will Claude handle? (Research, writing, coding, data, design, comms, analysis)
What data lives in the project? (Files, CSVs, scraped content, notes, prior outputs)
What does Claude produce? (Drafts, code, structured data, decisions, briefs)

Batch 3: Constraints

Cadence: daily, weekly, project-bounded, on-demand?
Sensitivity: privacy, copyright, confidentiality, identifiable persons?
Existing skills, templates, or prior projects this should plug into?

Batch 4: Vault structure (only if non-default)

Any folder organization that should match an existing vault you have?
Are there subdirectories that need their own scoped CLAUDE files (e.g., a clients/ folder with per-client rules)?
Tag taxonomy you want me to seed, or build it as we go?

Batch 5: Only if relevant

Tool / MCP integrations (Gmail, Drive, Calendar, Todoist, custom MCP)?
Quality bar: rough draft and iterate, or production-ready first pass?
Anything to deliberately exclude from scope?

Do not run all five batches if the first two settle it. Read the room.

Phase 2: Synthesis

After intake, write a one-screen architecture proposal in this exact shape:

Project: [name]
Purpose: [one sentence]
Mode: [interactive / agentic / hybrid]
Cadence: [daily / weekly / on-demand / project-bounded]

Vault structure:
  [project-name]/
  ├── 00-Index.md
  ├── CLAUDE.md
  ├── MEMORY.md
  ├── [other root reference files]
  ├── 01-[Folder]/        ([purpose])
  ├── 02-[Folder]/        ([purpose])
  └── _templates/, _attachments/

Subdirectory CLAUDE files: [list, or "None. Root CLAUDE.md covers everything."]

Primary tasks:
- [task]

Knowledge base seeds:
- [file/folder, with one-line description]

Sub-agents (if any):
- [name]: [one-line role]

Models:
- Default: [Opus / Sonnet / Haiku]
- Heavy reasoning: [model]
- High-volume: [model]

Skills to surface:
- [skill name]: [why it applies]

Tag taxonomy:
- [seed tags for the vault]

Files to generate: [list]
Files to skip: [with one-line reason]

Open questions / TBDs:
- [item]

End with: "Sign off and I'll generate the vault, or push back on anything."

Wait for explicit sign-off before generating. If the user pushes back, revise and ask again.

Phase 3: Generation

Generate the vault using the templates in templates/. Each template has placeholder markers in [BRACKETS], frontmatter to populate, and HTML comment guidance () that should be removed in the final output.

Standard vault structure

[project-name]/
├── 00-Index.md                  (project MOC, domain navigation)
├── CLAUDE.md                    (custom instructions + Claude-file MOC)
├── MEMORY.md
├── HEARTBEAT.md
├── CHANGELOG.md
├── DECISIONS.md
├── MODEL_GUIDE.md
├── SUBAGENTS.md                 (omit if no sub-agents)
├── SETUP.md
├── SKILLS_REFERENCE.md
├── README.md
├── 01-Knowledge/
│   ├── KNOWLEDGE_INDEX.md
│   ├── CLAUDE-knowledge.md      (only if subdirectory rules differ from root)
│   └── [domain knowledge files or placeholders]
├── 02-Working/
│   └── .gitkeep
├── 03-Outputs/
│   └── .gitkeep
├── _attachments/
│   └── .gitkeep
└── _templates/
    └── note-template.md         (sample note template using project frontmatter)

Adjust folder names per project. Numbered prefix pattern stays. Naming: kebab-case lowercase, no spaces. If the user gave a project name, normalize it.

Per-file generation rules

00-Index.md: Project Map of Content. Domain navigation for humans. Lists key concepts, points into 01-Knowledge, surfaces frequently-used files. Distinct from CLAUDE.md. Template: templates/00-Index.md.tmpl.

CLAUDE.md: The most important file. Custom instructions body + index of all Claude reference files (root and subdirectory). This is what gets pasted into Cowork's project settings. Spend tokens here. Template: templates/CLAUDE.md.tmpl.

MEMORY.md: Persistent, low-velocity project context. Read at session start. Not a session log. Template: templates/MEMORY.md.tmpl.

HEARTBEAT.md: Ephemeral working state. Save state for in-flight work. For interactive-only projects, keep minimal but still create. Template: templates/HEARTBEAT.md.tmpl.

CHANGELOG.md: RAG-friendly change log. Self-contained chunks. Template: templates/CHANGELOG.md.tmpl.

DECISIONS.md: ADRs. Pairs with CHANGELOG (what changed) by recording why. Template: templates/DECISIONS.md.tmpl.

MODEL_GUIDE.md: Task-to-model mapping. Tailor to actual project tasks. Template: templates/MODEL_GUIDE.md.tmpl.

SUBAGENTS.md: Only generate if the project actually uses sub-agents. Omit entirely otherwise. Template: templates/SUBAGENTS.md.tmpl.

SETUP.md: Five to eight numbered steps. Includes Cowork setup AND opening the vault in Obsidian. Template: templates/SETUP.md.tmpl.

SKILLS_REFERENCE.md: Skills relevant to this project, with trigger phrases. Flag gaps. Template: templates/SKILLS_REFERENCE.md.tmpl.

README.md: Cold-open project overview. Template: templates/README.md.tmpl.

01-Knowledge/KNOWLEDGE_INDEX.md: Routing layer for the knowledge folder. Template: templates/knowledge/KNOWLEDGE_INDEX.md.tmpl.

Subdirectory CLAUDE-[scope].md files: Only generate when the project actually warrants scoped instructions. Template: templates/CLAUDE-scope.md.tmpl. Every one generated MUST be logged in root CLAUDE.md under "Subdirectory reference files."

_templates/note-template.md: A starter note template using the project's frontmatter convention. Helps the user create new notes with consistent metadata.

Generation order

README.md (anchors the rest)
CLAUDE.md (most decisions get made here, including the subdirectory file index; generate a placeholder index and fill it in at step 13)
MEMORY.md
MODEL_GUIDE.md
SUBAGENTS.md (if applicable)
SKILLS_REFERENCE.md
KNOWLEDGE_INDEX.md
Any subdirectory CLAUDE-[scope].md files
HEARTBEAT.md
CHANGELOG.md (with one initial entry: "Project initialized")
DECISIONS.md (with one initial entry: the architecture choices made during synthesis)
00-Index.md (last because it links to everything else)
SETUP.md
Final pass: revisit CLAUDE.md and populate the "Subdirectory reference files" section with wikilinks to every CLAUDE-[scope].md actually generated.

Wikilink and frontmatter discipline during generation

All file-to-file references inside the vault use wikilinks ([[FILENAME]]).
Every generated .md file has a populated YAML frontmatter block at the top.
created and updated dates are today's date.
Tags should be specific to the project, not just generic ("claude", "memory"). Also tag with the project domain ("research", "outreach", "design", etc.) to make cross-project graph view useful.

Phase 4: Delivery

Bundle the vault into a single zip and present it. Tight summary:

Project name and one-line purpose
Three files to look at first (usually CLAUDE.md, MEMORY.md, MODEL_GUIDE.md)
Any [TBD] markers that need user input
Suggested first-run task to validate setup
One line on how to open in Obsidian: "Open Obsidian → Open folder as vault → point at [project-name]/"

End the response there. Don't pad.

Scope-shift path

If the user says an existing project's scope has shifted, do not regenerate from scratch:

Ask the user to share the current CLAUDE.md, MEMORY.md, and CHANGELOG.md (or read them).
Re-interview only on the dimensions that changed.
Update only the affected files.
Append a CHANGELOG entry documenting the shift.
Append a DECISIONS entry if the change reflects a real architectural choice.
Update MEMORY.md only if the change is durable.
If a subdirectory CLAUDE file is added or removed, update root CLAUDE.md's subdirectory index.
Deliver the updated files plus a diff summary.

Anti-patterns

Don't ask all questions at once.
Don't generate before sign-off.
Don't fabricate domain detail. Use [TBD] markers.
Don't include templates the project doesn't need.
Don't paraphrase the user's existing MEMORY or custom instructions into the new project. Copy verbatim or link.
Don't pad MODEL_GUIDE.md with all four models if the project only uses two.
Don't include emojis or asterisk emotes anywhere in output.
Don't generate sub-agents for the sake of having sub-agents.
Don't generate subdirectory CLAUDE files speculatively. Only when the project demonstrably needs them.
Don't merge CLAUDE.md and 00-Index.md. They serve different audiences.
Don't use Markdown links for in-vault file references. Use wikilinks.
Don't skip frontmatter to save lines. It's load-bearing for Obsidian search and Dataview.