Menu
Fetch a GitHub issue and run the full grooming → implementation → review → QA pipeline.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run the Definition of Done checklist for the current branch — PASS/WARN/FAIL with evidence.
Start a full delivery run from a GitHub issue number, URL, or raw description.
Adversarially review a grooming spec before implementation starts. Finds hidden risks, unvalidated assumptions, and missing dependencies. Standalone entry point for the challenger agent.
Check a change against WordPress.org plugin rules and PHPCS standards.
Update developer-facing documentation to reflect code changes on the current branch.
Run E2E smoke tests (basic) or full acceptance + regression suite (extended).
| name | issue-workflow |
| description | Fetch a GitHub issue and run the full grooming → implementation → review → QA pipeline. |
The following values are injected via the orchestrator prompt — do not read any config file:
{TEMP_ROOT} = .ai{REPO} = wp-media/imagify-plugin{SLUG} = imagify{E2E_URL} = http://localhost:8888{E2E_BOOT} = bash bin/dev-start.shRepository: wp-media/imagify-plugin
When the user asks to work on an issue by number, such as:
/task 123issue 123#123follow this workflow. The orchestrator runs inline in this conversation — read the user's opening message before kicking it off, since it uses that for escalation calibration (high autonomy / standard / high oversight).
Use shell commands as the primary approach. The GitHub MCP (mcp_github_*) may be used if it is connected — but shell is always the safe fallback and is preferred for reliability.
| Operation | Shell (primary) | GitHub MCP (if connected) |
|---|---|---|
| Issue fetch | bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N> | mcp_github_github_issue_read |
| Branch creation | bash .claude/skills/issue-workflow/scripts/make-issue-branch.sh | — |
| Staging & committing | git add / git commit | — |
| Pushing | git push -u origin <branch> | — |
| PR creation | gh pr create | mcp_github_github_create_pull_request |
| CI monitoring | gh pr checks <PR#> | mcp_github_github_pull_request_read |
Extract the issue number from the user's message.
Fetch the issue — run bash .claude/skills/issue-workflow/scripts/issue-sync.sh <N> (or use the MCP equivalent). Read the resulting file at .ai/issues/<N>/issue.md.
Check for parent epics — if Parent Epic (GitHub) or Parent Epics (Task List) has entries, sync each parent with issue-sync.sh <epic-N> and read those files at .ai/issues/<epic-N>/issue.md for context.
Check if this is an Epic — if the issue has label epics, Issue Type EPIC, or has sub-issues listed, ask the user: "Work the epic as a whole, or a specific sub-issue?" If a sub-issue is chosen, sync it and proceed with the epic context in mind.
Determine base branch — default is origin/develop unless the user specified otherwise.
Invoke the orchestrator command inline (do not spawn it as a sub-agent — it runs in this conversation context so it can read the user's intent for escalation calibration):
Inputs: issue number
N, issue file.ai/issues/<N>/issue.md, base branch
The orchestrator command manages everything from here: calibration → grooming → spec review → dispatch → implementation → lead review → push & PR → CI → QA → finalize. It spawns the specialist agents (grooming-agent, challenger, backend-agent, frontend-agent, release-agent, lead-reviewer, qa-engineer, ticket-writer) as isolated sub-agents, but the orchestrator itself stays inline so it can surface decisions back to the user naturally.
Track progress in context; an HTML log is written at .ai/issues/<N>/workflow-log.html only if the Podium plugin is enabled (see orchestrator Run log section).