Defines behavior protocol for spawned worker agents. Injected into worker prompts. Covers startup, progress reporting, exit conditions, and handover preparation.
Defines the behavioral contract for spawned worker agents, governing startup, progress reporting, exit conditions, and handover preparation. It's automatically injected into worker prompts by `worker-dispatch` to ensure consistent, self-documenting worker behavior.
/plugin marketplace add troykelly/claude-skills/plugin install issue-driven-development@troykelly-skillsThis skill is limited to using the following tools:
This skill defines the behavioral contract for spawned worker agents. It is injected into worker prompts and governs how workers operate.
Core principle: Workers are single-purpose, self-documenting, and gracefully exit.
Note: This skill is not invoked directly - it's embedded in worker prompts by worker-dispatch.
Every worker has:
| Property | Example | Purpose |
|---|---|---|
worker_id | worker-1701523200-123 | Unique identifier |
issue | 123 | Assigned issue number |
attempt | 1 | Which attempt this is |
orchestration_id | orch-2025-12-02-001 | Parent orchestration |
Workers MUST execute this checklist before starting work:
## Worker Startup Checklist
1. [ ] Read assigned issue completely
2. [ ] Check issue comments for context/history
3. [ ] Verify on correct branch (`git branch --show-current`)
4. [ ] Check worktree is clean (`git status`)
5. [ ] Run existing tests to verify baseline (`pnpm test` or equivalent)
6. [ ] Post startup comment to issue
š¤ **Worker Started**
| Property | Value |
|----------|-------|
| Worker ID | `[WORKER_ID]` |
| Attempt | [N] |
| Branch | `[BRANCH_NAME]` |
| Started | [TIMESTAMP] |
**Understanding:**
[1-2 sentence summary of what the issue requires]
**Approach:**
[Brief planned approach]
---
*Orchestration: [ORCHESTRATION_ID]*
Workers post progress comments:
š¤ **Worker Update**
**Status:** [Implementing|Testing|Blocked|Complete]
**Turns Used:** [N]/100
**Progress:**
- [x] [Completed item]
- [x] [Completed item]
- [ ] [In progress item]
- [ ] [Remaining item]
**Current:**
[What you're working on right now]
**Next:**
[What you'll do next]
---
*Worker: [WORKER_ID]*
Workers exit when ANY of these conditions are met:
š¤ **Worker Complete** ā
**PR Created:** #[PR_NUMBER]
**Issue:** #[ISSUE]
**Branch:** `[BRANCH]`
**Summary:**
[1-2 sentences describing what was implemented]
**Tests:**
- [N] tests passing
- Coverage: [X]%
**Ready for:** CI verification
---
*Worker: [WORKER_ID] | Turns: [N]/100*
When approaching 100 turns (at ~85-90 turns):
š¤ **Handover Required** š
**Turns Used:** [N]/100
**Reason:** Approaching turn limit
**Handover file created:** `.orchestrator/handover-[ISSUE].md`
A replacement worker will continue this work with full context.
---
*Worker: [WORKER_ID]*
See worker-handover skill for handover file format.
Only after exhausting all options:
š¤ **Worker Blocked** š«
**Reason:** [Clear description of blocker]
**What I tried:**
1. [Approach 1] - [Why it didn't work]
2. [Approach 2] - [Why it didn't work]
**Required to unblock:**
- [ ] [Specific action needed from human/external]
**Cannot proceed because:**
[Explanation of why this is a true blocker, not just a hard problem]
---
*Worker: [WORKER_ID] | Attempt: [N]*
When implementation fails after good-faith effort:
š¤ **Worker Failed - Research Needed** š¬
**Failure:** [What failed]
**Attempt:** [N]
**What I tried:**
1. [Approach 1] - [Result]
2. [Approach 2] - [Result]
**Error/Issue:**
[Error output or description]
**Hypothesis:**
[What I think might be wrong]
**Research needed:**
- [ ] [Specific question to research]
- [ ] [Area to investigate]
---
*Worker: [WORKER_ID] | Triggering research cycle*
Before creating ANY PR, workers MUST:
comprehensive-review skill (7 criteria)apply-all-findings skillReview artifact format (machine-parseable):
<!-- REVIEW:START -->
## Code Review Complete
| Property | Value |
|----------|-------|
| Worker | `[WORKER_ID]` |
| Issue | #[ISSUE] |
| Reviewed | [TIMESTAMP] |
[... full artifact per comprehensive-review skill ...]
**Review Status:** ā
COMPLETE
<!-- REVIEW:END -->
CRITICAL: The PreToolUse hook will BLOCK gh pr create if:
If worker modifies files matching security-sensitive patterns:
**/auth/**, **/api/**, **/middleware/****/*password*, **/*token*, **/*secret*Worker MUST:
security-reviewer subagent OR perform security-review skillcomprehensive-review before PRWorkers use this commit format:
[type]: [description] (#[ISSUE])
[Body if needed]
š¤ Worker: [WORKER_ID]
Types:
feat: New featurefix: Bug fixtest: Test additionsrefactor: Code refactoringdocs: DocumentationExample:
feat: Add dark mode toggle to settings (#123)
- Created ThemeContext with dark/light modes
- Added toggle switch to settings page
- Persisted preference to localStorage
š¤ Worker: worker-1701523200-123
PREREQUISITE: Review artifact MUST be posted to issue before PR creation.
# Verify review artifact exists in issue
REVIEW_EXISTS=$(gh api "/repos/$OWNER/$REPO/issues/$ISSUE/comments" \
--jq '[.[] | select(.body | contains("<!-- REVIEW:START -->"))] | length')
if [ "$REVIEW_EXISTS" = "0" ]; then
echo "ERROR: No review artifact found. Complete comprehensive-review first."
exit 1
fi
# Verify review is COMPLETE with 0 unaddressed
REVIEW_STATUS=$(gh api "/repos/$OWNER/$REPO/issues/$ISSUE/comments" \
--jq '[.[] | select(.body | contains("<!-- REVIEW:START -->"))] | last | .body' \
| grep -o "Review Status:.*" | head -1)
echo "Review status: $REVIEW_STATUS"
[type]: [description] (#[ISSUE])
## Summary
[1-2 sentence description]
Closes #[ISSUE]
## Changes
- [Change 1]
- [Change 2]
- [Change 3]
## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests passing
- [ ] Manual testing completed
## Code Review
- [x] Review artifact posted to issue
- [x] All findings addressed
- [x] Review status: COMPLETE
## Checklist
- [ ] Code follows project style
- [ ] Types are complete (no `any`)
- [ ] Documentation updated
- [ ] IPv6-first verified (if applicable)
---
š¤ **Automated PR**
Worker: `[WORKER_ID]`
Orchestration: `[ORCHESTRATION_ID]`
Attempt: [N]
Review: See issue #[ISSUE] for review artifact
Workers operate in isolated worktrees and must:
# Verify worktree
git worktree list
# Verify branch
git branch --show-current # Should be feature/[ISSUE]-*
# Verify not on main
if [ "$(git branch --show-current)" = "main" ]; then
echo "ERROR: On main branch in worktree!"
exit 1
fi
Workers should be aware of their turn budget:
| Turns | Status | Action |
|---|---|---|
| 0-50 | Early | Normal work |
| 50-80 | Mid | Monitor progress |
| 80-90 | Late | Prepare handover if needed |
| 90-100 | Critical | Finalize and handover |
At turn 85+:
ā ļø **Turn Check:** [N]/100 turns used
If work is not nearly complete, begin handover preparation now.
When errors occur:
š¤ **Error Encountered**
**Command:** `[command that failed]`
**Error:**
[error output]
**Analysis:** [What I think went wrong]
**Retry:** [What I'll try next]
Workers MUST create handover when:
See worker-handover skill for handover file format.
This protocol is used by:
This protocol requires workers to follow:
issue-driven-development - Core workflowstrict-typing - Type requirementsipv6-first - Network requirementstdd-full-coverage - Testing approachclean-commits - Commit standardsworker-handover - Handover formatcomprehensive-review - Code review (MANDATORY before PR)apply-all-findings - Address all findingssecurity-review - For security-sensitive filesdeferred-finding - For tracking deferred findingsreview-gate - PR creation gateThis protocol is enforced by:
PreToolUse hook on gh pr create - Blocks without review artifactStop hook - Verifies review completion before session endThis skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.