Use throughout all work - ensures GitHub issues are updated continuously as work happens, not batched at the end
Updates GitHub issues in real-time as work happens, not in batches. Triggers on starting work, hitting blockers, making decisions, completing criteria, and finishing work to maintain the issue as the source of truth.
/plugin marketplace add troykelly/claude-skills/plugin install issue-driven-development@troykelly-skillsThis skill is limited to using the following tools:
Update issues AS work happens, not in one dump at the end.
Core principle: The issue is the source of truth. Keep it current.
This skill is used THROUGHOUT work, not as a separate step.
Update the issue at these moments:
| Moment | Update Type |
|---|---|
| Starting work | Status → In Progress |
| Hitting a blocker | Comment explaining blocker |
| Making a decision | Comment documenting decision |
| Discovering new information | Comment with findings |
| Completing acceptance criterion | Check off in body |
| Completing verification | Post verification report |
| Raising PR | Link PR to issue |
| Work complete | Status → Done |
# Get item ID
ITEM_ID=$(gh project item-list [PROJECT_NUMBER] --owner @me \
--format json | jq -r '.items[] | select(.content.number == [ISSUE_NUMBER]) | .id')
# Update status
gh project item-edit --project-id [PROJECT_ID] --id $ITEM_ID \
--field-id [STATUS_FIELD_ID] \
--single-select-option-id [NEW_STATUS_OPTION_ID]
gh issue comment [ISSUE_NUMBER] --body "## Progress Update
**Time:** $(date -u +%Y-%m-%dT%H:%M:%SZ)
### Completed
- Implemented X
- Fixed Y
### In Progress
- Working on Z
### Blockers
- None
### Next Steps
- Will do A next"
When an acceptance criterion is met:
- [ ] to - [x]# Get current body
BODY=$(gh issue view [ISSUE_NUMBER] --json body -q '.body')
# Update checkbox (example with sed)
NEW_BODY=$(echo "$BODY" | sed 's/- \[ \] First criterion/- [x] First criterion/')
# Update issue
gh issue edit [ISSUE_NUMBER] --body "$NEW_BODY"
At absolute minimum, update at these points:
For active work, update more frequently:
## Progress Update - [TIME]
### Completed
- [What was done]
### Currently Working On
- [Active work]
### Decisions Made
- [Decision]: [Rationale]
### Issues Encountered
- [Issue]: [How resolved or current status]
### Next Steps
- [What comes next]
## Decision: [Brief Title]
**Context:** [Why this decision was needed]
**Options Considered:**
1. [Option A] - [Pros/Cons]
2. [Option B] - [Pros/Cons]
**Decision:** [Chosen option]
**Rationale:** [Why this option was chosen]
## Blocked: [Brief Description]
**Blocked at:** [TIME]
**Blocking issue:** [What's preventing progress]
**What was tried:**
1. [Attempt 1]
2. [Attempt 2]
**Needs:** [What's needed to unblock]
**Impact:** [How this affects timeline/scope]
| Anti-Pattern | Problem |
|---|---|
| Batch updates at end | No visibility during work |
| "Made progress" comments | Not specific enough |
| Updating only on success | Failures need documentation too |
| Skipping blocker documentation | Lost context on what went wrong |
| Closing without verification | Must verify before closing |
| Good Pattern | Benefit |
|---|---|
| Update as you go | Real-time visibility |
| Specific progress notes | Clear record of what happened |
| Document failures | Learn from problems |
| Document blockers immediately | Faster unblocking |
| Verification before close | Ensures quality |
Before starting work on any issue:
# View issue with all comments
gh issue view [ISSUE_NUMBER] --comments
# View timeline
gh issue view [ISSUE_NUMBER] --json timeline
Look for:
Keep these fields current:
| Field | When to Update |
|---|---|
| Status | When work state changes |
| Verification | After running verification |
| Criteria Met | After checking off criteria |
| Last Verified | After verification runs |
This skill is used by:
issue-driven-development - Throughout all stepsacceptance-criteria-verification - Post verification reportserror-recovery - Document failuresFor each work session, ensure:
This 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.