Autonomous Project Management

Project management apps (Linear, Asana, Jira) work for teams. Solo projects with 20 sub-steps fit none of them well — too much overhead for the writer/coder/researcher who just wants to move forward. The STATE.yaml pattern is dead simple: one file, one source of truth, the agent reads + writes it.

What it does

Each project has a STATE.yaml capturing tasks, status, owners
Agent watches the file, surfaces "what's next?", spawns subagents for parallel-runnable tasks
Daily morning summary: what moved yesterday, what's blocked, what's on deck for today
Friday retrospective: progress trend, drift signals, scope creep warnings

What you'll need

A simple convention for the YAML file structure
Delegate for parallel subagents
Cron for daily summaries

Setup

1. Define the STATE.yaml shape

yaml

# ~/projects/<slug>/STATE.yaml
project:
  name: Flowly Plugin System v1
  start: 2026-04-01
  goal: "Ship plugin system enabled by default to all users"

tasks:
  - id: t1
    title: "Build plugin manifest schema"
    status: done   # todo | in_progress | done | blocked
    owner: me
    notes: "Locked in flowly/plugins/manifest.py at commit 57d59ce"

  - id: t2
    title: "Wire pre_gateway_dispatch hook"
    status: in_progress
    owner: agent
    notes: "Started 2026-04-29; testing PII redactor as smoke"

  - id: t3
    title: "Desktop Plugins tab UI"
    status: todo
    owner: me
    blocked_by: [t2]

  - id: t4
    title: "Documentation pages for use cases"
    status: todo
    owner: me

decisions:
  - date: 2026-04-15
    text: "Plugins run in-process for v1; sandbox is v2"
  - date: 2026-04-22
    text: "Manifest format = YAML primary, JSON accepted"

2. Tell the agent about it

Send to Flowly

Remember: I have a project at ~/projects/<slug>/STATE.yaml using this schema: - project.{name, start, goal} - tasks[]: {id, title, status, owner, notes, blocked_by[]} - decisions[]: {date, text} When I say "what's next on <slug>?", read the file, find todo tasks whose blocked_by are all done, list them by priority (blocked-by-count descending). When I say "mark <id> done" or "<id> in progress", update STATE.yaml and confirm. When I say "log decision: <text>", append to decisions with today's date.

3. Daily morning summary cron

Send to Flowly

Cron "project-summary" daily at 9 AM: For each project in ~/projects/*/STATE.yaml: 1. Read the file 2. Compute status: - Tasks done in last 24h - Tasks moved to in_progress in last 24h - Currently blocked tasks (and what's blocking them) - Top 3 todo tasks ready to start (no blockers) 3. Format as Telegram message per project Send to me. If nothing changed in 24h, single line per project: "no movement".

4. Spawn subagents for parallel work

When you say "work in parallel on t4", the orchestrator:

Reads STATE.yaml, identifies t4
Spawns a subagent with the task description and any related memory/files
Subagent works, reports back; orchestrator updates STATE.yaml

This works best for self-contained tasks (research, draft, code module). Don't spawn for tasks that need multi-step human review.

Tips

STATE.yaml beats a kanban board for solo projects. Plain text, diffable, version-controllable, no UI to context-switch into.
Don't list 50 tasks. A project with 50 STATE.yaml entries is miscalibrated. Break into sub-projects or compress to 10–15.
Decisions log is gold. Future-you with no context will reach for it constantly: "wait, why did we pick YAML over JSON?" — the decision log answers.
Retrospective every Friday. Brief: what did the agent do well, where did I have to course-correct, what's drifting? Adjust the STATE.yaml and the project trajectory accordingly.
Don't auto-mark tasks done. Even when the agent thinks a task is complete, require human confirmation. Prevents premature declaration of victory.