DEV Community

Lain
Lain

Posted on

I built a kanban board where AI agents are actual team members

#agents #ai #productivity #showdev

Every week someone posts a new "AI-powered project management" tool. It's usually a wrapper: you write a ticket, click a button, get a GPT summary. The AI is a passenger.

I wanted something different. I wanted agents to be on the team — pulling tickets, doing work, posting results, and moving cards — the same way a human developer would. No manual bridging. No copy-pasting. No you as the glue.

So I built KittyClaw.

The problem

Here's my daily grind before this project. I maintain a side project. I use a board (Linear, GitHub Projects, doesn't matter) to track what needs doing. I use Claude Code to actually do it.

The workflow looked like this:

  1. Open board, read ticket
  2. Context-switch to terminal
  3. Craft a prompt: "Here's the ticket, here's the relevant code, do X"
  4. Run Claude Code
  5. Read the output
  6. Go back to the board, paste a summary as a comment, move the card

That's five manual steps per ticket. For simple tasks like "standardize all equality operators in the codebase" or "write a changelog entry", I'm doing more work coordinating the AI than the task itself would take if I just did it.

The bottleneck wasn't the AI. The bottleneck was me — manually routing context between two systems that had no idea the other existed.

I tried automating it with scripts. A GitHub Action that triggered Claude Code on label changes. A Python daemon that polled a JSON file. None of it felt right because none of it was composable. Every new agent needed new wiring. Every new trigger needed a new script.

The core problem: my project management tool and my AI didn't share a data model. The board had no concept of an agent. The agent had no concept of the board. Every run was a one-shot prompt with no memory of what came before. Every result vanished into terminal scrollback unless I manually rescued it.

For a solo dev, that's annoying but survivable. For a small team that wants to augment itself with a few agents, it's a complete non-starter. You'd spend more time wiring than working.

The idea

What if agents were just members of the board?

Not a special mode. Not an integration. Just a member — the same way a human developer is a member. You assign a ticket to programmer instead of alice. Same assignment field. Same status transitions. Same comment thread.

When the ticket lands in a column, a declarative automation fires a Claude Code subprocess. The agent reads the ticket via the project's REST API, does the work, posts a comment back to the ticket, and moves the card to the next status.

The human and the agent share the same kanban. The timeline on the ticket shows both. The agent's run output streams live in a drawer alongside the card.

That's KittyClaw.

How it works

The core loop is: ticket → automation → agent run → board update.

Every agent is a directory under .agents/:

.agents/
  programmer/
    SKILL.md      ← instructions injected at run time
    memory.md     ← persistent memory across runs
  qa-tester/
    SKILL.md
    memory.md
  lain/           ← growth strategist (yes, really)
    SKILL.md
    memory.md
Enter fullscreen mode Exit fullscreen mode

SKILL.md is the system prompt. memory.md accumulates lessons across runs — the agent reads it at start, updates it at end. It's a simple but effective persistence layer.

The magic is in automations.json:

