OpenClaw Project Tracking: Event-Driven State Management Instead of Kanban

Kanban fails quietly.

Not because the idea is wrong, but because the update loop is manual. When you are building solo, you do not want to spend your best hours dragging cards. So you stop updating. The board becomes stale. Context disappears. Three weeks later you cannot remember why you made a decision, what blocked you, or what changed in the plan.

An event-driven project tracking system fixes that by matching how you already work. You naturally say things like: “finished X, starting Y, blocked on Z.” OpenClaw captures those statements as structured events, updates the project’s current state, and preserves the full history. Your daily standup can be generated automatically from that same data.

Internal links:

• /blog/openclaw-use-cases
• /blog/openclaw-skills-guide

What you will build

A lightweight project state management system that:

• Stores projects, events, decisions, and blockers in a database (SQLite first, Postgres later)
• Lets you update project state via normal chat messages
• Preserves decision context as first-class data, not buried in chat logs
• Links git commits to project events for traceability
• Posts a daily standup summary to Discord or Telegram
• Answers natural language queries like:
  • “What is the status of Project X?”
  • “Why did we decide to do Y?”
  • “What is blocking us right now?”

This is not “project management theater”. It is a system for reducing context-switching and preserving truth.

Why event-driven tracking beats Kanban for solo builders

Kanban assumes a process. Solo work is not a process. It is a stream.

Event-driven tracking works because:

• It is low friction: you speak updates as you go
• It is audit-friendly: you can reconstruct what happened and when
• It preserves the “why”: decisions and pivots include reasoning
• It is automatable: once the state is structured, summaries and reminders are easy
• It reduces re-entry cost: you can jump back into a project in minutes

If you want a single line summary: Kanban is a snapshot. Events are a timeline.

Skills and prerequisites

Minimum requirements:

• A messaging channel for updates (Discord or Telegram)
• A database
  • SQLite for local-first, simplest setup
  • Postgres for multi-device writes and remote hosting
• A scheduler (cron, heartbeat, or OpenClaw scheduling) for daily standups

Nice-to-have:

• Git access to scan commits, PRs, and branches
• A “multi-agent team” so one agent tracks state while another executes (see /blog/openclaw-multi-agent-team)

If you are new to integrations and permissions, read: /blog/openclaw-skills-guide

The data model (simple but powerful)

Start with three tables:

• projects: current snapshot
• events: append-only timeline
• blockers: dedicated tracking for things that stop work

Example schema:

CREATE TABLE projects (
  id INTEGER PRIMARY KEY,
  name TEXT UNIQUE,
  status TEXT,          -- active | blocked | paused | completed
  current_phase TEXT,   -- short label like "onboarding" or "billing"
  last_update TEXT
);

CREATE TABLE events (
  id INTEGER PRIMARY KEY,
  project_id INTEGER,
  event_type TEXT,      -- progress | blocker | decision | pivot | note
  description TEXT,
  context TEXT,
  timestamp TEXT
);

CREATE TABLE blockers (
  id INTEGER PRIMARY KEY,
  project_id INTEGER,
  blocker_text TEXT,
  status TEXT DEFAULT 'open',   -- open | resolved
  created_at TEXT,
  resolved_at TEXT
);

Design rule: events are append-only. Corrections are new events.

Later upgrades (optional):

• links table for PRs, docs, and assets
• tags table for cross-project themes
• “owner” field if multiple people contribute

Event taxonomy (keep it small)

Your first instinct will be to model everything. Resist that.

A pragmatic event set:

• progress: “started”, “finished”, “shipped”, “reviewed”
• blocker: something preventing progress
• decision: a choice with reasoning
• pivot: a major change in approach
• note: anything worth recording without changing state

If you keep just these five types, you will still capture most of the value.

Step-by-step setup

Step 1: Create a dedicated “project updates” channel

Create a Discord channel like:

• #project-state

Or a Telegram topic.

Why a dedicated channel matters:

• it becomes a clean event stream
• you can add automation without accidental triggers
• it keeps you honest: updates become a habit

Step 2: Choose SQLite or Postgres

Use SQLite if:

• you want the simplest setup
• one machine runs the agent
• writes are mostly from the agent itself

Use Postgres if:

• multiple devices or services will write events
• you want remote hosting
• you plan to build a dashboard later

A common path: start with SQLite, migrate to Postgres once you feel real pain.

Step 3: Create a small “projects registry” file

A registry reduces ambiguity. Create a file like:

• ~/projects/project-registry.json

Example:

{
  "clawrapid-web": {"name": "ClawRapid Web", "repos": ["solopreneur-labs/clawrapid"]},
  "openclaw-skills": {"name": "OpenClaw Skills", "repos": ["openclaw/openclaw"]}
}

The agent can use this to map commits and messages to canonical project IDs.

Step 4: Define your update language patterns

You do not need strict commands, but patterns increase accuracy.

Recommended patterns:

• “Project: [name]” on its own line
• One of:
  • “Starting: …”
  • “Finished: …”
  • “Blocked on: …”
  • “Decision: …”
  • “Pivot: …”

Example update message:

Project: ClawRapid Web
Finished: onboarding flow UI
Context: copy still missing, but screens are wired.
Next: implement Stripe webhook handling.

This stays human-friendly and model-friendly.

Step 5: Give OpenClaw the operating prompt

Copy and paste:

You are my project state manager.

Instead of Kanban, I will post updates conversationally.

