ワンクリックで
iflow-yolo
Chain init → plan → start → close yolo for a small, low-risk issue under one consolidated confirm. Stops on any ambiguity.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Chain init → plan → start → close yolo for a small, low-risk issue under one consolidated confirm. Stops on any ambiguity.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Post-merge branch hygiene: switch to the default branch and delete merged local branches under one consolidated confirm. Never -D.
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.
Plan a larger change as a staged epic: draft epic<N>_plan.md with stages of manageable issue specs, then publish confirmed stages as GitHub issues.
Front door: choose the next issue, create the issue branch, and run /iflow-init.
Smart dispatcher: detect where the focus issue stands and dispatch to /iflow-init, /iflow-plan, /iflow-start, or /iflow-close.
Read-only snapshot of where every issue stands, locally and on GitHub.
| name | iflow-yolo |
| description | Chain init → plan → start → close yolo for a small, low-risk issue under one consolidated confirm. Stops on any ambiguity. |
| disable-model-invocation | true |
| issue-flow-version | 0.4.2a4 |
/iflow-yolo)Follow this skill to blast through a small, low-risk issue in one shot, with no mid-run confirmation checkpoints beyond the single consolidated confirm.
Use only for minor fixes, doc tweaks, and similar low-risk changes. Anything non-trivial should go through the individual commands.
Invoke: type iflow yolo in chat, or /iflow-yolo from the slash menu (iflow-yolo also works).
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.
Before any git, gh, or .issueflows/ path operation in this workflow:
Resolution order (stop when unambiguous):
root:<path>, repo:<folder-basename> (directory name, e.g. cellpy-core), or repo:owner/name.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.^\d+- → that root..issueflows/ tree visible in the workspace → that root.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.After resolution, treat the result as <project_root> and <owner/repo>:
git -C <project_root> … (or issue-flow agent … -C <project_root> for supported ops).gh … --repo <owner/repo> — never rely on gh's implicit cwd default..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.
Refuse on default branch. If the current branch is main / master / the detected default, stop and tell the user to create or switch to an issue branch first. Do not silently create one from yolo.
Refuse with dirty unrelated changes. Run git status --porcelain. If anything uncommitted is not clearly part of the target issue, ask once; if still unclear, stop. Suggest committing or stashing first.
Tests must pass up front. Run uv run pytest (or the repo's documented test command). On any failure, stop before the chain starts.
Single consolidated confirm. Present the full planned chain explicitly (issue reference, target branch, repo, downstream commands including any bump / patch / draft / stay flags). Require an explicit yes; any other input aborts. (When /iflow-pick routed here via the yolo issue label, its combined confirmation already covered this — do not ask twice.)
Once preflight has passed and the user confirmed:
/iflow-init — capture the issue (or skip if *_original.md already exists for the focus issue)./iflow-plan — write a short issue<N>_plan.md (Goal + Approach + Files to touch + Test strategy). Auto-confirm — the consolidated confirm above covered it. If the scope check reveals the change is not actually small, abort the yolo chain and tell the user to run the commands individually./iflow-start — implement the plan without an additional plan-mode prompt.uv run pytest again. On failure, stop before commit / push / PR./iflow-close yolo — run the close flow with the yolo token (plus forwarded bump / log / nohistory / draft / stay tokens). The yolo token makes close hands-off: changelog bullet written without a confirm prompt; PR listed/reused via gh pr list, then merged via gh pr merge --squash (on pending checks: gh pr checks --watch --fail-fast for up to 15 minutes, then retry merge; --squash --auto only as last resort when the cap elapses or checks never register), then default-branch switch + git pull --ff-only. draft conflicts with auto-merge — when passed, skip the merge and say so. Do not chain /iflow-cleanup automatically — local branch deletion stays a user decision.Report the PR URL, the merge result (merged, or queued via --auto), and the final branch. By default /iflow-close yolo merges the PR and switches back to the default branch with a pull; forwarded stay text leaves the user on the issue branch instead. Remind them that /iflow-cleanup will delete the now-merged local branch when they are ready.
-D, no force-push, etc.). /iflow-yolo is a chain, not a free pass.git status, ambiguous version bump, merge conflict, failed test), stop and hand back to the user./iflow-cleanup from this skill. Branch deletion always needs the user to see the merged PR first.