7 Kiro Features You're Probably Not Using

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 co