Adding Kiro support to Backlog.md using Backlog.md

I had Backlog.md on my radar for a while, but I never ended up using it. Today I decided to give it a try. Backlog.md is one of those tools in the galaxy of spec driven development. While it's "agent agnostic", its documentation and utilities assume a set of specific agents (e.g. Claude Code, Codex, Cursor, etc.). I decided to use Backlog.md to add Kiro explicit support to Backlog.md.

The goal wasn't to add Kiro. The goal was the journey (or workflow) to get there and eventually learn how Backlog.md works.

The first thing I did was to install the Backlog.md CLI following the instructions in the README of the repository. I then forked the repo and cloned it locally to work on it. I also added the Backlog.md MCP configuration to my Kiro agent using the syntax kiro-cli mcp add --scope global --name backlog --command backlog --args mcp,start (this assumes you have the Kiro CLI installed).

Given the AGENTS.md doesn't have much context about the repository itself I decided to generate foundational Kiro steering files (this capability only works in Kiro IDE today, and it's optional for this exercise). They are still not specific enough to how agents support work in Backlog.md so, using the Kiro CLI, I switched to /plan mode and started to ask questions about the repo, starting with the following prompt: Resarch deeply this repository and investigate how various agents are supported by Backlog.md. There was a number of back and forth to understand some of the details of agents support (for example, why Claude Code has a specific sub-agent configuration or why some of the agents have specific rules/steering files). I eventually concluded, after this exploration, that the Claude Code agent is a nice to have, that agents specific rules/steering files are a legacy implementation and that MCP is the preferred way to have agents interact with Backlog.md.

With this research output in my context and with the Backlog.md tools available, I was ready to start defining tasks to implement Kiro support. I prompted: Create the required tasks to add Kiro as an additional agent. Assume Kiro will work with MCP. Make sure you make updates to both the code and the documentation inside the repository.

Interestingly enough, Kiro tried to do create tasks using the backlog CLI instead of the MCP. I had to ask explicitly to use the MCP. I can't tell if this is because, by default, the Kiro agent has the README.md file of the repo in context (where there is a detailed description of all backlog CLI commands). This may need further investigation as it doesn't appear to be a broad issue with Backlog.md.

The result of this prompt is that Kiro (eventually) invoked the backlog MCP tools to create the following task and subtasks:

I am surprised to see two separate 379.3 sub-tasks. Looking at the traces I see that the agent invoked sub-agents to create the tasks and I suspect there was some sort of race condition. This also would require further investigation. Note also how the second of them assumes I also want to create Kiro specific instruction files. In reality, we do not want that, because there is no reason to pollute this repo further with agents specific stuff (duplicated over random folders) when Kiro works well with the Backlog.md MCP server. My prompt "assume Kiro will work with MCP" was perhaps too soft and I should have been more explicit about ONLY wanting MCP support. Long story short, I had Kiro remove this specific tasks (which invoked the Backlog.md task archiving tool).

This is how one of the tasks appears on the Kanban-like dashboard that ships with the project:

These are a few random observations I had at this stage:

• While we have removed the task for the Kiro specific instructions, I see reference to them in all other tasks. I was expecting (perhaps wrongly) that Backlog.md would sanitize all the tasks to adjust. To this end, I will try to ask (via the MCP server) to do that explicitly.
• I see the task is assigned to @codex. This is likely because, at the time of this test, the AGENTS.md that exist in the Backlog.md repository has this as part of the CRITICAL_INSTRUCTIONS: "When you're working on a task, you should assign it yourself: -a @codex". That sounds like something that should be sanitized in AGENTS.md.
• I also found interesting that the implementation plan in the tasks is empty. The README file of the project suggests that, when executing a task, the prompt includes something to the extent of "before starting to write code use 'ultrathink mode' to prepare and add an implementation plan to the task". Maybe this is just a personal preference, but I would have preferred the plan to be part of the instructions defined at "task definition time" rather than at "task execution time". But maybe I am missing something about Backlog.md that would make the current implementation more obvious.

With this in place, I was ready to execute all the tasks from Kiro CLI. This led to a working solution, but it wasn't as smooth as I was hoping. Below I will list some of the hiccups I noticed during the execution process.

First, the code generated for the automatic configuration of the Backlog.md server used the wrong syntax for the command. Ideally the agent should have researched for the proper syntax (but we also should have more commands example in the docs in addition to configuration files examples).

Second, for some reason, the tasks simply ignored the DEVELOPMENT.md file in the root folder. I assume this was due to poor initial research that did not spot that agents where mentioned in that file too. Backlog.md does not have any responsibility in terms of the quality (and coverage) of the tasks being created. This is a common problem in spec driven development: garbage in, garbage out.

Last but not least, the execution of the tasks ended up being run in Kiro CLI subagents. The way Kiro CLI subagents work today is that they do not support a trust-all option when executing tools and so there is extra work to be done to accept all suggested changes. Ideally, the user would need to create a Kiro CLI custom agent with all the trusted tools and commands upfront. Also, given how subagents work with different agents, perhaps Backlog.md should not push or suggest to the agent to use subagents by default (but this is not my call to make).

In the end this was a very interesting exercise to learn how Backlog.md works. This is the PR I opened off of this exercise: https://github.com/MrLesk/Backlog.md/pull/528. And now Backlog.md supports Kiro natively.

Massimo.

PS I submitted a draft of this blog to Alex (the creator and maintainer of Backlog.md) and he kindly reviewed it. This was his comment:

Dear Massimo,
Thank you for your great contribution. Kiro is an amazing tool, and I would be happy to officially support it in Backlog.md.
I agree with you regarding the task reference sanitization when a task is archived. That makes perfect sense, so I have already created a PR to fix this behavior: https://github.com/MrLesk/Backlog.md/pull/519