---

name: plan-feature description: "Plan a feature from BRD-lite brief or clear intent into PRD (What), decisions, implementation plan, and task slices." metadata: internal: true triggers: keywords: - plan feature - workflow

Plan Feature Skill

[!IMPORTANT] Plan a feature from BRD-lite brief or clear intent into PRD (What), decisions, implementation plan, and task slices.

Optional args: slug=, ticket=<id/url>, mode=interactive|autonomous|channel, channel=, auto_continue=true|false, profile=business|hybrid|technical.

Instructions

When the user asks to perform this workflow, execute the following steps:

Feature Planning Workflow (PRD / What)

Goal: Produce a PM-owned decision-complete PRD, delivery plan, and IT Department handoff before code starts.

Steps

1. Load context:
   • Load baseline PRD section and task-linked evidence with the stable slug; when intent is unclear, ask which matching ticket/brief is authoritative rather than selecting an unrelated recent document.
   • Load BRD-lite, ticket text, existing specs, repo patterns, common-product-requirements, common-operator-profile, common-decision-discipline, quality-engineering-business-analysis, and matched framework skills.
   • Carry forward operator_profile, lane, snc_tier, approval, BRD objective IDs, SMART metric, scope fence, assumptions, evidence ledger, glossary, risks, and delivery context. Use the approved task record/ticket and stable slug; equivalent evidence is sufficient when it supplies the required information, regardless of whether a separate BRD/PRD/SRS filename exists.
2. Interview:
   • Draft a provisional PRD direction from current context before asking.
   • Ask only for business logic, scope, constraints, and acceptance criteria that cannot be inferred.
   • Ask max 3 blocking decisions at a time; include a recommended default and 2-3 options for each.
   • Treat non-critical unknowns as explicit assumptions.
   • Confirm problem statement, assumptions, target users, JTBD/use cases, platforms, data, analytics, security, performance, rollout, and non-goals.
   • Confirm each requirement has owner, priority, and status.
   • Confirm success metrics and guardrails that must not regress.
   • Stop when requirements are actionable.
3. Draft PRD:
   • Save to docs/prd/prd-[slug].md when file writes are allowed.
   • Keep "what" separate from "how".
   • Add stable requirement IDs and AC IDs.
   • Use Given/When/Then AC when behavior can be misread.
   • Check user stories for specific persona, business value, INVEST, happy path, edge path, and negative path.
   • Link each requirement back to BRD-lite business objective.
   • Include risk categories, rollout/ops, decision log, analytics/telemetry, and changelog.
   • Mark unresolved blocking product decisions as blockers.
   • Include a RACI table for BA, PM, architect, backend, frontend, mobile, QA, release, and business/UAT approver when more than one delivery role is involved.
4. Create implementation plan:
   • Define product outcomes, acceptance criteria, dependencies, delivery risks and provisional owner-aligned slices.
   • Keep unresolved architecture, API/data contracts, migrations, and other consequential technical choices explicit for design-solution; do not author technical design twice in the PM plan.
   • Map each provisional task slice to requirement IDs, AC IDs, likely owner role, repo/module, expected artifact, and verification lane.
   • Estimate each slice (t-shirt size + confidence); roll up a delivery-window range in time/cost terms for operator_profile=business, points otherwise.
   • Identify whether design-solution is required before coding.
5. Route:
   • Continue when assumptions are non-critical; return BLOCKED for missing owner, untestable AC, approval, or release constraint.
   • Architecture unclear -> design-solution; approved build-ready plan with AC IDs and trace -> implementation-readiness.

Runtime Contract

• Use after BRD-lite or when clear feature intent exists but PRD does not.
• Required inputs: BRD-lite or equivalent intent, plus enough context to name users, goals, and constraints.
• Return BLOCKED only for missing owner, untestable AC, approval, or release constraint.

Handoff Payload

• slug, operator_profile, lane, snc_tier, approval, PRD path, REQ-*, AC-*, decisions, RACI, rollout notes, task slices, delivery-window estimate, verification plan, outcome report, next workflow.

Blocking Questions

• Ask max 3 at a time with a recommended default and 2-3 options.

Output Template

# Feature Plan: [Name]
## PRD
## Problem Statement
## Goals And Guardrails
## Personas / JTBD
## Use Cases
## Requirement Trace
## User Stories And ACs
## Decisions
| Decision   | Choice   | Reason   |
| ---------- | -------- | -------- |
| [decision] | [choice] | [reason] |
## RACI / IT Department Handoff
## Analytics / Telemetry
## Risks And Assumptions
## Rollout / Ops
## Implementation Plan
## Task Slices And Delivery Estimate
## Verification Plan
## Outcome Report
{schema_version: 1, run_id: "[run-id]", slug: "[slug]", workflow: plan-feature, feature_status: requirements_ready, started_at: "[timestamp]", completed_at: "[timestamp]", requirement_trace: {brd_objectives: [], requirements: [], acceptance_criteria: [], srs: []}, completed_evidence: [], missing_evidence: [], decision_needed: [], recommended_next_workflow: design-solution, cost: {source: unavailable}, agent: {identity: "[agent-identity]", model: "[model]"}}
## Next Workflow
design-solution | implementation-readiness
## Cost Report
Call `get_session_cost(workflow="plan-feature")` before final handoff.