Everything Changed When Claude Got Write Access to My Board

I wrote previously about giving Claude read access to task boards. That alone changed how I work with Claude — it could see my priorities, pick up context, and understand the bigger picture beyond just the code.

But it was still one-directional. I planned the board. Claude read it. Claude couldn't touch it.

That changed. Claude now has full write access to the board via a localhost API. And it turned boards from something I maintain into something Claude and I maintain together.

What write access actually means

Claude can now:

• Create cards — "Plan out my day" and Claude writes the task list directly onto your board
• Move cards — "Move that to Done" and Claude shifts it between lists
• Update cards — Claude adds notes, changes descriptions, updates progress as it works
• Delete cards — Clean up completed or irrelevant tasks
• Claim cards — A green pulsing indicator shows which cards Claude is actively working on

All of this happens through a lightweight API running on localhost. No cloud. No MCP. No API keys. Your machine talking to your machine.

The setup is one paste

Open your project's CLAUDE.md and paste this block (or tell Claude to put it into your CLAUDE.md for you):

## Task Board Read ~/.claude-code-toolkit/boards.json at session start. This contains all your boards, lists, and cards. For write access, read ~/.claude-code-toolkit/api.json for the API host and port (default: http://127.0.0.1:7899). Endpoints: - POST /api/boards/:boardId/cards — Create a card - PATCH /api/cards/:cardId — Update a card - DELETE /api/cards/:cardId — Delete a card - POST /api/cards/:cardId/move — Move a card between lists - POST /api/cards/:cardId/claim — Claim (shows live indicator) - POST /api/cards/:cardId/unclaim — Release claim

That's it. Claude reads the board file for context and discovers the API for write access. You don't need to understand the endpoints — Claude does.

The workflow instructions that make it click

The block above gives Claude the ability to use your board. But what makes it really work is telling Claude how you want it to use the board. I'd recommend also adding these workflow instructions to your CLAUDE.md:

## Board Workflow

On session start:
- Read ~/.claude-code-toolkit/boards.json
- Check the Planner board for Today and In Progress lists
- Summarise what's on deck before asking for direction

When starting work on a task:
- If it matches a card on the board, claim it via the API
- Move the card to In Progress
- Note the card ID so you can unclaim it later

As work is completed:
- Move finished cards to Done
- If new tasks come up during the session, create cards for them

On session end:
- Unclaim all cards this session claimed
- Move any completed work to Done if not already moved
- Summarise what shipped and what's still in progress

This is what turns the board from a static list into a live system. Claude checks the board when it starts, claims what it's working on, moves things as they finish, and cleans up when the session ends. You don't have to manage any of it.

Your board becomes a prompt deck

This is the use case I didn't expect. I started saving common prompts as cards on a board. Not tasks — prompts. Things like "Run the weekly analysis," "Process the inbox," "Do a code review on the latest PR."

Click "Send to Session" on any card and the text drops straight into your active Claude terminal. It's a prompt launcher built into your task board. No copy-paste, no markdown files to dig through, no "what was that prompt again?"

You can organise them by project, by frequency, by type. A board of your most-used prompts, one click away from any session.

Claude plans your day

This is where write access gets interesting. Instead of me writing the task list and Claude reading it, I can say:

"Read my board. Look at what's in the pipeline and what shipped yesterday. Write me a task list for today."

Claude reads the board, sees the current state, and creates the cards directly. They appear on the board in real time. I can drag them around, reprioritise, or tell Claude to adjust. It's collaborative planning where both of us can see and modify the same board.

This also works mid-session. Claude finishes a task, moves the card to Done, and picks up the next one. You're not managing the board anymore — Claude is updating it as it works.

The live indicator changed everything

When Claude claims a card, a green pulsing dot appears on it in the board UI. This sounds small. It's not.

I run multiple Claude sessions across different projects. Before the indicator, I had no visual signal for what Claude was actually doing across those sessions. I'd have to check each terminal to see what was happening.

Now I glance at the board. Green dots show me exactly which cards are being worked on, across all sessions. The board became a live dashboard of Claude's activity. When a dot disappears and the card moves to Done, I know it shipped.

At the end of a session, Claude unclaims everything it was working on. The dots go away. Clean state for the next session.

Boards became two-way

The shift is subtle but significant. Boards used to be something I maintained for Claude to read. Now they're a shared workspace. Claude reads the board for context, writes to it as it works, and signals what it's doing in real time.

The board went from a planning tool to an operating system for how I work with Claude. And the setup is one block in a markdown file.

Try it

The task board with full read/write access is part of Claude Code Toolkit. $24, one-time purchase, no subscription. Paste the block above into your CLAUDE.md and you're running.