How It Started: What 155 Files Taught Me

Start with a number: my WSL home directory contained 155 Markdown files.

Not 155 notes — 155 “important but I don’t know where to put them” files. Among them: 41 industry research reports (ERP selection, VPS migration, LLM rankings), 30 ops postmortems (written at 3 AM when services died), 20 personal documents (my cousin’s college application plans, my own resume), and hand-written handoff sheets for a dozen projects.

All of them sat in /home/li alongside 500+ other files. Every time I wanted “that Lightsail pricing research from last month,” my workflow was ls | grep lightsail and hoping I remembered the filename.

This is the indie hacker’s real condition: ideas are generated faster than they can be organized. New thoughts scatter across chat logs, Word documents, desktop folders, and Claude Code conversations. A single project spans research, business model, marketing, execution, experiments, and retrospective — yet no single tool ties them together.

Notion? I don’t want my core knowledge assets locked inside a SaaS. Obsidian? Great software, but my actual second brain lives in Claude Code’s memory library (527 memory files that survive across sessions), not in any note-taking app.

So I built something, tentatively named LynxOS: a three-in-one filesystem — Founder Knowledge Base + Project Management System + AI Agent Workspace. This article is the complete build log. Directory structure, design trade-offs, AI rules, templates — all free to copy.

Core Principles: Five, All Non-Negotiable

The constitution came before design. These five principles drove every decision:

1. Markdown First — All important knowledge must eventually land as .md files. Nothing lives only in a database or a format only one app can read.

2. Local First — Local files are the source of truth. Any software (Obsidian, VS Code, whatever comes next) is just an interface over these files. Swap the software, keep the files.

3. Git Friendly — The directory structure works with Git. No binary database blobs; diffs stay readable, history stays traceable.

4. AI Friendly — Claude Code can search, read, classify, create, edit, and summarize these files; it can generate project reports and retrospectives. This system isn’t just for me to read — it’s a workbench for AI.

5. Inbox First — Every sudden idea needs a frictionless entry point. When inspiration strikes, you shouldn’t agonize over “which folder does this go in.”

That last one is the most overlooked and the most lethal. Most note systems die of the same cause: friction kills capture. You’re on the subway, an idea strikes, you open your note app, face a dozen nested folders, spend 10 seconds wondering “is this a business idea or a technical one,” then close the app and scroll your phone instead.

Directory Structure: 8 Buckets

The final structure:

1
2
3
4
5
6
7
8
9

LynxOS/
├── 00-Inbox/          # Frictionless entry — messy ideas welcome
├── 01-Projects/       # One folder per project; README.md is the project card
├── 02-Marketing/      # Cross-project reusable marketing playbooks
├── 03-Research/       # Cross-project research reports
├── 04-SOP/            # Terminal station for validated methods
├── 05-Memory/         # Ops retrospectives and hard-won lessons
├── 06-Archive/        # Dead ideas and finished projects
└── 99-System/         # dashboard / conventions / AI rules / templates

Looks ordinary? The devil is in the trade-offs. Three key decisions:

Deleting the “Ideas” Folder

The original design had a 02-Ideas/ folder for “worth keeping, not yet a project” thoughts. I deleted it once I realized:

Inbox and Ideas are two places for ideas — and two places means deciding twice.

The correct approach: ideas have exactly one entrance (Inbox). Once triaged, an idea becomes a project folder with status: Idea on its card — no code, no schedule, just a card. As it matures, the status moves: Research, Planned, Active. Phase is a field on the card, not a location in the filesystem.

This makes “idea → project” a single pipeline. There’s no classification puzzle of “when does an idea become a project.”

Projects Default to One Card — No Pre-Built Skeleton

Typical project templates pre-create research/ marketing/ execution/ experiments/ assets/ subdirectories. Looks professional; actually it’s the psychological burden of empty folders — most projects never use all of them, and every empty folder reminds you of five things you haven’t done.

My rule: a new project gets one README.md (the project card). The template explains when to add each subdirectory — create experiments/ when you’re actually running one, marketing/ when you’re actually doing it. Directories are grown, not paved.

The card itself is minimal: one-line positioning, status and next step (a single action), background, core judgments (business model hypothesis / key risks / differentiation), resource pointers (where’s the repo, where’s the research), and a decision log table. Fifteen lines, done.

