8-phase task execution lifecycle for teamwork workers using native Claude Code APIs. Covers task discovery, claiming, structured description parsing, TDD workflow, implementation, verification, selective commit, and completion reporting.
Executes teamwork tasks through an 8-phase lifecycle including TDD, verification, and selective commits.
npx claudepluginhub mnthe/hardworker-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill provides the complete 8-phase lifecycle for executing teamwork tasks using native Claude Code APIs. Follow these phases in order.
The orchestrator creates tasks with structured markdown sections in the description. Workers MUST parse these sections to determine approach, criteria, and verification commands.
## Description
What needs to be done
## Approach
standard | tdd
## Success Criteria
- Criterion 1
- Criterion 2
## Verification Commands
npm test -- path/to/test
npx tsc --noEmit src/file.ts
Parsing rules:
| Section | Required | Default |
|---|---|---|
## Description | Yes | N/A |
## Approach | No | standard |
## Success Criteria | No | Use general evidence collection |
## Verification Commands | No | Skip automated verification |
Workers extract these sections from the task description after claiming. If ## Approach is missing, default to standard. If ## Success Criteria is missing, use general evidence collection.
List available tasks using native TaskList:
# List all tasks in the team
tasks = TaskList()
Filter for tasks that are:
blockedBy tasks are completed)owner assigned yetcompleted or in_progressIf your agent has a role specialization, prioritize tasks matching your role.
If no task found: Send a message to the orchestrator and wait for assignment.
SendMessage(
type="message",
recipient="orchestrator",
content="No available tasks matching my role. Waiting for assignment.",
summary="Worker idle - no tasks available"
)
Claim the task by setting yourself as the owner and updating the status:
TaskUpdate(
taskId="<TASK_ID>",
owner="<your-agent-name>",
status="in_progress",
activeForm="Working on: <task subject>"
)
If claim fails (conflict): Another worker took it. Return to Phase 1 and find a different task.
Extract the structured sections from the task description:
# Get full task details
task = TaskGet(taskId="<TASK_ID>")
Parse the description to extract:
standard or tdd (default: standard)Decision point after parsing:
| Approach | Next Phase |
|---|---|
standard | Skip to Phase 5 (Implement) |
tdd | Proceed to Phase 4 (TDD RED) |
Skip this phase if approach is standard.
Write the test FIRST, before any implementation code.
TDD-RED: prefix# Record test creation
TaskUpdate(
taskId="<TASK_ID>",
description="""
<original description>
## Evidence
- TDD-RED: Created test file tests/feature.test.ts
"""
)
# Run SCOPED test - MUST FAIL
npm test -- tests/feature.test.ts
# Record failure (expected)
TaskUpdate(
taskId="<TASK_ID>",
description="""
<updated description>
## Evidence
- TDD-RED: Created test file tests/feature.test.ts
- TDD-RED: npm test -- tests/feature.test.ts (exit code 1)
"""
)
Evidence required before proceeding:
Do NOT write implementation files during this phase. Only test files are allowed.
Execute the task using your specialization:
Write MINIMAL code to make the test pass. Do NOT add extra functionality beyond what the test requires.
# Run SCOPED test - MUST PASS
npm test -- tests/feature.test.ts
# Record implementation and passing test
TaskUpdate(
taskId="<TASK_ID>",
description="""
<updated description>
## Evidence
- TDD-RED: Created test file tests/feature.test.ts
- TDD-RED: npm test -- tests/feature.test.ts (exit code 1)
- TDD-GREEN: Implemented src/feature.ts
- TDD-GREEN: npm test -- tests/feature.test.ts (exit code 0)
"""
)
After GREEN, optionally improve code quality:
TDD-REFACTOR: prefixTaskUpdate(
taskId="<TASK_ID>",
description="""
<updated description>
## Evidence
...
- TDD-REFACTOR: Extracted helper function, npm test -- tests/feature.test.ts (exit code 0)
"""
)
Before committing, run ALL verification commands and check ALL success criteria.
Execute each command from ## Verification Commands in the task description:
# Example: run scoped tests
npm test -- path/to/test.ts
# Example: scoped type check on modified files only
npx tsc --noEmit src/file1.ts src/file2.ts
For each criterion from ## Success Criteria, collect concrete evidence:
| Bad Evidence | Good Evidence |
|---|---|
| "Tests pass" | "npm test -- auth.test.ts: 15/15 passed, exit code 0" |
| "API works" | "curl /api/users: 200 OK, 5 users returned, exit code 0" |
| "File created" | "Created src/auth.ts (127 lines)" |
For TypeScript projects, type check ONLY the files you modified:
# SCOPED - Type check only changed files
npx tsc --noEmit src/file1.ts src/file2.ts
# FORBIDDEN - Full build is deferred to final-verifier
npm run build
npx tsc
Every verification command MUST have its exit code recorded.
| All verifications pass | Proceed to Phase 7 (Commit) |
|---|---|
| ANY verification fails | Do NOT commit, do NOT mark complete, report failure |
On verification failure:
TaskUpdate(
taskId="<TASK_ID>",
description="""
<original description>
## Failure
- FAILED: npm test -- auth.test.ts exited with code 1
- Error: TypeError in auth.ts:42
- Root cause: Missing dependency injection for database client
""",
status="open",
owner=""
)
SendMessage(
type="message",
recipient="orchestrator",
content="Task <TASK_ID> failed verification. Reason: <failure description>. Released for retry.",
summary="Task <TASK_ID> failed - released"
)
Do NOT proceed to Phase 7 or Phase 8 if verification fails.
Only reach this phase if ALL verifications in Phase 6 passed.
# FORBIDDEN - NEVER use these:
git add -A # Stages ALL files
git add . # Stages ALL files
git add --all # Stages ALL files
git add * # Glob expansion - dangerous
# REQUIRED - Only add files YOU modified during this task:
git add path/to/file1.ts path/to/file2.ts
git add path/to/file1.ts path/to/file2.ts && git commit -m "$(cat <<'EOF'
<type>(<scope>): <short description>
[teamwork] Task: <TASK_ID>
<TASK_SUBJECT>
Evidence:
- <evidence 1>
- <evidence 2>
Files changed:
- path/to/file1.ts
- path/to/file2.ts
EOF
)"
| Type | When to Use |
|---|---|
| feat | New feature or functionality |
| fix | Bug fix |
| refactor | Code refactoring without behavior change |
| test | Adding or modifying tests |
| docs | Documentation changes |
| style | Code style changes (formatting, etc.) |
| chore | Build, config, or maintenance tasks |
git status --porcelain is empty)Why selective staging?
Mark the task as completed and notify the orchestrator:
# Mark task complete
TaskUpdate(taskId="<TASK_ID>", status="completed")
# Notify orchestrator with summary
SendMessage(
type="message",
recipient="orchestrator",
content="Task <TASK_ID> complete. <brief summary of what was done>. Commit: <short hash>.",
summary="Task <TASK_ID> completed"
)
A complete TDD task MUST produce this evidence sequence:
1. TDD-RED: Test file created
2. TDD-RED: Scoped test execution failed (exit code 1)
3. TDD-GREEN: Implementation created
4. TDD-GREEN: Scoped test execution passed (exit code 0)
5. TDD-REFACTOR: (optional) Improvements made, scoped tests still pass
Evidence format requirements:
npm test -- tests/feature.test.ts)TDD-RED:, TDD-GREEN:, TDD-REFACTOR:)Verification will FAIL if:
Key differences from ultrawork TDD:
TaskUpdate for evidence (not session scripts)For each criterion, evidence must include:
TDD-RED:, TDD-GREEN:, TDD-REFACTOR:TaskUpdate(
taskId="<TASK_ID>",
description="""
<original task description>
## Evidence
### Criterion: Tests pass
- Command: npm test -- src/auth.test.ts
- Output: PASS src/auth.test.ts (15/15)
- Exit code: 0
### Criterion: Type check passes
- Command: npx tsc --noEmit src/auth.ts
- Exit code: 0
"""
)
| Action | API Call |
|---|---|
| List tasks | TaskList() |
| Get task details | TaskGet(taskId="<id>") |
| Claim task | TaskUpdate(taskId="<id>", owner="<name>", status="in_progress") |
| Update description | TaskUpdate(taskId="<id>", description="...") |
| Complete task | TaskUpdate(taskId="<id>", status="completed") |
| Release task | TaskUpdate(taskId="<id>", status="open", owner="") |
| Message orchestrator | SendMessage(type="message", recipient="orchestrator", content="...") |
Before ending your work, verify:
If you skip Phase 6, unverified code enters the codebase.
If you skip Phase 7, your changes may be lost or mixed with other workers' changes.
If you skip Phase 8, the task will remain stuck in in_progress status forever.
Do NOT use these in your output or evidence:
If work is incomplete, say so explicitly with a concrete reason.
Expert 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.