AWS Builder Center
I automated AWS Correction of Event culture with a single Kiro hook

I automated AWS Correction of Event culture with a single Kiro hook

Kiro's Day 1 birthday challenge asked builders to automate something meaningful. This walks through Auto-COE, a Kiro Agent Hook that watches for a resolved BUG marker and instantly drafts a postmortem, a failing regression test, and a recurring-pattern trend report, deterministically, across six languages, with zero LLM cost.

Platform Engineer · AWS Builder Circle Lead, AWS UG Madurai · Shipping agentic apps on Bedrock

Introduction

Every AWS team writes a Correction of Event, a COE, after something breaks. What happened, why, what fixes it, what test makes sure it never happens again. It is one of the best habits in this industry. It is also one of the first habits to get skipped, because nobody has time to write a full postmortem for the twelfth small bug they fixed this week.
For Kiro's birthday week Day 1 challenge, "build a hook that automates something meaningful," I built the thing I actually wish existed on every team I have worked on: a Kiro hook that writes the postmortem for you, the moment you fix the bug, for free.

The gap it fills

Kiro's own example for this challenge is a docs-sync hook, and that is a real problem. But watching docs drift from code is reactive. I wanted something that catches the moment institutional knowledge is created and makes sure it does not evaporate.
Here is the pattern almost every codebase already has: a developer finds a bug, marks it with a # BUG: or # FIXME: comment while they investigate, then eventually fixes it and deletes the comment. That moment, the comment disappearing, is a signal nobody currently listens for. It means "a bug that someone cared enough to flag has just been resolved." That is exactly the moment a postmortem should get written, and exactly the moment nobody has time to write one.

What the hook does

The main hook lives at .kiro/hooks/auto-coe.kiro.hook. It fires on every file save, anywhere in the repository. On each save, a small deterministic script:
  1. Diffs the saved file against the last git commit.
  2. Checks whether a BUG or FIXME marker present in the previous version is gone in the new one.
  3. If so, drafts a Correction of Event markdown file, seeded with the description the developer already wrote in the marker, plus the exact diff that resolved it.
  4. Generates a regression test stub, in the idiomatic style for that language, that deliberately fails until a human fills in the real assertion, so the "we should add a test for this" step cannot be silently skipped.
  5. Records the fix in a ledger, and regenerates a trend index. If two or more resolved bugs share a known pattern keyword (off-by-one, null, race condition, and a dozen others), a recurring-pattern callout gets added automatically: "2x off-by-one bugs recorded, across: apply_loyalty_discount, reserve_stock. Worth a lint rule."
  6. Regenerates a small self-updating badge showing the live count.
Here is the hook definition itself, in Kiro's native .kiro.hook format:
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"enabled": true,
"name": "auto-coe-on-fix",
"version": "1",
"when": {
"type": "fileEdited",
"patterns": ["**/*.py", "**/*.js", "**/*.jsx", "**/*.ts", "**/*.tsx", "**/*.go", "**/*.java", "**/*.rs"]
},
"then": {
"type": "runCommand",
"command": "python scripts/generate_coe.py"
}
}
That is the whole integration point. Everything else is a plain Python script, no LLM call, no network call. I made that choice on purpose.

Why deterministic, on a platform built around agents

Kiro hooks support two action types: an agent prompt (askAgent), or a shell command (runCommand). Agent prompts are the more obvious choice for something that has to understand a diff and reason about it. I used a shell command instead, and I think that choice is the actual interesting part of this project.
A shell command runs the same way every time. It costs no credits. It does not depend on a model being available or in a good mood. When you are demoing something live, or shipping something a team will rely on daily, "boringly reliable" beats "occasionally brilliant." The hook fires in milliseconds, every single time, whether or not you have credits left that month.
That said, some parts of a postmortem genuinely need judgment. A shell script cannot infer why a bug happened, only that the marked code changed. So there is a second, optional hook, auto-coe-smart, that uses Kiro's other action type, an agent prompt, on a manual (userTriggered) trigger. You run it on demand from the Agent Hooks panel, so it never spends credits on its own. It reads the same diff and fills in the Root Cause and Impact sections that the deterministic hook leaves as TODO, and checks whether the same bug class exists elsewhere in the codebase. Between the two hook files, the project exercises both trigger types and both action types Kiro offers: an automatic file trigger, a manual trigger, a shell-command action, and an agent-prompt action.

It is not tied to one language, or one folder

The first version only understood Python files in one folder. That is a demo, not a tool anyone would adopt, so I generalized it before submitting.
The engine now scans the entire repository on every save, and speaks six languages out of the box: Python, JavaScript, TypeScript, Go, Java, and Rust. Each one gets its own comment syntax for the marker, its own function-boundary detection (indentation for Python, brace matching for the rest), and its own idiomatic regression-test format: a pytest stub for Python, a Jest-style stub next to the file for JavaScript and TypeScript, a _test.go file for Go, a JUnit class for Java, an integration test stub for Rust. Where a language's test-file convention is too project-specific to fully automate, like Java's package layout or Rust's crate path, the generated stub says so explicitly with a TODO instead of guessing wrong.
I did not just claim this works. The file tests/test_generate_coe_engine.py feeds real before-and-after code snippets in every supported language through the actual detection logic and asserts it finds the right bug and the right function. Anyone can clone the repo and run the tests to see all of it pass.
Adopting this in an existing project is two files: copy .kiro/hooks/auto-coe.kiro.hook and scripts/generate_coe.py into the same paths, open the project in Kiro, done. No config file, no directory convention to follow, no dependency to install.

Watching it compound

The part I like most only shows up after the second bug fix. Fix one bug, you get one postmortem. Fix a second bug that happens to share a pattern keyword with the first, off-by-one, null check, whatever, and the trend index surfaces it on its own:
1
2
3
4
## Recurring patterns

- 2x "off-by-one" bugs recorded so far, across:
apply_loyalty_discount, reserve_stock. Worth a lint rule or a shared helper.
Nobody scheduled a retro to notice that. Nobody had to remember to check. It is a byproduct of normal bug-fixing, computed fresh every time the ledger changes, from a small transparent keyword list in the script itself, not a black box. You can read exactly why a pattern got flagged.

Try it

The repo ships with two seeded, deliberately untested bugs, so you can reproduce this without touching your own codebase:
1
2
3
4
git clone https://github.com/yogeshselvarajan/kiro-auto-coe-hook
cd kiro-auto-coe-hook
pip install -r requirements-dev.txt
python -m pytest -q
You should see 13 tests pass: the two seeded bugs plus the proof for all six languages. Then open the repo in Kiro and fix the bug in src/pricing.py by deleting its # BUG: comment and replacing the marked body with a single line, return total * 0.90. Save, and watch docs/incidents/ and tests/ update on their own. Fix the second bug in src/inventory.py the same way and watch the recurring-pattern callout appear. You can also run python scripts/generate_coe.py by hand any time to see exactly what the hook does, no Kiro session required to understand it.

Closing thought

Kiro turned one this week. A year in, the thing that stands out to me about hooks specifically is that they are not another chat window, they are automation that happens whether or not you remember to ask for it. That is the same property that makes AWS's own COE culture work: the good habits that survive are the ones that do not depend on someone remembering to do them. This hook just moves that habit one step further back, to the moment the fix itself gets saved.
Happy birthday, Kiro.
Built for Kiro's birthday week Day 1 challenge. #BuildWithKiro #TeamKiro #1YearOfKiro
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article