Work Items Skill
Apply these patterns when working with issues, tickets, or work items from any system (GitHub Issues, Jira, Azure DevOps, Linear, etc.).
LLM Optimization Patterns
File Path Compression
Use glob patterns to compress multiple file paths:
| Before |
After |
routes/dev-routes.bicep, routes/test-routes.bicep, routes/prod-routes.bicep |
routes/{dev,test,prod}-routes.bicep |
src/components/Button.tsx, src/components/Input.tsx |
src/components/{Button,Input}.tsx |
Terse Language Rules
- No articles ("the", "a") unless needed for clarity
- No filler phrases ("In order to", "This will")
- Use arrows for transformations:
external -> internal, HTTP -> HTTPS
- Use equals for settings:
ingress.external = false
Output Structure
Optimize work items into this token-efficient format:
# {ID}: {title}
## Context
{1-2 sentence summary}
## Files
- {file paths with glob patterns}
## Changes
1. {file}: {action}
## Verify
- {non-obvious verification step}
Acceptance Criteria Filtering
Remove obvious/implicit criteria:
- "Deployment succeeds"
- "No downtime"
- "Tests pass"
- "Code reviewed"
- "PR merged"
Keep non-obvious verification:
- Specific HTTP status codes
- Portal/UI status checks
- Security constraints
- Integration behaviors
Task Breakdown Rules
Granularity
- 1 task = 1 logical change that can be committed independently
- Each task: ~5-30 min of work
- Group related file changes if they must be atomic
Sequencing
- Infrastructure/Config first (env vars, config files, dependencies)
- Core changes second (main logic, modules)
- Dependent files third (routes, integrations, consumers)
- Verification last (manual checks, cleanup)
Task Format
## Task {n}: {brief title}
**Files**: {file(s) to modify}
**Do**:
- {specific action}
**Test**:
- {how to verify}
Completeness Criteria
Title
- Descriptive (> 5 words typically)
- Clearly indicates what feature/change is needed
- Avoids vague terms: "fix bug", "update code", "improvements"
Description
- Exists and is not empty
- Explains what needs to be done
- Explains why it's needed (business value/context)
- Provides enough context for a developer to understand scope
Acceptance Criteria
- Present and populated
- Contains specific, testable conditions
- Uses clear language (Given/When/Then or bullet points)
- Defines what "done" looks like
1---2name: work-items3description: Optimize and analyze work items for LLM-assisted development4---5
6# Work Items Skill
7
8Apply these patterns when working with issues, tickets, or work items from any system (GitHub Issues, Jira, Azure DevOps, Linear, etc.).
9
10## LLM Optimization Patterns
11
12### File Path Compression
13Use glob patterns to compress multiple file paths:
14
15| Before | After |
16|--------|-------|
17| `routes/dev-routes.bicep`, `routes/test-routes.bicep`, `routes/prod-routes.bicep` | `routes/{dev,test,prod}-routes.bicep` |
18| `src/components/Button.tsx`, `src/components/Input.tsx` | `src/components/{Button,Input}.tsx` |
19
20### Terse Language Rules
21- No articles ("the", "a") unless needed for clarity
22- No filler phrases ("In order to", "This will")
23- Use arrows for transformations: `external -> internal`, `HTTP -> HTTPS`
24- Use equals for settings: `ingress.external = false`
25
26### Output Structure
27Optimize work items into this token-efficient format:
28
29```markdown
30# {ID}: {title}
31
32## Context
33{1-2 sentence summary}
34
35## Files
36- {file paths with glob patterns}
37
38## Changes
391. {file}: {action}
40
41## Verify
42- {non-obvious verification step}
43```
44
45### Acceptance Criteria Filtering
46**Remove** obvious/implicit criteria:
47- "Deployment succeeds"
48- "No downtime"
49- "Tests pass"
50- "Code reviewed"
51- "PR merged"
52
53**Keep** non-obvious verification:
54- Specific HTTP status codes
55- Portal/UI status checks
56- Security constraints
57- Integration behaviors
58
59## Task Breakdown Rules
60
61### Granularity
62- 1 task = 1 logical change that can be committed independently
63- Each task: ~5-30 min of work
64- Group related file changes if they must be atomic
65
66### Sequencing
671. Infrastructure/Config first (env vars, config files, dependencies)
682. Core changes second (main logic, modules)
693. Dependent files third (routes, integrations, consumers)
704. Verification last (manual checks, cleanup)
71
72### Task Format
73```markdown
74## Task {n}: {brief title}
75
76**Files**: {file(s) to modify}
77
78**Do**:
79- {specific action}
80
81**Test**:
82- {how to verify}
83```
84
85## Completeness Criteria
86
87### Title
88- Descriptive (> 5 words typically)
89- Clearly indicates what feature/change is needed
90- Avoids vague terms: "fix bug", "update code", "improvements"
91
92### Description
93- Exists and is not empty
94- Explains **what** needs to be done
95- Explains **why** it's needed (business value/context)
96- Provides enough context for a developer to understand scope
97
98### Acceptance Criteria
99- Present and populated
100- Contains specific, testable conditions
101- Uses clear language (Given/When/Then or bullet points)
102- Defines what "done" looks like
majiayu000