Hybrid task decomposition strategy for teamwork projects. Covers plan-based and semantic decomposition, granularity rules, role assignment, dependency management, and complexity assessment.
Decomposes teamwork projects into granular tasks with role assignments and dependencies for parallel execution.
npx claudepluginhub mnthe/hardworker-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill provides comprehensive guidelines for breaking down project goals into actionable tasks. Use this when planning teamwork projects to ensure optimal task granularity, proper role assignment, and appropriate complexity assessment.
Use a combination of plan-based (Strategy A) and semantic (Strategy B) decomposition:
Use when plans option is provided with detailed implementation documents.
Example transformation:
Plan: "03.impl-workspace-setup.md"
|- Step 1: Root workspace -> Task: "Initialize pnpm monorepo workspace"
|- Step 2.1: Database package -> Task: "Create database package structure"
|- Step 2.2: items schema -> Task: "Implement items.schema.ts"
|- Step 2.3: item-features schema -> Task: "Implement item-features.schema.ts with pgvector"
+- Step 3: Docker -> Task: "Configure Docker Compose for dev environment"
Use when no plan documents provided, or as sub-decomposition within Strategy A.
Create tasks using the native TaskCreate API:
# Create a task
TaskCreate(
subject="Implement items.schema.ts",
description="Create PostgreSQL schema for items table with id, name, description, price columns. Include proper indexes.",
activeForm="Implementing items schema"
) # Returns task with auto-assigned ID
Use TaskUpdate with addBlockedBy to define task dependencies:
# Task 1: no dependencies (can start immediately)
TaskCreate(subject="Setup database schema", description="...") # -> task 1
# Task 2: depends on task 1
TaskCreate(subject="Implement auth middleware", description="...") # -> task 2
TaskUpdate(taskId="2", addBlockedBy=["1"])
# Task 3: depends on task 2
TaskCreate(subject="Create login/signup UI", description="...") # -> task 3
TaskUpdate(taskId="3", addBlockedBy=["2"])
# Task 4: depends on both task 1 and task 2
TaskCreate(subject="Write integration tests", description="...") # -> task 4
TaskUpdate(taskId="4", addBlockedBy=["1", "2"])
blockedBy linksblockedBy tasks complete, the task becomes available for workers# Foundation tasks (no dependencies)
TaskCreate(subject="Initialize project structure", description="...") # -> task 1
TaskCreate(subject="Configure TypeScript and ESLint", description="...") # -> task 2
# Core implementation (depends on foundation)
TaskCreate(subject="Create database models", description="...") # -> task 3
TaskUpdate(taskId="3", addBlockedBy=["1"])
TaskCreate(subject="Implement REST API endpoints", description="...") # -> task 4
TaskUpdate(taskId="4", addBlockedBy=["1", "3"])
TaskCreate(subject="Build React components", description="...") # -> task 5
TaskUpdate(taskId="5", addBlockedBy=["2"])
# Integration (depends on both API and UI)
TaskCreate(subject="Connect frontend to API", description="...") # -> task 6
TaskUpdate(taskId="6", addBlockedBy=["4", "5"])
# Testing (depends on integration)
TaskCreate(subject="Write E2E tests", description="...") # -> task 7
TaskUpdate(taskId="7", addBlockedBy=["6"])
This creates a natural execution order where independent tasks run in parallel and dependent tasks wait for their prerequisites.
Assign each task to the appropriate role based on its primary focus:
| Role | When to Use |
|---|---|
frontend | UI, components, styling, user interactions |
backend | API, services, database, business logic |
test | Tests, fixtures, mocks |
devops | CI/CD, deployment, infrastructure |
docs | Documentation, README, examples |
security | Auth, permissions, input validation |
review | Code review, refactoring |
general | Miscellaneous, cross-cutting |
Workers use different models based on task complexity. Assign complexity to optimize resource usage:
| Complexity | Model | Criteria | Examples |
|---|---|---|---|
simple | haiku | Single file, <10 lines, minor changes | Config updates, typo fixes, simple docs |
standard | sonnet | 1-3 files, typical CRUD, straightforward | API endpoints, UI components, tests |
complex | opus | 5+ files, architecture, security-critical | Auth systems, DB migrations, major refactors |
Default to standard when uncertain. Upgrade to complex if:
Tasks should use structured descriptions with markdown sections to provide clear guidance to workers.
## Description
What needs to be done (clear, actionable explanation)
## Approach
standard | tdd
## Success Criteria
- Criterion 1
- Criterion 2
- Criterion 3
## Verification Commands
command1
command2
| Section | Required | Default | Purpose |
|---|---|---|---|
## Description | Yes | - | What needs to be done |
## Approach | No | standard | standard or tdd workflow |
## Success Criteria | Recommended | General evidence | Checklist for verification |
## Verification Commands | Recommended | Skip | Commands workers run to verify |
| Task Type | Recommended Approach | Rationale |
|---|---|---|
| New feature with clear spec | tdd | Test-first ensures spec compliance |
| Bug fix | tdd | Test reproduces bug first |
| Refactoring | standard | Existing tests cover behavior |
| Configuration/docs | standard | Not testable |
| Security-critical code | tdd | Security tests first |
| API endpoints | tdd | Contract-driven development |
| Database schema | standard | Migrations not test-driven |
| UI components | standard | Visual testing preferred |
Good criteria are:
Examples:
❌ Vague:
- Code works
- Tests pass
- No errors
✅ Specific:
- Auth middleware in src/middleware/auth.ts
- Tests pass: npm test -- tests/auth.test.ts (exit code 0)
- Invalid tokens return 401 status
- Type check passes: npx tsc --noEmit src/middleware/auth.ts
Include commands that:
Examples:
# Test commands (scoped)
npm test -- tests/feature.test.ts
bun test tests/feature.test.ts
# Type checking
npx tsc --noEmit src/file.ts
# Build verification
npm run build
bun run build
# Runtime checks
docker-compose up -d && docker-compose ps
curl -X POST http://localhost:3000/api/endpoint
Do NOT include:
npm test without scope)TaskCreate(
subject="Implement user registration endpoint",
description="""## Description
POST /api/auth/register endpoint with email/password validation, password hashing, and duplicate email check.
## Approach
tdd
## Success Criteria
- Test file created first (TDD-RED)
- Endpoint in src/api/auth/register.ts
- Tests pass: npm test -- tests/auth-register.test.ts (exit code 0)
- Duplicate emails return 409
- Weak passwords rejected with 400
## Verification Commands
npm test -- tests/auth-register.test.ts
npx tsc --noEmit src/api/auth/register.ts
""",
activeForm="Implementing user registration"
)
TaskCreate(
subject="Create market card component",
description="""## Description
React component displaying market name, description, current odds, and bet buttons. Include loading states and error handling.
## Approach
standard
## Success Criteria
- Component in src/components/MarketCard.tsx
- Tests pass: npm test -- tests/MarketCard.test.ts (exit code 0)
- Accessible: proper ARIA labels
- Responsive design for mobile/desktop
## Verification Commands
npm test -- tests/MarketCard.test.ts
npm run build
""",
activeForm="Creating market card component"
)
TaskCreate(
subject="Configure CI/CD pipeline",
description="""## Description
GitHub Actions workflow for automated testing and deployment. Run on every push to main. Deploy to Vercel on success.
## Approach
standard
## Success Criteria
- .github/workflows/ci.yml created
- Workflow runs on push to main
- Tests run in CI environment
- Deployment to Vercel on success
## Verification Commands
gh workflow view ci
gh run list --workflow=ci
""",
activeForm="Configuring CI/CD pipeline"
)
addBlockedBy dependenciesExpert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.