Building Necro-Feed: How Spec-Driven Development Changed Everything

The Resurrection Story

RSS readers were once essential. Google Reader's death in 2013 scattered users to the winds, and the format slowly faded from mainstream consciousness. Social media algorithms took over, deciding what we see and when.

I've been using RSS readers for years, but the apps I rely on charge for features like AI summarization and advanced search. When I discovered the Kiroween hackathon with its "Resurrection" category, I thought: "If I build this, I win regardless of the outcome — because I'll have an app I actually use every day."

That's how Necro-Feed was born — a gothic RSS reader that resurrects dead feeds with AI.

My Journey with Kiro

I first met Kiro on its launch day in July 2025. Back then, I wasn't familiar with concepts like spec-driven development, so I'll be honest — I uninstalled it pretty quickly without giving it a real chance. 😅

Shortly after, I saw that the AWS Turkey office was hosting a Kiro workshop in Istanbul. Both the instructors and the content caught my attention, so I decided to attend. That workshop was a turning point.

It introduced me to agentic IDEs and showed me how to integrate spec-driven development into my daily workflow. Thanks to the AWS Turkey team, I didn't just learn a new tool — I completely transformed my coding efficiency and experience.

What is Necro-Feed?

Necro-Feed is a modern RSS reader with a gothic aesthetic. Key features include:

• Séance Mode — Detects dormant feeds (60+ days inactive) and celebrates when they "rise from the grave"
• AI Summaries — Streaming AI-generated summaries using OpenRouter
• Global Search — Command palette (⌘K) with keyboard navigation
• Relics — Bookmark system for saving favorite articles
• Echoes — Reading history from the past 30 days
• OPML Support — Import/export feeds from other readers
• Crypts — Folders for organizing feeds

The tech stack: Bun + Next.js 16 + Drizzle ORM + Better Auth + Tailwind CSS v4 + Radix UI + Neon + OpenRouter

Spec-Driven Development: The Game Changer

I built 10 specs for all major features. Each spec follows the requirements → design → tasks structure.

Here's what a spec looks like for AI Summarization:

Requirements define user stories and acceptance criteria:

• "As a user, I want to generate an AI summary for any article"
• "As a user, I want to see the summary appear progressively as it's generated"
• "As a user, I want previously generated summaries to load instantly"

Design documents the technical approach:

• OpenRouter integration with Vercel AI SDK
• Streaming responses with cursor animation
• Database caching for generated summaries
• Rate limiting (50 requests/hour)

Tasks break down implementation into checkboxes:

• [ ] Create API route for summarization
• [ ] Implement streaming UI component
• [ ] Add database schema for cached summaries
• [ ] Build rate limiting logic

The Results Exceeded My Expectations

Features that other RSS apps charge money for — AI summarization, global search — I one-shot with a single spec each.

The AI summarization spec produced:

• Full streaming summary system
• OpenRouter API integration
• Database caching
• Rate limiting with user feedback
• Themed loading states ("Summoning spirits...")

All working on the first implementation.

Global search was equally impressive — full-text search across all articles with keyboard shortcuts (⌘K), debounced input, highlighted results, and recent search history. One spec, fully working.

Specs vs Vibe Coding

I used both approaches:

Specs for complex, multi-file features where context matters. Kiro gets the full picture — requirements, design decisions, constraints — and produces more accurate implementations.

Vibe coding for quick fixes, UI tweaks, and exploration. Sometimes you just need to say "make this button purple" without writing a formal spec.

The combination is powerful. Specs for major features, vibe coding for refinements.

Steering Docs: No More Repeating Context

This is my favorite Kiro feature.

I created 4 steering documents:

File	Purpose
coding-conventions.md	Bun, Next.js 16, Drizzle patterns, TypeScript standards
ui-patterns.md	Gothic theme, colors, animations, accessibility
ai-sdk-openrouter.md	OpenRouter integration patterns
nextstepjs-doc.md	Onboarding tour implementation

The biggest difference: I don't need to explain my project in every prompt.

Before steering docs, I'd constantly repeat:

• "Use Bun, not npm"
• "This is Next.js 16 with async params"
• "Follow the gothic theme with these colors"
• "Use Drizzle ORM, not Prisma"

Now Kiro just knows. It automatically follows the gothic theme, uses the correct Tailwind class order, and writes API routes with async params (Next.js 16 style).

No more absurd results like wrong import paths, inconsistent styling, or outdated API patterns. It just works.

I also built a kiroween-companion power with hackathon-specific steering docs for submission requirements, video demo structure, and deadline tracking.

Kiro Powers

Powers package documentation, steering files, and MCP servers into reusable bundles. I used 2:

Neon — Serverless Postgres management directly from Kiro. Database branching, schema pushes, and queries without leaving the IDE.

kiroween-companion — A custom power I built for the hackathon. Includes submission requirements, video demo structure, and documentation templates. When I asked about deadlines or needed help with this write-up, Kiro already had the context.

Building a custom power is simple: create a folder in .kiro/powers/, add POWER.md, and optionally include steering docs.

Agent Hooks: One-Click Automation

I created 9 hooks, all manually triggered. I prefer manual triggers because I want control over when these operations run — database migrations and full builds shouldn't happen automatically on every save.

My favorites:

Check Dependency Updates — runs bunx taze to find outdated packages with one click.

Check Unused Dependencies — runs bunx depcheck to identify dead packages bloating the bundle.

Full Verification — chains TypeScript checking, ESLint, Prettier, and production build into a single pre-commit check:

bash
bunx tsc --noEmit && bun run lint && bun run format:check && bun run build