I Built a Necromancy Simulator for GitHub Issues (and Kiro Made Me a Better Developer)

You know that feeling when you open a repo you haven't touched in months and see 47 open issues staring back at you?

I decided to make that experience worse. On purpose.

The Idea: What if GitHub Issues Were Undead?

Grim Repo transforms your repository into an isometric graveyard:

• Files become tombstones that visually decay based on how long since their last commit
• Open issues rise as undead entities — bugs are zombies, feature requests are ghosts
• You're the Caretaker, and closing issues triggers a "Holy Fire" exorcism animation
• A Corruption Level HUD shows how haunted your codebase really is

The twist? Issues don't just float randomly. A Smart Haunt algorithm scans issue bodies for file references and positions the undead near the code they're haunting.

The Part Where I Usually Mess Up

Here's my typical hackathon workflow:

1. Get excited about idea
2. Start coding immediately
3. Realize halfway through I need to restructure everything
4. Rewrite 60% of the code
5. Ship something that works but makes me cringe

This time I tried something different.

Enter Kiro's Spec Workflow

Kiro has this feature called Specs — structured documents that force you to think through requirements, design, and implementation tasks before writing code.

I was skeptical. Planning? In a hackathon? That's time I could spend coding!

But I tried it anyway.

What Actually Happened

Requirements phase: I had to articulate exactly what "tombstone decay" meant. Turns out there are four variants based on code age:

• < 30 days: polished marble
• 30-180 days: weathered stone
• 180-365 days: cracked with moss
• > 365 days: heavily decayed

Without this step, I would've just winged it and ended up with inconsistent visuals.

Design phase: Kiro helped me map out the data flow:

GitHub API → Transformers → Zustand Store → React Components

I defined TypeScript interfaces for everything. Tombstone, Mausoleum, UndeadEntity, GraveyardView. When I actually started coding, I knew exactly what shape my data needed to be.

Tasks phase: The implementation got broken into 28 phases with specific subtasks. Each one linked back to requirements. When I finished a task, I knew it was actually done — not "done but I'll fix it later."

The Smart Haunt Algorithm

This is the part I'm most proud of. When an issue mentions src/utils/helpers.js in its body, the zombie should haunt that specific tombstone.

The spec forced me to define the priority:

1. Exact path match first (src/utils/helpers.js)
2. Filename match as fallback (helpers.js)
3. If multiple matches, pick the first one mentioned
4. No match? Zombie goes to the Graveyard Gate (unassigned area)

I wrote property-based tests for this using fast-check. The tests generate random issue bodies and file trees, then verify the algorithm behaves consistently.

// Property: Smart Haunt prioritizes exact path matches
fc.assert(
  fc.property(
    arbitraryIssueWithPaths,
    arbitraryFileTree,
    (issue, files) => {
      const result = smartHaunt(issue, files);
      // If exact path exists, it should always win
      if (hasExactPathMatch(issue, files)) {
        expect(result.matchType).toBe('exact');
      }
    }
  )
);

Without the spec, I would've hacked together something that "mostly works" and discovered edge cases in production.

The Tech Stack

• Next.js 14 (App Router) — server components for data fetching
• TypeScript (strict mode) — the spec made me define types upfront
• Tailwind CSS — dark theme with neon accents
• Framer Motion — floating undead, holy fire particles, fog effects
• Zustand — state management with navigation cache
• GitHub GraphQL API — efficient data fetching
• react-markdown + rehype-sanitize — safe Markdown rendering in the Grimoire modal

What I Learned

Specs aren't overhead — they're scaffolding.

The time I spent planning saved me from:

• Rewriting the tombstone component 3 times
• Debugging state management issues
• Figuring out z-index layering for isometric grids mid-implementation

Property-based testing catches things I wouldn't think to test.

The corruption formula is min(100, (openIssueCount * 500) / activeSourceFileCount). What happens when activeSourceFileCount is 0? Division by zero. The spec made me handle that edge case before I wrote the code.

Kiro's workflow changed how I think about building things.

It's not about the AI writing code for me. It's about having a structured process that prevents the chaos I usually create for myself.

Try It Yourself

The repo is available on GitHub. You can:

• Authenticate with GitHub and visualize your own repos
• Use Demo Mode to explore without authentication
• Watch your issues rise from the dead

And if you close an issue through the Grimoire modal, you get to watch it burn in holy fire. Very satisfying.

---

Built for the Kiroween Hackathon. The graveyard is fake but the productivity gains are real.

kiro