pac-to-issues

Files (2)

• SKILL.md
• skill.test.mjs

SKILL.md (first lines)

# pac-to-issues

Break a plan into independently-grabbable GitHub issues using vertical slices (tracer bullets).

## Process

### 1. Gather context

Reuse the conversation and already-read authoritative target/context. If the user passes a GitHub issue number or URL and its required body and metadata are not already available, start with a focused read:

```bash
gh issue view <number> --repo <owner/repo> --json number,title,body,state,labels,url
```

Note the issue number — it becomes the parent for all created sub-issues.

Before each additional read, identify the specific missing or ambiguous scope, constraint, acceptance criterion, or dependency it must resolve. Follow explicit links or pointers to governing PRDs, Decisions/ADRs, acceptance criteria, and known blockers when needed for the breakdown. Use targeted comment or linked-artifact reads to load and honor applicable requirements before finalizing slices; do not load the whole discussion by default. If a pointer is ambiguous, retrieve enough discussion to locate the governing comment rather than skipping it. If dependencies or acceptance criteria remain unresolved after targeted reads, ask the user rather than inventing them.

If the plan and governing context are complete, proceed directly to drafting slices without further issue or source reads.

If the input is a free-form plan or PRD with no parent issue, skip parent wiring steps.

### 2. Explore the codebase (optional)

Explore repository code only to answer a specific unresolved slicing, dependency, interface, or verification question. State the question first. Limit the search and reads to the relevant area, reuse existing findings, and stop once the question is answered. Being unfamiliar with the codebase alone is not a reason to explore.

### 3. Draft vertical slices

Break the plan into **tracer bullet** issues. Each slice is a thin vertical cut through ALL relevant layers end-to-end, not a horizontal layer (e.g. not "write all the tests" or "update all the schemas").

Classify each slice as **HITL** or **AFK**:

- **HITL** (Human In The Loop): requires a human decision, design review, or approval before work can proceed or be merged.
- **AFK** (Away From Keyboard): independently implementable without further human decisions or input.

AFK describes implementation readiness; it does not authorize push, merge, or other publication. Follow existing session authorization and repository restrictions for those operations. Reuse authorization already granted by the active workflow, including `/pac-lwot` delivery authorization, without adding a redundant approval checkpoint. A repository's user-only force-push rule remains user-only.

Prefer AFK over HITL where possible.

<vertical-slice-rules>
- Each slice delivers a narrow but complete path through every relevant layer
- A completed slice is demoable or verifiable on its own
- Prefer many thin slices over few thick ones
- Do not create horizontal slices (one layer at a time)
</vertical-slice-rules>

### 4. Quiz the user

Present the proposed breakdown as a numbered list. For each slice, show:

- **Title**: short descriptive name
- **Type**: HITL / AFK
- **Blocked by**: which other slices (if any) must complete first
- **Summary**: one sentence describing the end-to-end behavior

Ask the user:

- Does the granularity feel right? (too coarse / too fine)
- Are the dependency relationships correct?
- Should any slices be merged or split?
- Are the HITL / AFK classifications correct?

Iterate until the user approves the breakdown.

### 5. Create the GitHub issues

Create issues in **dependency order** — blockers first — so real issue numbers are available when writing `## Blocked by` in dependent issues.

For each approved slice:

#### 5a. Create the issue

```bash
gh issue create \
  --repo <owner/repo> \
  --title "<title>" \
  --body-file <temp-file>
```

Use the issue body template below.

Apply the `pac:hitl` or `pac:afk` label only if it already exists in the repository. Create the issue first, then add the label conditionally:

```bash
issue_url=$(gh issue create \
  --repo <owner/repo> \
  --title "<title>" \
  --body-file <temp-file>)

issue_number=${issue_url##*/}
label_name="pac:hitl"   # or "pac:afk"

if gh label list --repo <owner/repo> --json name --jq '.[].name' | grep -Fxq "$label_name"; then
  gh issue edit "$issue_number" --repo <owner/repo> --add-label "$label_name"
else
  echo "Warning: expected pac workflow label is missing: $label_name; run /pac-setup-workflows; skipping label"
fi
```

If the label does not exist, warn the user to run `/pac-setup-workflows` and skip it — do not fail the run.

#### 5b. Wire GraphQL relationships

After creating each issue, resolve its node ID:

```bash
gh issue view <number> --repo <owner/repo> --json id --jq .id
```

**Attach to parent** (if a parent issue exists):

```bash
gh api graphql \
  -f query='mutation($issueId:ID!, $subIssueId:ID!) {
    addSubIssue(input:{issueId:$issueId, subIssueId:$subIssueId}) {
      issue { number }
      subIssue { number }
    }
  }' \

From ladislas/mypac, MIT.

More from ladislas/mypac