clickup-task-extractor-prd

name: clickup-task-extractor-prd description: Extract task requirements from Product Requirements Documents (PRDs) and prepare them for ClickUp task creation. Use this skill when you need to convert PRD specifications into structured ClickUp tasks. Always calls silver-fern-knowledge for product context.

ClickUp Task Extractor - PRD

Overview

This skill extracts actionable development tasks from Product Requirements Documents (PRDs) and prepares them for ClickUp task creation using the clickup-task-formatter skill.

When to Use This Skill

Invoke this skill when:

• User provides a PRD markdown file (exported from ClickUp)
• User requests tasks be created from a PRD
• User says "create tasks from this PRD"
• User wants to break down product requirements into development work

Process

1. Parse PRD Structure - Identify key sections:

   • Problem statement / User needs
   • Feature requirements
   • User stories
   • Acceptance criteria
   • Technical specifications
   • Constraints and dependencies
   • Success metrics
   • Out of scope items

   For Large PRDs (>256KB): See "Handling Large PRDs" section below

2. Understand Context - Use silver-fern-knowledge to:

   • Identify which Silver Fern product
   • Validate strategic alignment
   • Understand customer impact
   • Note technical constraints

3. Extract Requirements - Pull out:

   • Functional requirements (what the system must do)
   • Non-functional requirements (performance, security, etc.)
   • User stories (as a [role], I need to [action])
   • Acceptance criteria (must have, should have)
   • Technical specifications (APIs, data models, integrations)

4. Structure Tasks - Convert requirements into discrete tasks:

   • Map user stories to implementation tasks
   • Break down technical specifications into components
   • Identify dependencies between requirements
   • Separate MVP from future enhancements
   • ALL tasks must include user stories (even technical/architectural tasks can have developer-facing user stories)

5. Document Out-of-Scope Items - Explicitly catalog:

   • Features explicitly excluded from MVP (from "Out of Scope" section)
   • Features deferred to future releases
   • This ensures team alignment on what's NOT being built

6. Organize by Dependency - Foundation → Backend → Frontend → Integration → Testing

7. Create Requirements Traceability Matrix - Verify coverage:

   • Map each PRD requirement to extracted tasks
   • Identify any missing requirements
   • Document deferred (P1) requirements
   • Ensure 100% coverage or explicit deferral

8. Review Complex Tasks - For tasks marked 🔴 Complex and >1.5 weeks:

   • Consider breaking into subtasks
   • Provide breakdown recommendations
   • See "Breaking Down Complex Tasks" section below

9. Prepare for Formatter - Ask user if they want to proceed with ClickUp creation:

   • Save extraction to temporary file
   • Invoke clickup-task-formatter skill if user approves
   • See "Handoff to Formatter" section below

Task Output Structure

Each task must include:

• Task name - Clear, action-oriented (starts with verb)
• Type - Feature | Enhancement | Bug Fix | Technical Debt | Documentation
• Description - What needs to be done and why (1-2 sentences)
• User Story - REQUIRED for ALL tasks (format: "As a [role], I want [goal] so that [benefit]")
  • Even technical tasks should have user stories (e.g., "As a development team, we need...")
• Acceptance Criteria - Testable, specific checklist items (from PRD)
  • Be specific: Instead of "Visual indicator shows..." → "Avatar icon with user initials appears in top-right corner..."
  • Include measurable outcomes when possible (e.g., "< 2 seconds load time", "90%+ accuracy")
• PRD Reference - Section/requirement this task implements (include line numbers if possible)
• Technical Notes:
  • APIs or data models mentioned in PRD
  • Performance/security requirements
  • Integration points
  • Reference any PRD diagrams or conceptual flows
• Estimated Complexity - 🟢 Simple | 🟡 Moderate | 🔴 Complex
• Estimated Time - Hours or days
• Priority - High (P0 - Must-Have) | Medium (P1 - Should-Have) | Low (P2 - Nice-to-Have)

Special Flags

Flag unclear requirements explicitly:

