Practice Exercises

Objective: Use chat with the #file and #codebase context providers to understand unfamiliar code, then make one small change safely in Supervised mode.

Scenario: You have a tiny recipe-box web app (index.html, app.js, styles.css) that you wrote months ago and barely remember. You just opened it in the Kiro IDE for the first time.

Expected outcome: Kiro gives an accurate walkthrough of the project, and the rename lands in your files only after you explicitly accepted each hunk. Open the files (or run git diff) and confirm the result matches exactly what you approved.

★ Optional challenge: Repeat the same rename in Autopilot mode on a throwaway copy of the project. Compare the two experiences and decide which mode you would use for everyday edits versus risky ones.

Objective: Turn a one-line feature idea into a structured spec and execute your first task from it.

Scenario: Your personal todo app works, but you want starred todos to appear in a pinned Favorites section. Instead of improvising in chat, you will drive the feature as a Kiro spec.

Expected outcome: The spec exists as three files (requirements.md, design.md, tasks.md), the first task is marked complete, and the corresponding code behaves exactly as the EARS requirement describes.

★ Optional challenge: Run the optional requirements analysis on requirements.md and see whether Kiro flags ambiguity, contradictions, or gaps you missed when reading it yourself.

Objective: Write a steering file so a project convention persists across every future Kiro session without you restating it.

Scenario: In your recipe-box project you keep reminding Kiro to use arrow functions and to prefix boolean variables with is/has. You will write the rules down once in .kiro/steering/ instead.

Expected outcome: In a brand-new session with no reminder from you, generated code follows the conventions in your steering file, and follows the changed rule after you edit the file.

★ Optional challenge: Add a second steering file for CSS conventions with fileMatch front matter so it only loads when style files are involved, and verify it stays out of unrelated sessions.

Objective: Create an event-driven hook from a natural-language description and scope it narrowly enough to be helpful instead of noisy.

Scenario: The Features section of your weather-dashboard README goes stale every time you touch src/. You will make Kiro refresh it automatically whenever a source file is saved.

Expected outcome: Saving a source file produces a README update in the same session, while saving an out-of-scope file triggers nothing; you have observed both behaviors at least once.

★ Optional challenge: Add a manual on-demand hook (e.g., "audit every TODO comment in the project") and write down one situation where a manual trigger beats an automatic one.

Objective: Configure an MCP server at the workspace level and invoke one of its tools from chat with deliberate, per-call approval.

Scenario: Your markdown-notes project keeps needing facts from outside the repo. You will connect a web-search (or documentation) MCP server so the agent can fetch information itself.

Expected outcome: The MCP servers panel shows your server connected, and a chat request successfully runs one of its tools after your explicit approval, with the tool output visible in the conversation.

★ Optional challenge: Add the single safest read-only tool to "autoApprove", repeat the request, and note the difference; then explain why setting autoApprove to "*" would be a risky default.

Objective: Run a complete Kiro workflow in the terminal: context globs, shell commands, and a session you can put down and pick back up.

Scenario: You manage your dotfiles repo entirely from the terminal and want Kiro there too: no IDE window, just a chat session that survives being closed.

Expected outcome: After resuming, Kiro answers the follow-up using details from before you exited, proof that the session and its context survived the round trip.

★ Optional challenge: Exit again and restart with kiro-cli chat --resume-picker to choose among saved sessions, and try /editor to compose a long multi-line prompt in your editor.

Objective: Define a custom agent with a restricted toolset and prove the restriction holds under a direct write request.

Scenario: You want a code-review persona for your expense-tracker repo that can read and critique anything but can never touch a file, so it is safe to point at a branch you do not want modified.

Expected outcome: You get a useful review, every attempt to modify a file fails, and git status reports zero changes after the session. The restriction is real, not cosmetic.

★ Optional challenge: Build a sibling agent that may write but only sees a narrow resources list, give both agents the same task, and compare where each one hits its walls.

Objective: Drive a disciplined bugfix (root-cause analysis, minimal diff, regression test) using the bugfix spec workflow instead of panic-patching.

Scenario: Your expense-tracker has a monthly-totals function. You will plant a double-counting bug (expenses with two category tags get summed twice), then fix it the way you would during an incident: with a paper trail.

Expected outcome: bugfix.md names the real root cause, the final diff touches only the faulty logic, and the regression test passes, then goes red again if you temporarily revert the fix.

★ Optional challenge: Use a checkpoint to roll the entire fix back, then re-execute the fix task and confirm you reach the same green state. Treat it as a recovery drill for real incidents.

Objective: Combine steering, a spec, and a hook into one team-ready workflow, and learn where the responsibility of each mechanism ends.

Scenario: Your team's clickstream ETL repo loads daily events into the warehouse. You are adding a sessionization stage and want every future contributor, human or agent, to follow the same conventions automatically.

Expected outcome: The design and code follow team conventions with zero reminders in chat, and the save hook reliably fails on a deliberate violation and passes again once you repair it.

★ Optional challenge: Write a short boundary memo for your team: which rules went into steering versus the spec versus the hook, and which one you would relocate first if the team doubled in size.