Marketing Knowledge Gets Its Own Bucket — Separate “This Campaign” From “Reusable Forever”

Two things get confused constantly:

• Project-specific strategy: “What keywords and landing pages did the LinuxDo charity site campaign use?” → lives in 01-Projects/linuxdo/marketing/
• Reusable methodology: “How to cold-start Google Ads in general” → lives in 02-Marketing/Google-Ads/cold-start.md

The first is a battle record; the second is a compounding business capability. Mix them and your hard-won lessons end up buried three levels deep in a dead project’s folder. Separate them, and 02-Marketing/ becomes your armory, organized by channel (Google-Ads/ Telegram/ SEO/). Read it before launching the next project.

The Lifecycle: How an Idea Becomes a Capability

Everything runs on one pipeline:

1
2

Idea → Inbox → Research → Decision → Project → Strategy →
Execution → Experiment → Review → SOP

An idea’s final destination isn’t “project done” — it’s an SOP (Standard Operating Procedure): a method validated by real experiments, extracted from the project, written as repeatable steps, and stored in 04-SOP/.

Example: “Telegram channel cold-start.” First attempt lives in Project A with its hypothesis, execution log, and real data. Once validated, it becomes an SOP (when to use it, steps, key parameters, expected CAC, known pitfalls). Next time Project B needs Telegram growth, open the SOP and run it.

That’s the difference between repeatable capability and one-off effort. Project outcomes are out of your control; methodology compounding is not. A thicker SOP library means faster cold starts for every future project — the only asset in this system that strictly appreciates.

AI Rules: Legislation for Claude Code

Whether this system survives long-term depends half on me and half on whether AI wrecks it. Claude Code will enthusiastically “organize” for you — and without constraints, it might split one simple idea into a dozen files, or rewrite your raw thoughts into polished prose for tidiness (the messiness of a raw idea is information).

So 99-System/AI-RULES.md is the most important file in the system. Two parts:

Allowed: triage Inbox (list moves and wait for confirmation), detect duplicates (show diffs before merging, let me arbitrate), create project cards from templates, add project structure (only when the project actually reaches that phase), analyze research, help draft marketing plans and experiment designs (with speculation labeled), analyze experiment results, distill SOPs (into the library only after my confirmation), update the dashboard.

Eight red lines:

1. Never delete raw ideas — even terrible ones get archived, not deleted
2. Never overwrite important material — show a diff first
3. Never over-refactor for “tidiness” — structural stability beats aesthetics
4. Never mass-produce valueless Markdown — leave fields empty rather than fill placeholders
5. Never split one simple idea into a dozen files
6. Never modify completed business conclusions without confirmation
7. Never fake experiments that weren’t run — results come only from real data
8. Never present speculation as fact — label it explicitly

Lines 7 and 8 sound redundant but protect the most fragile thing in an AI-era knowledge base: if you ever discover that “validated data” in your SOP library was hallucinated, the whole library loses credibility — and a knowledge base without credibility is worse than none. The red lines exist to protect the library’s credit.

There’s also a batch-operation gate: any move/rename/delete touching 5+ files requires a full operation list and explicit confirmation first. During this migration of 145 files, the AI generated the list, I reconciled it (its first pass covered 139 files and missed 15 — batch AI operations need reconciliation mechanisms), and only then did execution begin.

In Practice: Reclaiming 155 Files in One Afternoon

Building the system was the easy part; the existing mess was the real battle. My migration ran in five batches:

Hard-won details:

Reconcile before you move. After the migration list was generated, a script compared “actual file count in home” vs “files covered by the plan” — and found 15 stragglers (the AI’s list claimed full coverage; it didn’t). Without reconciliation, those 15 files would have been lost in root-directory noise forever.

Deliberate exceptions. Three files stayed put: AGENTS.md is an AI harness config read by every session — moving it breaks injection; two others were of unclear purpose, pending identification. “Move everything” is not the goal; “every file is where it belongs” is.

Migrate by moving, not renaming. The naming convention demands lowercase-with-hyphens, but historical files keep their original names — renaming 145 files creates 145 potential broken references (memory library entries and external scripts may point at old paths). Conventions bind new files only.

One commit per batch. Every migration step is a Git record; any mistake rolls back. The final state got pushed to a private GitHub repo — a knowledge base is an asset, and assets need off-site backup.

