guided-issue-filing

name	guided-issue-filing
description	File or reconcile one or more GitHub issues from Work Type templates through one complete Issue Plan, with clarifying questions, native parent and blocker routing, evidence-backed acceptance criteria, and agent attribution. Use when the user says 'file an issue', 'open a bug', 'log a feature', 'track this task', 'turn these findings into issues', or runs a /github-coordination:file-*-issue or /github-coordination:to-issues command.
user-invocable	true

Guided Issue Filing

This is the single filing flow behind every Work Type command and the batch `/github-coordination:to-issues` command. GitHub is the authoritative coordination record. One Issue Plan expresses the complete result; callers do not assemble issue writes or relationship updates step by step.

Confirm the repository and writer

Resolve the repository and verify the bot writer before drafting:

gh repo view --json nameWithOwner -q .nameWithOwner
jakuta-agent-issue doctor --repo OWNER/REPO

If the repository cannot be resolved or GitHub auth is unavailable, stop with that blocker. If the CLI is missing, repair it through the dotfiles jakuta_agent_issue_cli step. If doctor reports missing generated credentials, repair the dotfiles machine environment and reopen the shell. If the GitHub App is not installed or lacks issue write permission, surface that repository blocker. All issue writes must remain on the bot-authored plan path.

Draft the complete issue set

For each requested issue, resolve and read its Work Type template:

node .pi/skill-assets/github-coordination/lib/resolve-template.js <work-type>

A committed repository override at .github-coordination/templates/<work-type>.md wins over the bundled template. Fill every field supported by the user's input. Ask one grouped question only when a required fact, Work Type, scope boundary, or routing choice remains truly ambiguous. A batch gets one grouped clarification pass, not one interview per issue.

Keep each acceptance criterion concrete and leave its evidence slot empty at filing time. Append the Agent Attribution Marker exactly once:

node -e "process.stdout.write(require('.pi/skill-assets/github-coordination/lib/attribution.js').AGENT_ATTRIBUTION_MARKER)"

Write each finished body to a separate file beside the plan file.

Route through GitHub's native graph

Read open parent candidates and relevant existing issue relationships before building the plan:

gh issue list --state open --label parent --json number,title

If exactly one parent owns an issue, select it. If several plausibly own it, ask once with the candidates and a standalone choice. Never invent a parent. A parent Work Type is a root. Capture dependencies the user named as native blocked_by relationships. Do not copy parents, children, or blockers into issue-body fields or checklists.

Apply one complete plan

Read `.pi/skill-assets/github-coordination/references/issue-plan.md` and build one Issue Plan covering the whole request. A single-file command produces a one-issue plan; a batch produces one multi-issue plan. Include the full desired labels: the Work Type label for every issue and `parent` for a parent Work Type.

Submit the plan exactly once:

jakuta-agent-issue apply-plan --repo OWNER/REPO --plan-file <plan.json>

Use stable issue keys so rerunning the same plan reconciles the same records. Read the structured result and report every issue URL, Work Type, native parent or standalone status, and blocker set in one final block.

Boundary

Keep branch creation, commits, pushes, and worktrees in `github-workflow`. If the user also asks to start implementation, hand the filed issue set to that workflow after this plan succeeds.