| name | seacow-conventions |
| description | SEACOW meta-framework expertise for organizational design. Use when designing structures, analyzing systems, asking 'where should this go', creating conventions for projects/vaults, or understanding organizational patterns. |
| title | SEACOW Meta-Framework: Analytical Lens for Organization |
| stratum | 2 |
| branches | ["agentic"] |
Purpose
Expertise in using SEACOW as an analytical lens for designing and understanding organizational structures. This skill teaches you HOW TO THINK about organization, not what folders to create.
Critical Understanding
SEACOW IS NOT A FOLDER STRUCTURE.
SEACOW is a meta-framework - a set of questions and categories for ANALYZING any organizational system, whether it's:
- A personal Obsidian vault
- A corporate file share
- A code repository
- A Claude Code project
- A Notion workspace
- A physical filing cabinet
The Framework: S.E.A.(C.O.W.r)
System (S)
Question: What platform/technology context are we in?
Examples:
- Obsidian vault with plugins
- Windows SMB file share
- Git repository
- Notion workspace
- Claude Code
.claude/ directory
- Physical office with file cabinets
Analysis: The system determines your constraints and affordances:
- Can you use tags? Properties? Wikilinks? Only folders?
- Is it hierarchical? Graph-based? Database-like?
- Who has access? What are the permissions?
- Is it versioned? Searchable? Shareable?
Entity (E)
Question: WHO accesses or interacts with this?
Examples:
- Just you (personal knowledge base)
- Multiple teams (engineering, marketing, sales)
- Public audiences (blog readers, recruiters)
- AI agents (Claude, custom tools)
- Mix of internal/external stakeholders
Analysis: Entities create natural boundaries:
- Personal vs shared spaces
- Read-only vs read-write access
- Different views of the same content
- Audience-specific outputs
Activities (A)
These are the three fundamental activities that happen to information:
Capture (C)
Question: Where and how does information ENTER the system?
NOT prescribing: "You must have a /Capture/ folder"
Instead asking:
- Where do raw inputs land?
- How do you save things for later?
- What's your "inbox" (whatever you call it)?
- Where does unprocessed information live?
Example implementations:
- Personal vault:
Inbox/, Clippings/, Quick Notes/
- Corporate share:
Teams/[name]/Drop/, Incoming/, Submissions/
- Code repo:
docs/ADRs/, issue templates, raw-data/
- Email: Inbox, unread messages
- Physical: In-tray on desk
Work (W)
Question: Where and how does information get PROCESSED?
NOT prescribing: "You must have a /Work/ folder"
Instead asking:
- Where does active processing happen?
- What's the difference between raw input and finished output?
- Where do you iterate, refine, synthesize?
- What's "in progress" vs "done"?
Example implementations:
- Personal vault:
Projects/, Zettelkasten/, Active/
- Corporate share:
Teams/[name]/Active/, WIP/, Drafts/
- Code repo:
src/, tests/, docs/drafts/
- Email: Flagged, folders, drafts
- Physical: Working files on desk, active project folders
Output (O)
Question: Where and how does finished information EXIT to consumers?
NOT prescribing: "You must have an /Output/ folder"
Instead asking:
- Where do finished artifacts go?
- What's ready for an audience?
- How do you distinguish drafts from published work?
- What leaves your control (shared, published, delivered)?
Example implementations:
- Personal vault:
Blog/, Published/, Presentations/, Portfolio/
- Corporate share:
Shared/Reports/, Public/, Client Deliverables/
- Code repo:
dist/, build/, docs/api/, releases
- Email: Sent folder, templates
- Physical: Outbox, filed completed work
Relation (r)
Question: How do things CONNECT across the structure?
NOT prescribing: "Use these exact tags"
Instead asking:
- How do you link related items?
- How do you track dependencies?
- How do you navigate cross-cutting concerns?
- What's your graph/network layer?
Example implementations:
- Obsidian: Wikilinks, tags, graph view, Dataview queries
- File share: Shortcuts, README files, index documents
- Code repo: Import statements, references, dependency graphs
- Notion: Relations, mentions, backlinks
- Physical: Cross-reference notes, index cards
How to Use SEACOW: The Analysis Process
Step 1: Identify Your System
What platform/context are you in? What are its affordances?
Example: "I'm using Obsidian with Templater and Dataview plugins. I have wikilinks, tags, and properties available."
Step 2: Identify Your Entities
Who accesses this? Are there boundaries between different users/audiences?
Example: "Just me, but I share some notes publicly on my blog."
Step 3: Map Activities
For Capture:
- Where do things land when you first encounter them?
- What's raw/unprocessed?
- Examples: Web clipper →
Clippings/, voice notes → Inbox/, PDFs → References/
For Work:
- Where do you process/refine/synthesize?
- What's the workspace?
- Examples: Active projects, permanent notes, drafts
For Output:
- What's finished and ready for consumption?
- Where do published/delivered artifacts live?
- Examples: Blog posts, presentations, client deliverables
For Relation:
- How do you connect things?
- What's your linking/tagging strategy?
- Examples: Tags for topics, wikilinks for connections, MOCs for structure
Step 4: Design Your Structure
Based on your analysis, create a structure that fits YOUR context.
Diagnostic Questions
When you're stuck organizing something, ask:
-
Is this raw input or processed?
- Raw → Capture area
- Processed → Work or Output area
-
Is this finished or in progress?
- Finished → Output area
- In progress → Work area
-
Who is this for?
- Just me processing → Work area
- An audience → Output area
- Future me to process → Capture area
-
Does this support the system itself?
- Yes → System area (templates, config, meta)
- No → Content area (capture, work, output)
-
How does this connect to other things?
- Use your system's relation layer (tags, links, properties)
Anti-Patterns to Avoid
Don't Copy Blindly
❌ "I'll create /Capture/, /Work/, /Output/ because SEACOW says so"
✓ "Let me think about where information enters, gets processed, and exits MY system"
Don't Force the Framework
❌ "This doesn't fit any SEACOW category, so I don't know where to put it"
✓ "SEACOW is a lens, not a prison. Some things span categories or don't fit neatly."
Don't Ignore Your Platform
❌ "I'll use this exact tag structure even though my system doesn't support tags"
✓ "My platform uses database properties, so I'll adapt the SEACOW activities to that"
Don't Forget Evolution
❌ "I must get the perfect SEACOW structure before I start"
✓ "I'll start with a basic structure and refine as I learn how I actually work"
Summary: The Core Insight
SEACOW is about asking the right questions:
- Where does information ENTER? (Capture)
- Where does it get PROCESSED? (Work)
- Where does it EXIT? (Output)
- What PLATFORM are you on? (System)
- WHO interacts with it? (Entity)
- How do things CONNECT? (Relation)
Answer these for YOUR context, and design a structure that fits. Don't copy folder names. Copy the thinking process.
House conventions (this stack's instantiation)
Relocated from CLAUDE.md (2026-07-10 slim-down) — example conventions, not requirements.
Tags (ASCII-sort prefixes)
This scaffold demonstrates ONE way to tag things:
| Tag Prefix | Example Use | ASCII Sort |
|---|
#-- | Entity/audience tags | Sorts first |
#- | Input/capture tags | |
#/ | System/meta tags | |
#_ | Output/published tags | |
#word | Topic/relation tags | Sorts last |
You don't have to use these. They're an example of how you MIGHT tag based on SEACOW activities. Your system might use:
- No prefixes at all
- Different prefixes
- Colors/emojis instead
- Folder structure alone
- Database properties (Notion, Obsidian properties)
Frontmatter with named SEACOW links
This scaffold uses YAML frontmatter with named SEACOW links as an EXAMPLE:
