| name | issue-flow |
| description | Use when a GitHub issue should be driven through clarification recovery, spec-build-test-QA-acceptance, and enforced human review gates with quality gates. |
| disable-model-invocation | true |
| allowed-tools | Read, Write, ApplyPatch, Grep, Glob, Bash, Question |
| argument-hint | [continue|status|issue <number-or-url>] |
Issue Flow
Purpose
Drive one GitHub issue through the full Harnessy delivery lifecycle using the repository's existing skills, mandatory evaluation gates, explicit human review checkpoints, and strategy-aware intake when a standard docs/strategy/ folder exists. GitHub Project metadata is optional enrichment, not a required intake dependency.
Inputs
-
Optional arguments: continue, status, or issue <number-or-url>
-
Template paths are resolved from ${AGENTS_SKILLS_ROOT}/issue-flow/.
Steps
- Follow the command specification in
${AGENTS_SKILLS_ROOT}/issue-flow/commands/issue-flow.md exactly.
- Use existing child skills rather than replacing them.
- Run each new issue cycle in the canonical project-container worktree root
projects/<project-name>/worktrees/<issue_id>_<friendly_name> when viewed from the container, or ../worktrees/<issue_id>_<friendly_name> when invoked from projects/<project-name>/dev/, derived at runtime via ${AGENTS_SKILLS_ROOT}/issue-flow/scripts/issue_flow_git.py.
- Persist and reconcile progress through
${SPEC_ROOT}/<epic>/.issue-flow-state.json using portable git metadata only; never store machine-specific absolute worktree paths in tracked state.
- Do not advance phases when a required quality gate or human gate is unresolved.
Output
- A phase-by-phase issue delivery run with artifacts, evidence, gate results, and GitHub status updates.
