01 / 15
Kai
Introducing @jira-writer

Stop Writing Tickets
for Humans

Start writing them for agents. The bottleneck isn't code anymore — it's specification.

Kai Agent Ecosystem · by 21no.de

02 · The Problem Kai

The Paradox Nobody's Talking About

The better AI coding agents get,
the worse traditional Jira tickets become.

Traditional tickets rely on tribal knowledge and assume context.
An AI agent reads "Add dark mode" and asks 47 clarifying questions.

03 · The Shift Kai

The Bottleneck Moved

Developer's Desk
PO's Desk
+75%
PO Time ↑
-95%
Agent Time ↓
40 min
Dev → Reviewer

As code generation accelerates, the discussion phase gets longer.
POs spend more time clarifying tickets than developers spend implementing them.

04 · The Numbers Kai

The Real Cost of Vague Tickets

Metric Before AI Agents AI + Traditional Tickets AI + @jira-writer
PO time per ticket 65 min 105 min (+75%) 30 min (-54%)
Dev time 5.5 hours 40 min 20 min
Clarification rounds 1 round 2-3 rounds 0 rounds
Agent implementation 37 min 15 min
Total time 6.5 hours 3.1 hours 1.1 hours

The lever isn't faster agents. It's better tickets.

05 · The Ecosystem Kai

Meet Kai — The Orchestrator

21 specialized agents. One master brain. Sharp, witty, and relentlessly factual.

🧠

Smart — Sees the architecture behind the ask

Spots edge cases early. Always knows why, not just what. Connects dots others miss.

😎

Cool — Prod is down? Already triaging

Scope tripled? Re-planning. Radiates "I got this" energy because it actually does.

🎯

Factual — No hallucinations, no hand-waving

If it knows, it says with confidence. If it doesn't, it says that with confidence. Precision is the brand.

21 agents — One orchestrator

Pipeline, Quality, Research, Fast-Track, Learning, Utility — each routed automatically by intent.

06 · @jira-writer Kai
Specialized Sub-Agent

@jira-writer

Writes tickets optimized for AI implementation.
Codebase-aware. Zero-ambiguity. Machine-parseable.

🔍

Codebase Recon

Scans your project — tech stack, patterns, conventions, file structure — before writing a single word.

🎯

Zero Ambiguity

Every ticket references real files, real patterns. An AI agent can start implementing without asking questions.

🧩

Epic Decomposition

Automatically breaks large features into atomic subtasks with clear dependency graphs.

07 · Live Demo Kai

How a PO Uses Kai in OpenCode

opencode ~/acme-platform
claude-opus-4 session: #42 Kai
You 14:32
Spec a feature: add rate limiting to /api/orders. 100 req/min per user, Redis-backed, return 429 with Retry-After header.
Kai 14:32
Routing to @jira-writer — this is a ticket spec, not implementation.
Intake — scope clear, 0 questions needed
Codebase recon — 14 files scanned tree rg cat
Composing ticket — agentic template, 9 AC, agent context
Quality gate PASSED
(ok) Ticket written → tickets/007-add-rate-limiting-to-api-orders.md
AC: 9 Entry pts: 6 Anti-patterns: 5 Clarifications: 0
Kai 14:33
Done in 47s. Agent-ready ticket — any agent can implement without clarification.
Ask Kai anything... ctrl+s send · ctrl+e editor

Natural language in → implementation-ready spec out. Zero clarification rounds.

08 · How It Works Kai

The 4-Phase Pipeline

Phase 0
🎤 Intake — Parse request, ask ≤ 5 targeted questions
Phase 1
🔍 Codebase Recon — Scan files, detect patterns, find references
Phase 2
✍️ Ticket Composition — Agentic Ticket Template, AC, agent context
Phase 3
Validate & Deliver — Quality gate, persist to tickets/
<8m
Single Ticket
<15m
Epic (3-5 tix)
95%
SLA Target
09 · AI-Friendly Tickets Kai

5 Properties of AI-Friendly Tickets

1. Explicit File Paths

Not "add an auth service" but Create src/services/auth/jwtService.ts following pattern in userService.ts

2. Concrete Acceptance Criteria

GIVEN/WHEN/THEN format. Every criterion independently verifiable. No "should work correctly".

3. Reference Implementations

Not "follow existing patterns" but Follow error handling in src/errors/AppError.ts

