# gh-task-creator

> 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.

- Author: Mark
- Repository: markashton480/sum_platform
- Version: 20260206154756
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-07
- Source: https://github.com/markashton480/sum_platform
- Web: https://mule.run/skillshub/@@markashton480/sum_platform~gh-task-creator:20260206154756

---

---
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:

```bash
python 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)