issue-flow 0.4.3.post3__tar.gz → 0.4.4__tar.gz

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: issue-flow
-Version: 0.4.3.post3
+Version: 0.4.4
 Summary: Agents should behave. Let them follow the issue flow.
 Keywords: cursor,ai,agents,issue-tracking,workflow
 Author: jepegit

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "issue-flow"
-version = "0.4.3.post3"
+version = "0.4.4"
 description = "Agents should behave. Let them follow the issue flow."
 readme = "README.md"
 license = "MIT"

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/agent.py

@@ -1395,6 +1395,11 @@ def run_status(project_root: Path, console: Console, local: bool, as_json: bool)
     ]
     solved_numbers = sorted(tracking.group_issue_files(folders["solved"]))
 
+    # An in-flight /iflow-cycle leaves a cycle_status.md in current-issues; a
+    # finished one is archived to solved/, so its presence here means a batch
+    # run is paused or active.
+    cycle_active = (folders["current"] / "cycle_status.md").is_file()
+
     github: dict[str, Any] | None = None
     if not local:
         github = _github_section(project_root, folders)
@@ -1406,6 +1411,7 @@ def run_status(project_root: Path, console: Console, local: bool, as_json: bool)
         "parked": parked,
         "solved_count": len(solved_numbers),
         "solved_recent": solved_numbers[-5:],
+        "cycle_active": cycle_active,
         "github": github,
     }
 