When I say:
- "Project: [name]" -> resolve to a canonical project record (ask if ambiguous)
- "Starting: <task>" -> log a progress event and update current_phase
- "Finished: <task>" -> log a progress event and update status to active
- "Blocked on: <issue>" -> create a blocker entry and set project status to blocked
- "Decision: <decision>" -> log a decision event with context (why, trade-offs)
- "Pivot: <new approach>" -> log a pivot event with reasoning

Queries:
- "Status: <project>" -> return latest events, open blockers, and current phase
- "Why: <decision>" -> search decision events and return context
- "Blockers" -> list open blockers across all projects

Daily standup at 09:00:
1) Scan commits from the last 24 hours
2) Link commits to projects via project-registry.json, branch names, or commit tags
3) Post a standup summary:
- Yesterday: events + commits
- Today: 1-3 next actions
- Blocked: open blockers + what is needed to unblock

Rules:
- Preserve decision context
- Keep summaries concise
- If confidence is low, ask a question instead of guessing

Step 6: Link git commits to projects

Pick one approach and be consistent.

Option A: commit tags

• Include proj:<key> in the commit message
• Example: feat: add onboarding step (proj:clawrapid-web)

Option B: branch naming

• feature/clawrapid-web-billing

Option C: mapping file

• Use project-registry.json and map repos to projects

Most solo builders choose mapping file because it requires the least discipline.

Step 7: Define the standup output format

Your standup should be predictable and action-oriented.

Template:

• Yesterday

  • Progress events (bullets)
  • Commits and PRs (bullets)

• Today

  • 1 to 3 next actions

• Blockers

  • List open blockers, who owns the next step, and the “unblock question”

Add a final line:

• “Decision needed from you: …”

This prevents the agent from getting stuck.

Practical prompts for daily use

Log progress

Project: ClawRapid Web
Starting: implement Stripe webhook handler
Context: need to reconcile events into our DB
Definition of done: local test suite passes and webhook endpoint is idempotent

Log a blocker

Project: ClawRapid Web
Blocked on: waiting for access to analytics account
Impact: cannot validate conversion funnel
Unblock request: please invite me to the GA property

Log a decision

Project: ClawRapid Web
Decision: keep onboarding to 3 steps
Because: reduces abandonment and is easier to A/B test
Trade-offs: less flexibility for power users
Revisit if: activation drops for experienced users

Ask for status

Status: ClawRapid Web

Advanced upgrades (when the basics work)

Upgrade 1: Auto-detect “stuck” projects

Rule:

• If a project is active but no events were logged in 7 days, mark it paused and ask whether to archive.

This prevents zombie projects.

Upgrade 2: Add a weekly review

Once per week:

• list projects by last_update
• summarize what changed
• propose what to drop
• propose one focus theme for next week

A weekly review is where you regain focus.

Upgrade 3: Integrate with a multi-agent team

Pattern:

• One agent is the Project Librarian (state manager)
• Another agent is the Executor (coding, writing, shipping)

The librarian maintains structured truth, and the executor does the work.

Upgrade 4: Use Todoist as an execution queue

If you like tasks, combine:

• event log for truth
• Todoist tasks for execution

See /blog/openclaw-todoist.

A practical 7-day rollout plan

If you try to build everything at once, you will abandon it.

Day 1:

• Create the #project-state channel.
• Log one update message.

Day 2:

• Add the database and start storing events.

Day 3:

• Add blocker tracking.

Day 4:

• Add decision events (force “Because” and “Trade-offs”).

Day 5:

• Add daily standup generation.

Day 6:

• Link commits using a mapping file or commit tags.

Day 7:

• Review the timeline for one project and adjust the event taxonomy.

If you follow this plan, the habit forms before the tooling gets fancy.

Troubleshooting

The assistant cannot tell which project you mean

Fix:

• use canonical names
• maintain a project registry
• add a short project key you always include

The system becomes too heavy

Fix:

• reduce event types
• keep context short
• log only meaningful changes

You stop using it

Fix:

• set one daily ritual: end-of-day update
• let the standup be the reward in the morning

FAQ

Q: Can I keep Kanban and still use this? A: Yes. Keep a board for external communication and use events as the internal source of truth.

Q: SQLite or Postgres? A: SQLite is perfect to start. Move to Postgres when you need multi-device writes, remote hosting, or a dashboard.

Q: How does this reduce context switching? A: Instead of rereading chats and commits, you query the current phase and the last 5 events.

Q: Can multiple agents update the same state? A: Yes. Use one agent to log and summarize, and other agents to execute tasks.

Q: What if OpenClaw misclassifies an event? A: Log a correction as a new event. Avoid rewriting history.

Q: Is this overkill for one project? A: For one project, a changelog may be enough. The value spikes when you juggle multiple projects.

Next steps

Once you have event-driven project tracking:

• Add Todoist visibility for long agent runs (openclaw-todoist)
• Add a morning brief that includes project status (openclaw-morning-brief)
• Run a multi-agent team where Strategy reads this state and assigns next actions (openclaw-multi-agent-team)

If you are tired of stale boards, stop dragging cards and start logging events. The automation layer is where OpenClaw shines.

Quick checklist (print this)

• Create a dedicated update channel (#project-state).
• Start with SQLite and 5 event types.
• Log one end-of-day update for three days in a row.
• Add blockers as soon as you feel stuck.
• Add one decision event per week (minimum).
• Only after the habit exists: add commit linking and automated standups.

This order matters. Tools do not create habits. Habits make tools valuable. Start small and iterate every week carefully.