Context Management with Kiro (Part 1)

The Weight of Context for Humans and AI Coding Assistant

With the advancement of AI technology, coding assistants have become deeply embedded in the daily development environment. But, let’s momentarily set aside AI and consider how vital Context is when we work with people. If a colleague abruptly asks about a single line of code without any background knowledge of the previous discussion or project history, you’d likely feel just as lost.

Just as collaboration is impossible without context, context is everything in collaboration with an AI coding agent. The agent must accurately understand the project’s goals, architecture, and existing codebase to serve as a truly “smart” partner.

I’ve been using spec-driven development tools like Kiro (or VSCode + Cline) for my personal coding projects. While these tools offer incredible productivity, the process of constantly prompting and providing context for better code quality led to the following pain points:

1. Repetitive Work: Having to re-enter the project’s relevant context every time I start a new session.
2. Token Limits: Issues where the agent’s token limit was hit during long sessions, causing previous conversation history to be cut off.

In this article, I will explain how I overcame these inefficiencies and introduce my method for systematically managing context for the AI coding assistant throughout my projects.

The Automation Strategy for Recording and Utilizing ‘Memory’

To solve the recurring problem of context entry, I devised a method to automatically select and include highly relevant context. This involves leveraging the Kiro Steering or Cline Rule features.

About Kiro Steering and Cline Rules

Kiro Steering: This is a core feature of Kiro, the AWS-provided, agent-based IDE. It’s a system that permanently guides the AI agent’s behavior by providing continuous project knowledge (e.g., coding conventions, architectural decisions) stored as Markdown files in the .kiro/steering/ directory. This grants the agent an Institutional Memory of the project.

Cline Rule: A feature provided by the VSCode extension Cline, which offers system-level guidelines or preferences. These are typically stored as Markdown files in the .clinerules/ directory (or a file) at the project root, delivering project-wide context and rules to the agent to ensure consistent behavior.

Practical Application: ‘Memory Management’ Instructions in the Steering File

I leveraged these features to give the agent specific Instructions demanding continuous context management for the project. In a real Kiro project, the .kiro/steering/implementation.md file specifies the following rules. These instructions are key to ensuring the agent records new implementations and is mandated to reference past records before starting the next task.

Upon Implementation Completion (Mandatory Recording)

• MUST: Write an implementation summary or task completion status as Markdown and save it to the .kiro_context/ folder. (Purpose: Record implementation history)
• SHOULD: Write design decisions or technical specifications as Markdown and save them to the .design_decision/ folder. (Purpose: Record design decisions)

Before Starting Work (Mandatory Reference)

• MUST: Read the .kiro_context/*.md files and understand the entire context. (Purpose: Reference previous implementation)
• SHOULD: Refer to the .design_decision/*.md files to grasp the design intent. (Purpose: Understand design intent)

Context Recording Example in the GraphLoom Project

Through these instructions, the agent is instructed to summarize the implementation after completing each task and save it to the .kiro_context folder. If you check the GraphLoom repository and .kiro_context, you can see the files the agent is actually recording:

.kiro_context/
├── task_1_implementation_summary.md
├── task_2_implementation_summary.md
...

Consequently, when the agent needs to reference previously implemented code, there is no need for me to explain the details repeatedly. The agent can understand the project’s current status and implementation history simply by reading the summary files it recorded itself.

Interestingly, even when these files are included in the Rule or Steering instructions, the agent doesn’t always read every file. The agent appears to make its own relevance judgment on the current task and selectively reads only the most necessary context files. Therefore, writing clear and intuitive titles and content for the summary files is a crucial factor in helping the agent with its ‘selective knowledge utilization.’

Faster, More Accurate Development

By establishing this system for context management, the time spent inputting context during development has been drastically reduced. The greatest advantages are:

• Agent Perspective: The agent maintains continuous project memory without worrying about token limits, and it performs subsequent tasks faster and more accurately because there’s no need for repetitive prompting of detailed previous work.
• Developer Perspective: The context files provide automated project documentation, allowing both the agent and me to quickly verify past implementations.

Ultimately, this method is more than just a developer convenience; it’s a core strategy that advances AI agent collaboration from ‘one-time conversations’ to ‘sustainable knowledge sharing.’

In the next post, I’ll introduce GraphLoom, a tool I personally developed for context management, and provide specific examples of its use. For a broader perspective on building knowledge bases for AI systems, you might also be interested in my article on building an AWS-based RAG pipeline.