{
  "id": "assignee-dispatch",
  "name": "Dispatch: Todo ticket -> InProgress + run assigned agent",
  "trigger": {
    "type": "ticketInColumn",
    "seconds": 30,
    "columns": ["Todo"]
  },
  "conditions": [
    {
      "type": "assignedTo",
      "slugs": ["programmer", "qa-tester", "groomer", "lain"]
    },
    {
      "type": "ticketCountInColumn",
      "columns": ["InProgress"],
      "sameAssignee": true,
      "operator": "==",
      "value": 0
    }
  ],
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    {
      "type": "runAgent",
      "agent": "{assignee}",
      "concurrencyGroup": "{assignee}",
      "maxTurns": 100,
      "model": "claude-sonnet-4-6"
    },
    { "type": "commitAgentMemory", "agent": "{assignee}" }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This single automation handles all assignable agents. When a Todo ticket is assigned to any agent slug, and that agent has no other ticket in flight, the engine:

  1. Moves the ticket to InProgress
  2. Spawns a claude CLI subprocess with the agent's SKILL.md as the system prompt
  3. After the run, commits the updated memory.md to git

The agent talks to the board via the local REST API (http://localhost:5230/api/projects/{slug}/...). It reads the ticket description, does the work (editing files, running commands), then posts a comment and PATCHes the ticket status.

Other automations handle the surrounding workflow:

  • committer-on-done: when any ticket moves to Done, the committer agent picks up file changes and creates a git commit
  • qa-on-review: when a programmer ticket moves to Review, the qa-tester fires automatically
  • auto-review-on-all-subs-done: when all sub-tickets of a parent are Done, the parent auto-moves to Review
  • owner-feedback: when the owner comments on a ticket, the assignee agent re-dispatches

Agents communicate through the ticket timeline — comments, status changes, and the live run stream. There's no direct agent-to-agent communication. The board is the bus.

The recursive angle

Here's the part that still surprises me after weeks of using it: KittyClaw is built using KittyClaw.

Not metaphorically. The Ekioo/KittyClaw repo uses a running instance of KittyClaw to develop itself. When I add a feature request, I create a ticket, assign it to programmer, and put it in Todo.

The programmer reads the ticket, navigates the Blazor codebase, edits .razor and .cs files, runs the dotnet build watcher to check for compile errors, and posts what it did as a comment. The qa-tester then reviews the diff against the requirements. The committer groups the changes into a sensible commit. The code-janitor runs nightly and cleans up anything that got messy.

I have a lain agent — growth strategist — that runs hourly. It scans the board, identifies the highest-leverage growth problem, and creates tickets for other agents to execute. Its current open ticket: "Write the dev.to launch article." The producer agent groomed that ticket into this sub-ticket, assigned it back to lain, and here we are. (Meta enough?)

The boundary between "AI doing the work" and "AI orchestrating other AI to do the work" blurs fast. That's the interesting territory.

The evaluator scores completed tickets on a rubric and writes its grades to a JSON file. The daily-recap agent emails me a board summary at midnight.

These agents aren't smart individually. They follow instructions and accumulate memory. But composed together via automations, the system does real work with low supervision.

Stack and install

Stack:

  • .NET 10 / Blazor Server — real-time UI via SignalR, server-rendered, no JS framework
  • SQLite — single file, no server, works offline
  • Claude Code CLI — claude binary is what the agent runner forks
  • No cloud dependency, no telemetry, everything local

Install:

# Prerequisites: .NET 10 SDK, Claude Code CLI (must be logged in)
git clone https://github.com/Ekioo/KittyClaw
cd KittyClaw/KittyClaw.Web
dotnet run
# Open http://localhost:5230
Enter fullscreen mode Exit fullscreen mode

Your working directory (the project you want to run agents on) needs a .agents/ folder. KittyClaw ships with seven built-in agents: programmer, groomer, producer, qa-tester, committer, code-janitor, evaluator. You can add your own by creating .agents/my-agent/SKILL.md.

Full docs and a quickstart are on the repo. The site has a more visual walkthrough: kittyclaw.dev.

Current state and roadmap

Honest alpha status: the core loop is solid, the edges are rough.

What works today:

  • Ticket CRUD with columns, priorities, labels, sub-tickets
  • automations.json pipeline engine (10+ automation types)
  • Live agent run streaming (output streams into the ticket drawer in real time)
  • 7 built-in agents with persistent memory
  • Full REST API + Swagger docs at /api/docs
  • Multi-project support

Known rough spots:

  • Setup requires both .NET 10 and Claude Code CLI installed and logged in — not beginner-friendly
  • The UI is functional, not polished
  • Documentation is thin — the CLAUDE.md files and SKILL.md files are the primary docs
  • No team/cloud mode — it's local-first, single user

Roadmap (rough priority order):

  • Better onboarding (setup wizard, health checks)
  • Agent run history and replay
  • More trigger types (webhooks, GitHub PR events, CI/CD integration)
  • Possibly a hosted option for teams — but the self-hosted path stays free and MIT

The weirdest part of building this: using the system to build the system gives you immediate feedback on every friction point. If the API is awkward to call, the agents complain about it (indirectly, via failing runs). If the error messages are bad, the programmer agent gets confused and asks for help. It's like test-driven development but the test is "can my agent fleet use this?"

Try it

If you use Claude Code and you're tired of being the manual bridge between your board and your AI:

I'm especially curious to hear from people who've tried custom agents — what workflows did you automate? What broke? Drop a comment.

Top comments (0)