Frontend Best Practices with Kiro

What you will learn

This workshop walks you through configuring Kiro so that every frontend interaction — from creating a new project to building full features — follows your team's standards automatically. You write the rules once, and Kiro applies them every time.

A quick note on the tools we are using

For this workshop, we chose React + Vite as our example stack. But Kiro works with any frontend framework: Vue, Angular, Svelte, plain HTML, or anything else. The concepts you learn here (steering, skills, hooks, specs) apply regardless of your framework choice.

If you are new to these tools, here is what each one does:

• React is a JavaScript library for building user interfaces, originally created by Meta. It lets you break your UI into reusable pieces called "components" — a button, a card, a whole page — and compose them together.
• Vite (pronounced "veet") is a fast build tool. It serves your code during development and bundles it for production. Think of it as the engine that runs your app locally so you can see changes in the browser instantly.
• ESLint is a tool that checks your JavaScript code for common mistakes. It works like a spell-checker, but for code — catching things like unused variables, missing imports, or inconsistent formatting.

What we are building

The goal is to build an internal tool for Vopak — a terminal management dashboard styled like the AWS Console. By the end, you will have a working "Terminal Overview" page that lists storage terminals with their name, location, capacity, and operational status.

You will work through seven exercises:

1. Build a full landing page from a single prompt using Kiro's Vibe mode
2. Create steering files — both auto-generated foundations and custom rules — that encode your frontend conventions
3. Import agent skills from the open-source community for React best practices
4. Use web search to avoid outdated code and get current documentation
5. Compare AI models — see how Auto and Claude Sonnet 4.5 reason differently about the same problem
6. Use Spec mode to plan and build a Terminal Overview dashboard with all layers working together
7. Connect Chrome DevTools MCP to debug, screenshot, and test your running app directly from Kiro

Estimated time: ~1 hour 45 minutes for the core workshop (Exercises 1–7 + Summary). Two bonus exercises are available if time permits.

Exercise 1: Build a page from scratch with Vibe mode

In this exercise, you will go from an empty folder to a fully working web page in a single prompt. This is Kiro's Vibe mode — you describe what you want in plain language, and Kiro builds it. No manual setup, no config files, no boilerplate.

Step 1: Open a new project folder in Kiro

Step 2: Open Vibe mode and build a page

Step 3: See the result

Open your browser at http://localhost:5173. You should see a full landing page with a dark nav bar, a hero section, stats, and terminal cards.

Exercise 2A: Foundational steering — let Kiro learn your project

Why start with foundations?

Before you write custom rules, Kiro can auto-generate steering documents that describe your project's tech stack, product context, and file structure. These give Kiro a baseline understanding of your project so it does not have to guess what framework you are using, where your files live, or what your dependencies are.

Step 1: Generate steering docs

Kiro will scan your project and create three files automatically:

• product.md — what your project does and who it is for
• tech.md — your tech stack, dependencies, and build tools
• structure.md — your folder layout and file organization

Step 2: Review the generated files

Exercise 2B: Custom steering — add your own rules

Why add custom rules?

The auto-generated docs tell Kiro what your project is. Custom steering tells Kiro how you want code written. Without it, Kiro makes reasonable guesses — but those guesses might not match your team's preferences.

Here is what the same kind of component looks like when Kiro has steering rules:

With steering (the goal)

 1// ✓ With steering — Kiro follows your conventions
 2import './Card.css';
 3
 4export function Card({ title, children }) {
 5  return (
 6    <section className="card">
 7      <h3 className="card-title">{title}</h3>
 8      {children}
 9    </section>
10  );
11}

1.card {
2  background: var(--color-surface);
3  border-radius: var(--radius-md);
4  padding: var(--space-lg);
5  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
6}
7
8.card-title {
9  color: var(--color-text);
10}

Named export, semantic HTML (<section>), co-located CSS file, CSS custom properties instead of hardcoded values. That is the target. Let's set up the steering to get there.

Step 1: Create a component conventions file

 1# Frontend conventions
 2
 3## Stack
 4- React 19 with Vite
 5- JavaScript (not TypeScript)
 6- Plain CSS with custom properties — no Tailwind, no CSS-in-JS
 7- ESLint for linting
 8
 9## Component rules
10- Function components only, no class components
11- Named exports: `export function MyComponent()`, never default exports
12- Destructure props in the function signature
13- One component per file, filename matches component name in PascalCase
14- Place components in `src/components/`
15- Place shared data and constants in `src/data/`
16
17## Styling
18- Define a design token system using CSS custom properties in `src/index.css`
19- Never hardcode colors, spacing, or font sizes — always use variables
20- Component-specific styles go in a co-located `.css` file
21
22## Accessibility
23- Use semantic HTML: `<nav>`, `<main>`, `<section>`, `<header>`, `<footer>`
24- ARIA labels on all interactive elements
25- Minimum 4.5:1 contrast ratio
26- All interactions must be keyboard accessible

Option B — or ask Kiro to create it for you:

Step 2: Create a conditional CSS steering file

 1---
 2inclusion: fileMatch
 3fileMatchPattern: "**/*.css"
 4---
 5
 6# CSS design tokens
 7
 8When writing or editing CSS in this project, always use these tokens:
 9
