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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: work-items3description: Optimize and analyze work items for LLM-assisted development Use when this capability is needed.4---56# Work Items Skill78Apply these patterns when working with issues, tickets, or work items from any system (GitHub Issues, Jira, Azure DevOps, Linear, etc.).910## LLM Optimization Patterns1112### File Path Compression13Use glob patterns to compress multiple file paths:1415| 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` |1920### Terse Language Rules21- No articles ("the", "a") unless needed for clarity22- 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`2526### Output Structure27Optimize work items into this token-efficient format:2829```markdown30# {ID}: {title}3132## Context33{1-2 sentence summary}3435## Files36- {file paths with glob patterns}3738## Changes391. {file}: {action}4041## Verify42- {non-obvious verification step}43```4445### Acceptance Criteria Filtering46**Remove** obvious/implicit criteria:47- "Deployment succeeds"48- "No downtime"49- "Tests pass"50- "Code reviewed"51- "PR merged"5253**Keep** non-obvious verification:54- Specific HTTP status codes55- Portal/UI status checks56- Security constraints57- Integration behaviors5859## Task Breakdown Rules6061### Granularity62- 1 task = 1 logical change that can be committed independently63- Each task: ~5-30 min of work64- Group related file changes if they must be atomic6566### Sequencing671. 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)7172### Task Format73```markdown74## Task {n}: {brief title}7576**Files**: {file(s) to modify}7778**Do**:79- {specific action}8081**Test**:82- {how to verify}83```8485## Completeness Criteria8687### Title88- Descriptive (> 5 words typically)89- Clearly indicates what feature/change is needed90- Avoids vague terms: "fix bug", "update code", "improvements"9192### Description93- Exists and is not empty94- Explains **what** needs to be done95- Explains **why** it's needed (business value/context)96- Provides enough context for a developer to understand scope9798### Acceptance Criteria99- Present and populated100- Contains specific, testable conditions101- Uses clear language (Given/When/Then or bullet points)102- Defines what "done" looks like103104---105> Converted and distributed by [TomeVault](https://tomevault.io/claim/dariuszparys) — claim your Tome and manage your conversions.106<!-- tomevault:4.0:skill_md:2026-04-13 -->