// Break a PRD into native GitHub sub-issues attached to the parent PRD. Project-local variant of /to-issues, adapted for this repo's PRD-as-parent + native sub-issues + agent:implement multi-session workflow. Argument is the parent PRD issue number.
Optimize slow React Router loaders by eliminating redundant DB queries, creating slim query variants, and parallelizing independent fetches. Use proactively when writing or reviewing loader code that calls DBFunctionsService, or when triaging a slow page load.
Survey the codebase, pick ONE high-leverage deepening opportunity (filtering out anything already proposed), and publish it as a PRD-shaped GitHub issue via /to-prd-project. Designed to run unattended in the daily architecture-review workflow.
Turn the current conversation context into a PRD and publish it as a GitHub issue that is ready to receive sub-issues from /to-issues-project. Project-local variant of /to-prd, adapted for this repo's PRD-as-parent-issue + sub-issues + agent:implement workflow.
Generate or update documentation for the AI Hero API by reading the source code at ~/repos/ai/course-builder. Use when user wants to document, update docs for, or understand the AI Hero API endpoints.
Install @effect/* packages safely. Use whenever adding a new Effect ecosystem dependency.
End-to-end implementation workflow. Use when user wants to implement a feature, fix a bug, or make changes and have everything validated and committed.
| name | to-issues-project |
| description | Break a PRD into native GitHub sub-issues attached to the parent PRD. Project-local variant of /to-issues, adapted for this repo's PRD-as-parent + native sub-issues + agent:implement multi-session workflow. Argument is the parent PRD issue number. |
Break a parent PRD into a flat list of native GitHub sub-issues, in execution order. Each sub-issue is a tracer-bullet vertical slice that the PRD-mode agent:implement workflow will pick up one at a time.
gh issue view <PRD_NUMBER> --comments
Read the body carefully. The PRD is the spec. Don't add scope; don't redesign. If the PRD is ambiguous, ask the user to clarify before drafting slices — the slices should reflect the PRD as-is, not your interpretation.
gh api repos/$GH_REPO/issues/<PRD_NUMBER>/sub_issues --jq 'length'
If non-zero, stop and ask the user whether to (a) abort, (b) add more on top of what's there, or (c) close/delete the existing ones first. Don't silently double up.
If you haven't already, explore the repo to understand the area you're touching. Use the project's domain glossary (CONTEXT.md) and respect ADRs under docs/adr/. Sub-issue titles and bodies should use the project's vocabulary.
Break the PRD into tracer-bullet sub-issues. Each slice is a thin vertical cut through every layer (schema → API → UI → tests), NOT a horizontal slice of one layer.
- Each slice delivers a narrow but COMPLETE path through every layer - A completed slice is demoable or verifiable on its own - Prefer many thin slices over few thick ones - Sub-issues are **flat** — a sub-issue must not itself need sub-issues. If a slice is too big to leaf, split it into multiple peer slices instead of nesting - Sub-issues run in **list order** under the PRD. Order them so dependencies are satisfied: if slice B builds on slice A's schema, A must come firstThe PRD-mode workflow implements sub-issues one at a time, each in its own agent session, committing to a shared branch. Keep that in mind:
Present the proposed breakdown as a numbered list. For each slice, show:
Ask:
Iterate until the user approves.
Publish in order. For each slice:
Create the issue:
gh issue create --title "<title>" --body "$(cat <<'EOF'
<body — see template>
EOF
)"
This prints the new issue URL. Capture the issue number.
Get its node ID (needed by the sub-issues API):
gh api repos/$GH_REPO/issues/<sub_issue_number> --jq '.id'
The .id field is the REST integer ID. Save it.
Attach as sub-issue of the PRD:
gh api -X POST "repos/$GH_REPO/issues/<PRD_NUMBER>/sub_issues" \
-f sub_issue_id=<sub_issue_id>
This is the native sub-issues link — it shows up in the PRD's progress bar and is what the agent-implement-prd.yml workflow reads.
Do not apply agent:implement to the sub-issues — they're never labeled directly. The user (or you, if asked) adds agent:implement to the PRD when ready to start work.
#<PRD_NUMBER>
A concise description of this slice's end-to-end behavior. One to three short paragraphs. Frame it around what the slice delivers, not which files change.
Avoid specific file paths or code snippets — they go stale fast.
Exception: a prototype-derived snippet (state machine, reducer, schema, type shape) may be inlined when prose can't encode the decision as precisely. Trim to the decision-rich parts.
If this slice builds on an earlier sub-issue's work, name it (e.g. "Sub-issue #N — <title>"). If not, omit this section.
The body intentionally does NOT include a Closes directive. Closing this sub-issue is the PRD-mode workflow's job (it closes the sub-issue at the end of its implementation run). Closing the PRD itself happens when the bundled PR merges via Closes #<PRD> in the PR description.
agent:implement to PRD #<N> when ready. The workflow will implement sub-issues in order, accumulating commits on a single agent/prd-<N>-... branch, and open a draft PR after the first sub-issue."PATCH /repos/{owner}/{repo}/issues/{issue_number}/sub_issues/priority endpoint.