DEV Community: yongrean

I built an AI that filters what actually needs your attention — architecture, failures, and what works

yongrean — Sun, 17 May 2026 16:21:32 +0000

I used to start every morning the same way: open Gmail, feel immediately overwhelmed, spend 40 minutes triaging emails that turned out not to matter — and then miss the one thing that actually did.

So I built Jigeum — an AI Chief of Staff that reads your inbox, scores every signal by urgency, and surfaces only what needs you. This is the architecture, the honest failures, and what actually changed my routine.

The first version completely failed

My original product was called EVE. The pitch: "AI employee — connect your tools, EVE handles the rest."

It was too broad. Every demo, people nodded politely. Nobody knew what to do with it. I shipped features — Slack integration, task management, autonomous agent loops — but the core value proposition was muddy. Four months in, I was the only person using it daily.

Every morning I'd open it and quietly ask myself: why am I actually using this?

That question cracked it open.

The real problem: attention is the bottleneck

The problem isn't having too many emails. It's that every notification competes for the same finite resource: your decision-making capacity.

A GDPR newsletter. A contract waiting for signature. A customer reporting a critical bug. A LinkedIn request. Your inbox treats them identically.

I renamed the product Jigeum (지금 — Korean for right now) and rebuilt around a single question: what needs my attention right now, and what doesn't?

Architecture: the Attention OS

The core model is a 5-tier escalation system. Every incoming signal — email, calendar event, extracted commitment — gets classified before it ever reaches me:

SILENT    → don't surface, don't notify
QUEUE     → add to review list, no interrupt
PUSH      → mobile push notification
CALL      → urgent interrupt (not yet built)
AUTO      → handle automatically without asking

I call this the Attention Firewall. Before anything reaches my conscious attention, it passes through classification.

Trust Score

Each sender gets a Trust Score (0–100). Higher score means more likely to escalate. It's derived from:

Historical reply frequency
Whether I've responded before, and how fast
Explicit feedback ("always notify me from this person")
Domain-level signals (my own domain scores higher than cold outreach)

interface TrustScore {
  userId: string;
  contactEmail: string;
  score: number;               // 0–100
  interactionCount: number;
  avgResponseMinutes: number | null;
  lastInteractionAt: Date | null;
}

A newsletter I've never replied to scores ~10. My co-founder scores 95. The escalation tier is calculated from trust score combined with content analysis of the email itself.

Voice Profile

The AI needs to know how I communicate, not just what to do. Voice Profile stores the patterns extracted from my sent mail:

interface VoiceProfile {
  userId: string;
  tone: string;                // "direct", "warm", "formal"
  signatureStyle: string;
  preferredLength: "short" | "medium" | "long";
  phrases: string[];           // things I actually say
  avoidPhrases: string[];      // things I never say
}

When drafting a reply suggestion, the AI pulls this profile. The goal is that a suggested reply reads like me — not like a generic AI assistant.

Commitment Ledger

This is the feature that made me realize the product had real value.

Every email where I wrote "I'll send this by Friday" or "Let me get back to you next week" — those are commitments. They disappear into threads. I forget them. The other person doesn't.

The commitment extractor runs on every processed email and populates a ledger:

interface Commitment {
  id: string;
  userId: string;
  title: string;
  kind: "DELIVERABLE" | "MEETING" | "FOLLOW_UP" | "DECISION";
  owner: "USER" | "COUNTERPART";
  dueAt: Date | null;
  dueText: string | null;      // "by Friday", "next week"
  confidence: number;          // 0–1
  status: "OPEN" | "DONE" | "OVERDUE";
}

The confidence field matters a lot. "Let's sync sometime" → confidence 0.3, stays quiet. "Please send the NDA by Tuesday EOD" → confidence 0.9, surfaced immediately in the Command Center.

The Command Center

The UI is a single page. This replaced my inbox as the first screen I open each morning.

Layout (left → right on desktop):

