looselyorganized

lo — LO Work System Plugin

Claude Code plugin for managing work in Loosely Organized projects. Provides a complete work lifecycle: idea capture, planning, execution, knowledge capture, and a shipping pipeline.

Install

Add the marketplace and install the plugin:

/plugin marketplace add looselyorganized/lo-plugin
/plugin install lo@looselyorganized

Skills

Skill	Command	Purpose
setup	/lo:setup	Scaffold .lo/ directory
park	/lo:park	Capture ideas and conversation context for later
plan	/lo:plan	Brainstorm and design implementation plans
work	/lo:work	Execute plans with branch/worktree + parallel agents
ship	/lo:ship	Quality gates → commit → push/PR; also starts releases
status	/lo:status	Dashboard and lifecycle transitions with automation wizards
stream	/lo:stream	Milestone entries in .lo/STREAM.md
solution	/lo:solution	Capture reusable knowledge in .lo/solutions/

lo-design plugin

Skill	Command	Purpose
stocktaper-design-system	—	Monochromatic, monospace, minimal design system for LO projects

Install separately: /plugin install lo-design@looselyorganized

The .lo/ Convention

Version 0.6.0 — 2026-03-12

Every LO project repo contains a .lo/ directory at the repository root. This directory is the single source of truth for all project content that appears on the LO website. The website reads project data exclusively from Supabase, which is populated by a GitHub webhook that parses .lo/ on push.

Source-of-truth principle: The .lo/ directory in the project repo is canonical. The website never reads from the filesystem directly. Supabase is a cache of .lo/ content, kept in sync by webhooks. If Supabase and .lo/ disagree, .lo/ wins (re-sync fixes it).

Why not MDX in the website repo? Project content belongs with the project code. When an agent works on a project, it can update the brief or add a stream entry in the same commit as the code change. The website repo stays focused on presentation.

Directory Structure

.lo/
├── project.yml           # Project metadata (5 required fields, pure YAML)
├── BACKLOG.md            # Feature and task backlog with ID counters
├── STREAM.md             # Milestones only (single file, newest first)
├── park/                 # Conversation captures (/lo:park)
├── work/                 # In-progress feature/task plans (deleted on ship)
│   └── f001-feature-slug/
│       └── 001-phase-slug.md
├── solutions/            # Reusable knowledge captured after shipping
│   └── s001-topic-slug.md

All files use Markdown with YAML frontmatter (parsed by gray-matter). No MDX — .lo/ content is plain Markdown to keep the contract simple and parseable by any tool.

project.yml — Project Metadata

The root file. One per project. Pure YAML — no frontmatter delimiters, no markdown body.

Format:

id: "proj_166345da-d821-4b3a-abbc-e3a439925e85"
title: "Nexus"
description: "A coordination server for multi-agent engineering teams."
status: "build"
state: "public"

Required fields (all 5): id, title, description, status, state No optional fields. Data previously stored in PROJECT.md has moved to canonical sources (git remote, package.json, CLAUDE.md, README.md).

Validation rules:

• status must be one of: explore, build, open, closed
• state must be one of: public, private
• id format: proj_ + lowercase UUID v4

STREAM.md — Project Stream

Single file containing milestones only, newest first. This is the project's milestone feed.

File format: YAML frontmatter (type: stream), then entries using XML tags for reliable parsing. Newest first.

---
type: stream
---

<entry>
date: 2026-02-15
title: "Prototype deployed to Railway"
version: "0.1.0"
<description>
First working deployment with Redis-backed coordination. API responds to health checks, WebSocket connections establish successfully.
</description>
</entry>

<entry>
date: 2026-01-15
title: "Project initialized"
<description>
Initial project scaffolding and architecture decisions.
</description>
</entry>

Entry metadata fields: date (required), title (required), version (optional, releases only), research (optional, comma-separated slugs)

Body: 1-3 sentences per entry inside <description> tags. Public-facing voice.

park/ — Conversation Captures

Rich conversation summaries saved by /lo:park. When you've been discussing an idea and want to preserve the thinking without committing to planning, park it. The capture file preserves the flow of ideas, decisions, and open questions.

Filename convention: <id>-<slug>.md (e.g., f010-image-gen.md)

Format: Plain heading with date, followed by narrative capture. No YAML frontmatter.

work/ — In-Progress Work