From hatch3r
Guides an 8-step agentic development workflow for issues: parsing, loading issue-type skills, reading specs, planning, implementing, testing, opening PRs/MRs, and addressing review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hatch3r:hatch3r-issue-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
When assigned an issue or work item (GitHub Issue, Azure DevOps Work Item, or GitLab Issue — check `platform` in `.hatch3r/hatch.json`), follow these 8 steps in order:
When assigned an issue or work item (GitHub Issue, Azure DevOps Work Item, or GitLab Issue — check platform in .hatch3r/hatch.json), follow these 8 steps in order:
Task Progress:
- [ ] Step 0: Detect ambiguity (P8 B1)
- [ ] Step 1: Parse the issue
- [ ] Step 2: Load the issue-type skill
- [ ] Step 3: Read relevant specs
- [ ] Step 4: Produce a plan
- [ ] Step 5: Implement
- [ ] Step 6: Test
- [ ] Step 6b: Browser verification (if UI)
- [ ] Step 7: Open PR
- [ ] Step 8: Address review
Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per agents/shared/user-question-protocol.md. Do not proceed under silent assumption. Default path, not an exception. This upgrades the existing Escalation block from exception to default. Triggers for THIS skill: issue type unclear (bug vs feature vs refactor), acceptance criteria missing or contradictory, scope boundary undefined, irreversible operation in path (schema change, public API rename), and target branch / merge policy ambiguous.
Navigate to the matching skill based on issue type:
| Issue Type | Skill |
|---|---|
| Bug report | hatch3r-bug-fix |
| Feature request | hatch3r-feature |
| Code refactor | hatch3r-refactor |
| Logical refactor | hatch3r-logical-refactor |
| Visual refactor | hatch3r-visual-refactor |
| QA E2E validation | hatch3r-qa-validation |
Load only the specs relevant to the issue area. See the spec mapping table in the project context rule.
Also check project ADRs for architectural constraints.
Output a structured plan before writing code:
Every issue MUST be delegated to a dedicated hatch3r-implementer sub-agent — never implement inline. The board-pickup command orchestrates this automatically; if running issue-workflow standalone, apply the pattern that matches your scenario:
| Scenario | Pattern |
|---|---|
| Single issue | Spawn one hatch3r-implementer sub-agent via the Task tool with issue number, body, acceptance criteria, issue type, researcher output, and spec references. Await result. |
| Epic with sub-issues | Load references/delegation-patterns.md — Pattern 2 |
| Batch of standalone issues | Load references/delegation-patterns.md — Pattern 3 |
| Plain chat with multiple tasks | Load references/delegation-patterns.md — Pattern 4 |
The implementer sub-agent protocol is defined in the hatch3r-implementer agent. Each sub-agent handles its own implementation and testing but does NOT create branches, commits, or PRs.
Skip this step if the issue has no user-facing UI changes.
board.defaultBranch from .hatch3r/hatch.json (fallback: "main").platform in .hatch3r/hatch.json):
gh pr create --base {defaultBranch} --head {branch} --title "..." --body "..."az repos pr create --source-branch {branch} --target-branch {defaultBranch} --title "..." --description "..."glab mr create --source-branch {branch} --target-branch {defaultBranch} --title "..." --description "..."Fan-out scales with task size; token cost never justifies serializing independent work (rules/hatch3r-fan-out-discipline.md P8 B2; agents/shared/efficiency-patterns.md). Tier boundaries for THIS skill:
Emit sub_agents_spawned: { count, rationale } in your output.
Stop and ask when:
npx claudepluginhub hatch3r/hatch3r --plugin hatch3rGenerates structured GitHub issues with TDD plans, acceptance criteria, and agent instructions for autonomous PR lifecycle management.
Investigates and resolves GitHub issues with systematic triage, root cause analysis, test-driven fixes, and pull request management. Use when given an issue ID or URL.
Resolves GitHub issues via 8-phase workflow: fetch details, analyze requirements, implement solutions, verify correctness, code review, commit changes, create PRs. Activates on resolve, implement, fix requests or issue references.