atomic-tasks
4
总安装量
2
周安装量
#51863
全站排名
安装命令
npx skills add https://github.com/doubleslashse/claude-marketplace --skill atomic-tasks
Agent 安装分布
opencode
2
claude-code
2
windsurf
1
antigravity
1
gemini-cli
1
Skill 文档
Atomic Tasks Skill
This skill provides patterns for creating well-structured, atomic tasks that follow the principle: One task = One commit = One thing.
Core Principles
Atomicity
Each task should be:
- Self-contained: Completes a single logical unit of work
- Independently verifiable: Can be tested/verified in isolation
- Safely committable: Results in a working codebase if committed alone
- Rollback-friendly: Can be reverted without breaking other tasks
Task Properties
| Property | Purpose | Required |
|---|---|---|
id |
Unique identifier (TASK-XXX) | Yes |
status |
Current state (pending/in_progress/completed/blocked) | Yes |
name |
Short descriptive name | Yes |
description |
What this task accomplishes | Yes |
depends |
Task IDs this depends on | No |
files |
Files to create/modify | Yes |
actions |
Specific steps to take | Yes |
verify |
How to verify completion | Yes |
done |
Completion criteria | Yes |
commit |
Conventional commit message | Yes |
Task Sizing Guidelines
Too Large (Split It)
- Touches more than 5 files
- Has more than 5 actions
- Takes more than 30 minutes
- Multiple logical concerns mixed together
- Commit message needs “and” multiple times
Too Small (Combine It)
- Only renames a variable
- Single-line change with no logic
- Cannot be meaningfully verified
- Would create noise in git history
Just Right
- 1-3 files modified typically
- 2-5 clear actions
- Single responsibility
- Clear verification steps
- Concise commit message
Task Status Flow
pending âââ in_progress âââ completed
â â
â âââ blocked (external dependency)
â
âââ skipped (no longer needed)
Dependency Management
Dependency Types
- Code Dependency: Task B needs code from Task A
- Schema Dependency: Task B needs database changes from Task A
- Config Dependency: Task B needs configuration from Task A
- Knowledge Dependency: Task B needs information gathered in Task A
Dependency Rules
- No circular dependencies allowed
- Minimize dependency chains (prefer parallelizable tasks)
- Document why dependency exists
- Re-evaluate if blocked task is taking too long
Verification Patterns
Automated Verification
<verify>
<step>npm test -- [test-pattern]</step>
<step>npm run build</step>
<step>npm run lint -- [file]</step>
</verify>
Manual Verification
<verify>
<step>Visually confirm [UI element] appears</step>
<step>Manual test: [test scenario]</step>
</verify>
Combined Verification
<verify>
<step>npm test -- auth</step>
<step>Manual: Login with test credentials</step>
<step>Check logs for errors</step>
</verify>
Done Criteria Patterns
Feature Tasks
<done>
<criterion>Feature is accessible via [entry point]</criterion>
<criterion>Tests cover happy path and error cases</criterion>
<criterion>No new lint warnings introduced</criterion>
</done>
Bug Fix Tasks
<done>
<criterion>Original issue no longer reproduces</criterion>
<criterion>Regression test added</criterion>
<criterion>Related functionality still works</criterion>
</done>
Refactor Tasks
<done>
<criterion>All existing tests still pass</criterion>
<criterion>No functional changes detected</criterion>
<criterion>[Quality metric] improved</criterion>
</done>
Commit Message Convention
Follow Conventional Commits:
<type>(<scope>): <description>
[optional body]
[optional footer]
Types
| Type | Use For |
|---|---|
feat |
New feature |
fix |
Bug fix |
refactor |
Code restructuring |
test |
Adding/updating tests |
docs |
Documentation only |
chore |
Maintenance tasks |
style |
Formatting changes |
perf |
Performance improvements |
Examples
feat(auth): add login endpoint
fix(cart): prevent negative quantities
refactor(api): extract validation middleware
test(user): add registration edge cases
Task Decomposition Process
- Start with the goal: What is the end result?
- Identify major components: What distinct pieces are needed?
- Check for dependencies: What order must they happen in?
- Size each component: Is each one atomic?
- Split if needed: Break large components down
- Define verification: How will we know each is done?
- Write commit messages: Force clarity of purpose
Anti-Patterns to Avoid
The Kitchen Sink
<!-- BAD: Too many unrelated changes -->
<task id="TASK-001">
<name>Add auth and update styling and fix bugs</name>
...
</task>
The Invisible Task
<!-- BAD: No way to verify -->
<task id="TASK-001">
<name>Improve code quality</name>
<verify></verify>
</task>
The Dependency Chain
<!-- BAD: Long sequential chain -->
TASK-001 â TASK-002 â TASK-003 â TASK-004 â TASK-005
The Vague Action
<!-- BAD: Not actionable -->
<actions>
<action>Make it better</action>
<action>Fix the thing</action>
</actions>
Integration with Workflow
PLAN Phase
- Create all tasks using XML format
- Verify cross-plan consistency
- Establish execution order
EXECUTE Phase
- Process one task at a time
- Mark status transitions
- Run verification after each
- Commit on success
VERIFY Phase
- Review all completed tasks
- Run integration verification
- Confirm done criteria met
See xml-format.md for complete XML schema reference.