product-planning

name	product-planning
description	Plan products using the plan-heavy, execute-light methodology. Creates PRDs, breaks them into feature specifications, and manages the development lifecycle. Use when assigned a planning task, PRD creation, or feature specification work.

Product Planning Skill

This skill implements the plan-heavy, execute-light methodology. All critical thinking happens during planning. By execution time, decisions are finalized and implementation is mechanical.

Planning Phases

Phase 1: PRD Creation (PM Role)

When assigned a "Create PRD" task:

1. Read context — Get the product description from the project and any company goals
2. Research — Analyze the problem space, identify competitors, define the target user
3. Write the PRD as a comment on the assigned issue with this structure:

# PRD: {Product Name}

## Executive Summary
One paragraph describing the product and its value proposition.

## Problem Statement
What problem does this solve? Who has this problem? Why does it matter?

## Proposed Solution
High-level description of the approach.

## Core Features
1. **Feature Name** — Description, user story, acceptance criteria
2. **Feature Name** — Description, user story, acceptance criteria
(repeat for each core feature)

## Technical Requirements
- Platform/stack constraints
- Performance requirements
- Integration needs

## MVP Scope
Which features are in v1? Which are deferred?
Prioritize ruthlessly — the goal is a working MVP, not a complete product.

## Success Metrics
How will we know this product is working?

## Open Questions
List any unresolved decisions that need human input.

4. Request review — Post a comment: "PRD ready for review. Please approve or request changes."
5. Set status to in_review
6. Wait — Do not proceed until the human approves via a comment

Phase 2: Feature Specification (PM Role)

After PRD approval (human posts an approval comment):

1. For each core feature in the PRD, create a sub-issue with:

   • Title: Feature: {feature_name}
   • Description: detailed feature specification including:
     • User story ("As a ..., I want ..., so that ...")
     • Acceptance criteria (checkboxes)
     • Technical notes from the PRD
     • Dependencies on other features
   • Priority: based on MVP scope (critical features = high, nice-to-have = low)

2. Assign features to appropriate team members:

   • Implementation tasks → Developer
   • UX review tasks → UX Expert
   • UI implementation → UI Expert
   • Test/review tasks → QA
   • Architecture decisions → Architect

3. Post a summary comment on the parent issue listing all created sub-issues

Phase 3: Architecture Review (Architect Role)

When assigned a feature specification for review:

1. Read the PRD and the feature spec
2. Design the technical approach:
   • Data models and schemas
   • API contracts and endpoints
   • Component structure and relationships
   • Technology choices with rationale
3. Post the technical design as a comment on the feature issue
4. Flag risks — identify potential issues, performance concerns, or security considerations
5. If the design is sound, comment "Architecture approved for implementation"
6. If changes needed, comment with specific revision requests

Phase 4: Oversight (CEO Role)

The CEO handles:

• High-level decisions when the PM or Architect raises questions
• Cross-team conflicts when agents disagree on approach
• Priority changes when business context shifts
• Roadmap updates based on progress

The CEO does NOT micromanage implementation. Trust the team.

Meetings

Agents do NOT meet autonomously. Meetings happen only when a human requests one.

When a meeting is requested:

1. Create an issue titled "Meeting: {topic}"
2. Each invited agent posts their analysis/position as a comment
3. The CEO (or PM) synthesizes a decision comment
4. Action items become sub-issues assigned to the relevant agents

Approval Gates

Critical transitions require human approval:

• PRD → Feature specs (human reviews PRD)
• Feature specs → Implementation (human reviews specs, or auto-approved if Architect approves)
• Implementation → Done (QA review required)

Communication Style

• Use issue comments for all agent-to-agent communication
• Keep comments focused and actionable
• Reference specific issues/features by identifier
• When blocked, clearly state what you need and from whom