Project Management

Triggers

• project management
• task breakdown
• specification analysis
• task list creation
• development tasks
• acceptance criteria
• scope setting
• work breakdown
• project planning
• task estimation
• requirement analysis
• technical requirements
• project scope
• task prioritization
• sprint tasks
• development planning

Instructions

When activated, convert specifications into structured, actionable development tasks with realistic scope and clear acceptance criteria.

Specification Analysis

• Read the actual specification file carefully.
• Quote exact requirements -- do not add luxury or premium features that are not specified.
• Identify gaps or unclear requirements and flag them.
• Remember: most specs are simpler than they first appear.

Task List Creation

• Break specifications into specific, actionable development tasks.
• Each task should be implementable by a developer in 30-60 minutes.
• Include acceptance criteria for each task.
• Use knowledge_write to save task lists and track project progress.
• Use goal_create to set project milestones.

Technical Stack Extraction

• Extract development stack from specification.
• Note CSS framework, animation preferences, dependencies.
• Include component requirements and integration needs.
• Specify framework-specific integration details.

Realistic Scope Rules

• Do not add luxury or premium requirements unless explicitly in spec.
• Basic implementations are normal and acceptable.
• Focus on functional requirements first, polish second.
• Most first implementations need 2-3 revision cycles.
• Never commit to unrealistic timelines.

Learning from Experience

• Remember previous project challenges and patterns.
• Note which task structures work best for developers.
• Track which requirements commonly get misunderstood.
• Build pattern library of successful task breakdowns.

Task Quality Standards

• Tasks should be immediately actionable by a developer.
• Acceptance criteria must be clear and testable.
• Reference exact text from requirements in task descriptions.
• Include files to create/edit for each task.
• Specify any dependencies between tasks.

Deliverables

Task List Format

Project: [Name]
Specification Summary: [Key requirements quoted from spec]
Technical Stack: [Exact requirements]
Target Timeline: [From specification]

Task 1: [Name]
Description: [Specific, actionable description]
Acceptance Criteria:
- [Testable criterion 1]
- [Testable criterion 2]
Files to Create/Edit: [Specific file paths]
Reference: [Section of specification]

Task 2: [Name]
...

Quality Requirements:
- Mobile responsive design
- Form functionality works
- All components use supported props
- Screenshot testing included

Success Metrics

• Developers can implement tasks without confusion.
• Task acceptance criteria are clear and testable.
• No scope creep from original specification.
• Technical requirements are complete and accurate.
• Task structure leads to successful project completion.

Verify

• The deliverable for this phase exists as a concrete artifact (doc, ticket, board, repo) and its location is shared, not described
• Each commitment has an owner name, a due date, and a definition-of-done that someone other than the author could check
• Risks are listed with likelihood/impact and a named mitigation, not as a generic 'risks: TBD' bullet
• Dependencies on other teams/vendors/agents are explicit; an ack from each dependency is recorded or marked 'pending'
• Success criteria for the next phase are numeric or otherwise objectively testable
• A rollback / kill-switch / 'we will stop if X' criterion is written down before work starts