LOS-starter: The Markdown Memory System That Makes Claude Code Remember

The Idea

Public cold-start template for the Life Operating System. Users clone it, run onboarding, and get a working LOS instance with task-system, skills, and memory. Also the upstream source for /update-los.

Why it exists: Gives people a single place to understand LOS and bootstrap their own instance. Managed files are pulled from this repo during updates.

Repo: https://github.com/GadOfir/LOS-starter Version: v0.3.0

The Stack

Static HTML landing page (GitHub Pages) + Claude Code skills + markdown-based system.

What's in the box

• Task system (BMAD-inspired plan phase, loop mode, cross-repo support)
• Self-assembling routing (skills declare their own triggers via SKILL.md)
• Update mechanism (/update-los — migration + regular updates)
• Identity in memory/identity.md (survives updates)

• LOS:managed markers on all updatable files

  The skills that make it work

  Every workflow in LOS is a Claude Code skill. Here's what's actually in .claude/skills/:

• /learn — Captures and structures knowledge into memory/knowledge/. Handles two modes: topic learning and source ingestion

• /build-project — Creates a new project in memory/projects/ with standard structure

• /task-system — Manages a single-task-at-a-time project workflow inside the repo

• /evolve — Runs a full LOS system review, health check, and improvement suggestions

• /create-skill — Creates new Claude Code skills for LOS following Skills 2.0 conventions

• /design-html — Creates beautiful single-file HTML pages with modern CSS. No frameworks, no build tools

Skills self-register by dropping a SKILL.md file into .claude/skills/{name}/. No central registry. No hardcoded lists. The routing layer reads the frontmatter and dispatches automatically.

Memory is the whole point

I didn't want another Notion database. I wanted Claude to remember what I'm working on — across conversations, across compactions, across weeks.

LOS does that by storing everything in plain markdown files under memory/:

memory/
├── identity.md         # who I am, current state, active task
├── projects/           # one folder per active project
│   └── my-project/
│       ├── README.md
│       ├── tasks.md
│       └── decisions.md
└── knowledge/          # things I've learned, organised by topic
    ├── docker.md
    └── react.md

At session start, Claude reads memory/identity.md and knows: who I am, what projects are active, and what I was working on last. No onboarding, no re-explaining context.

Updates to LOS replace managed files cleanly — your memory never gets touched because identity.md is outside the managed scope.

One skill deep-dive: /task-system

Of the six skills, /task-system is the one with the most structure. It runs a BMAD-inspired lifecycle on a single task at a time:

plan → build → verify → fix → learn → close

The plan phase wears three thinking hats in sequence:

1. Analyst — what are we really solving, what's the domain context
2. Architect — what's the technical approach, what could break
3. PM — break it into 8-10 concrete steps, each one atomic

All three hats write into one file — .tasks/active/task-NNN.md. Analysis, architecture notes, plan, work log, verify results, fix attempts, learnings — one file is the truth. No scattered briefs, no Google Docs, no side files.

Two modes:

• Gated — human approves each phase. Default.
• Loop — Claude auto-advances through phases until STUCK, BLOCKED, or PASS. Use this when you're away.

Status vocabulary is deliberately small: IN_PROGRESS, FAIL, STUCK, BLOCKED, PASS, ABANDONED. STUCK is the only full-stop — two failed fix attempts and the loop exits, waiting for a human.

Real tasks that built this project

This isn't theoretical. Here are the actual tasks from memory/projects/LOS-starter/tasks.md:

Each of these was a single task file, planned with three hats, built, verified, and closed. The fact that they're all Done is the task system working.

The decisions I had to make

Every decision is logged in decisions.md with a reason. This file answers the question "why is it done this way?" without anyone having to read the code:

Host on GitHub Pages as static HTML

2026-03-28 — Zero-cost, zero-ops, fast to iterate

Single landing page (no framework)

2026-03-28 — Keeps it simple, matches LOS philosophy

Identity in memory/identity.md, not CLAUDE.md

2026-03-29 — Makes CLAUDE.md 100% replaceable on update

LOS:managed markers for update boundary

2026-03-29 — Any file with marker gets replaced, everything else untouched

Self-assembling routing from skill frontmatter

2026-03-29 — No hardcoded skill lists — custom skills auto-route

No CLI for updates — Claude is the update tool

2026-03-29 — /update-los skill fetches from GitHub, simpler than npm tooling

What makes it different

Most dev tooling fights Claude Code. LOS works with it:

• Memory is the foundation. memory/identity.md is the source of truth for who I am and what's active. Claude reads it at session start — no re-onboarding, ever.
• Identity survives updates. /update-los can replace CLAUDE.md, routing, and skills cleanly because your identity lives outside the managed scope.
• Skills are self-assembling. Drop a new skill into .claude/skills/my-thing/SKILL.md, and the routing layer finds it via frontmatter. No config to edit.
• LOS:managed markers — every updatable file is tagged so the update mechanism knows exactly what it's allowed to touch.
• One file per task. The /task-system skill enforces a single active task file. No scatter, no lost context.

Try it

git clone https://github.com/GadOfir/LOS-starter.git
cd LOS-starter
claude

Then say "start session" and let it bootstrap your first task.

Repo: https://github.com/GadOfir/LOS-starter

Built with: Claude Code + markdown + zero frameworks