Morning Briefing — AI summary of what happened overnight and what needs attention today, full width at top
Approval Queue — actions Jigeum wants to take but needs my sign-off first
Commitment Ledger — things I promised, things others promised me
Reply Needed — emails where someone asked a direct question

The Reply Needed surface was the hardest to get right. Naive approach (detect ? in email body) had terrible precision — questions in automated receipts, rhetorical questions, quoted threads all triggered false positives.

What actually works: question detection + sender trust weighting + thread position analysis (a question in the first email of a thread means something different than the same question in reply #5).

// GET /api/inbox/reply-needed
const rows = await prisma.emailMessage.findMany({
  where: { userId, needsReply: true },
  orderBy: [
    { needsReplyConfidence: "desc" },
    { receivedAt: "desc" }
  ],
  take: 8,
  select: {
    id: true,
    subject: true,
    from: true,
    snippet: true,
    needsReplyReason: true,
    needsReplyConfidence: true,
    receivedAt: true,
  },
});

Tech stack

Layer	Choice
API	Fastify + TypeScript + Prisma
Database	PostgreSQL (Supabase)
Web	Next.js 15 App Router
AI	OpenRouter — Claude Sonnet for analysis, Haiku for classification
Email	Gmail API (OAuth2, incremental sync via `historyId`)
Push	Web Push API + service workers
Deploy	Render (API) + Vercel (web)

One thing I'd do differently: Gmail sync architecture. I built polling with historyId-based incremental sync when I should have used Gmail Push Notifications from day one. The polling works but introduces ~30s latency on new emails. That latency matters when something urgent arrives.

What failed (honestly)

Notification flood. The early version pushed a notification for every signal classified as PUSH tier. Within 24 hours I had disabled push notifications on my own app. Had to rebuild with rate limiting — same-sender notifications within 15 minutes now collapse into one.

Over-trusting AUTO. The autonomous tier where Jigeum acts without asking me — I thought I wanted this. Turns out I don't trust it yet. I've pulled AUTO back to only unsubscribes and read-receipts. Anything that involves sending a message or making a decision goes through the Approval Queue.

The rebrand was a distraction. Spent a full week renaming EVE → Jigeum across the codebase, updating marketing copy, redoing the landing page. The code ran identically after. Should have shipped instead.

Mobile doesn't exist yet. It's web-only. For something meant to filter morning attention, the fact that you have to open a browser tab is a real friction point. Working on it.

Four weeks of dogfooding — what actually changed

I check the Commitment Ledger before every morning standup. It's caught 3 things I would have genuinely dropped.
Reply Needed reduced my inbox-zero anxiety. If something actually needs me, it surfaces there. If it's not there, I'm not missing anything.
Morning Briefing saves roughly 20 minutes of triage per day.
The AI still occasionally misclassifies cold outreach as high-priority. Trust Score calibration is ongoing.

Try it

Jigeum is in private beta at hire-eve-web.vercel.app. Connect Gmail + Calendar, initial sync takes about 30 seconds.

If you're a founder, solo operator, or anyone who feels like their attention is being managed by their inbox rather than by themselves — I'd genuinely value the feedback. Especially where it gets the classification wrong.

Happy to answer architecture questions in the comments.

Built solo. Stack: Next.js, Fastify, PostgreSQL, Gmail API, and a lot of OpenRouter credits.

ko-prompt-kit: Production-ready Korean LLM prompts for Claude & GPT

yongrean — Sun, 17 May 2026 15:31:15 +0000

If you're building AI apps that need to output natural Korean, translating English prompts doesn't cut it. Korean has formal/informal speech levels (존댓말/반말), unique document conventions, and cultural context that English-native prompts completely ignore.

So I built ko-prompt-kit — 14 production-ready Korean prompt templates across 5 categories, with a TypeScript API and CLI.

Zero install, instant use

npx ko-prompt list
npx ko-prompt get coding/code-review

14 prompts across 5 categories

Category	Prompts
Business	Email reply, meeting minutes, report summary
Coding	Code review, commit message, bug analysis, JSDoc
Customer Service	Complaint reply, FAQ answer
Writing	Blog post, marketing copy
Analysis	Document summary, sentiment, competitive analysis

TypeScript API

import { getById, buildPrompt, search } from 'ko-prompt-kit';

const prompt = getById('coding/code-review');
const built = buildPrompt(prompt, {
  language: 'typescript',
  code: yourCode,
  focus: '보안',
});

// Use with Claude
const response = await anthropic.messages.create({
  model: 'claude-opus-4-7',
  system: built.system,
  messages: [{ role: 'user', content: built.user }],
});

What makes Korean prompts different

Each prompt is designed around Korean language specifics:

Speech level: formal (합쇼체) vs informal (해체) — selected per use case
Document structure: Korean business docs have specific conventions
Cultural context: complaint handling, business email norms

Search and filter

// Find formal prompts for business use
const formal = search({ category: 'business', speechLevel: 'formal' });

// Search by keyword (Korean or English)
const emailPrompts = search({ query: '이메일' });

GitHub: k08200/ko-prompt-kit

npm install ko-prompt-kit

Would love contributions — especially prompts for domains I haven't covered yet (legal, medical, education).

I built the npm audit for MCP servers

yongrean — Sun, 17 May 2026 13:53:28 +0000

The MCP (Model Context Protocol) ecosystem has exploded. awesome-mcp-servers lists 200+ servers — but there was no way to know if any of them actually worked.

So I built mcp-probe: a zero-config CLI that validates MCP servers in one command.

The problem

You add a server to Claude Desktop, it silently fails. You look at logs, get "connection closed". You have no idea if it is a network issue, a broken dependency, or the server just does not implement the protocol correctly.

What mcp-probe does

npx @k08200/mcp-probe @modelcontextprotocol/server-memory

mcp-probe  @modelcontextprotocol/server-memory
────────────────────────────────────────────────────
  ✓  MCP protocol handshake  1392ms — memory-server v0.6.3
  ✓  Tools discovery  33ms — Found 9 tools
  ✓  Tool schema validation — All tool schemas are valid
────────────────────────────────────────────────────
  Server   memory-server v0.6.3
  Caps     tools

  Tools
    ▸ create_entities  Create multiple new entities in the knowledge graph
    ▸ read_graph  Read the entire knowledge graph
    ▸ search_nodes  Search for nodes in the knowledge graph
    ▸ ...and 6 more

  ✓  PASS  1455ms total

For a server with resources and prompts too (server-everything):

  ✓  Tools discovery  22ms — Found 14 tools
  ✓  Resources discovery  2ms — Found 7 resources
  ✓  Prompts discovery  5ms — Found 4 prompts

It catches real bugs

@modelcontextprotocol/server-filesystem — one of the most well-known MCP servers — currently has a broken dependency:

  ✗  MCP protocol handshake — Error: Cannot find module 'ajv'

Before mcp-probe, this would show as "connection closed" with no indication of why.

CI integration

Exit code 1 on failure means it works as a CI gate:

- name: Validate MCP server
  run: npx @k08200/mcp-probe @your-org/your-mcp-server
  timeout-minutes: 2

JSON output for scripting:

npx @k08200/mcp-probe @scope/server --output json

How it works

Under the hood it uses the official @modelcontextprotocol/sdk to run the actual protocol handshake. It pipes stderr from the spawned process so when a server crashes on startup, you see the real error.

const transport = new StdioClientTransport({
  command: 'npx',
  args: ['--yes', target],
  stderr: 'pipe',  // capture crash output
});

const client = new Client(
  { name: 'mcp-probe', version: '0.1.0' },
  { capabilities: { roots: { listChanged: false } } }
);

await client.connect(transport);
const tools = await client.listTools();
// also listResources() and listPrompts() if server advertises them

Get it

npx @k08200/mcp-probe @modelcontextprotocol/server-memory

GitHub: k08200/mcp-probe
npm: @k08200/mcp-probe

Would love to hear what servers you try it on — especially if you find one where the output is confusing or wrong.