✨ Present full flow and step-by-step mode in implement-plan

Two changes to the implement-plan flow:

- It now shows the whole picture before touching the repo: which
  issue and branch will be created (or the current branch it
  continues on), the execution style, and the task checklist — then
  waits for the user's confirmation. Flow detection is read-only;
  issue and branch creation moved to the execution step.

- New opt-in execution mode: on request ("step by step"), it runs
  one task at a time, commits each one with the create-commit skill,
  and waits for the user's review before the next task. The default
  stays as it was: every task, one commit.

README and the implement-plan command description updated to match.

AI-assisted-by: omen-alpha

.agents/README.md

@@ -34,7 +34,7 @@ JSON, REPL access, and so on.
 |---|---|---|
 | [`make-a-plan`](skills/make-a-plan/SKILL.md) | Researches the task, writes an implementation plan, asks you the open questions in plain language, and saves the plan to `.agents/plans/`. | "make a plan for the token refresh bug" |
 | [`review-plan`](skills/review-plan/SKILL.md) | Evaluates a plan before anyone writes code: completeness, ordering, risks. Approves it or asks for changes. | "review this plan before we start" |
-| [`implement-plan`](skills/implement-plan/SKILL.md) | Executes a ready plan and ends with one commit. Starting from a base branch (`main`, `develop`, `staging`), it first creates a GitHub issue and a matching `issue-NNNN` branch; already on a feature branch, it continues there without creating anything. | "implement the plan" |
+| [`implement-plan`](skills/implement-plan/SKILL.md) | Shows you the full flow first — the issue and branch it will create (or the branch it continues on), the execution style, and the task checklist — and, after your go-ahead, executes a ready plan. Default: every task, one commit. On request ("step by step"): one task, one commit, your confirmation between tasks. | "implement the plan" · "step by step, one commit per task" |
 | [`review-code`](skills/review-code/SKILL.md) | Reviews a diff, branch, or PR and returns findings ranked by impact. | "review my changes before I push" |
 | [`create-pr`](skills/create-pr/SKILL.md) | Opens a pull request for the current branch — with checks on base branch, commits, issue, and push state — or updates an existing PR's title and description. | "open a PR for this branch" |
 | [`resolve-git-conflicts`](skills/resolve-git-conflicts/SKILL.md) | Untangles merge or rebase conflicts: explains both sides, proposes a resolution, applies it after you approve. Never runs `git rebase --continue`. | "resolve these conflicts" |

.agents/skills/implement-plan/SKILL.md

@@ -1,13 +1,17 @@
 ---
 name: implement-plan
-description: Implementation flow — execute a ready plan from the session context: detect the flow (new issue + branch when on a base branch, or continue on the current branch), implement, and commit. Use it when the user asks to implement or execute a plan, in any phrasing.
+description: Implementation flow — execute a ready plan from the session context: read the plan, detect the flow, then present the full picture (issue and branch to create or the branch to continue on, execution style, task checklist) and wait for confirmation. Default is every task with one final commit; on request ("step by step"), one task and one commit at a time with a pause after each. Use it when the user asks to implement or execute a plan, in any phrasing.
 ---
 
 # Implement Plan
 
 This flow is run once a plan is ready (for example, from plan mode). Execute
-the plan already prepared in the current session context. This flow ends
-with exactly one commit. It never pushes — the user pushes.
+the plan already prepared in the current session context. It never pushes —
+the user pushes.
+
+By default it ends with exactly one commit. When the user asks for it
+("step by step"), it commits once per task instead and waits for the
+user's confirmation after each one (see *Execution modes*).
 
 ## When to use
 
@@ -19,63 +23,95 @@ with exactly one commit. It never pushes — the user pushes.
 
 Do not use it to produce plans — that is the `make-a-plan` flow.
 
-## 1. Detect the flow (no questions)
+## 1. Read the plan first
+
+Identify the plan to execute — from the file path the user gave, the
+arguments, or the session context. Read it completely. Read the required
+memories before writing any code: `mem:critical-info` and the core memory
+of every module the plan touches, plus the deeper memories they reference
+(AGENTS.md governs this).
+
+## 2. Detect the flow (no questions)
 
 Inspect the current branch with `git rev-parse --abbrev-ref HEAD`, pick the
-mode, and announce it in one line before acting.
+mode, and announce it in one line before presenting anything. Detection is
+read-only: nothing is created until the user confirms (step 3).
 
 - **On a base branch** (`main`, `develop`, `staging`) → **standalone mode**:
-  create the issue and the branch, then implement and commit.
+  a new GitHub issue and a branch `issue-NNNN` will be created after the
+  user's confirmation.
 - **On any other branch** (a feature branch, typically `issue-NNNN`) →
-  **continue mode**: implement on the current branch and commit. No issue or
-  branch is created.
+  **continue mode**: the implementation continues on the current branch.
+  No issue or branch is created. The branch name provides the issue
+  reference when it follows the `issue-NNNN` pattern.
 
 Arguments override detection: `standalone`, `continue`,
 `no issue` / `without issue`, or an explicit base such as
 `from origin/develop`.
 