After migration, root-level Markdown files dropped from 155 to 3, and 12 project cards made every project’s status visible at a glance. Finding “that research from last time” used to be ls | grep; now it’s opening the dashboard — or asking Claude Code: “Which projects are Active, and what’s the next step for each?”

The Dashboard: Everything on One Page

99-System/dashboard.md is the system’s entry point — pure Markdown, nine sections: Active Projects (a table of project + next step), Paused, Completed, Inbox count, Needs Attention (projects whose Next step hasn’t moved in 14+ days), Recently Updated Research, Experiments, Recently Completed, SOP Library.

It doesn’t chase beauty; it chases this: every time I open Claude Code, saying “update the dashboard” lets the AI scan all project cards and repaint the global picture. Want project details? Follow the pointers on its card. Want to know why a project stalled? The status field and decision log tell you.

Why This System Can Survive 3-5 Years

Most note systems die of three causes: capture friction (solved by Inbox), structure too heavy for the ideas it holds (solved by thin project cards), and AI corrupting the library (solved by red lines). But the real reasons for long-term survival are these three:

It parasitizes your existing workflow and adds zero new tools. I never have to “open my note-taking app” — Claude Code is the interface, VS Code is the interface, grep is search. The system just collects the files I was already producing into a structure.

It’s a workbench for AI, not just a notebook for humans. The status field in frontmatter, the uniform project card structure, grep-friendly naming — these conventions let Claude Code reliably locate, read, and update anything. “Triage my Inbox,” “summarize LynxAct’s marketing strategy,” “which marketing methods have been experimentally validated” — all of these actually execute, because the structure is machine-readable. When RAG and automation workflows arrive later, the interfaces are already there.

Its asset value appreciates with time. Projects die (my real-estate platform Lynxhouse was just judged NO-GO), but its postmortem and lessons enter the Memory bucket, its validated methods enter the SOP bucket — project corpses become fertilizer for the system. Every step taken deposits into the SOP and Memory libraries, and those two only ever grow.

Addendum: Wiring In Obsidian — A Real Pitfall

The evening the system was built, I wired in Obsidian too — after all, I’d said “any software is just an interface over these files,” and it was time to verify that claim.

I hit a snag: pointing Obsidian’s vault at the WSL path \\wsl.localhost\Ubuntu\home\li\LynxOS wouldn’t open — it threw EISDIR illegal operation on a directory. Obsidian’s file watcher (chokidar) doesn’t support network paths. It can read files, but can’t “watch” them.

The fix was unglamorous: move LynxOS from the WSL home directory to the Windows filesystem (C:\Users\li\Documents\LynxOS). WSL accesses it via /mnt/c as before, and git showed zero content changes — 182 files shifted filesystems, their mode went from 100644 to 100755, and git config core.fileMode false cleaned that up.

Once wired in, the workflow looks like this: I open the dashboard in Obsidian to see “which projects are alive, what’s next,” and tweak a project card or two; Claude Code runs batch triage in the terminal, fills templates, migrates files. Both sides edit the same files, git records everything — who changed what and when is fully traceable.

This is “Local First” paying off in its most concrete form: the interface breaks, you change posture (switch software, move paths), the files don’t move. Markdown First, refusing to lock into any one software — that bet cashed in here.

The Obsidian usage tutorial is in the next post: Obsidian + Claude Code: The Dual-Driving Workflow.

The Minimal Version You Can Copy Today

You don’t need the whole thing. The minimal viable version:

1
2

mkdir -p LynxOS/{00-Inbox,01-Projects,04-SOP,06-Archive,99-System}
cd LynxOS && git init

Add three files: README.md (directory map), 99-System/AI-RULES.md (copy the eight red lines above), and one project card template. That’s enough. Add 02-Marketing when you have your first reusable playbook; add 05-Memory after your first retrospective.

First give ideas somewhere to land, then give methods somewhere to live, finally give AI rules to follow. Get the order wrong and you’ll end up with a beautiful but idling directory tree — I’ve seen too many such “digital gardens.”

As for my 155 files? They’re all in place now — along with 13 project cards, one dashboard, and a pipeline from idea to SOP — sitting quietly in a Git repository, waiting for the next idea to arrive.