Automatically enrich Jira tasks with comprehensive context, technical requirements, dependencies, and estimates through intelligent analysis and extraction patterns.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
Automatically enrich Jira tasks with comprehensive context, technical requirements, dependencies, and estimates through intelligent analysis and extraction patterns.
Activate this skill when:
Use this decision tree to determine enrichment strategy:
START: Analyze Issue
│
├─ Is issue type Epic?
│ ├─ YES → Apply Epic Decomposition Strategy
│ │ ├─ Extract business objectives
│ │ ├─ Identify user journeys
│ │ ├─ Break into Stories
│ │ ├─ Map story dependencies
│ │ └─ Create epic roadmap
│ │
│ └─ NO → Continue to next check
│
├─ Does issue have clear acceptance criteria?
│ ├─ NO → Apply Acceptance Criteria Extraction
│ │ ├─ Analyze description for implicit criteria
│ │ ├─ Extract "should", "must", "will" statements
│ │ ├─ Identify testable conditions
│ │ ├─ Add Given-When-Then scenarios
│ │ └─ Flag missing requirements
│ │
│ └─ YES → Continue to next check
│
├─ Is technical complexity unclear?
│ ├─ YES → Apply Complexity Analysis
│ │ ├─ Analyze affected codebase areas
│ │ ├─ Identify integration points
│ │ ├─ Assess risk factors
│ │ ├─ Compare with historical issues
│ │ └─ Suggest story point estimate
│ │
│ └─ NO → Continue to next check
│
├─ Are dependencies unknown?
│ ├─ YES → Apply Dependency Mapping
│ │ ├─ Check linked issues
│ │ ├─ Analyze code dependencies
│ │ ├─ Identify team dependencies
│ │ ├─ Map external dependencies
│ │ └─ Create dependency graph
│ │
│ └─ NO → Continue to next check
│
├─ Is technical approach unclear?
│ ├─ YES → Apply Technical Design Enhancement
│ │ ├─ Suggest implementation patterns
│ │ ├─ Identify affected files/modules
│ │ ├─ Propose architecture approach
│ │ ├─ List potential risks
│ │ └─ Create design checklist
│ │
│ └─ NO → Continue to next check
│
├─ Are test scenarios missing?
│ ├─ YES → Apply Test Case Generation
│ │ ├─ Generate happy path scenarios
│ │ ├─ Identify edge cases
│ │ ├─ Create error scenarios
│ │ ├─ Add integration test cases
│ │ └─ Define performance criteria
│ │
│ └─ NO → Continue to final check
│
└─ Is sprint context needed?
├─ YES → Apply Sprint Context Analysis
│ ├─ Check team capacity
│ ├─ Analyze sprint goals alignment
│ ├─ Review team velocity
│ ├─ Identify resource constraints
│ └─ Suggest sprint priority
│
└─ NO → Enrichment Complete
When to Apply:
Process:
Extract Business Objectives
## Business Objectives Extracted:
- Primary Goal: [What business problem does this solve?]
- Success Metrics: [How will success be measured?]
- Target Users: [Who benefits from this?]
- Business Value: [What's the ROI/impact?]
Identify User Journeys
Break into Stories
## Suggested Stories:
### Story 1: [Story Title]
**As a** [user type]
**I want** [capability]
**So that** [benefit]
**Acceptance Criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
**Estimated Complexity:** [Story Points]
**Priority:** [High/Medium/Low]
Map Story Dependencies
Create Epic Roadmap
Output Format:
# Epic Decomposition: [EPIC-KEY]
## Original Epic Summary
[Epic description]
## Business Objectives
- Objective 1
- Objective 2
## User Journeys Affected
1. Journey 1: [Description]
2. Journey 2: [Description]
## Recommended Stories
### Phase 1: Foundation (Sprint 1)
- [ ] STORY-001: [Title] (5 pts)
- [ ] STORY-002: [Title] (3 pts)
### Phase 2: Core Features (Sprint 2-3)
- [ ] STORY-003: [Title] (8 pts) - Depends on STORY-001
- [ ] STORY-004: [Title] (5 pts) - Depends on STORY-002
### Phase 3: Enhancements (Sprint 4)
- [ ] STORY-005: [Title] (3 pts)
## Dependency Graph
```mermaid
graph TD
STORY-001 --> STORY-003
STORY-002 --> STORY-004
STORY-003 --> STORY-005
### Strategy 2: Acceptance Criteria Extraction
**When to Apply:**
- Vague or missing acceptance criteria
- Description contains implicit requirements
- Need to clarify "done" conditions
- Preparing for development work
**Extraction Patterns:**
1. **Modal Verb Detection**
- "must", "should", "shall", "will", "can"
- "requires", "needs", "allows"
- "enables", "supports", "provides"
2. **Behavior Keywords**
- "when", "if", "then"
- "after", "before", "during"
- "given", "and", "but"
3. **Constraint Indicators**
- "only", "except", "unless"
- "within X seconds", "at least", "no more than"
- "compatible with", "compliant with"
4. **Stakeholder Requirements**
- "user can", "user should"
- "system must", "application will"
- "admin requires", "customer expects"
**Process:**
1. **Parse Description**
```python
# Pseudo-code for extraction
requirements = []
for sentence in description.sentences:
if contains_modal_verb(sentence):
requirements.append(extract_requirement(sentence))
if contains_behavior_keyword(sentence):
requirements.append(convert_to_given_when_then(sentence))
Categorize Requirements
Convert to Testable Criteria
## Extracted Acceptance Criteria
### Functional
- [ ] **AC1:** User can [action] when [condition]
- [ ] **AC2:** System must [behavior] if [trigger]
### Non-Functional
- [ ] **AC3:** Response time < 200ms for [operation]
- [ ] **AC4:** Supports 1000 concurrent users
### Business Rules
- [ ] **AC5:** Only [role] can [action]
- [ ] **AC6:** [Entity] must validate [field]
Add Given-When-Then Scenarios
Scenario: [Scenario Name]
Given [initial context]
When [action occurs]
Then [expected outcome]
And [additional expectation]
Output Format:
# Acceptance Criteria Enrichment: [ISSUE-KEY]
## Original Description Analysis
**Keywords Found:** "must", "should", "will" (15 instances)
**Implicit Requirements Detected:** 8
**Testable Conditions:** 12
## Extracted Acceptance Criteria
### Functional Requirements
- [ ] **AC1:** User can submit form when all required fields are filled
- Required fields: name, email, phone
- Validation: email format, phone format
- [ ] **AC2:** System must send confirmation email within 1 minute
- Email contains: submission ID, timestamp, summary
- [ ] **AC3:** User receives immediate feedback on validation errors
- Error messages: clear, actionable, field-specific
### Non-Functional Requirements
- [ ] **AC4:** Form submission completes within 2 seconds
- [ ] **AC5:** Works on mobile devices (iOS 14+, Android 10+)
- [ ] **AC6:** Accessibility: WCAG 2.1 AA compliance
### Security Requirements
- [ ] **AC7:** Form data encrypted in transit (TLS 1.3)
- [ ] **AC8:** CSRF protection enabled
- [ ] **AC9:** Rate limiting: max 5 submissions per hour per user
## Test Scenarios
### Scenario 1: Successful Form Submission
```gherkin
Given user is on the contact form page
And all required fields are empty
When user fills in valid data for all required fields
And user clicks "Submit" button
Then form is submitted successfully
And user sees success message
And confirmation email is sent
Given user is on the contact form page
When user enters invalid email format
And user clicks "Submit" button
Then form is not submitted
And user sees error message "Please enter a valid email address"
And error is highlighted on email field
### Strategy 3: Complexity Analysis and Estimation
**When to Apply:**
- Story point estimate is missing or unclear
- Need to assess technical risk
- Preparing sprint planning
- Analyzing implementation effort
**Complexity Factors:**
1. **Code Complexity Indicators**
- Number of files to modify
- Lines of code affected
- Cyclomatic complexity of affected code
- Number of integration points
- Technology stack complexity
2. **Risk Factors**
- New technology/framework
- External dependencies
- Data migration required
- Breaking changes
- Security implications
- Performance requirements
- Cross-team coordination needed
3. **Historical Comparison**
- Similar issues resolved
- Team velocity on similar work
- Past estimation accuracy
- Lessons from similar tickets
**Complexity Scoring Matrix:**
| Factor | Weight | Score (1-5) | Weighted Score |
|--------|--------|-------------|----------------|
| Code Changes | 0.25 | [1-5] | [calculated] |
| Integration Points | 0.20 | [1-5] | [calculated] |
| Risk Level | 0.20 | [1-5] | [calculated] |
| Testing Complexity | 0.15 | [1-5] | [calculated] |
| Dependencies | 0.10 | [1-5] | [calculated] |
| Uncertainty | 0.10 | [1-5] | [calculated] |
| **Total** | **1.00** | - | **[sum]** |
**Story Point Mapping:**
- 1-10: 1 point (trivial)
- 11-20: 2 points (simple)
- 21-30: 3 points (moderate)
- 31-40: 5 points (complex)
- 41-50: 8 points (very complex)
- 51+: 13 points or break down further
**Process:**
1. **Analyze Codebase Impact**
```bash
# Identify affected files
- Search for related code patterns
- Identify modules/services affected
- Count estimated file changes
- Assess code quality of affected areas
Assess Integration Complexity
Compare with Historical Issues
-- Example query pattern
SELECT issue_key, summary, story_points, resolution_time
FROM jira_issues
WHERE similarity(summary, '[current issue]') > 0.7
AND status = 'Done'
ORDER BY updated_date DESC
LIMIT 10
Calculate Complexity Score
Output Format:
# Complexity Analysis: [ISSUE-KEY]
## Summary
**Recommended Story Points:** 5
**Confidence Level:** Medium (70%)
**Risk Level:** Medium
**Estimated Duration:** 2-3 days
## Complexity Breakdown
### Code Impact Analysis
- **Files to Modify:** ~8 files
- `src/services/auth.service.ts` (high complexity)
- `src/controllers/user.controller.ts` (medium complexity)
- `src/models/user.model.ts` (low complexity)
- ... 5 more files
- **Estimated LOC Changes:** 300-400 lines
- **New Files Required:** 2-3 files
- `src/middleware/token-refresh.middleware.ts`
- `src/services/token.service.ts`
### Integration Complexity
- **External APIs:** 1 (Auth0 integration)
- **Database Changes:** Medium
- Add `refresh_token` column to users table
- Migration required: backward compatible
- **Service Dependencies:** 3
- Authentication service
- User service
- Session service
### Risk Factors (Score: 3.5/5)
- ⚠️ **High Risk:** Token security implementation
- Mitigation: Security review required
- ⚠️ **Medium Risk:** Database migration
- Mitigation: Test on staging first, rollback plan
- ℹ️ **Low Risk:** Breaking existing auth flow
- Mitigation: Backward compatible design
### Historical Comparison
**Similar Issues:**
1. **PROJ-234:** "Add OAuth2 support" (8 points, 4 days)
- Similar: Auth changes, token management
- Different: Larger scope, more integrations
2. **PROJ-189:** "Fix session expiry" (3 points, 1 day)
- Similar: Token handling
- Different: Bug fix vs. feature
**Team Velocity:**
- Average points completed per sprint: 25
- Average time per 5-point story: 2.5 days
- Team expertise in auth: High
### Complexity Scoring
| Factor | Weight | Score | Weighted | Rationale |
|--------|--------|-------|----------|-----------|
| Code Changes | 0.25 | 3 | 0.75 | Moderate file count, medium LOC |
| Integration Points | 0.20 | 3 | 0.60 | Auth0 + DB + 3 services |
| Risk Level | 0.20 | 4 | 0.80 | Security implications |
| Testing Complexity | 0.15 | 3 | 0.45 | Auth testing required |
| Dependencies | 0.10 | 2 | 0.20 | Minimal blocking issues |
| Uncertainty | 0.10 | 3 | 0.30 | Some unknowns in token refresh |
| **Total** | **1.00** | - | **3.10** | **→ 5 Story Points** |
## Estimation Confidence
**High Confidence Factors:**
- Similar work done before
- Clear requirements
- Team has expertise
**Low Confidence Factors:**
- Auth0 integration details unclear
- Performance requirements not specified
- Migration rollback scenario undefined
**Recommended Actions Before Starting:**
- [ ] Clarify Auth0 token refresh configuration
- [ ] Define performance SLA for token operations
- [ ] Create migration rollback plan
- [ ] Security review acceptance criteria
## Testing Requirements
**Estimated Test Effort:** 30% of development time
- Unit tests: 8-10 test cases
- Integration tests: 5-6 scenarios
- Security tests: Token validation, encryption
- Performance tests: Token generation throughput
- Manual testing: Cross-browser auth flows
## Alternative Approaches
### Option 1: Full Implementation (5 points)
- Implement token refresh with Auth0
- Database migration
- Complete test coverage
- **Pros:** Complete solution
- **Cons:** Higher risk, longer timeline
### Option 2: Phased Approach (Split into 2 stories)
- Story 1: Token service + basic refresh (3 points)
- Story 2: Auth0 integration + migration (3 points)
- **Pros:** Lower risk per story, easier to test
- **Cons:** More coordination overhead
### Option 3: Use Existing Library (2 points)
- Integrate auth middleware library
- Minimal custom code
- **Pros:** Faster, battle-tested
- **Cons:** Less flexibility, external dependency
## Recommendation
Proceed with **Option 1** (5 points) if sprint capacity allows and team has Auth0 experience. Otherwise, consider **Option 2** for risk reduction.
When to Apply:
Dependency Types:
Jira Issue Dependencies
Code Dependencies
Team Dependencies
External Dependencies
Process:
Query Jira Links
// Example using Jira API
const links = await jira.getIssueLinks(issueKey);
const blockers = links.filter(l => l.type === 'Blocks');
const dependencies = links.filter(l => l.type === 'Depends on');
Analyze Code Dependencies
# Search for module imports
grep -r "import.*auth" src/
# Find database references
grep -r "users\\.refresh_token" src/
# Identify API calls
grep -r "auth0\\.api" src/
Identify Team Dependencies
Create Dependency Graph
graph TD
CURRENT[Current Issue]
CURRENT --> DEP1[Dependency 1]
CURRENT --> DEP2[Dependency 2]
DEP1 --> DEP3[Sub-dependency]
Output Format:
# Dependency Analysis: [ISSUE-KEY]
## Dependency Summary
- **Total Dependencies:** 7
- **Blocking Issues:** 2 (CRITICAL)
- **Code Dependencies:** 3
- **Team Dependencies:** 2
- **External Dependencies:** 1
## Critical Path
```mermaid
graph LR
START[Start] --> PROJ-100[Auth API Ready]
PROJ-100 --> PROJ-123[Current Issue]
PROJ-123 --> PROJ-124[Frontend Integration]
PROJ-124 --> END[Complete]
Estimated Timeline: 5 days (including blockers)
auth.service.tsuser.model.ts| Dependency | Type | Status | Risk | Impact | Mitigation |
|---|---|---|---|---|---|
| PROJ-100 | Blocking Issue | In Progress | High | Cannot start | Daily follow-up |
| PROJ-111 | Blocking Issue | In Review | Medium | Delayed DB changes | Review and test PR |
| auth.service.ts | Code | Stable | Low | None | Standard testing |
| user.model.ts | Code | Active Dev | Medium | Merge conflicts | Coordinate with owner |
| Security Review | Team | Pending | Medium | Deployment delay | Schedule early |
| Auth0 API | External | Active | Low | Service outage | Fallback plan |
Pre-work (Days 1-2):
Implementation (Days 3-4):
Review & Deploy (Day 5):
While waiting for blockers, can work on:
### Strategy 5: Technical Design Enhancement
**When to Apply:**
- Technical approach unclear
- Need architecture guidance
- Identifying affected components
- Risk mitigation planning
**Output Format:**
```markdown
# Technical Design: [ISSUE-KEY]
## Architecture Impact
### Components Affected
```mermaid
graph TD
API[API Gateway] --> Auth[Auth Service]
Auth --> DB[(Database)]
Auth --> Cache[Redis Cache]
Auth --> Auth0[Auth0 Service]
File: src/services/auth.service.ts
// Proposed new method
async refreshAccessToken(refreshToken: string): Promise<TokenPair> {
// Validate refresh token
// Call Auth0 refresh endpoint
// Update session cache
// Return new token pair
}
Migration: migrations/YYYYMMDD_add_refresh_token.sql
ALTER TABLE users
ADD COLUMN refresh_token VARCHAR(512) ENCRYPTED,
ADD COLUMN refresh_token_expires_at TIMESTAMP,
ADD INDEX idx_refresh_token (refresh_token);
File: src/controllers/auth.controller.ts
POST /auth/refresh
Body: { refreshToken: string }
Response: { accessToken: string, refreshToken: string, expiresIn: number }
Probability: Low Impact: High Mitigation:
Probability: Very Low Impact: High Mitigation:
Probability: Low Impact: Medium Mitigation:
## Integration with Atlassian MCP Tools
### Using Jira MCP for Enrichment
```typescript
// Example enrichment workflow using MCP tools
// 1. Fetch issue details
const issue = await mcp.atlassian.getIssue(issueKey);
// 2. Extract description
const description = issue.fields.description;
// 3. Analyze for requirements
const criteria = extractAcceptanceCriteria(description);
// 4. Find similar issues
const similarIssues = await mcp.atlassian.searchIssues(
`text ~ "${issue.fields.summary}" AND status = Done ORDER BY updated DESC`
);
// 5. Analyze linked issues
const links = issue.fields.issuelinks;
const blockers = links.filter(l => l.type.name === 'Blocks');
// 6. Get historical data
const history = await mcp.atlassian.getIssueChangelog(issueKey);
// 7. Update issue with enrichment
await mcp.atlassian.updateIssue(issueKey, {
fields: {
customfield_10100: criteria, // Acceptance Criteria field
customfield_10101: estimatedPoints, // Story Points
description: enhancedDescription
}
});
// 8. Add enrichment comment
await mcp.atlassian.addComment(issueKey, formatEnrichmentComment(analysis));
// Link to related Confluence documentation
// 1. Search Confluence for related docs
const docs = await mcp.atlassian.searchConfluence(
`space = PROJ AND text ~ "${issue.fields.summary}"`
);
// 2. Extract technical requirements from Confluence
const techSpec = await mcp.atlassian.getConfluencePage(docs[0].id);
const requirements = parseConfluenceContent(techSpec.body.storage.value);
// 3. Add documentation links to Jira
await mcp.atlassian.addWebLink(issueKey, {
url: docs[0].url,
title: "Related Technical Specification"
});
// Analyze related code changes
// 1. Search git history for related commits
const relatedCommits = await searchCommits(
`git log --grep="${issue.fields.summary}" --all`
);
// 2. Identify affected files
const affectedFiles = extractFilesFromCommits(relatedCommits);
// 3. Analyze code complexity
const complexity = await analyzeCodeComplexity(affectedFiles);
// 4. Add findings to Jira
await mcp.atlassian.addComment(issueKey, `
## Code Impact Analysis
### Recently Modified Files Related to This Issue:
${affectedFiles.map(f => `- ${f.path} (${f.changes} changes in last 30 days)`).join('\n')}
### Complexity Assessment:
- Average cyclomatic complexity: ${complexity.average}
- High complexity files: ${complexity.high.length}
### Recommendation:
${generateComplexityRecommendation(complexity)}
`);
Issue Created
Issue Moved to "Ready for Development"
Issue Assigned to Sprint
Issue Description Updated
# Trigger full enrichment
/enrich-task PROJ-123
# Specific enrichment types
/enrich-task PROJ-123 --criteria-only
/enrich-task PROJ-123 --complexity-only
/enrich-task PROJ-123 --dependencies-only
# Batch enrichment
/enrich-sprint "Sprint 24"
/enrich-epic EPIC-456
Original Issue:
Title: Login not working
Description: Users can't log in sometimes
After Enrichment:
Title: Login not working
Description: Users can't log in sometimes
---
## AI-Generated Enrichment
### Extracted Requirements (Needs Verification)
Based on the vague description, likely requirements:
- [ ] Identify specific scenarios where login fails
- [ ] Determine if issue is browser-specific
- [ ] Check if issue occurs for all users or specific roles
- [ ] Verify if related to recent deployments
### Missing Information (Critical)
- **Reproduction Steps:** How to reproduce the issue?
- **Affected Users:** All users or specific group?
- **Frequency:** Always, sometimes, rarely?
- **Browser/Device:** Which browsers/devices affected?
- **Error Messages:** What errors do users see?
- **Recent Changes:** Any recent deployments to auth system?
### Suggested Investigation Steps
1. Check application logs for authentication errors
2. Review Auth0 dashboard for failed login attempts
3. Test login flow in different browsers
4. Check if issue correlates with specific time periods
5. Review recent changes to auth.service.ts
### Similar Historical Issues
- **PROJ-89:** "Login timeout issues" (3 points, resolved in 1 day)
- Root cause: Session expiry misconfiguration
- Fix: Updated session timeout settings
### Preliminary Complexity Assessment
**Story Points:** Cannot estimate without reproduction steps
**Recommended Action:** Move to "Needs More Info" status
### Recommended Labels
- bug, authentication, needs-reproduction, priority-tbd
Original Issue:
Title: Add export functionality
Description: Users should be able to export their data
After Enrichment:
Title: Add export functionality
Description: Users should be able to export their data
---
## AI-Generated Enrichment
### Extracted Acceptance Criteria
#### Functional Requirements
- [ ] **AC1:** User can trigger data export from profile settings
- [ ] **AC2:** User can choose export format (CSV, JSON, PDF)
- [ ] **AC3:** Export includes all user data (profile, activity, preferences)
- [ ] **AC4:** User receives download link via email when export is ready
- [ ] **AC5:** Export file is available for download for 7 days
#### Non-Functional Requirements
- [ ] **AC6:** Export generation completes within 5 minutes for typical user
- [ ] **AC7:** Supports users with up to 10,000 records
- [ ] **AC8:** Export files are encrypted and access-controlled
- [ ] **AC9:** GDPR compliant (right to data portability)
### Technical Design Suggestions
#### Recommended Architecture
- **Async Processing:** Use job queue for export generation
- **Storage:** Temporary S3 bucket with 7-day TTL
- **Notification:** Email service integration
- **Formats:**
- CSV: For spreadsheet import
- JSON: For API integrations
- PDF: For archival/printing
#### Affected Components
- User Settings UI
- Export Service (new)
- Job Queue Worker
- Email Notification Service
- S3 Storage
### Complexity Analysis
**Recommended Story Points:** 8
**Complexity Factors:**
- Multiple export formats: +2 complexity
- Async job processing: +2 complexity
- Email integration: +1 complexity
- Security/access control: +2 complexity
- GDPR compliance: +1 complexity
**Risk Factors:**
- ⚠️ Large data exports may timeout
- ⚠️ S3 costs for storage
- ℹ️ Email deliverability
### Dependencies
- Job queue infrastructure (existing)
- S3 bucket configuration (DevOps)
- Email template design (Design team)
- GDPR compliance review (Legal)
### Test Scenarios
#### Happy Path
```gherkin
Given user has data in the system
When user requests CSV export from settings
Then export job is queued
And user sees "Export in progress" message
And within 5 minutes, user receives email with download link
And user can download encrypted CSV file
And file contains all user data
## Summary
This skill provides comprehensive task enrichment capabilities through:
1. **Intelligent Extraction**: Automatically parse and extract requirements from vague descriptions
2. **Complexity Analysis**: Assess technical complexity and provide accurate estimates
3. **Dependency Mapping**: Identify all blockers and dependencies before work starts
4. **Design Guidance**: Suggest technical approaches and architecture patterns
5. **Historical Learning**: Leverage past issues for better estimates and approaches
6. **Integration**: Use Atlassian MCP tools for seamless Jira/Confluence integration
Use this skill as part of the EXPLORE phase in the Jira Orchestration Workflow to ensure all issues have comprehensive context before development begins.