-### Standalone mode
-
-1. Create the issue with the **`create-issue`** skill, following the
-   *Creating Issues from Draft Body* flow in `mem:workflow/creating-issues`.
-   Derive the issue title and body from the plan. Capture the new issue's
-   number — call it **NNNN** (needed for the branch name and the commit
-   reference).
-2. Create the branch from the current HEAD:
-
-   ```
-   git checkout -b issue-NNNN
-   ```
-
-3. If the arguments say `no issue` / `without issue`, skip the issue and
-   create a branch named `plan-<slug>` instead, where `<slug>` is the plan
-   title, lowercase and hyphen-separated.
-
 **Standalone while already on a feature branch:** stop and explain that this
 would stack branches. Ask the user to re-run with an explicit base, for
 example `from origin/develop` — then branch from that base instead of HEAD.
 
-### Continue mode
+## 3. Present the checklist and wait
 
-No issue and no branch. Implement on the current branch. The branch name
-provides the issue reference when it follows the `issue-NNNN` pattern.
+Before touching the repository, show the user the full picture:
 
-## 2. Execute the plan
+- **The flow**: whether the GitHub issue and the branch will be created
+  (standalone mode — give the planned branch name, `issue-NNNN` or
+  `plan-<slug>`), or whether you continue on the current branch
+  (continue mode — name it).
+- **The execution style**: batch or step-by-step (see *Execution modes*).
+- A checklist (todolist) of the plan's tasks, in order.
 
-Implement the prepared plan from the session context. Work methodically,
-keeping changes focused on what the issue requires. Respect the plan's
-proposed parallelization when it applies. Do not commit — the commit happens
-in the next step.
+Then WAIT for the user's explicit confirmation. Do not start until you
+have it. If the plan has no discrete tasks, ask the user how to split
+it, or propose running it as a single change.
 
-## 3. Commit with the create-commit skill
+## 4. Execute the plan
 
-After the implementation is complete, load the **`create-commit`** skill and
-follow its workflow to commit the changes. Provide a brief summary of what was
-implemented and why, the issue reference (`issue-NNNN`) when there is one, and
-the model name you are running as so the `AI-assisted-by` trailer is set
-correctly.
+**Standalone setup, after the confirmation:** create the issue with the
+**`create-issue`** skill, following the *Creating Issues from Draft Body*
+flow in `mem:workflow/creating-issues`. Derive the issue title and body
+from the plan, capture the new issue's number — call it **NNNN** — and
+create the branch from the current HEAD:
 
-Do not push. Pushing is handled separately by the user.
+```
+git checkout -b issue-NNNN
+```
+
+If the arguments say `no issue` / `without issue`, skip the issue and
+create a branch named `plan-<slug>` instead, where `<slug>` is the plan
+title, lowercase and hyphen-separated.
+
+### Batch mode (default)
+
+Implement every task in one go. Work methodically, keeping changes
+focused on what the issue requires. Respect the plan's proposed
+parallelization when it applies.
+
+When the implementation is complete, load the **`create-commit`** skill
+and follow its workflow to commit the changes. Provide a brief summary
+of what was implemented and why, the issue reference (`issue-NNNN`) when
+there is one, and the model name you are running as so the
+`AI-assisted-by` trailer is set correctly.
+
+### Step-by-step mode (on request)
+
+When the user asks for it — "step by step", "task by task", "one commit
+per task" — loop one task at a time:
+
+- Execute exactly ONE task.
+- Commit it now: load the **`create-commit`** skill and follow it —
+  one commit per task, never two tasks in one commit. Same inputs as
+  always: what and why, the issue reference, your model name.
+- Show the user the result (what changed, files touched, how it was
+  verified).
+- WAIT for the user's confirmation before starting the next task.
+
+Never batch in this mode: no two tasks in one commit, and no new task
+before the user confirms. If a task turns out much bigger than planned,
+stop and ask the user before splitting it.
 
 ## When you are done
 
@@ -88,7 +124,9 @@ instruction from me overrides them):
 
 ## User context
 
-Extra context in the user's invocation (the message that triggered this skill)
-plays the role command arguments play elsewhere: `standalone`, `continue`,
-`no issue` / `without issue`, or an explicit base such as
-`from origin/develop`.
+Extra context in the user's invocation (the message that triggered this
+skill) plays the role command arguments play elsewhere: `standalone`,
+`continue`, `no issue` / `without issue`, an explicit base such as
+`from origin/develop`, or `step by step` / `one commit per task` for the
+step-by-step execution mode. Modes combine freely, for example
+"standalone step by step".

.opencode/commands/implement-plan.md

@@ -1,5 +1,5 @@
 ---
-description: Execute a ready plan — create issue + branch when on a base branch, or continue on the current branch; implement and commit — loads and follows the implement-plan skill
+description: Execute a ready plan — task checklist, your confirmation, then all tasks with one commit (default) or step by step with a commit and a pause per task; creates issue + branch when on a base branch — loads and follows the implement-plan skill
 agent: build
 ---