Did you know that Kiro doesn't just have a Spec-Driven Development (SDD) flow, but also a bug fix workflow that helps you resolve one issue at a time? That's one of seven features worth knowing about.
If you're completely new to Kiro, it's an agentic harness for the CLI, web, IDE, iOS, and more. It helps teams and individuals do their best work while coding. I've been using it since it launched in July last year, and I keep finding features I didn't know were there.
(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is a part of AWS. I use it every day, and I'll be forthcoming about the parts that are still preview or experimental.)
Heads up: Kiro ships fast. I've flagged the version-sensitive bits of these features inline. Check the docs if something looks different in your build.
1. Stop approving every single command
After talking to a lot of people about Kiro, one of the main pieces of feedback I get is on approving commands. When Kiro asks permission to run a shell command, the default reaction is to hit yes and move on. Then it asks again for the next git command. And the next one.
Press Tab instead in the CLI. This allows you to edit it and put the exact permissions you'd like. For example you can be pickier on the trust tiers:
git pull --rebase # this exact command
git pull * # git pull with any arguments
git * # anything git
* # the entire shell tool
Whatever you pick persists for the session and gets stored as a regex in your agent's allowedCommands.
There's also /tools trust-all, which trusts everything. It's the documented replacement for the old /acceptall, and the security docs are blunt about it: don't use it in production or with sensitive data, and you're responsible for whatever it does.
One version note: on CLI v3 this moves to a permissions.yaml file, so the agent JSON advice above is v2. More on v3 in a minute.
Full details: tool permissions
2. The # menu is bigger than #file in the IDE
Type # in the IDE chat and you get a list of context providers. #file is the one I use a lot. The full list:
#codebase · #file · #folder · #git diff · #terminal · #problems · #url: · #code: · #repository · #current · #steering: · #docs: · #spec: · #mcp:
You can stack them in a single message. #git diff #problems review my changes is a different request than either one alone.
The one I've been using more is the #terminal. It hands Kiro your recent terminal output and command history, so you stop copying and pasting errors:
#terminal why did this build fail
One thing I find handy is the "#Currently Open files." However, keep in mind that Kiro pulls in your open files and their dependencies automatically without you asking.
Full list: context providers
Also you can't drag a file in the IDE's own explorer to the chat window, however you can copy and past the location of the file and past that into the chat window as a workaround.
3. Pick a workflow instead of freeform chatting
Kiro gives you structured starting points, and it's tempting to just start typing into the chat box instead. Instead you can choose any of these in the IDE.
- Spec for a full feature, with requirements, design, and tasks
- Plan when you want an implementation plan and zero code changes
- Bug Fix to investigate, diagnose, and resolve one problem
- Quick Spec when you want Kiro to ask a couple of clarifying questions and then generate the requirements, design, and tasks for you
Bug Fix is the one I'd try first. It writes down current behavior, expected behavior, and unchanged behavior. I like how it doesn't change a bunch of files it shouldn't. It basically tells the agent what it is not allowed to touch.
On a feature spec you also get a choice between requirements-first and tech design-first. If you already know your architecture, pick design-first. There's no reason to answer requirements questions you already have answers to.
4. Skills are slash commands
Kiro activates a skill automatically when your prompt matches the skill's description. That works, but I feel like it doesn't always automatically activate.
You can invoke one directly instead. Skills in .kiro/skills/ or ~/.kiro/skills/ show up as slash commands, so a skill named pr-review becomes:
/pr-review
That loads the entire instruction file, not just the description. Works in the CLI and the IDE.
Powers are a different thing and worth knowing about separately. A power bundles MCP server config with steering and optional hooks, and Kiro loads it only when your task is relevant to it. Powers are keyword-activated, and they're free on every plan.
5. You might be running an old build
Open Help > About and check your version against kiro.dev/downloads.
Kiro's own changelog says auto-updates were paused for IDE 1.0.x and tells you to download the latest release directly from the site. So if your version doesn't match what's on the downloads page, that's why, and no amount of restarting will fix it. Reinstalling keeps your settings, extensions, and sign-in state.
On the CLI:
kiro-cli --version
kiro-cli update
kiro-cli doctor # install and config problems
And /changelog in the CLI inside a chat session shows the release notes inline, which is a nicer way to find out what shipped than scrolling a webpage.
6. The work doesn't have to run on your laptop
One subscription covers the IDE, the CLI, Kiro on the web, ACP-compatible editors, and automation in CI/CD. Same credit pool.
I really like the web version. You kick off a session, it runs in a cloud sandbox, and it opens the pull request when it's done. Your laptop can be closed. There are also Automations, which are cron-scheduled agent runs that open PRs on their own.
Web is still in preview, gated to Pro and above, and it needs a connected GitHub account. There's an iOS app too, but it's early access via TestFlight, Pro or higher, and it's a surface for starting and reviewing cloud sessions rather than an editor. No Android yet.
7. The experimental stuff is opt-in and worth trying
Three of these are behind a flag or a toggle.
CLI v3. Run kiro-cli --v3 and it runs alongside your existing 2.x setup without touching it. You get the spec agent in the terminal:
kiro-cli --v3
/spec new my-feature
Plus capability-based permissions.yaml, standalone hooks in .kiro/hooks/*.json, and markdown agent configs. See the v3 docs for the full list of features.
Agent Focus in the IDE. Toggle it from the button in the top right. The layout flips: parallel sessions down the left, chat in the middle, specs and diffs in a panel on the right. It's a different job than editing files. You're directing several agents and reviewing what they produce. Settings, powers, MCP management, the terminal, and direct file editing all still live in the normal view, so you'll toggle back and forth.
/goal. Give it an objective and a definition of done, and it loops implement-then-verify until the criteria are met:
/goal Migrate the auth module to the new SDK. Done when all tests pass and there are no TypeScript errors.
This is available in v3 CLI.
Default is five iterations, --max <n> raises it, /goal clear cancels. The docs are right that the definition of done is the part that matters. "All tests pass" works. "Make it better" does not. You can interrupt mid-loop, or nudge it without cancelling using queue steering with Ctrl+S.
A few more worth a mention
While I'm listing CLI commands: /rewind forks the conversation at an earlier turn instead of you fighting a thread that went off the rails, and the original session is preserved. /compact summarizes history to free up context. /tangent (Ctrl+T) lets you run commands on the side (like /btw in Claude). /guide is a docs-grounded agent for "how do I do X in Kiro" questions, and it can write agents, prompts, and steering files into .kiro/ for you.
If Shift+Enter for multi-line input has been annoying you, /settings terminal fixes it and backs up your terminal config first.
Where to go when you're stuck
The Kiro Discord is the main support channel, and there's an active subreddit at r/kiroIDE. Note the name, it's kiroIDE, not r/kiro. Billing lives in your account settings. Bugs and feature requests go to the GitHub repo, and /issue in the CLI opens that workflow for you. If you need to send logs along with a bug report, /logdump zips them up.
Which of these did you not know about? Let me know in the comments. Until next time.
Top comments (1)
What features are you using in Kiro?