Markdown tasks
Every piece of work is a _tasks/NNN-*.md file with YAML
frontmatter. Plain files, versioned with your code.
You are now the CTO, not a developer
From AI chats to shipped products.
Keep track of multiple projects running at once.
$ npx cogyard serve
You’re not writing any code these days, right?
The LLM is the new compiler. Think at product level not code level.
-
2022 Copilot autocomplete finishes your lines
-
2023–24 early Claude the AI writes it, you read every diff
-
2025 Claude matures you give AI features to build
-
Dec 2025 Claude Opus 4.5 Claude writes most of the code
-
Jun 2026 Claude Fable you are the architect, not a developer
Why it works this way
Each product is a stack of tasks. You assign the work, set priorities,
and sequence the merges — one person running several products at once.
cogyard keeps every one of them on track.
-
Tasks are markdown, in your repo.
Every unit of work is a
_tasks/NNN-*.mdfile, the source of truth. No database, no lock-in. Readable by you, your agents, and git; versioned alongside the code it describes. - You direct. The agents execute. You write the directional task. The agent does the work; you review and merge. The agent is the worker. You are the architect.
- Collisions are impossible by design. One atomic claim per task, one worktree per task, one port pair per worktree. N agents never race the same work, branch, or port.
- Agent-agnostic, plain Node. The engine is a Node data layer and CLI. Claude, Codex, or a human drive the same commands. No lock-in to one model or vendor.
Quickstart
# install the CLI
$ npm i -g cogyard
# set up the task store in your project
$ cogyard tasks init
# reserve a task file, then write the spec
$ cogyard tasks next-id add-auth → _tasks/001-add-auth.md
# run the portal: every project, agent, and worktree in one view
$ cogyard serve # http://localhost:7440
Driving it with Claude Code? cogyard claude install wires in the
skills and hooks so agents claim tasks and get their own worktree
automatically. Any agent (or human) that can call the CLI works the same way.
What it does
The machinery that lets you run several products at once and never lose track of where each one is.
Collision-free claims
One session claims a task atomically. The next agent is refused, not doubled up. Works across a team too: claims carry your name and sync over a git remote.
Per-task worktrees
Every task runs in its own git worktree, named after the task. Isolated, ready to merge on your call.
Auto-allocated ports
Each worktree reserves its own port pair, so parallel dev servers never fight. The portal tracks who owns what.
One portal
A git-tree graph and every live worktree, across every project, in a single always-on view.
Agent-agnostic
Claude, Codex, or a human all drive the same CLI. The engine doesn’t care who’s at the keyboard.
Find the chat behind a task
Ask which chats created, built, or mentioned any task — then read the transcript, right in the portal. Survives archiving and deleted worktrees.
A task is just a file
Tasks live in your repo as plain markdown. Nothing to export, nothing to migrate.
---
id: 1
slug: add-auth
title: Add email + password auth
status: OPEN
depends_on: []
claimed_by_session: null
---
# 001: Add email + password auth
## Scope
- [ ] signup + login routes
- [ ] session cookies
- [ ] password reset email