10- Colors: `--color-primary`, `--color-secondary`, `--color-bg`, `--color-surface`, `--color-text`, `--color-text-muted`
11- Status: `--color-success`, `--color-warning`, `--color-error`, `--color-info`
12- Spacing: `--space-xs` (4px), `--space-sm` (8px), `--space-md` (16px), `--space-lg` (24px), `--space-xl` (32px)
13- Radii: `--radius-sm` (4px), `--radius-md` (8px), `--radius-lg` (16px)
14- Font: `--font-family`, `--font-mono`
15
16Never hardcode hex values, pixel spacing, or font stacks.

Option B — or ask Kiro to create it:

Step 3: Test your steering

Steering best practices

As you write and maintain steering files, keep these two rules in mind:

To understand why this matters, you need to know how Kiro "sees" your project. Everything Kiro reads — system instructions, steering files, your files, conversation history, and your current prompt — goes into a context window. This is the total amount of information the model can process at once:

The context window has a fixed size. When it fills up — with too much steering content, large files, long conversation history — the model loses focus and quality drops:

This is why what you put in steering files matters. Kiro already knows common programming patterns, standard library docs, and general best practices. Putting that in your steering wastes context space. Avoid this:

Instead, focus on project-specific context that Kiro cannot figure out on its own — your conventions, architecture decisions, business domain, and constraints:

Exercise 3: Import agent skills from the community

What are skills?

Skills are portable instruction packages that follow the open Agent Skills standard — a way for the community to share best-practice instructions that any AI coding tool can use. They bundle patterns, rules, and templates into reusable packages. Kiro loads only the name and description at startup, then activates the full instructions on demand when your task matches.

In plain terms: if steering is your team's internal style guide, skills are like importing an expert's playbook. Someone already figured out the best patterns for React performance, accessibility, or state management — skills let you use that knowledge without reading through hundreds of blog posts.

Step 1: Import the Vercel React best practices skill

Option A — via the Kiro UI:

Option B — ask Kiro to import it for you (project-scoped):

Step 2: Verify and explore the skill

Check the Agent Steering & Skills section in the Kiro panel. You should see the skill listed:

Step 3: Test the skill with a prompt

Bonus skill: Anthropic's frontend-design

Anthropic — the company behind Claude, the AI model that powers Kiro — maintains an official set of agent skills. Their frontend-design skill focuses on creating distinctive, production-grade frontend interfaces with high design quality. Instead of generating generic-looking UI, it pushes Kiro to make creative choices about typography, color, layout, and motion.

To install it, use the same process as before:

Option A — via the Kiro UI:

Option B — ask Kiro:

Step 4: Refactor your landing page with the frontend-design skill

Now that both skills are installed, let's see the frontend-design skill in action. Ask Kiro to redesign the landing page you built in Exercise 1:

Other skills worth exploring

Skills best practices

Exercise 4: Web search — avoid outdated code and hallucinations

The problem: AI models have a knowledge cutoff

AI models are trained on data up to a certain date. After that, they don't know about new releases, API changes, or deprecations. This means Kiro might generate code that compiles without errors but uses deprecated APIs that will break in the next version — or worse, silently produce wrong behavior.

Kiro has built-in web search that can look up current documentation before generating code. In this exercise, you will see the difference it makes.

Step 1: Ask without web search context

Step 2: Ask with web search context

Why this matters

This is not just about Vite. The same problem applies to any fast-moving technology: React Server Components, Next.js App Router, AWS SDK v3, Terraform provider updates. Without web search, Kiro relies on its training data — which may be months or years behind. With web search, it checks the source of truth before writing code.

Exercise 5: Compare models — Haiku vs. Sonnet 4.5

Kiro lets you choose which AI model powers your chat. Different models have different strengths — some are faster and cheaper, some reason more deeply. In this exercise, you will ask the same planning question to two different models and compare how they think.

Step 1: Ask Haiku to plan an architecture

Step 2: Ask the same question with Sonnet 4.5

Exercise 6: Build a Terminal Overview dashboard with Spec mode

Spec mode is Kiro's structured approach to building features. Instead of jumping straight into code, it turns an ambiguous idea into a precise plan through a series of documents — requirements, design, and tasks — that you review and approve at each step. This diagram shows the flow:

Scenario

Vopak operates storage terminals around the world for chemicals, oil, gas, and LNG. Your team needs an internal Terminal Overview dashboard — a page that lists Vopak storage terminals with their name, location, capacity, and operational status. The design should follow the AWS Console style: dark top navigation, white content cards with subtle shadows, and color-coded status badges.

This is a self-contained feature that exercises everything you have set up: steering conventions, community skills, and automated hooks. In a real scenario, this dashboard could be connected to live data from Vopak's systems — for now, we will use static sample data.

Step 1: Start a Spec session

Step 2: Review the requirements

Kiro will generate a requirements.md. Check it against this list:

Step 3: Review the design

Step 4: Execute the tasks

Step 5: Verify the result

Once Kiro finishes executing the tasks, verify the result directly in the IDE:

