Research-driven workflow from ticket evaluation through codebase review to sprint planning.

Evaluate, estimate, review against codebase, produce planning reports — then decide what to commit.

Best for: Tech leads, engineering managers, sprint planners Time estimate: 5-15 min (depending on ticket count) Skills used: mk:intake, mk:jira-issue, mk:jira-evaluator, mk:jira-estimator, mk:jira-relationships, mk:planning-engine, mk:scout (optional), mk:web-to-markdown (optional)

Not for standalone bugs or hotfixes

This workflow is for planning new work into a sprint. If you have an existing ticket to fix or implement, use the Ticket to Code workflow instead.

Quick path

/mk:jira-evaluator AUTH-201                # per ticket: ready?
/mk:jira-estimator AUTH-201                # per ticket: how big?
/mk:planning-engine review AUTH-201 --scout   # check the estimate against the real codebase
/mk:planning-engine plan --tickets AUTH-201,AUTH-202 --capacity 40

You end up with a sprint plan backed by codebase evidence rather than by estimates alone. The machinery is Jira reads plus a codebase scout; see Jira Integration.

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.

The Principle

Every step produces a report. Human reads and decides before proceeding. No automation. No auto-creation. No auto-assignment.

Step-by-step

Step 1: Have tickets in your backlog

This workflow assumes the work is already represented as Jira tickets. If you're starting from a spec document instead, see the "Importing a spec" sidebar below.

Importing a spec (alternative entry point)

Two paths depending on where the spec lives:

Confluence (first-party path):

/mk:confluence-spec-analyst analyze <PAGE-ID> — produces a Spec Research Report with requirements, ACs, gaps, and suggested user stories (read-only — no tickets created)
Resolve [MISSING] / [VAGUE] / [AMBIGUOUS] flags with the PM via /mk:confluence-collaborate add-comment <PAGE-ID> ... --footer
Optional pre-ticket feasibility scan with /mk:scout + /mk:docs-finder (see the Spec → PR walkthrough for the full pattern)
Create tickets manually (Step 2 below) — never auto-creation
At Step 5, pass the report path back in: /mk:planning-engine plan --tickets ... --spec <report-path> brings the spec context into the Planning Report

Notion / generic URL (fallback):

/mk:web-to-markdown <spec-url> — convert the page to markdown
/mk:intake and paste/reference the markdown — produces a similar Spec Research Report
Create tickets manually (Step 2)

Both paths are manual and human-gated. No path auto-creates Jira tickets from the spec.

For a step-by-step walkthrough showing what every skill does behind the scenes, see Spec → PR: Behind the Scenes.

Step 2: Create tickets (your decision)

For stories you approve from the report:

/mk:jira-issue create --project AUTH --type Story --summary "Implement OAuth2 login" \
  --description "OAuth2 flow for Google and GitHub providers"

You decide which stories to create, what priority to set, and how to word them.

Step 3: Evaluate and estimate

/mk:jira-evaluator AUTH-201
/mk:jira-estimator AUTH-201

Produces complexity assessment and story point suggestion. The team makes the final estimate in planning poker — the AI provides signals, not decisions.

Step 4: Tech review (optional, with codebase context)

Run scout first for codebase context:

/mk:scout
/mk:planning-engine review AUTH-201 --scout

Produces a Tech Review Report: affected files, feasibility rating, dependencies, risks, complexity signals.

Step 5: Sprint planning

/mk:planning-engine plan --tickets AUTH-201,AUTH-202,AUTH-203 --capacity 40

If the tickets originated from a Confluence spec (see the sidebar above), pass the Spec Research Report back in to preserve spec context end-to-end:

/mk:planning-engine plan \
  --tickets AUTH-201,AUTH-202,AUTH-203 \
  --capacity 40 \
  --scout \
  --spec tasks/reports/spec-research-260511-q3-auth-refresh.md

Produces a Planning Report: sprint goal candidate, dependency map, grouping suggestions, capacity analysis. With --spec, the report includes a ## Spec Context (mk:confluence-spec-analyst) section summarizing the upstream requirements / ACs / gaps relevant to the planning tickets.

The team negotiates the sprint goal, self-selects work, and commits.

You Can Start Anywhere

Starting point	Skip to
Have tickets ready	Step 3 (evaluate)
Have a spec/URL	"Importing a spec" sidebar above, then Step 2
One ticket only	Step 4 (tech review)
Ready for sprint planning	Step 5

No step requires the previous step's output as a hard dependency.

Human Gates

Gate	Who decides	AI provides
Which stories to create	You	Suggestions in spec / intake report
Story point estimates	Team (planning poker)	Complexity signals
Which tickets enter sprint	Team (self-selection)	Grouping suggestions
Sprint goal	PO + team (negotiation)	Candidate draft
Dependency resolution	Team	Cycle detection

mk:jira-issue — ticket CRUD
mk:jira-evaluator — complexity assessment
mk:jira-estimator — story-point suggestion
mk:planning-engine — tech review + sprint planning
PRD Intake Automation — raw ticket triage (different workflow)
Ticket Evaluation & Estimation — single-ticket evaluation
Spec → PR: Behind the Scenes — deep-dive walkthrough showing every skill, agent fork, and gate

Tickets to Sprint Planning