Kiro Workflow for Copilot, Claude & More

Last week we introduced how an agent understands a codebase and built an actual codebase agent to demonstrate the underlying mechanism.

During this process, we highlighted some current limitations of Kiro. For instance, even with a detailed design.md file, Kiro frequently deviates from the plan during execution, producing results that diverge significantly from the intended design.

The root cause lies in Kiro's execution process, where it uses design.md as context but fails to fully read the entire file. This issue becomes particularly serious when steering content is extensive, as the agent tends to protect its context window. Consequently, it may only read the first few lines of a file and consider it fully processed.

This means when Kiro executes plans, we still need to constantly remind it to deviate from the design. Not only does this waste a lot of vibe request quotas, but it also lowers overall development efficiency. After all, we need to review every detail more carefully.

The problem is that Kiro is a closed-source product, so we can't fine-tune its prompts. We're left watching this cycle repeat over and over. So I wondered if there's a way to use prompts to make tools like Copilot or Claude Code perform Kiro-like workflows while still allowing adjustment of each execution detail.

After actually trying it out, it turns out to work.

https://github.com/wirelessr/kiro-workflow-prompts

Although this project is written in Copilot's format, it can be applied to any agent, including Claude Code. However, since I'm using Copilot, I'll demonstrate using its actual workflow.

Installation is straightforward, simply place these prompt files in the project directory or a global prompts folder to use them directly in Copilot's chat window.

All prompt files are thoroughly explained in the README.md. This article will focus on how to use them.

Copilot Spec-driven Development

At first, just like Kiro's spec mode, we need to ask Copilot to create a spec directory and convert our requirements into an EARS specification document.

/createSpec
I want to build a web service with OAuth authentication, integrating Google OAuth and requiring a database to store user information.

By running the /createSpec command with these requirements, the Agent begins preparing the requirements.md file. If there are materials under .kiro/steering that provide behavioral guidelines for the Agent, it will also reference those contents.

Throughout the requirements creation process, we can continuously interact with the Agent to refine the details of the entire requirements document.

Here's an interesting observation, I've noticed Kiro tends to over-engineer things, adding some obsessive details. So I used system instructions to make our Agent more pragmatic like Linus Torvalds, adhering to the KISS (Keep It Simple, Stupid) principle.

Once we have the requirements.md file, we move on to the design phase.

/design
I approve the requirements document. Let's begin the design phase.

The design phase requires no prompting, as demonstrated by Kiro. We only need to approve requirements.md, after which the Agent will autonomously initiate the design process. Of course, the Agent will still reference steering documents for design guidance, and we can continue to fine-tune the process throughout.

Upon completing the design, the Agent will generate the corresponding design.md file, enabling us to proceed to the next step, the planning phase.

/createTask
I approve the design document. Let's begin planning.

Here, explicit approval is still required; otherwise, the Agent will not proceed.

After this phase is complete, we will have the three most critical specifications: requirements.md, design.md, and tasks.md. Interestingly, these outputs follow Kiro's rules exactly. Therefore, switching back to Kiro to execute tasks from this stage is no problem at all.

After approving tasks.md, the final step is to enter the execution phase.

/executeTask task1

You can explicitly specify which task to start with, or omit the task number altogether. In that case, the Agent will attempt to begin with the first uncompleted task.

This workflow finishes once the entire tasks.md file is marked as complete. We can see this is basically identical to Kiro's process.

Wrap Up

In these prompts, I explicitly state that all documents must be thoroughly reviewed before proceeding. However, the preceding steps don't need to be so meticulous, as humans will collaborate with the Agent to co-create those specification documents.

However, /executeTask operates in headless execution mode, so we absolutely must ensure the Agent understands its purpose. Therefore, within the executeTask prompt, I not only require it to thoroughly review all files but also demand it summarize each one. Only by asking for summaries can we enforce sufficient rigor to ensure the Agent genuinely reads everything carefully.

This insight emerged during my implementation of the codebase agent. The greatest advantage of this workflow is that we can achieve results comparable to Kiro, or even better. Using tools we're familiar with (and have paid for), we can customize prompts to meet specific needs. Just as I required the agent to thoroughly read files, there's lots of room for adjustment, allowing us to fully unleash our creativity.

If you have any good ideas, feel free to contribute to my project. Currently, I've tailored the prompts based on my own habits and needs, but you might have even more insights to share.