⚠️ **CLARIFICATION NEEDED**:
- Missing technical detail: [Specific question]
- Unclear requirement: [What's unclear in PRD]
- Assumption made: [Assumption and alternative if wrong]

Flag complex tasks that should be broken down:

⚠️ **RECOMMENDATION**: This task is complex (2 weeks). Consider breaking down into:
- Subtask A: [Description] (X days)
- Subtask B: [Description] (Y days)

PRD Analysis Patterns

Look for these sections (common PRD structure):

• Problem/Opportunity → Informs task descriptions (the "why")
• Goals/Objectives → Informs success metrics and priorities
• User Stories → Maps directly to feature tasks
• Functional Requirements → Core implementation tasks
• Non-Functional Requirements → Technical constraints and quality tasks
• Out of Scope → Explicitly exclude from task list
• Dependencies → Task ordering and blocking relationships
• Success Metrics → Instrumentation and analytics tasks

Extract systematically:

1. Read entire PRD first for context
2. List all user stories
3. List all functional requirements
4. List all technical specifications
5. Map requirements to implementation tasks
6. Group related tasks into phases
7. Identify dependencies

Special Handling

• Unclear requirements: Flag in task description, add clarification question
• Missing technical details: Add research/design task as prerequisite
• Large features: Break into incremental deliverables, mark phases clearly
• Out of scope items: Explicitly note as "Future Enhancement" to avoid scope creep

Handling Large PRDs (>256KB)

When the PRD exceeds the Read tool limit (256KB):

Systematic Chunking Strategy

1. Initial Scan (first 500 lines):

   Read with limit=500, offset=0
   

   • Identify PRD structure, table of contents, executive summary
   • Get overview of product, problem statement, success criteria

2. Section Discovery:

   grep -n "^##" [prd_file] | head -100
   

   • Find all section headers with line numbers
   • Create mental map: {section_name: start_line}

3. Prioritized Reading (read sections in this order):

   • Must-read: Functional requirements, User stories, Acceptance criteria, Technical specifications
   • Should-read: Non-functional requirements, Success metrics, Risks, Out of scope
   • Nice-to-read: Workflows, UI specifications, Background/context

4. Chunked Extraction:

   • For each prioritized section, use Read with appropriate offset/limit
   • Take notes incrementally (don't re-read sections)
   • Example:

     Read offset=320, limit=500  # Functional Requirements section
     Read offset=1800, limit=400 # Non-Functional Requirements section
     

5. Synthesize:

   • After reading all priority sections, synthesize accumulated notes into task list
   • Use wc -l to understand total PRD size
   • Use grep to find specific requirement numbers (e.g., "FR-F1.1")

Tips for Large PRDs

• Don't try to read entire PRD linearly
• Focus on requirements sections (highest information density)
• Use grep to search for specific terms if needed
• Take notes as you read each section
• Synthesize at the end (don't try to extract tasks while reading)

Requirements Traceability Matrix

After extracting tasks, create a matrix to verify ALL requirements are covered:

## Requirements Traceability Matrix

| PRD Requirement | Requirement Name | Extracted Tasks | Status |
|-----------------|------------------|-----------------|--------|
| FR-F1.1 | Master Forecast Generation | Task 1.5, Task 2.1 | ✅ Covered |
| FR-F1.2 | Master Forecast Viewing | Task 4.1 | ✅ Covered |
| FR-F2.1 | Historical Data Display | Task 2.6, Task 4.6 | ✅ Covered |
| FR-F2.2 | Accuracy Analytics | Task 7.2 (P1 - deferred) | ⚠️ Deferred |
| NFR-1.1 | Response Time | Task 6.1 | ✅ Covered |
| NFR-4.1 | Data Security | Task 1.2 | ✅ Covered |

### Coverage Summary
- ✅ Covered: X/Y requirements (Z%)
- ⚠️ Deferred (P1): A/Y requirements (B%)
- ❌ Missing: 0/Y requirements (0%)

If any requirements are missing: Add tasks to cover them or explicitly document why they're out of scope.

Out-of-Scope Documentation

After extracting in-scope tasks, explicitly document what's OUT of scope:

## Out-of-Scope / Future Enhancements

### Explicitly Excluded from MVP (from PRD)
1. ❌ Real-time collaborative editing (PRD lines 1945-1949)
   - Reason: Complexity too high for MVP timeline
   - Deferred to: Phase 2 (Q3 2026)

2. ❌ Multiple ML models UI (PRD lines 1950-1954)
   - Reason: MVP uses single ML model only
   - Deferred to: Future release (TBD)

### Deferred to Future Releases
1. ⏭️ Multi-tenancy
   - Not required for initial customers (single tenant)
2. ⏭️ Mobile application
   - Desktop/tablet sufficient for MVP

### Why Document Out-of-Scope?
- Ensures team alignment on what's NOT being built
- Prevents scope creep during development
- Provides clear roadmap for future releases
- Manages stakeholder expectations

Breaking Down Complex Tasks

When a task is marked 🔴 Complex and estimated at >1.5 weeks, consider breaking it into subtasks:

Example Breakdown

Before:

#### Task 3.1: Implement Replenishment Allocation Calculation Engine
**Type**: Backend Feature
**Estimated Complexity**: 🔴 Complex
**Estimated Time**: 2 weeks
**Priority**: High (P0)

After (with breakdown recommendation):

#### Task 3.1: Implement Replenishment Allocation Calculation Engine
**Type**: Backend Feature
**Estimated Complexity**: 🔴 Complex
**Estimated Time**: 2 weeks
**Priority**: High (P0)

⚠️ **RECOMMENDATION**: This task is complex (2 weeks). Consider breaking down into:
- **Subtask 3.1a**: Implement WOH (Weeks On Hand) calculation logic (3 days)
- **Subtask 3.1b**: Implement Slope (demand velocity) calculation logic (2 days)
- **Subtask 3.1c**: Implement store ranking and prioritization logic (2 days)
- **Subtask 3.1d**: Implement delivery eligibility checks (2 days)
- **Subtask 3.1e**: Implement allocation calculation algorithm (4 days)
- **Subtask 3.1f**: Unit testing and regression testing (2 days)

When NOT to Break Down

• Task is complex but tightly coupled (can't be done in pieces)
• Task is exploratory/research (hard to estimate subtask granularity)
• Task is already at the right level of granularity for team's sprint planning

Handoff to ClickUp Task Formatter

AUTOMATIC HANDOFF - Do NOT ask the user for permission. After extraction is complete:

1. Tell the user:

   I've extracted [X] tasks from the PRD. The extraction includes:

   • [Y] P0 tasks (Must-Have for MVP)
   • [Z] P1 tasks (Should-Have, may defer)
   • Requirements traceability matrix showing [N]% coverage
   • Out-of-scope documentation for [M] excluded features

   Now automatically proceeding to validate and create these tasks in ClickUp...

2. Save extraction to temporary file (e.g., /tmp/tasks-extraction.md)

3. Immediately invoke clickup-task-formatter skill (do not wait for user response)

4. Pass extraction file path to formatter for validation and ClickUp creation

IMPORTANT: The workflow should be fully automatic from PRD → extraction → ClickUp creation. Only ask the user for input if there are ambiguities in the PRD that need clarification BEFORE extraction completes.

Success Metrics Alignment (Optional)

If PRD includes success metrics, map tasks to metrics to show how implementation enables measurement:

## Success Metrics Alignment

| Success Metric | Target | Related Tasks | How Tasks Enable Metric |
|----------------|--------|---------------|-------------------------|
| Forecast Accuracy Improvement | 5-10% reduction in MAPE | Task 2.6 (Forecast vs. Actual), Task 2.4 (Microforecast) | Provides visibility into accuracy and tools to refine forecasts |
| User Adoption | 80%+ active users | Task 6.3 (Usability Testing), Task 6.4 (Training) | Ensures intuitive UI and comprehensive training |
| Performance | Sub-2-second loading | Task 6.1 (Performance Testing), Task 4.1 (Grid with virtualization) | Ensures performance targets met |

This helps stakeholders understand how technical tasks connect to business outcomes.

Remember

Always ask: "If I received this PRD and these tasks, would the implementation match the product vision?"

Final Checklist Before Handoff:

• ✅ All tasks have user stories (even technical tasks)
• ✅ Acceptance criteria are specific and testable
• ✅ Requirements traceability matrix shows 100% coverage (or explicit deferral)
• ✅ Out-of-scope items explicitly documented
• ✅ Complex tasks (🔴 >1.5 weeks) have breakdown recommendations
• ✅ Tasks organized by dependency (Foundation → Backend → Frontend → Testing)
• ✅ PRD references included (with line numbers when possible)
• ✅ Success metrics alignment shown (if PRD includes metrics)