Iflow Issue

issue-flow — create a normal issue (/iflow-issue)

Follow this skill to author and create one well-specified GitHub issue (a single deliverable), then optionally set up the normal lifecycle (branch + /iflow-capture → hand off to /iflow-plan).

Do not use this skill from /iflow, /iflow-build, or /iflow-close. /iflow-issue is explicit-only because it creates GitHub issues (and optionally branches).

Coexists with:

• /iflow-pick fix — one-shot general-fixes chore bucket into plan/start.
• /iflow-fix — iterative small-fixes session that stays in a loop.
• /iflow-epic — staged multi-issue work; use /iflow-issue first when the epic anchor does not exist yet.
• /iflow-split — cut an existing over-large issue into linked children. Do not use /iflow-issue for that.

Input

• free text — seed for the issue title and/or short description (e.g. iflow issue add dry-run flag to doctor).
• epic (alone or as a leading token, e.g. epic Large rewrite) — epic-anchor mode: title prefixed with Epic:, and apply the epic label when it exists (gh label list).
• (nothing) — ask for a one-line intent before drafting.

Invoke: type iflow issue in chat, or /iflow-issue from the slash menu (iflow-issue also works).

MODEL & EXECUTION DIRECTIVE

Profile: reasoning — Prioritize deep thinking and careful trade-offs over speed or token economy.

In Cursor: switch to a thinking-capable model before invoking this step (not Auto-only).

Keep scope tight to what this step requires.

Resolve project root (multi-root workspaces)

Before any git, gh, or .issueflows/ path operation in this workflow:

Resolution order (stop when unambiguous):

1. Explicit hints in slash input — root:<path>, repo:<folder-basename> (directory name, e.g. cellpy-core), or repo:owner/name.
2. CLI fast path — issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]. Use the returned project_root and repo; pass -C <project_root> to other issue-flow agent … subcommands. When the answer came from the workspace registry, the payload sets resolved_via_workspace_default: true.
3. Branch context — exactly one workspace repo whose branch matches ^\d+- → that root.
4. Single scaffold — exactly one .issueflows/ tree visible in the workspace → that root.
5. Workspace default — an issueflow-workspace.toml at the workspace root (created with issue-flow workspace init) may name a default member repo; use it when no scaffold matched above. Tell the user the default was used.
6. Ambiguous → stop and ask; never guess between sibling repos.

After resolution, treat the result as <project_root> and <owner/repo>:

• Git: git -C <project_root> … (or issue-flow agent … -C <project_root> for supported ops).
• GitHub: pass an explicit repo on every gh call — never rely on gh's implicit cwd default. For most commands use --repo <owner/repo>; exception: gh repo view takes the repo as a positional arg (gh repo view <owner/repo> …) and rejects --repo.
• Paths: all .issueflows/… paths are under <project_root>.

When .issueflows/04-designs-and-guides/multi-repo-workspaces.md exists, read it for layout and cross-repo guidance.

Instructions

Phase 1 — draft and create

1. Preflight. Detect the default branch (gh repo view --json defaultBranchRef -q .defaultBranchRef.name; fall back to git symbolic-ref --quiet --short refs/remotes/origin/HEAD, else main). Run git fetch --prune. Report current branch + clean/dirty tree (git status --porcelain).
2. Parse input. If the first token is epic (case-insensitive), enable epic-anchor mode and treat the remainder as the seed. Bare epic with no remainder → ask for the epic intent.
3. Draft title + body. Propose a title and a body with this light structure (not a full /iflow-plan):
   • Problem / context
   • Spec (what to change)
   • Acceptance criteria
   • Out of scope (optional; omit the heading when empty) Refine with the user until they confirm the text. If the draft is clearly over-large for one PR, offer /iflow-split (flat parent/child) or /iflow-epic (staged) — do not auto-create sub-issues.
4. Create (confirm first). Show the final title and body (and, in epic-anchor mode, the planned epic label when present). On yes: gh issue create --repo <owner/repo> (add --label epic only when epic-anchor mode is on and gh label list shows epic). Capture number N. Set the chat tab title to Issue <N> <short title>. Optional labels/milestones other than the epic-anchor label: only if the user asked for them in this turn — do not invent them.