4. Anti-Patterns & Pitfalls

❌ Do NOT use global state
❌ Do NOT add a new DB table
❌ Do NOT bypass auth middleware

5. Architectural Context

Blocks, blocked-by, related tickets. Out of scope. The agent knows the bigger picture.

Result

The agent starts coding in seconds, not after a 3-round clarification cycle.

10 · The Template Kai

The Agentic Ticket Template

Every ticket follows this canonical structure — machine-first, human-readable.

Type & Priority & Summary

Feature | Bug | Refactor — business context, user impact

Acceptance Criteria

Functional (GIVEN/WHEN/THEN) + Technical (VERIFY:) + Test Requirements

🤖 Agent Implementation Context

Entry points, reference implementations, architecture patterns

File Organization

Visual tree showing exactly what to CREATE vs MODIFY

Anti-Patterns & Dependencies

What NOT to do + imports needed + packages to avoid

Implementation Notes

Step-by-step approach, complexity estimate, related tickets, out of scope

11 · Real Output Kai

From One Sentence to Full Spec

Input
"Spec a feature that allows developers to measure response-time latency via HTTP response headers. It should be configurable and disabled by default."
Output

9 Functional acceptance criteria
7 Technical requirements
4 Test requirement groups
6 Entry points identified
7 Reference implementations cited
9 Anti-patterns documented
~200 LOC estimated

Agent Context Sample
### Entry Points Primary: internal/handler/middleware.go Config: internal/config/config.go CLI: cmd/static-web/main.go Tests: internal/handler/middleware_test.go ### Reference Implementations middleware.go (L93-117) — loggingMiddleware() middleware.go (L119-133) — recoveryMiddleware() config.go (L94-104) — HeadersConfig struct config.go (L167-169) — applyDefaults() main.go (L104-106) — CLI flag pattern ### Anti-Patterns ❌ Do NOT use sync.Pool for time measurement ❌ Do NOT measure in loggingMiddleware() ❌ Do NOT use floating-point for time ❌ Do NOT write header after next(ctx)
12 · Quality Kai

Built-in Quality Gates

Every ticket self-validates before delivery. No ticket ships incomplete.

📋

Completeness

  • Title is action-oriented
  • All AC are testable
  • Files reference real paths
  • Agent context populated
🤖

Agent Readiness

  • Zero clarifying questions
  • Patterns verified in code
  • No vague terms
  • Concrete test expectations
📏

Scope

  • Atomic — one session
  • No hidden dependencies
  • Realistic complexity
  • Human-readable in 30s
13 · Registry Kai

Persistent Ticket Registry

Version-controllable. Durable. Your backlog as code.

Single Tickets

tickets/
├── 001-add-jwt-authentication-service.md
├── 002-implement-login-logout-endpoints.md
├── 003-add-token-refresh-flow.md
└── 004-update-frontend-token-storage.md

Epic Decomposition

tickets/010-user-authentication/
├── README.md  ← epic overview + deps
├── 010-setup-auth-middleware.md
├── 011-implement-jwt-token-flow.md
└── 012-add-login-signup-endpoints.md

Auto-Increment IDs

Zero-padded 3-digit IDs. Collision-safe. Deterministic ordering.

Kebab-Case Slugs

Derived from title. Max 60 chars. Human-scannable in file explorers.

Git-Friendly

Markdown files in your repo. Review tickets in PRs. Track changes over time.

Living Docs

Your ticket registry becomes institutional knowledge of how your system works.

14 · The New Model Kai

The Role Revolution

❌ Old Model

  • PO as scribe — transcribes requirements
  • Developer as code factory — 4h on routine features
  • 3-round clarification cycles
  • Value in communication, not decisions
  • Developer reviews own code

✓ New Model

  • PO as technical contributor — designs solutions
  • Developer as reviewer — 20 min expert validation
  • Agent as implementer — executes with clarity
  • Value in decisions and architecture
  • PO proposes, Dev reviews, Agent builds
Developers become technical authorities, not code factories.
15 · The Edge

The Competitive Edge

0
Clarification
Rounds
83%
Faster Total
Delivery
54%
Less PO
Time
Scalable
Backlog
The future of software development isn't faster agents.
It's smarter requirement engineering,
better roles, and teams that actually enjoy their work.

Kai · @jira-writer · by 21no.de