• Check the file explorer on the left — you should see new component files in src/components/ and a data file in src/data/
• Open the browser at http://localhost:5173 — the Terminal Overview page should be visible with cards, search, and status badges
• Click through the files Kiro created and review the code

Spec best practices

Tips for getting the most out of Spec-driven development. Full guide →

Exercise 7: Debug and test your app with Chrome DevTools MCP

What is Chrome DevTools MCP?

Chrome DevTools MCP lets Kiro control and inspect a live Chrome browser. It acts as an MCP server that gives Kiro access to the full power of Chrome DevTools — taking screenshots, checking console errors, analyzing network requests, and running performance audits. Instead of switching between Kiro and Chrome to debug, Kiro can do it directly.

Step 1: Configure the MCP server

Ask Kiro to add the Chrome DevTools MCP server to your project configuration:

Kiro will update your .kiro/settings/mcp.json file with the new server entry. The MCP server should connect automatically — check the MCP Servers panel to confirm chrome-devtools is listed as connected.

Step 2: Make sure your app is running

Before testing with Chrome DevTools, make sure your dev server is running. If it is not, ask Kiro to start it:

Your app should be running at http://localhost:5173.

Step 3: Take a screenshot and review

Ask Kiro to open your app in Chrome and take a screenshot:

Kiro will open Chrome (or connect to an existing instance), navigate to your app, capture a screenshot, and report any console messages.

Step 4: Run a performance audit

Ask Kiro to analyze your app's performance:

Step 5: Debug a specific interaction

Test the search functionality by asking Kiro to interact with the page:

Other things you can do with Chrome DevTools MCP

MCP security best practices

MCP servers are third-party code that connects to external services. Follow these practices to stay secure. Full guide →

Bonus A: Use Kiro Powers to generate Terraform for AWS deployment

What are Kiro Powers?

Powers are pre-packaged integrations that bundle MCP tools with documentation and workflow guidance. While steering teaches Kiro about your project and skills teach it best practices, Powers give Kiro access to external tools and services — like the Terraform registry, AWS documentation, or Figma designs.

Think of it this way: steering is your team's style guide, skills are expert playbooks, and Powers are specialized toolboxes. The Terraform Power, for example, gives Kiro access to the HashiCorp registry so it can look up real provider documentation, module versions, and resource schemas when generating infrastructure code.

Step 1: Install the Terraform Power

Once installed, Kiro gains access to Terraform registry providers, modules, policies, and HCP workflow management tools.

Step 2: Ask Kiro to generate the infrastructure

Now ask Kiro to create the Terraform code that would deploy your Terminal Overview dashboard to AWS. You do not need to run terraform apply — the goal is to see how Powers work.

Step 3: Review the generated files

Kiro should create an infra/ directory with Terraform files. Check for:

1ls infra/
2# Expected: main.tf, variables.tf, outputs.tf, providers.tf

Bonus B: Automate quality checks with hooks

What are hooks?

Think of hooks as automatic reminders or checks. Just like your phone can remind you to drink water every hour, Kiro hooks can automatically check your code every time you save a file, create a new component, or submit a prompt. You set them up once, and they run in the background without you having to remember.

A hook is made of two parts: a trigger (when should it run?) and an action (what should it do?). Here are all the available triggers and actions:

There are two ways to create a hook: describe it in natural language and let Kiro build it, or write the JSON file yourself. We will try both.

Step 1: Create a lint hook using natural language

This is the easiest way — you describe what you want and Kiro creates the hook for you.

Kiro will generate the hook JSON file for you and save it in .kiro/hooks/.

Step 2: Create an accessibility review hook manually

Now let's create one by writing the JSON file directly — this gives you full control over the configuration.

 1{
 2  "name": "Accessibility Review",
 3  "version": "1.0.0",
 4  "description": "Review new components for a11y issues",
 5  "when": {
 6    "type": "fileCreated",
 7    "patterns": ["src/components/*.jsx"]
 8  },
 9  "then": {
10    "type": "askAgent",
11    "prompt": "Review this new component for accessibility: semantic HTML, ARIA labels, keyboard navigation, color contrast using CSS custom properties, and focus management. List any issues."
12  }
13}

Verify your hooks

Check the Agent Hooks section in the Kiro explorer. You should see two hooks listed.

Hooks best practices

Summary and next steps

You configured three layers of Kiro's frontend workflow and used them together to build a Vopak Terminal Overview dashboard:

Together, these layers cover the full development lifecycle: steering and skills shape the code Kiro writes, hooks automate quality checks, Powers handle infrastructure, and MCP integrations let Kiro test the running application.

Next steps

• Explore Kiro Powers — MCP integrations that bundle tools with guidance (Figma validation, deployment automation, AWS infrastructure)
• Create a custom skill that encodes your team's specific component library
• Add a postTaskExecution hook that runs your test suite after each spec task completes
• Connect the Terminal Overview to live data — replace the static terminals.js with an API call to Vopak's systems
• Browse more community skills at awesome-frontend-skills
• Try the frontend-design built-in skill — type /frontend-design in chat to activate it for high-fidelity UI generation