@@ -1485,6 +1491,12 @@ def _render_status_text(
 
     console.print(f"[bold]Solved[/bold]: {payload['solved_count']}")
 
+    if payload.get("cycle_active"):
+        console.print(
+            "[bold]Cycle[/bold]: [yellow]in-flight[/yellow] "
+            "(cycle_status.md present — resume with `/iflow-cycle resume`)"
+        )
+
     github = payload["github"]
     summary_github = ""
     if github is None:

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/commands/iflow-cleanup.md.j2

@@ -47,6 +47,10 @@ Optional free-form text after the command. Examples:
    - For each group whose status file contains `- [x] Done` (case-insensitive on `done`), move the group to `{{ issueflows_dir }}/{{ solved_folder }}/`.
    - Groups without a checked `Done` stay put — do not route them to `{{ issueflows_dir }}/{{ partly_solved_folder }}/` from `/iflow-cleanup`. That is `/iflow-pause`'s job and requires a human decision.
 
+6. **Epic stage gate (offer only).**
+   - If the just-merged issue's number appears in a `- Published: #<N>` line of an `epic<M>_plan.md` under `{{ issueflows_dir }}/{{ epics_folder }}/`, it belongs to an epic. Run `issue-flow agent epic-status <M> --json`; if the issue's stage now has no open issues left, the stage just completed.
+   - On a completed stage, **offer** (never automatic): (a) post a short stage-summary comment on the epic anchor issue, and (b) run `/iflow-epic <M> publish` to publish the next stage. Publishing and commenting stay the user's explicit call.
+
 ## Output
 
 Report:

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/commands/iflow-cycle.md.j2

@@ -11,6 +11,9 @@ Use only when every queued issue is genuinely yolo-fit (small, low-risk, well-sp
 ## Input — queue spec
 
 - **explicit numbers** (`12 15 18`), **`label:<L>`**, or **`epic <N> [stage <k>]`**.
+- **`resume`** — pick up an interrupted cycle from `cycle_status.md`.
+- **`onfail:stop`** (default) / **`onfail:skip`** — failure policy.
+- **`parallel:<n>`** — experimental, opt-in: run provably **independent** issues concurrently when the harness supports it (see the skill's *Parallel dispatch* section and `{{ issueflows_dir }}/{{ designs_folder }}/parallel-cycle.md`). Sequential is the default; refused when the harness can't confirm background execution.
 - **`max:<n>`** — raise the safety cap (default 10) for this run.
 - **`stay`** — forward `stay` to each close (rarely wanted in a cycle).
 
@@ -20,11 +23,15 @@ The full playbook lives in `{{ agent_dir }}/skills/iflow-cycle/SKILL.md` — fol
 
 1. **Resolve the queue** with `issue-flow agent queue <spec> --json` (ordered queue + blocked + skipped_closed; a reported dependency `cycle` stops the run).
 2. **Cap check**: refuse a queue longer than 10 without `max:<n>`.
-3. **One consolidated confirm**: the ordered queue, skipped/blocked issues, that each PR is auto-merged, and the stop-on-first-failure policy. Explicit yes required.
-4. **Per-issue loop**: from a clean default branch, follow `{{ agent_dir }}/skills/iflow-yolo/SKILL.md` verbatim for each issue (its safeguards stay in force; the batch confirm satisfies its per-issue confirm).
-5. **Strictly-necessary-input rule**: stop and ask only for unfixable failures, refused merges / non-fast-forward pulls, ambiguous or not-actually-small specs, or anything outside the confirmed queue. Everything else proceeds.
-6. **Failure policy (default: stop)**: halt on the first stop condition, leave the repo clean on the default branch, report progress.
-7. **Batch report**: per-issue outcome, skipped/blocked, stop reason + not-reached; remind the user to run `/iflow-cleanup` once.
+3. **One consolidated confirm**: the ordered queue, skipped/blocked issues, that each PR is auto-merged, and the `onfail` policy. Explicit yes required.
+4. **Write `cycle_status.md`** under `{{ issueflows_dir }}/{{ current_issues_folder }}/`: queue spec, `onfail` policy, timestamp, and the ordered queue as a checklist. Update it as the loop progresses (it makes the run resumable and visible to `/iflow-status`; the folder sweep ignores it).
+5. **Per-issue loop**: from a clean default branch, follow `{{ agent_dir }}/skills/iflow-yolo/SKILL.md` verbatim for each issue (safeguards stay in force; the batch confirm satisfies its per-issue confirm), recording each outcome in `cycle_status.md`.
+6. **Strictly-necessary-input rule**: stop and ask only for unfixable failures, refused merges / non-fast-forward pulls, ambiguous or not-actually-small specs, or anything outside the confirmed queue. Everything else proceeds.
+7. **Failure policy**: `onfail:stop` (default) halts the cycle clean on the default branch; `onfail:skip` parks the failed issue (pause conventions) and continues.
+8. **Finish**: mark `cycle_status.md` done and move it to `{{ solved_folder }}/cycle_status_<date>.md`.
+9. **Batch report**: per-issue outcome, skipped/blocked, stop reason + not-reached; remind the user to run `/iflow-cleanup` once.
+
+**Resume** (`/iflow-cycle resume`): read `cycle_status.md`, re-verify the remaining issues with `issue-flow agent queue` (state can move while paused), and continue **without** re-asking the original confirm for unchanged items.
 
 ## Constraints
 

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/commands/iflow-pick.md.j2

@@ -28,9 +28,11 @@ Optional free-form text after the command:
 
 2. **Source the candidates** (in precedence order):
    - **Parked work first.** If `{{ issueflows_dir }}/{{ partly_solved_folder }}/` contains any `issue<n>_*` groups, list them as the **primary** candidates — these are already-started issues that deserve to be finished before new work begins. Show issue number, title (from each `issue<n>_original.md`), and a one-line status if a status file exists.
+   - **Active epic next.** If an epic plan under `{{ issueflows_dir }}/{{ epics_folder }}/` has open issues (or the user named one, e.g. `epic 144`), prefer its **current stage's unblocked issues**. Fast path: `issue-flow agent epic-status <N> --json` — its `next_candidates` are exactly the open, dependency-satisfied issues of the current stage. Surface those near the top so the epic advances stage by stage instead of stalling.
    - **Otherwise, pull from GitHub.** Run `gh issue list --state open --json number,title,labels,milestone,updatedAt` (add `--repo owner/repo` if the default remote is ambiguous). Drop any issue already captured locally under `{{ issueflows_dir }}/{{ current_issues_folder }}/`, `{{ partly_solved_folder }}/`, or `{{ solved_folder }}/`.
 
 3. **Rank by relevance and present a shortlist.** Rank candidates using, in combination:
+   - **Epic membership** — an active epic's current-stage `next_candidates` first (note the epic + stage on those entries).
    - **Milestone** — prefer issues on the nearest / active milestone (and honour any milestone hint in the input).
    - **Labels** — prefer labels that match recent work or any label hint in the input.
    - **Topical similarity** — bias toward issues whose title/labels resemble recently solved issues (skim `{{ issueflows_dir }}/{{ solved_folder }}/` and recent branch names) so related work clusters together.

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/skills/iflow_cleanup/SKILL.md.j2

@@ -35,7 +35,9 @@ Follow this skill to **run post-merge branch hygiene** after a PR has been merge
 
 5. **Optional folder sweep** (safe; no destructive git). In `{{ issueflows_dir }}/{{ current_issues_folder }}/`, for each `issue<N>_*` group whose status file contains `- [x] Done` (case-insensitive on `done`), move the group to `{{ issueflows_dir }}/{{ solved_folder }}/`. Leave groups without a checked `Done` in place — routing them to `{{ issueflows_dir }}/{{ partly_solved_folder }}/` is `/iflow-pause`'s job.
 
-6. **Report.** Summarize: default branch, PR/merge status, commands run, branches deleted, branches skipped (with reason), folder sweep result. If `issue-flow agent resolve --json` reports `sibling_roots`, list them and remind the user that **each scaffolded repo needs its own `/iflow-cleanup`** — do not loop automatically in this step.
+6. **Epic stage gate (offer only).** If the just-merged issue belongs to an epic — its number appears in a `- Published: #<N>` line of an `epic<M>_plan.md` under `{{ issueflows_dir }}/{{ epics_folder }}/` — check whether that closed the stage: run `issue-flow agent epic-status <M> --json` and see if the issue's stage now has no open issues left. If the stage just completed, **offer** (do not do automatically) to (a) post a short stage-summary comment on the epic anchor issue and (b) run `/iflow-epic <M> publish` to publish the next stage. Both are the user's explicit call — never auto-publish or auto-comment.
+
+7. **Report.** Summarize: default branch, PR/merge status, commands run, branches deleted, branches skipped (with reason), folder sweep result, and any epic stage-gate offer. If `issue-flow agent resolve --json` reports `sibling_roots`, list them and remind the user that **each scaffolded repo needs its own `/iflow-cleanup`** — do not loop automatically in this step.
 
 ## Constraints
 

issue_flow-0.4.4/src/issue_flow/templates/skills/iflow_cycle/SKILL.md.j2

@@ -0,0 +1,95 @@
+---
+name: iflow-cycle
+description: >-
+  Process many issues hands-off in a row: resolve a queue, then run each
+  through the yolo chain under one up-front confirm. Stops only when input is
+  strictly necessary.
+disable-model-invocation: true
+---
+
+# issue-flow — issue cycle (`/iflow-cycle`)
+
+Follow this skill to **process a queue of issues hands-off**, one after another, with a **single up-front confirmation** — the batch equivalent of `/iflow-yolo`. Each issue runs the full yolo chain (`init → plan → start → close yolo`, PR auto-merged, switch back to default); the cycle interrupts you only when input is **strictly necessary**.{% if commands_supported %} Matches `{{ agent_dir }}/{{ commands_dir }}/iflow-cycle.md`.{% endif %}
+
+Use only when every queued issue is genuinely yolo-fit (small, low-risk, well-specified, test-guarded). A queue of risky changes belongs in the individual commands.
+
+## Input — queue spec
+
+- **explicit numbers** — e.g. `12 15 18`.
+- **`label:<L>`** — every open issue carrying label `<L>`.
+- **`epic <N> [stage <k>]`** — the current stage of epic `<N>` (or stage `<k>`).
+- **`resume`** — pick up an interrupted cycle from its state file (see **Resuming** below).
+- **`onfail:stop`** (default) / **`onfail:skip`** — failure policy (see step 7).
+- **`max:<n>`** — raise the safety cap (default 10) for this run.
+- **`stay`** — forward `stay` to each close so the working copy stays on each issue branch (rarely wanted in a cycle).
+
+{% set iflow_step = "cycle" %}
+{% include "skills/_invocation_forms.md.j2" %}
+
+{% include "skills/_model_directive.md.j2" %}
+
+{% include "skills/_resolve_project_root.md.j2" %}
+## Instructions
+
+1. **Resolve the queue.** Run `issue-flow agent queue <spec> --json` (numbers, `--label`, or `--epic`). Use its `queue` (ordered), `blocked`, and `skipped_closed` output as the source of truth — do not re-derive the order by hand. If it reports a dependency `cycle`, **stop** and show it; nothing runs. If the CLI is unavailable, fall back to reading the issues and ordering by `Depends on #N` lines yourself, but prefer the CLI.
+
+2. **Cap check.** If the ordered queue is longer than **10** and the input did not pass `max:<n>` raising the limit, **stop** and ask the user to confirm a larger run explicitly. Long unattended runs compound risk.
+
+3. **One consolidated confirm** (the only planned interruption). Present, in normal prose:
+   - the **ordered** queue (numbers + titles), and which issues are **skipped** (closed) or **blocked** (open dependency outside the queue) with the reason;
+   - that each issue runs the **full yolo chain** and its PR is **auto-merged**;
+   - the failure policy (`onfail:stop`, the default, or `onfail:skip` — see step 7);
+   - the default-branch preflight that must hold before starting (clean tree, tests passing).
+   Require an explicit yes; anything else aborts before any work.
+
+4. **Write the cycle state file.** After the confirm, write `{{ issueflows_dir }}/{{ current_issues_folder }}/cycle_status.md` — the durable record that makes the run resumable and visible to `/iflow-status`. Include: the queue spec, the `onfail` policy, an ISO timestamp, and the ordered queue as a checklist with one line per issue (`- [ ] #<N> — <title> — pending`). Update this file as the loop progresses (see step 5); it is a normal tracking file (not an `issue<N>_*` group), so the folder sweep never touches it.
+
+5. **Per-issue loop.** For each issue in order, from a clean default branch:
+   - mark it `in-progress` in `cycle_status.md`, then create/switch to its `<N>-<slug>` branch and follow `{{ agent_dir }}/skills/iflow-yolo/SKILL.md` **verbatim** — including its own preflight (refuse on default branch, refuse with dirty unrelated changes, tests pass up front) and its consolidated-confirm step, which the up-front batch confirm in step 3 satisfies (do not re-ask per issue).
+   - after the yolo close merges and switches back to the default branch, record the outcome in `cycle_status.md` (`- [x] #<N> — <title> — merged <PR-url>`) and continue to the next issue.
+   - Every yolo safeguard stays in force. A safeguard that trips is a **stop condition** (step 6), never a guard to skip.
+
+6. **Strictly-necessary-input rule.** Between issues the cycle runs unattended. **Stop and ask only** when:
+   a. tests or lint fail in a way you cannot fix within the current issue's scope;
+   b. a merge is refused or a `git pull --ff-only` will not fast-forward (divergence);
+   c. the issue spec is ambiguous, contradictory, or turns out **not** small (yolo's scope check aborts);
+   d. an action would fall **outside the confirmed queue** (touching an unlisted issue, an unrelated dirty file, a destructive op).
+   Anything else — routine implementation choices, passing tests, clean merges — proceeds without asking.
+
+7. **Failure policy** (from the `onfail:` token; default **stop**). When a stop condition (step 6) trips on an issue:
+   - **`onfail:stop`** (default) — **halt the cycle**: finish no further issues, leave the repo on the **default branch, clean** (the in-flight issue's branch stays as-is for the user to inspect), record the stop reason and the not-reached issues in `cycle_status.md`, and report. Do not attempt the rest of the queue.
+   - **`onfail:skip`** — **park and continue**: record the failure against that issue in `cycle_status.md` (`- [~] #<N> — <title> — failed: <reason>`), park its work per `{{ agent_dir }}/skills/iflow-pause/SKILL.md` conventions (status note + move to `{{ partly_solved_folder }}/`), return to a clean default branch, and proceed to the next queued issue. A skip never bypasses a yolo safeguard — it records the trip and moves on.
+
+8. **Finish.** When the queue is exhausted (or halted), finalize `cycle_status.md` (mark it `- [x] Done`) and move it to `{{ issueflows_dir }}/{{ solved_folder }}/cycle_status_<YYYY-MM-DD>.md` so it is archived, not re-detected as in-flight.
+
+9. **Batch report.** Summarize the whole run: per issue — number, title, PR URL, merge result (merged / queued via `--auto` / failed-and-skipped / not reached), and duration if tracked; then the queue items **skipped** (closed), **blocked** (with blockers), and — on a halt — the **stop reason** and which issues were **not reached**. End by reminding the user to run `/iflow-cleanup` once to prune the merged local branches.
+
+## Resuming
+
+`/iflow-cycle resume` picks up an interrupted cycle:
+
+1. Read `{{ issueflows_dir }}/{{ current_issues_folder }}/cycle_status.md`. If it is missing, tell the user there is no in-flight cycle and stop.
+2. Take the **remaining** issues (those still `pending` / `in-progress`) and **re-verify** them with `issue-flow agent queue <original-spec> --json` — an issue that has since closed, or become blocked, is dropped/deferred with a note (state can move while a cycle is paused).
+3. **Do not re-ask the original consolidated confirm** for the unchanged remaining items — the batch was already authorized. Ask again only if the re-verified queue differs materially from what was confirmed (new blockers, added issues), and only about the delta.
+4. Continue the per-issue loop (step 5) with the same `onfail` policy recorded in the file.
+
+## Parallel dispatch (experimental, opt-in)
+
+By default the cycle is **sequential** — one issue fully lands before the next starts. When the input passes **`parallel:<n>`** *and* the harness supports background execution, provably independent issues may run concurrently (up to `n` at a time). This is experimental; the sequential path above is always the default and is never weakened to enable it.
+
+- **Only independent issues qualify.** Use `issue-flow agent queue`'s **`independent`** list — issues with *no* dependency relation (either direction) to any other queue member. Everything else runs sequentially.
+- **Harness gate.** If you cannot confirm the harness supports background execution (worktrees + parallel agents/subagents), **refuse `parallel:<n>` and run sequentially** — never pretend to parallelize.
+- **Worktree per issue.** `git worktree add ../<repo>-<N> <N>-<slug>` so each issue has an isolated tree; run the yolo work there.
+- **Serialize merges.** Never merge PRs concurrently — the coordinating session merges them one at a time on the default branch, pulling between merges and rebasing/retrying on a non-fast-forward or CI refusal.
+- **Shared files via the coordinator only.** Parallel workers must **not** each edit `{{ history_file }}`; each leaves its changelog bullet in its issue status file / PR body, and the coordinator appends them in **merge order** during the serial merge step.
+
+When in doubt, prefer the sequential run — parallel dispatch trades safety for speed and every one of the rules above must hold.
+
+## Constraints
+
+- **Off-path**: `/iflow` never auto-dispatches to `/iflow-cycle`; it is an explicit, deliberate batch action.
+- **Sequential is the default and floor.** Parallelism (`parallel:<n>`) is opt-in and experimental; refusing it must always leave a working sequential run.
+- Never weaken a yolo safeguard to keep the cycle moving — safeguards are stop conditions, not obstacles.
+- Never run `/iflow-cleanup` from this skill; batch branch deletion still needs the user to see the merged PRs first.
+- One consolidated confirm covers the batch; never silently expand the queue beyond what was confirmed.
+- `cycle_status.md` is the single source of truth for an in-flight cycle: keep it current so `resume` and `/iflow-status` stay accurate. It is not an `issue<N>_*` group, so the folder sweep leaves it alone; archive it (step 8) when the run ends.

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/skills/iflow_pick/SKILL.md.j2

@@ -32,8 +32,9 @@ Do **not** use this skill from `/iflow`, `/iflow-start`, or `/iflow-close`. `/if
 2. **`fix` shortcut.** If the user passed `fix`, skip selection and go to step 5 (create a new general-fixes issue), then Phase 2.
 3. **Source candidates** (precedence):
    - **Parked work first** — list `issue<n>_*` groups in `{{ issueflows_dir }}/{{ partly_solved_folder }}/` as the primary candidates (already-started work to finish first).
+   - **Active epic next** — if an epic plan under `{{ issueflows_dir }}/{{ epics_folder }}/` has open issues (or the user named one, e.g. `epic 144`), prefer its **current stage's unblocked issues**. Use the fast path `issue-flow agent epic-status <N> --json` when the CLI is on `PATH` — its `next_candidates` are exactly the open, dependency-satisfied issues of the current stage. Surface those at the top of the shortlist so an epic advances stage by stage instead of stalling.
    - **Else GitHub** — `gh issue list --state open --json number,title,labels,milestone,updatedAt` (add `--repo owner/repo` if ambiguous). Drop issues already captured under `{{ current_issues_folder }}/`, `{{ partly_solved_folder }}/`, or `{{ solved_folder }}/`.
-4. **Rank and present.** Rank by **milestone** (nearest/active, honour any hint) + **labels** (match recent work / hint) + **topical similarity** to recently solved issues (skim `{{ issueflows_dir }}/{{ solved_folder }}/` and recent branch names). Show a numbered shortlist (~3–7) with number, title, labels, milestone, and **ask the user to confirm** the pick or override. Never pick silently.
+4. **Rank and present.** Rank by **epic membership** (an active epic's current-stage `next_candidates` first) + **milestone** (nearest/active, honour any hint) + **labels** (match recent work / hint) + **topical similarity** to recently solved issues (skim `{{ issueflows_dir }}/{{ solved_folder }}/` and recent branch names). Show a numbered shortlist (~3–7) with number, title, labels, milestone, and (for epic issues) the epic + stage, and **ask the user to confirm** the pick or override. Never pick silently.
 5. **Create a `fix` issue (only when requested).** Use `gh issue create` (e.g. `chore: general fixes`), confirm title/body first, capture the new number. A fresh issue is created each time — never reuse an existing open general-fixes issue.
 6. **Over-large issue (note only).** If the chosen issue is too big for one PR, **mention** that breaking it into sub-issues is possible and tracked as a follow-up (Phase B of issue #63). Do **not** auto-create sub-issues here.
 {% if label_flows and "iflow-yolo" in included_commands %}

{issue_flow-0.4.3.post3 → issue_flow-0.4.4}/src/issue_flow/templates/skills/iflow_status/SKILL.md.j2

@@ -39,6 +39,8 @@ Do **not** use this skill to *change* anything. It is read-only and off-path; fo
 
 4. **Solved archive** (`{{ issueflows_dir }}/{{ solved_folder }}/`). Report the count of distinct solved issue numbers and the most recent few.
 
+4a. **In-flight cycle.** If `{{ issueflows_dir }}/{{ current_issues_folder }}/cycle_status.md` exists, a `/iflow-cycle` batch run is paused or active — report it and its progress (from the file's checklist), and note that `/iflow-cycle resume` continues it. (`issue-flow status --json` reports this as `cycle_active`.)
+
 5. **Open GitHub issues** (skip if the user passed `local`). Run `gh issue list --state open --json number,title,labels,milestone,updatedAt` and tag each issue's local state: **focus**, **parked**, **solved-locally**, or **untracked**. If `gh` is missing/unauthenticated, skip this section and note it (suggest `gh auth login`) — never fail.
 
 6. **Summary line.** One terse line, e.g. `Focus: #20 (start). Parked: 2. Solved: 31. Open on GitHub: 7 (5 untracked).`

issue_flow-0.4.3.post3/src/issue_flow/templates/skills/iflow_cycle/SKILL.md.j2

@@ -1,65 +0,0 @@
----
-name: iflow-cycle
-description: >-
-  Process many issues hands-off in a row: resolve a queue, then run each
-  through the yolo chain under one up-front confirm. Stops only when input is
-  strictly necessary.
-disable-model-invocation: true
----
-
-# issue-flow — issue cycle (`/iflow-cycle`)
-
-Follow this skill to **process a queue of issues hands-off**, one after another, with a **single up-front confirmation** — the batch equivalent of `/iflow-yolo`. Each issue runs the full yolo chain (`init → plan → start → close yolo`, PR auto-merged, switch back to default); the cycle interrupts you only when input is **strictly necessary**.{% if commands_supported %} Matches `{{ agent_dir }}/{{ commands_dir }}/iflow-cycle.md`.{% endif %}
-
-Use only when every queued issue is genuinely yolo-fit (small, low-risk, well-specified, test-guarded). A queue of risky changes belongs in the individual commands.
-
-## Input — queue spec
-
-- **explicit numbers** — e.g. `12 15 18`.
-- **`label:<L>`** — every open issue carrying label `<L>`.
-- **`epic <N> [stage <k>]`** — the current stage of epic `<N>` (or stage `<k>`).
-- **`resume`** — reserved for the resumable cycle (a later slice); not yet available.
-- **`max:<n>`** — raise the safety cap (default 10) for this run.
-- **`stay`** — forward `stay` to each close so the working copy stays on each issue branch (rarely wanted in a cycle).
-
-{% set iflow_step = "cycle" %}
-{% include "skills/_invocation_forms.md.j2" %}
-
-{% include "skills/_model_directive.md.j2" %}
-
-{% include "skills/_resolve_project_root.md.j2" %}
-## Instructions
-
-1. **Resolve the queue.** Run `issue-flow agent queue <spec> --json` (numbers, `--label`, or `--epic`). Use its `queue` (ordered), `blocked`, and `skipped_closed` output as the source of truth — do not re-derive the order by hand. If it reports a dependency `cycle`, **stop** and show it; nothing runs. If the CLI is unavailable, fall back to reading the issues and ordering by `Depends on #N` lines yourself, but prefer the CLI.
-
-2. **Cap check.** If the ordered queue is longer than **10** and the input did not pass `max:<n>` raising the limit, **stop** and ask the user to confirm a larger run explicitly. Long unattended runs compound risk.
-
-3. **One consolidated confirm** (the only planned interruption). Present, in normal prose:
-   - the **ordered** queue (numbers + titles), and which issues are **skipped** (closed) or **blocked** (open dependency outside the queue) with the reason;
-   - that each issue runs the **full yolo chain** and its PR is **auto-merged**;
-   - the failure policy (**stop on the first failure** — see below);
-   - the default-branch preflight that must hold before starting (clean tree, tests passing).
-   Require an explicit yes; anything else aborts before any work.
-
-4. **Per-issue loop.** For each issue in order, from a clean default branch:
-   - create/switch to its `<N>-<slug>` branch, then follow `{{ agent_dir }}/skills/iflow-yolo/SKILL.md` **verbatim** — including its own preflight (refuse on default branch, refuse with dirty unrelated changes, tests pass up front) and its consolidated-confirm step, which the up-front batch confirm in step 3 satisfies (do not re-ask per issue).
-   - after the yolo close merges and switches back to the default branch, record the outcome (PR URL, merge result) and continue to the next issue.
-   - Every yolo safeguard stays in force. A safeguard that trips is a **stop condition** (step 5), never a guard to skip.
-
-5. **Strictly-necessary-input rule.** Between issues the cycle runs unattended. **Stop and ask only** when:
-   a. tests or lint fail in a way you cannot fix within the current issue's scope;
-   b. a merge is refused or a `git pull --ff-only` will not fast-forward (divergence);
-   c. the issue spec is ambiguous, contradictory, or turns out **not** small (yolo's scope check aborts);
-   d. an action would fall **outside the confirmed queue** (touching an unlisted issue, an unrelated dirty file, a destructive op).
-   Anything else — routine implementation choices, passing tests, clean merges — proceeds without asking.
-
-6. **Failure policy (default: stop).** On the first stop condition, **halt the cycle**: finish no further issues, leave the repo on the **default branch, clean** (the in-flight issue's branch stays as-is for the user to inspect), and report. Do not attempt the rest of the queue. (A skip-and-continue policy, `onfail:skip`, is a later slice.)
-
-7. **Batch report.** Summarize the whole run: per issue — number, title, PR URL, merge result (merged / queued via `--auto` / not reached), and duration if tracked; then the queue items **skipped** (closed), **blocked** (with blockers), and — on a halt — the **stop reason** and which issues were **not reached**. End by reminding the user to run `/iflow-cleanup` once to prune the merged local branches.
-
-## Constraints
-
-- **Off-path**: `/iflow` never auto-dispatches to `/iflow-cycle`; it is an explicit, deliberate batch action.
-- Never weaken a yolo safeguard to keep the cycle moving — safeguards are stop conditions, not obstacles.
-- Never run `/iflow-cleanup` from this skill; batch branch deletion still needs the user to see the merged PRs first.
-- One consolidated confirm covers the batch; never silently expand the queue beyond what was confirmed.