Building an AI-Assisted Project with Kiro: A Practical Guide for Student Builders
If you are part of a student developer group and want to use AI coding tools beyond simply asking an agent to "build this feature," Kiro provides a useful workflow for turning an idea into a structured, testable project. In this tutorial, I'll walk through the workflow I used while building AeroOps, a flight operations and incident intelligence dashboard, during the Kiro University Challenge.
What we'll build
We'll use a simple project and progressively add context and automation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Idea
↓
Specs
↓
Steering
↓
Implementation
↓
Hooks
↓
Tests
↓
Power
↓
MCP
↓
Custom Agent
By the end, Kiro knows:
- what the application is supposed to do
- how the project should be structured
- what rules the code should follow
- how to validate changes
- what domain-specific knowledge to use
- how to access external tools
- which specialized agent should handle a particular workflow
Kiro's current documentation describes Specs as a workflow covering requirements, design, and implementation tasks, while Steering provides persistent project context and conventions.
1. Start with a project
Install Kiro and open your project directory.
You can open an existing project from the IDE or use the CLI:
1
kiro .
Once the project is open, start by explaining the project in plain language.
For example:
1
2
3
4
5
6
7
I want to build a flight operations dashboard for airline operations teams.
The dashboard should show flights, disruptions, incidents,
airport status, and operational priorities.
Use mock data initially.
Keep the data source replaceable so a backend can be added later.
Don't immediately ask the agent to generate the entire application.
The first goal should be to establish what the application actually needs to do.
2. Use Specs to define the feature
Kiro Specs turn a high-level feature into:
1
2
3
4
5
Requirements
↓
Design
↓
Tasks
Kiro's documentation describes these as the three phases of the spec workflow.
For AeroOps, the first specification was:
1
2
3
4
.kiro/specs/flight-operations-dashboard/
├── requirements.md
├── design.md
└── tasks.md
The requirements defined things such as:
- what counts as a disrupted flight
- what makes an incident active
- severity levels
- airport statuses
- delay calculation
- prioritization
- loading and error states
- testing requirements
For example, instead of simply telling the AI:
1
Show delayed flights.
define the rule explicitly:
1
2
3
A flight is considered delayed when its status is DELAYED
or when estimated departure is more than 15 minutes later
than scheduled departure.
This matters because the same rule can then be used by the implementation, tests, and future agents.
Where to keep your specs
1
.kiro/specs/
For AeroOps:
1
2
3
.kiro/specs/flight-operations-dashboard/
.kiro/specs/flight-disruption-intelligence/
.kiro/specs/incident-severity-badge/
3. Add Steering
Once the requirements are defined, tell Kiro how you want the project developed.
Create:
1
.kiro/steering/
For example:
1
2
3
4
.kiro/steering/
├── product.md
├── structure.md
└── tech.md
product.md
Describe the product principles.
Example:
1
2
3
4
5
6
7
- Optimize for fast operational scanning.
- Critical information must be easy to identify.
- Avoid decorative UI that does not support the workflow.
- Empty, loading, and error states must be explicit.
- Important state must not be communicated through color alone.
structure.md
Describe where things belong.
1
2
3
4
5
6
7
8
# Project Structure
- UI components belong in components/.
- Domain logic belongs in lib/domain/.
- Data sources belong in lib/data/.
- Presentation transformations belong in lib/viewmodel/.
- Tests belong in tests/.
- UI components should not contain business rules.
tech.md
Describe technical conventions.
1
2
3
4
5
6
7
8
# Technical Conventions
- Use TypeScript strict mode.
- Avoid any.
- Keep business logic framework-independent.
- Use typed domain models.
- Test pure business logic.
- Run type-check, lint, and tests before completing features.
Steering files are stored under
.kiro/steering/ and become available across Kiro interactions.This is useful for student teams because you don't need to repeatedly tell the agent:
"Please use TypeScript."
or:
"Don't put business logic inside the React component."
The project already contains that context.
4. Let Kiro implement the tasks
Once the specification is ready, review the generated
tasks.md.For example:
1
2
3
4
5
6
- [ ] 1. Create domain models
- [ ] 2. Create mock data
- [ ] 3. Implement data-source abstraction
- [ ] 4. Build dashboard view model
- [ ] 5. Build dashboard UI
- [ ] 6. Add tests
Don't blindly execute every task.
Review them first.
Then implement them incrementally.
A useful workflow is:
1
2
3
4
5
6
7
8
9
Task
↓
Implementation
↓
Test
↓
Review
↓
Next task
This gives you smaller checkpoints and makes it easier to understand what the agent actually changed.
5. Add Hooks for repetitive checks
Once the project is working, automate repetitive validation.
For AeroOps, I created:
1
.kiro/hooks/aeroops-quality-check.json
The hook targets relevant TypeScript and TSX files and runs:
1
2
3
npm run type-check
npm run lint
npm run test
The idea is simple:
1
2
3
4
5
6
7
8
9
Source file changes
↓
Hook
↓
Type-check
↓
Lint
↓
Tests
Kiro hooks can be configured to respond to agent/file events and automate repetitive workflows.
This is especially useful in group projects because the same validation workflow can be shared with everyone.
6. Don't rely only on example-based tests
This was one of the more useful lessons from the AeroOps project.
Suppose you have:
1
isDisrupted(flight)
You could write:
1
2
3
Flight A → delayed → true
Flight B → cancelled → true
Flight C → scheduled → false
Those are useful examples.
But they don't tell you whether the rule continues to behave correctly for many possible inputs.
For the disruption logic, I added property-based testing using
fast-check.The tests generate combinations of:
- flight statuses
- incidents
- severity levels
- timestamps
- incident links
and check properties such as:
1
2
3
4
5
6
7
8
9
10
A resolved incident must not make a flight disrupted.
A disrupted flight must satisfy at least one
of the defined disruption conditions.
Higher severity must always rank above lower severity.
Prioritization should be deterministic.
The input data should not be mutated.
The relevant files are:
1
2
3
4
5
tests/disruption.property.test.ts
tests/incidentLinks.test.ts
lib/domain/disruption.ts
lib/domain/incidentLinks.ts
The principle is:
Test the rules, not just a few examples.
7. Package domain knowledge into a Power
As projects become more complicated, the agent needs more than coding instructions.
For AeroOps, I created a reusable Power:
1
tools/aeroops-flight-ops/
Its structure is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
tools/aeroops-flight-ops/
├── plugin.json
├── mcp.json
├── skills/
│ └── flight-operations/
│ ├── SKILL.md
│ └── references/
│ ├── domain-model.md
│ ├── operational-rules.md
│ ├── prioritization.md
│ └── invariants.md
└── dev.kiro/
└── steering/
└── conventions.md
A Power is useful when you have reusable knowledge that shouldn't have to be re-explained every time.
For example, the AeroOps Power knows:
1
CRITICAL > HIGH > MEDIUM > LOW
and knows how AeroOps defines:
- active incidents
- disrupted flights
- delays
- prioritization
- domain invariants
Kiro's current Power format uses
plugin.json as the required manifest, with optional skills and MCP configuration. Powers can be packaged and shared through GitHub.8. Add MCP when the agent needs external context
MCP is useful when your project needs information or tools outside the repository.
For AeroOps, I configured:
1
mcp-server-fetch
through:
1
tools/aeroops-flight-ops/mcp.json
The important architectural decision was not simply:
"Give the AI access to the internet."
Instead, I defined a boundary:
1
2
3
4
5
6
7
8
9
External Information
↓
MCP
↓
External Context
↓
AI Analysis
↓
Existing Project Rules
For example, an external source might tell us something about an airport.
That does not automatically mean:
1
airport.status = MAJOR_DELAYS
unless the AeroOps domain explicitly defines how that external information maps to its internal state.
Kiro's MCP documentation describes MCP as a way to connect the agent to specialized tools, APIs, knowledge bases, and external services.
9. Create a Custom Agent for a specific workflow
Once you have:
- project rules
- steering
- domain knowledge
- tools
you can create a specialized agent.
For AeroOps:
1
.kiro/agents/aeroops-ops-analyst.md
The agent is an:
1
AeroOps Operations Analyst
Its job is to analyze:
- flights
- disruptions
- incidents
- severity
- operational priorities
rather than acting as a generic coding assistant.
The important part is the prompt.
I instructed the agent to:
1
2
3
4
5
6
7
8
9
10
11
12
13
Use project rules as the source of truth.
Reuse existing domain functions.
Separate:
- project facts
- domain rules
- external context
- analysis
Do not invent operational classifications.
Remain read-only.
This makes the agent much more predictable.
10. Connect the pieces
At this point, the project looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
PROJECT
|
+-------------+-------------+
| | |
v v v
Specs Steering Domain Code
| | |
+-------------+-------------+
|
v
Testing
|
v
Hooks
|
+----------+----------+
| |
v v
Power MCP
| |
+----------+----------+
|
v
Custom Agent
|
v
Application
Each Kiro feature solves a different problem.
| Feature | Purpose |
|---|---|
| Specs | What are we building? |
| Steering | How should we build it? |
| Hooks | What should happen automatically? |
| Tests | Does the implementation satisfy the rules? |
| Powers | What reusable domain knowledge does the agent need? |
| MCP | What external tools/context does it need? |
| Custom Agent | Which specialized workflow should the agent perform? |
11. Keep the repository organized
A project using these features should make the configuration visible.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
project/
│
├── .kiro/
│ ├── agents/
│ ├── hooks/
│ ├── specs/
│ └── steering/
│
├── components/
├── lib/
├── tests/
│
├── tools/
│ └── your-power/
│
├── README.md
└── DEVLOG.md
This also makes it easier for another group member to understand what Kiro has been configured to do.
12. Share the Power with your group
If you package a Power in a public GitHub repository, other members can install it from Kiro's Powers panel.
The current Kiro documentation supports importing custom Powers from a public GitHub repository.
For AeroOps, the Power is available inside:
1
tools/aeroops-flight-ops/
If you want to share it separately, you can also place the Power in its own public repository.
The important file is:
1
plugin.json
and the repository must contain the Power package structure.
13. A practical workflow for your next project
You don't need to use every Kiro feature for every project.
For a normal college project, I'd start with:
1
2
3
4
5
6
7
8
9
10
11
1. Create project
↓
2. Generate/customize Steering
↓
3. Create a Spec
↓
4. Implement tasks
↓
5. Add tests
↓
6. Add Hooks
Then add the advanced capabilities only when they're useful:
1
2
3
4
5
6
7
8
Need reusable domain expertise?
→ Power
Need an external service/API?
→ MCP
Need a specialized workflow?
→ Custom Agent
This keeps the configuration proportional to the project.
14. What I learned from building AeroOps
The most useful change wasn't using an AI agent to write more code.
It was giving the agent better context.
Instead of:
1
"Build a flight dashboard."
the project eventually had:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Requirements
+
Architecture
+
Coding conventions
+
Domain rules
+
Executable tests
+
Reusable domain knowledge
+
External tools
+
Specialized agent
That made the AI-assisted development process much more structured.
For student projects, this approach is particularly useful because the
.kiro/ configuration can live alongside the source code and become part of the project's documentation and development workflow.Try it yourself
If you're working on a project with our student developer group, try this sequence:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Start with one feature.
→ Write the requirements as a Spec.
→ Add Steering for your project's conventions.
→ Implement the generated tasks.
→ Add tests for the important rules.
→ Automate repetitive checks with Hooks.
→ Package reusable domain knowledge into a Power.
→ Add MCP only when you need external tools or context.
→ Create a Custom Agent for a workflow you perform repeatedly.
Don't start by trying to configure everything.
Start with the problem you're solving and add the Kiro capability that addresses the next constraint.
Resources
AeroOps example repository
Kiro documentation
Kiro — First Project
Kiro — Steering
Kiro — MCP
Kiro — Powers
Kiro — Custom Agents
Final takeaway
Kiro becomes more useful when you treat it as part of the project's engineering workflow rather than only as a code generator.
Define the requirements, give the agent persistent context, encode important rules in tests, automate repetitive checks, and introduce external tools or specialized agents only where they solve a real problem.
That's the workflow I used for AeroOps, and it's a pattern that can be adapted to almost any student software project.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article