This post is written as part of the Kiroween 2026 hackathon.
The meeting nobody wants
Every release ends the same way. Monday morning, the freeze is Friday at six, and the board holds far more work than the team can do. Someone has to decide what gets cut, and it is usually the loudest voice in the room.
Deadline Séance turns that meeting into a rule you can see. Tickets that fit stay inside the safehouse; the rest are buried under tombstones with an epitaph that says why ("It needed 8 points; the night had 0 left"). Burn the candle down from Friday to Wednesday and capacity drops from 59 to 35 points. Send Ana away and the cut updates at once. Every decision goes into a chronicle you can undo.
Try it (no sign-in, nothing leaves your browser): https://hvaler.github.io/deadline-seance/
Writing the rule before the code
The first thing I put into Kiro's steering was not a style guide. It was the rule in plain words: keep must-haves, keep a ticket's whole dependency chain, fit the capacity, maximise the cost of delay you save, and break ties in a fixed order. Every spec started from that sentence, so "best cut" meant the same thing in the engine, the UI, the death certificate and the MCP server.
I used eight specs: rule-engine, board-ui, fog, night-tour, death-certificate, jira-csv, mcp-server and night-chronicle. Each one stopped twice: after requirements and design, so I could argue with the decisions, and at a checkpoint with real numbers before I committed. For small polish I used vibe mode in a fresh chat. My rule of thumb became: spec when a property must hold, vibe when only a pixel moves.
The test that changed the product
The fog of estimates simulates 1,000 nights where every estimate lands between 80 % and 150 % of what was written. On the sample board the optimal cut holds on 0 of 1,000 nights; with a 20 % reserve, on 707.
I assumed more reserve is always safer. A property-based search with fast-check found a small board where it is not: a bigger reserve changes which tickets the rule keeps, and the new set can be riskier. That one finding changed the UI. The strip now shows the number for every reserve instead of promising that more margin helps. There are 27 numbered properties and 1,532 tests in the repo, and a Kiro hook runs them every time an engine file is saved.
Giving the rule back to Kiro
The same engine ships as an MCP server with three read-only tools: solve_freeze, what_if and death_certificate. Registered in .kiro/settings/mcp.json, it turned Kiro's agent into a user of the product it built. Asked what happens if Ana is away all week, it answered with the engine's numbers: capacity 59 → 39, nine tickets kept, cost of delay 167 → 124. No number came from the model.
Kiro Crew and a real Jira
I also tried Kiro Crew. First as a second reviewer of my last four commits (it found a guard that was created but never called), then to build a separate app, Deadline Séance Crew, that reads live Jira Cloud issues and asks the same engine. Crew deliberately keeps Jira credentials away from the processes it starts, so the Jira reader runs outside Crew, only on 127.0.0.1, and Crew reaches it by URL. Seeded with the sample board, the real Jira gave exactly the same cut.
https://github.com/hvaler/deadline-seance-crew
What went wrong
- Three deploys failed in a row because two CSV test fixtures kept Windows line endings only on my machine. The tests stopped a broken build; a
.gitattributesfixed it at the root. - Jira's issue-link API names its two ends the opposite way to what you expect. The seed script read back its first "Blocks" link, found it reversed and stopped before creating the rest. A test now pins the direction.
What I learned
Spec mode is worth it whenever two features share state. A steering file that states the rule in plain words beats a long list of style rules. And property tests are where an assumption like "more margin is always safer" goes to die.
Demo video: https://youtu.be/Vn5QPBWRCSQ
Code (MIT): https://github.com/hvaler/deadline-seance
Written for the Kiroween 2026 hackathon.
