Work on a GitHub issue by number for wp-media/wp-rocket. Fetches the issue and hands control to the orchestrator skill (running inline in this conversation), which manages grooming, spec review, implementation, lead review, CI, and QA end-to-end.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
Repository: wp-media/wp-rocket
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 .TemporaryItems/Issues/wp-rocket/issues/<N>.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 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 skill 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.TemporaryItems/Issues/wp-rocket/issues/<N>.md, base branch
The orchestrator skill 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.
Monitor progress at .TemporaryItems/Issues/wp-rocket/issue-<N>-workflow-log.html.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Adversarially review a grooming spec before implementation starts. Finds hidden risks, unvalidated assumptions, and missing dependencies. Standalone entry point for the challenger agent.
The English summary is being prepared. Showing the original description.
Check a change against WordPress.org plugin rules and PHPCS standards.
The English summary is being prepared. Showing the original description.
Update developer-facing documentation to reflect code changes on the current branch. Runs as an inline skill inside backend-agent and frontend-agent (step 2.5 of the internal sequence) after implementation and before DOD. Receives the explicit list of changed files from the implementation agent. No-op if no public API changes occurred.
The English summary is being prepared. Showing the original description.
Run the Definition of Done checklist for the current wp-rocket branch and report PASS/WARN/FAIL with evidence. Two modes: layer 1 (self-correction inside backend-agent / frontend-agent — resolves FAILs before handoff) and layer 2 (independent orchestrator gate — fresh perspective after handoff). Pass layer: "1" or layer: "2" when invoking.
The English summary is being prepared. Showing the original description.
Run a basic E2E behavioral probe — one primary scenario smoke test for the grooming step.
The English summary is being prepared. Showing the original description.
Groom a single GitHub issue — produce an implementation spec and optionally post the grooming summary as a GitHub comment. Standalone entry point for the grooming-agent.
The English summary is being prepared. Showing the original description.