create-dev-task

create-dev-task

Generate a development task document for the Dev agent to implement based on validated issue and investigation.

When to Use

• After QA or Support has validated and investigated an issue
• When a bug needs to be assigned to the Dev agent
• Before sprint planning to prepare development specifications
• When creating fix specifications from customer-reported issues

Quick Start

1. Gather investigation results (validation report, root cause, affected components)
2. Create dev task document with problem statement
3. Define fix requirements (functional and non-functional)
4. Add risk assessment and deployment considerations
5. Package handoff notes for Dev agent

Purpose

Create a comprehensive development task that describes WHAT needs fixing and WHY, not HOW to code it. The Dev agent will use this specification to implement the actual fix.

SEQUENTIAL Task Execution

1. Compile Investigation Results

inputs:
  - Issue validation report with evidence
  - Root cause analysis findings
  - Affected components identified
  - Business impact assessment
  - QA test specification (if created)

2. Create Development Task Document

dev_task_specification:
  ticket_id: "ISSUE-{number}"
  priority: "P0|P1|P2|P3"
  estimated_effort: "1-2 hours|2-4 hours|1 day|2-3 days"
  
  problem_statement: |
    When {user action}, the system {current behavior}
    instead of {expected behavior}, causing {impact}.
  
  investigation_summary:
    root_cause: "{Brief description of why it happens}"
    affected_areas:
      - "{Component/Service 1}"
      - "{Component/Service 2}"
    first_occurred: "{Date or version}"
    frequency: "{Always|Sometimes|Under specific conditions}"

3. Define Fix Requirements

fix_requirements:
  functional_requirements:
    - System must {specific behavior}
    - Error handling for {edge case}
    - Maintain backward compatibility
    
  non_functional_requirements:
    - Performance: Response time < {threshold}
    - Security: Validate {input/authorization}
    - Reliability: Handle {failure scenario}
    
  constraints:
    - Minimal code changes preferred
    - No breaking changes to API
    - Must be deployable without downtime
    
  suggested_approach: |
    Based on investigation, consider:
    - {High-level approach 1}
    - {High-level approach 2}
    Note: Dev agent determines actual implementation

4. Development Task Package

# Dev Task: Fix for Issue #{ticket}

## Issue Summary
**Customer Impact:** {severity and scope}
**Business Priority:** {P0|P1|P2|P3}
**First Reported:** {date}
**Frequency:** {occurrence rate}

## Problem Description

### What's Happening
{Detailed description of the issue from user perspective}

### Root Cause Analysis
**Investigation Result:** {what was found}
**Component:** {affected component/service}
**Introduced:** {when/which version if known}

### Evidence
- Screenshot: {reference to validation evidence}
- Error Logs: {key error messages}
- Stack Trace: {if available}
- Reproduction Rate: {percentage}

## Requirements for Fix

### Functional Requirements
1. {Requirement 1}
2. {Requirement 2}
3. {Requirement 3}

### Technical Constraints
- {Constraint 1}
- {Constraint 2}

### Suggested Investigation Areas
- Check: {file/component 1}
- Review: {logic/flow}
- Consider: {potential approach}

## Definition of Done
- [ ] Issue no longer reproduces with validation steps
- [ ] QA test passes (will be created separately)
- [ ] No performance regression
- [ ] Code reviewed and approved
- [ ] Deployment plan documented

## Testing Requirements
- QA team will create regression test
- Dev to ensure fix doesn't break existing tests
- Manual validation in staging required

## Deployment Considerations
- Risk Level: {Low|Medium|High}
- Rollback Strategy: {approach if issues}
- Monitoring: {what to watch}

## Handoff Notes
- Support validated issue via Playwright
- QA task created for test implementation
- Architecture team consulted if needed

5. Risk and Impact Assessment

risk_assessment:
  fix_complexity:
    low: "Single line/simple logic change"
    medium: "Multiple files, moderate logic"
    high: "Architecture change, multiple services"
    
  regression_risk:
    low: "Isolated feature, good test coverage"
    medium: "Shared component, some dependencies"
    high: "Core functionality, many dependencies"
    
  deployment_risk:
    low: "Feature flag available, easy rollback"
    medium: "Standard deployment, monitoring needed"
    high: "Database changes, careful coordination"

6. Sprint Planning Information

sprint_planning:
  story_points: {1|2|3|5|8}
  
  acceptance_criteria:
    - Customer issue resolved
    - QA test passes
    - No new issues introduced
    - Performance maintained
    
  dependencies:
    - QA test implementation
    - Environment access
    - External team approval (if needed)
    
  deliverables:
    - Code fix implemented
    - Tests passing
    - Documentation updated
    - Deployment plan ready

7. Communication Template

## Dev Team Handoff

**Ticket:** #{ticket}
**Priority:** {priority}
**Assigned to:** Dev Agent

**Summary:** Customer experiencing {issue}. Support has validated and investigated. Need fix implementation.

**Key Files:** 
- Investigation report: {link}
- Validation evidence: {link}
- QA test spec: {link}

**Timeline:**
- Target Sprint: {sprint}
- Customer Commitment: {date if any}

**Questions:** Contact Support team via {channel}

Success Criteria

• Complete dev task specification created
• Problem clearly described without prescribing solution
• Requirements defined without implementation details
• Risk assessment completed
• Handoff package ready for Dev agent

Output

• Development task document
• Sprint planning metadata
• Risk assessment
• Clear requirements for Dev team