executing-github-task（executing GitHub task 开发）

Executing GitHub Task

This skill is the per-task execution orchestrator for the GitHub workflow. It does exactly three things: validate that the selected task is ready, dispatch the right specialist for each phase, and decide whether to advance, run a targeted fix cycle, or escalate.

Execution kickoff is the first point at which the workflow may mutate GitHub issue state or otherwise cross from critique-only work into active execution. Everything before kickoff remains critique and planning on disk; kickoff is the first execution mutation boundary after the user approves implementation. The orchestrator running this skill keeps only concise summaries in memory; subagents do the heavy work in isolation.

Inputs

Required artifacts

Read ./references/contracts.md when validating task readiness or artifact shape.

Workflow Overview

These are the execution skill's ordered internal stages. Read ./references/pipeline.md for the full run -> check -> fix -> re-check order and ./references/contracts.md for readiness and handoff contracts.

Requirements gaps are resolved after internal step 4 and before internal step 5. Quality-gate fix cycles happen after internal step 5.

Subagent Registry

Use this registry as a lookup table. Read exactly one subagent definition per dispatch, then pass only the inputs that subagent needs.

How This Skill Works

The orchestrator uses direct reads only to load this skill, the reference file for the current phase, and the specific subagent it is about to dispatch. Everything else is delegated. Pass file paths and short summaries between subagents instead of raw file contents or command output.

In practice, the orchestrator does only three kinds of work directly: load the current instructions, dispatch the next specialist, and carry forward the smallest summary needed for the next decision. Execution, mutation, analysis, and artifact updates stay inside the specialist subagents.

Every task run follows the same validation loop: confirm readiness, cross the kickoff mutation boundary deliberately after critique approval, verify Definition of Done coverage before the review gates, and re-run only the failing phase when a targeted fix is needed.

Treat artifacts in two categories:

• Category A: docs/<ISSUE_SLUG>*.md, progress files, briefs, plans, test specs, refactoring plans, critique, and decisions. Stay on disk, never committed, never deleted.
• Category B: source code, tests, config, in-code documentation. Committed normally.

If a selected task is already complete, blocked by unmet prerequisites, or produces a repeated unresolved blocker, stop and report that state instead of forcing the pipeline forward.

Output Contract

After a successful run, this skill leaves behind these deliverables:

• Category B implementation artifacts: committed source code, tests, config changes, and in-code documentation.
• Category A orchestration artifacts: updated on disk but left uncommitted, including task status, implementation summary, file list, and optional GitHub tracking updates recorded in the plan.
• Kickoff summary: a returned KICKOFF_REPORT covering readiness, workspace state, and GitHub kickoff actions (or documented skips).
• Task-only completion report: a concise user-facing report summarising the selected task's execution, commits, and gate verdicts.

Phase Guide

Execution Steps

1. Read ./references/contracts.md and confirm the task is ready to cross the execution boundary.
2. Read ./references/pipeline.md and follow its normal run order exactly.
3. Dispatch only the next required subagent, passing explicit inputs and keeping only structured summaries in orchestration context.
4. When a blocker, missing prerequisite, or failing gate appears, read the relevant recovery reference from ## Phase Guide and run only the targeted retry or escalation path.
5. Report the selected task's outcome once the pipeline finishes or stops. Do not auto-continue to the next task.

Operating Constraints

• Execute one task per invocation, then stop and wait for a new invocation for the next task.
• Keep the task plan as the source of truth. If execution reveals a plan change is needed, escalate instead of silently rewriting the plan.
• Preserve Category A artifacts on disk and out of git history.
• Keep fix cycles targeted. Re-run only the failing verification or review steps, not the entire pipeline.
• Treat missing required skills, missing tracker capability, or unresolved ambiguity as orchestration decisions. Surface them clearly and stop.

Example

Input:

• ISSUE_SLUG=acme-app-42
• TASK_NUMBER=3

1. Validate the required per-task artifacts exist; Task 3 is not already complete.
2. Dispatch execution-starter for kickoff (first gh mutations after critique).

- KICKOFF_REPORT -> READY

1. Dispatch task-executor with artifact paths under docs/acme-app-42-task-3-*.md.

- EXECUTION_REPORT -> COMPLETE

1. Dispatch documentation-writer with EXECUTION_REPORT, ISSUE_SLUG, TASK_NUMBER.
2. Dispatch requirements-verifier.

- VERIFICATION_RESULT -> PASS

1. Run clean-code-reviewer, then architecture-reviewer, then security-auditor.

- All gates return a pass variant

1. Report kickoff outcome, final verdicts, commits, files changed, and any skipped GitHub updates.

Input:

• ISSUE_SLUG=acme-app-42
• TASK_NUMBER=3

1. execution-starter returns READY.
2. task-executor returns COMPLETE.
3. documentation-writer returns COMPLETE.
4. requirements-verifier returns FAIL because one DoD item is untested.
5. Re-dispatch task-executor with only the verifier gap summary.
6. Re-dispatch documentation-writer for the new Category B delta.
7. Re-run requirements-verifier.

- VERIFICATION_RESULT -> PASS

1. Continue into the review gates, and if one gate returns NEEDS FIXES, re-run only that gate's targeted fix cycle instead of the whole pipeline.