PRD Intake Automation

Automated ticket analysis: product area classification, completeness scoring, root cause analysis, technical assessment, and structured recommendations — powered by MeowKit skills with the mk:jira-* leaf family.

Best for: Team leads, engineering managers, DevOps teams Time estimate: ~2 min per ticket (automated) Skills used: mk:intake, mk:jira-issue, mk:jira-evaluator, mk:jira-lifecycle, mk:jira-relationships, mk:jira-collaborate, mk:scale-routing, mk:scout, mk:investigate, mk:decision-framework

Quick path

/mk:intake PRD-123          # classify area, score completeness, run RCA if it is a bug
/mk:jira-evaluator PRD-123  # readiness
/mk:jira-lifecycle transition PRD-123 "In Analysis"

You end up with a structured analysis posted back to the ticket as a comment. Worth knowing the analysis skills work on pasted text too, so you can try this before setting up Jira access at all.

Overview

When a new PRD or ticket lands in Jira, MeowKit can analyze it automatically: classify the product area, score description completeness, run root cause analysis (for bugs), scan the codebase for technical context, and post structured results back as a Jira comment.

MeowKit talks to Jira through the mk:jira-* leaf family, which uses the jira-as CLI under the hood. mk:intake orchestrates the analysis pipeline; the leaves handle Jira I/O.

Prerequisites

Jira access needs the jira-as CLI and three variables in .meowkit/.env. Jira Integration covers the install, the token, what the skills will and will not do on their own, and what to check when authentication fails.

Define Product Areas

Create a YAML file mapping product areas to code paths and team ownership:

# .claude/product-areas.yaml
areas:
  - name: Authentication
    paths: ["src/auth/**", "src/middleware/auth*"]
    keywords: ["login", "session", "token", "OAuth", "JWT"]
    pic: ["alice", "bob"]

  - name: Payments
    paths: ["src/billing/**", "src/stripe/**"]
    keywords: ["payment", "invoice", "subscription", "charge"]
    pic: ["charlie"]

  - name: API
    paths: ["src/api/**", "src/routes/**"]
    keywords: ["endpoint", "REST", "GraphQL", "route"]
    pic: ["alice", "dave"]

This feeds into mk:scale-routing for automatic product area detection.

Configure Trigger

Two options:

Option A: Jira Automation (webhook → Claude)

Jira Automation Rule:
  When: Issue created, type = PRD
  Then: Send webhook to your service
  Your service: calls `claude -p` with ticket content

Option B: Manual / On-demand

/mk:cook analyze PRD-123 using the intake workflow

Step-by-step Guide

/mk:intake

Step 1: Fetch the ticket

MeowKit reads the ticket via mk:jira-issue:

/mk:jira-issue get PRD-123

The leaf reads the description, acceptance criteria, comments, attachments, and linked issues via the jira-as wrapper. See mk:jira-issue for the full read surface.

Step 1.5: Evaluate ticket complexity

Optionally, assess ticket complexity before proceeding with full intake:

/mk:jira-evaluator PRD-123

This produces a qualitative complexity assessment (Simple/Medium/Complex), detects missing acceptance criteria, vague language, and unlinked dependencies. The evaluation feeds into estimation and sprint planning. See Ticket Evaluation & Estimation for details.

Step 2: Classify product area (mk:scale-routing)

MeowKit scans the ticket description for domain keywords and matches against .claude/product-areas.yaml:

