---

name: gh-task-creator description: Create AI-executable TASK/FIX GitHub issue bodies (and optionally create/link them as sub-issues) for SUM Platform work orders. Use when converting a WO/idea/report into a deterministic task ticket that an agent can execute without guessing, and when you want a “wording approval → create issue” workflow.

gh-task-creator

Overview

Turn a WO/idea/report into a high-quality TASK/FIX ticket that functions as the implementer agent’s primary prompt, then (only after approval) create it as a sub-issue under the WO.

Workflow (Author → Approve → Create)

0) Inputs to request (if missing)

• Parent WO issue number (required).
• Task ID (required): <WO-CODE>-<seq> (e.g. HEALTH-11).
• The “source” to implement (required): an idea, PR feedback, or a concrete artifact (e.g. docs/dev/reports/...).
• Desired PR target (required): usually the WO feature branch.

1) Load only the load-bearing context

• Read the repo’s task ticket shape: .github/ISSUE_TEMPLATE/task-template.md.
• Read the parent WO issue body (and the referenced VD if needed).
• Read only the concrete artifact(s) the task is based on (report, PR comment, etc.).

2) Draft a ticket that is executable (not “human nice”)

• Objective must describe the end state to achieve, not constraints, not methods.
• Include “why/impact”, “change surface”, and explicit boundaries.
• Add an “Assumptions & Decision Policy” section (allowed assumptions, must-ask questions, smallest-change rule).
• Test Strategy must describe what good tests look like and include targeted local commands (or explicitly mark CI-only).
• The ticket must contain any critical constraints inside the body (linking to policy is allowed, but not as the only instruction).

2.5) Apply Planning Markdown Conventions

When authoring planning markdown (before GitHub issues exist):

• Replace template placeholders with #TBD:

  • Template says: Part of: #NNN → Use: Part of: #TBD
  • Template says: Closes #NNN → Use: Closes #TBD
  • Any other issue number references → Use: #TBD

• Why: Planning markdown is created in Stage 3 (before issues exist). The template assumes the issue already exists, but we're authoring the SSOT first. Real issue numbers get backfilled after issue creation (see PROJECT-PLANNING-GUIDELINES.md for stage numbers per flow).

• When NOT to use #TBD:

  • When referencing an existing parent WO/VD that already has an issue number
  • When doing retroactive planning for issues that already exist (use the real issue numbers)

3) Quality Gate (RCI)

Before finalizing, critique the draft for:

• Missing inputs that would force guessing (branch base/target, paths, contracts, expected behavior).
• Vague acceptance criteria (“remove warnings”, “improve”, “fix”) without stating the intended end state.
• Hidden policy (“follow X doc”) without in-ticket summary of the relevant rule/decision.
• Test strategy that’s only “commands” (no explanation of what good tests validate).

Revise once after the critique.

4) Output rules (chat vs issue body)

• Save the full ticket body to a file for issue creation. Use workspace-local path (e.g., tmp/task.md) to avoid permission issues with /tmp/.
• In chat, provide a concise approval summary and confirm the full body is ready.
• Only paste the full ticket body if the user explicitly asks to see it.
• Do not paste any template author guidance / HTML comments into the issue body.

5) Create the GitHub issue (only after approval)

Only create the issue if the user explicitly approves the wording (e.g. “approved, create it”).

Use the helper script to avoid shell-escaping pitfalls:

Copypython docs/dev/agents/skills/gh-task-creator/scripts/create_sub_issue.py \
  --parent <WO_NUMBER> \
  --title "TASK: <title>" \
  --label type:task \
  --body-file tmp/task.md

References

• references/task-ticket-authoring-guidelines.md (authoring process + RCI gate)