Product area: Authentication
Confidence: HIGH (keywords: "login", "session timeout", matched paths: src/auth/**)
Suggested PIC: alice, bob

If multiple areas match, MeowKit reports all with confidence scores.

Step 3: Evaluate completeness (mk:plan-creator scope challenge)

MeowKit checks the PRD against required sections:

Completeness score: 55/100

Step 4: Scan codebase (mk:scout)

MeowKit pulls latest code and scans for relevant files:

Related files:
  src/auth/session-manager.ts (session timeout logic)
  src/middleware/auth-guard.ts (token validation)
  src/config/auth.ts (timeout configuration: 24h)
  tests/auth/session.test.ts (existing test coverage)

Technical considerations:
  - Session timeout is hardcoded to 86400s in auth.ts:15
  - Token refresh logic exists but only triggers on page navigation
  - No background refresh mechanism for idle sessions

Step 5: Root cause analysis (mk:investigate)

For bug tickets, MeowKit runs structured RCA:

RCA Method: 5 Whys (single-event, simple causal chain)

Why 1: Users get logged out → session token expires
Why 2: Token expires → 24h timeout reached
Why 3: Timeout reached → no refresh during idle period
Why 4: No idle refresh → refresh only triggers on navigation
Why 5: Navigation-only refresh → design gap (no background keep-alive)

Root cause: Token refresh is tied to user navigation events.
           Idle users (reading, in meetings) get no refresh.

Suggested fix: Add background token refresh interval (e.g., every 20min)
                OR extend timeout to 7 days with sliding expiration.

Step 6: Generate structured output

MeowKit posts a structured comment back to Jira via mk:jira-collaborate:

## AI PRD Analysis — PRD-123

### Product Area

**Authentication** (confidence: HIGH)

### Completeness Score: 55/100

Missing:

- ❌ Acceptance criteria (add pass/fail conditions)
- ❌ Steps to reproduce (add exact repro steps)
- ⚠️ Out-of-scope section (clarify boundaries)

### Technical Considerations

- Session timeout hardcoded at 24h (`src/config/auth.ts:15`)
- Token refresh only triggers on navigation (no idle refresh)
- Existing test coverage: `tests/auth/session.test.ts` (12 tests)

### Root Cause (for bugs)

Token refresh tied to navigation events. Idle users receive no refresh.

### Suggested Breakdown

1. Add background refresh interval (src/auth/session-manager.ts)
2. Update session config to support sliding expiration (src/config/auth.ts)
3. Add integration test for idle session scenario

### Related Tickets

- PRD-098: "Session management improvements" (similar scope)
- BUG-045: "Intermittent logout" (possibly same root cause)

### Suggested PIC

**alice** (Authentication domain owner, 3 open tickets)
**bob** (Authentication domain, 5 open tickets — alice preferred for load balance)

Step 7: Auto-assign and transition

If configured, MeowKit can:

• Assign the ticket to the suggested PIC via mk:jira-lifecycle
• Transition status (e.g., "New" → "In Analysis") via mk:jira-lifecycle
• Link related tickets via mk:jira-relationships

/mk:jira-lifecycle transition PRD-123 "In Analysis"
/mk:jira-relationships link PRD-123 blocks BUG-045
/mk:jira-lifecycle assign PRD-123 alice

Skill Graph

MeowKit Skills Used

What MeowKit Does NOT Do

Be honest about boundaries:

• Team roster management — You maintain .claude/product-areas.yaml. MeowKit reads it.
• Workload balancing — MeowKit reports open ticket count per PIC (via mk:jira-search). Your rules decide assignment.
• Jira workflow rules — MeowKit suggests transitions. Your Jira automation enforces them.
• Duplicate detection — MeowKit finds related tickets via keyword search. Exact dedup is your JQL.

Gotchas

• No MEOW_JIRA_* env = no Jira I/O: The analysis skills work standalone (you can paste ticket text), but automated read/write requires the three env vars in .meowkit/.env.
• Product areas YAML must be maintained: Stale domain mappings = wrong classification. Update when team structure changes.
• RCA only for bugs: Feature PRDs get completeness scoring + breakdown, not root cause analysis.
• PIC suggestion ≠ assignment: MeowKit suggests based on domain + load. Human confirms. Never auto-assign without review unless your team explicitly opts in.
• Rate limits: If running on every Jira webhook, consider batching or filtering (e.g., only PRD type, only specific projects).

Related

• Build a Feature — Full implementation workflow after intake
• Fix a Bug — Bug-specific investigation workflow
• Review Code — Review workflow for the fix
• mk:decision-framework — Decision architecture for triage