diff --git a/plugin/meta/ase-common-code.md b/plugin/meta/ase-common-code.md
index 17aa24fc..3fd6c31d 100644
--- a/plugin/meta/ase-common-code.md
+++ b/plugin/meta/ase-common-code.md
@@ -148,8 +148,14 @@ Set <args>--int-reuse-task</args>.
     <if condition="<getopt-option-next/> is not equal `none`">
         Set <args><args/> --next <getopt-option-next/></args>
     </if>
+    <if condition="<getopt-option-quick/> is equal `true`">
+        Set <args><args/> --mode all</args>
+    </if>
     Call the tool `Skill(skill: "ase:ase-task-implement", args: "<args/>")`
     to *implement* the freshly composed plan, bypassing `ase-task-edit`.
+    The `--quick`/`-Q` one-shot forwards `--mode all` so
+    `ase-task-implement` runs the plan in a single pass, without
+    the interactive step-mode dialog.
     </elseif>
 
 3.  <elseif condition="<head/> is equal `PREFLIGHT`">
diff --git a/plugin/skills/ase-code-resolve/help.md b/plugin/skills/ase-code-resolve/help.md
index f859104a..40a51570 100644
--- a/plugin/skills/ase-code-resolve/help.md
+++ b/plugin/skills/ase-code-resolve/help.md
@@ -60,8 +60,11 @@ entirely and applies the change set to the affected artifacts itself.
     Shorthand alias for `-a -d -n IMPLEMENT,DELETE`: automatically pick
     the recommended resolution approach, compose the plan *without* the
     `##  VERIFICATION` section, immediately hand off to `ase-task-implement`,
-    and finally `ase-task-delete` the now-consumed plan. This gives a
-    single, fast *one-shot* resolution mode.
+    and finally `ase-task-delete` the now-consumed plan. The hand-off
+    additionally forwards `--mode all`, so `ase-task-implement` applies
+    the plan in a single pass *without* the interactive step-mode
+    dialog. This gives a single, fast, fully non-interactive *one-shot*
+    resolution mode.
 
 `--next`|`-n` *option*[,...]:
     Automatically choose the next step after composing the plan.
diff --git a/plugin/skills/ase-task-implement/SKILL.md b/plugin/skills/ase-task-implement/SKILL.md
index 7488d6bd..9c69b754 100644
--- a/plugin/skills/ase-task-implement/SKILL.md
+++ b/plugin/skills/ase-task-implement/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: ase-task-implement
-argument-hint: "[--help|-h] [--next|-n <option>[,...]] [--worktree|-w] [<id>]"
+argument-hint: "[--help|-h] [--next|-n <option>[,...]] [--mode|-m all|steps] [--worktree|-w] [<id>]"
 description: >
     Implement current or given task plan.
     Use when the user calls to "implement", "realize" or "apply" the
@@ -21,7 +21,7 @@ Implement a Task Plan
 
 <expand name="getopt"
     arg1="ase-task-implement"
-    arg2="--next|-n=(none|DONE|DELETE)... --worktree|-w --int-reuse-task">
+    arg2="--next|-n=(none|DONE|DELETE)... --worktree|-w --int-reuse-task --mode|-m=(ask|all|steps)">
     $ARGUMENTS
 </expand>
 
@@ -156,7 +156,70 @@ Procedure
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ◉ worktree: **.ase/worktree/<worktree-name/>**, ▶ status: **worktree created**
         </template>
 
-4.  **Create Implementation:**
+4.  **Determine Mode:**
+
+    1.  <if condition="
+            <task-content/> contains a `##  IMPLEMENTATION STEPS` section
+            heading with at least one still open checkbox item (`- [ ]`)
+        ">
+        A previous `steps` mode run was interrupted (paused for
+        discussion or ended with the session), so *resume* it: set
+        <mode>steps</mode> *without* any user dialog, set <total/> to
+        the total number of checkbox items and <open/> to the number
+        of still open checkbox items (`- [ ]`) of this section, only
+        output the following <template/>, and then directly continue
+        with step 5 (the implementation loop):
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **resuming step mode (<open/>/<total/> steps open)**
+        </template>
+        </if>
+
+    2.  <elseif condition="<getopt-option-mode/> is NOT equal to `ask`">
+        Honor the pre-selected mode: set <mode><getopt-option-mode/></mode>.
+        Do not output anything.
+        </elseif>
+
+    3.  <elseif condition="<ase-headless/> is `true`">
+        No user dialog is possible in headless contexts, so default to
+        the single-pass mode: set <mode>all</mode>.
+        Do not output anything.
+        </elseif>
+
+    4.  <else>
+        Let the *user interactively choose* the implementation mode.
+
+        In the following, you *MUST* *NOT* use your built-in
+        <user-dialog-tool/> tool! Instead, you *MUST* just show a
+        custom dialog according to the expanded `custom-dialog`
+        definition. You *MUST* closely follow this definition:
+
+        <expand name="custom-dialog" arg1="--no-other">
+            Mode: How should the plan be implemented?
+            ALL: One complete change set in a single pass.
+            STEPS: Small review-ready increments, pausing for review after each.
+        </expand>
+
+        Check the tool <result/> and dispatch accordingly:
+
+        -   If <result/> is `ALL`:
+            Set <mode>all</mode>.
+
+        -   If <result/> is `STEPS`:
+            Set <mode>steps</mode>.
+
+        -   If <result/> is `CANCEL`:
+            Only output the following <template/> and then immediately
+            *STOP* processing the entire current skill:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **implementation cancelled**
+            </template>
+        </else>
+
+5.  **Create Implementation:**
+
+    <if condition="<mode/> is `all`">
 
     1.  Perform a *final implementation* of the task plan
         by modifying the *artifacts* with a corresponding, complete
@@ -253,7 +316,235 @@ Procedure
         </ase-tpl-hint>
         </if>
 
-5.  **Decide Next Step:**
+    </if>
+
+    <if condition="<mode/> is `steps`">
+
+    1.  **Derive Step List:**
+
+        <if condition="
+            <task-content/> does NOT contain a `##  IMPLEMENTATION STEPS`
+            section heading
+        ">
+
+        1.  *Restructure* the task plan in <task-content/> into <m/> small,
+            self-contained, individually verifiable *increments*, each
+            the *smallest landable unit*: one reviewable diff (about
+            one class or one feature cut) bundling the code belonging
+            together plus its corresponding test, ending "compiles +
+            tests green + report" -- *never* "all files at once".
+            Respect the dependency order, but the plan order is no
+            dogma: sensible restructuring is encouraged. Where the
+            plan calls for them, use the two special increment
+            *types*: `[measure]` probes whose *measured* result
+            decides whether a dependent increment is built or
+            cancelled, and `[live]` verifications where the *user*
+            runs the application and reports logs/screenshots back
+            (their diagnosis loops belong to the increment). Like in
+            `all` mode, the plan text in <task-content/> always overrules
+            the optional `IMPLEMENTATION DRAFT` hints.
+
+            Do not output anything in this step.
+
+        2.  *Persist* the step list (critical: progress *MUST* survive
+            discussion pauses and session restarts): append the
+            following new section to the plan in <task-content/> and call
+            the `ase_task_save(id: "<ase-task-id/>", text: "<task-content/>")`
+            tool of the `ase` MCP server to save the updated plan:
+
+            <format>
+            ##  IMPLEMENTATION STEPS
+
+            -   **BASELINE**: pre-existing failures: <list, or `none`>
+
+            - [ ] 1. <step-title-1/> -- <one-sentence scope>
+            - [ ] 2. [measure] <step-title-2/> -- <one-sentence scope>
+            </format>
+
+            The **BASELINE** bullet names the build/test failures
+            existing *before* the first increment (extend it when
+            verification reveals further pre-existing ones); the
+            optional `[measure]`/`[live]` tag marks the increment type.
+
+            Do not output anything in this step.
+
+        3.  Only output the following <template/> (with one trailing
+            line per step):
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **restructured into <m/> review-ready steps**
+            ➤ <n/>. <step-title-n/>
+            </template>
+
+        </if>
+
+    2.  **Implementation Loop:**
+
+        The loop is a *contract*, not a schedule -- four rules bind
+        *every* iteration:
+
+        -   *One increment at a time*: *never* implement past the
+            next review gate, however trivial the next increment
+            seems.
+
+        -   *Implementing is the default*: the gate reviews *results*
+            and never re-asks permission to implement; ask separately
+            only on genuine *scope changes*.
+
+        -   *Git remains with the user*: *never* commit, and stage
+            only when the user explicitly chooses `STAGE` at a review
+            gate -- otherwise leave *all* changes unstaged for the
+            user to review, stage, and commit.
+
+        -   *Resequencing is allowed, silence is not*: when contact
+            with the code shows an increment is mis-cut or mis-ordered,
+            reorder/split/merge the step list and record the
+            rationale as an indented note below the affected item
+            (e.g. "moved after step 7, because ...") via
+            `ase_task_save`. Deferred work *MUST* name its target
+            increment.
+
+        Set <m/> to the total number of checkbox items of the
+        `##  IMPLEMENTATION STEPS` section in <task-content/>.
+        For each still *open* increment <n/> (checkbox `- [ ]`, in
+        ascending order), perform the following sub-items:
+
+        1.  *Implement* only increment <n/> by modifying the
+            corresponding *artifacts*.
+
+            <if condition="<task-content/> contains a `##  VERIFICATION` section heading">
+            Verify the increment according to the `##  VERIFICATION`
+            section, as far as applicable, matching the increment
+            *type*: unit tests for behavior, architecture/structure
+            tests for structural increments, the recorded measurement
+            for `[measure]`, the user-reported evidence for `[live]`.
+            Also check *harness realism*: does the harness reflect
+            the live conditions (advancing clock, concurrency,
+            reconnects)?
+            </if>
+            <else>
+            The task plan deliberately *omits* the `##  VERIFICATION`
+            section: *strictly skip* the entire verification phase,
+            exactly as specified for `all` mode above (no build, no
+            tests, no linter, no type-checker, no program execution,
+            no other verification).
+            </else>
+
+            Then *compose* the <step-summary/> of increment <n/>:
+            2-5 bullet lines telling what was changed (functionally,
+            not as a file list), the affected artifacts, the
+            verification result (e.g. "tests 12/12 green" or
+            "verification skipped per plan"), and any *findings* worth
+            remembering (including deferred work with its named target
+            increment).
+
+            <if condition="increment <n/> is a `[measure]` increment">
+            The measured result *gates* the dependent increments: mark
+            a cancelled increment's checkbox as `- [x]`, strike its
+            title through (`~~...~~`), and record the measured
+            rationale as an indented note below it.
+            </if>
+
+            Then set the checkbox of increment <n/> to `- [x]` in
+            <task-content/>, insert the <step-summary/> as indented bullet
+            lines directly below it, and call the `ase_task_save(id:
+            "<ase-task-id/>", text: "<task-content/>")` tool of the `ase`
+            MCP server again to persist progress and summary.
+
+            Do not output anything in this step.
+
+        2.  Only output the following *step report* <template/>, where
+            the table lists the changed *production* files (one row
+            per file), <status/> is `A` (added), `M` (modified), or
+            `D` (deleted), <what/> is a one-clause change description,
+            and <verdict/> is the verification result:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ➤ step: **<n/>/<m/>** -- **<step-title-n/>**, ▶ status: **step implemented**
+
+            | Status    | File      | What    |
+            | --------- | --------- | ------- |
+            | <status/> | `<file/>` | <what/> |
+
+            ● **Tests**: <tests added/changed and their result, or `none`>
+            ● **Verification**: <verdict/> (pre-existing failures: <list, or `none`>)
+            ● **Staging**: all changes left unstaged -- staging/committing remains with you
+            </template>
+
+        3.  <if condition="at least one increment is still open">
+            *Review gate*: let the *user interactively choose* how to
+            proceed.
+
+            You *MUST* have output the step report <template/> of the
+            previous sub-item as regular text *BEFORE* the dialog is
+            shown -- it is the basis for the user's review decision.
+            If it was not output yet, output it now.
+
+            Set <step-gist/> to a one-line condensation (at most about
+            25 words, no line breaks) of the just emitted step report,
+            ending with the verification result.
+
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
+
+            <expand name="custom-dialog" arg1="--no-other">
+                Step <n/>/<m/>: <step-gist/> -- How to proceed?
+                CONTINUE: Implement the next step.
+                STAGE: Stage this step's not-yet-staged files, then implement the next step.
+                DISCUSS: Pause here; re-invoke ase-task-implement to resume.
+                DONE: Stop and PRESERVE the plan including step progress.
+            </expand>
+
+            Check the tool <result/> and dispatch accordingly:
+
+            -   If <result/> is `CONTINUE`:
+                Continue the loop with the next open increment.
+
+            -   If <result/> is `STAGE`:
+                *Stage* exactly the files of increment <n/> (the step
+                report's production files plus its test files) that
+                are not already staged, via `git add <file/> [...]`
+                (*never* `git add -A`), then continue the loop with
+                the next open increment.
+
+            -   If <result/> is `DISCUSS` or `CANCEL`:
+                Only output the following <template/> and then
+                immediately *STOP* processing the entire current
+                skill (the user discusses freely in the chat;
+                re-invoking `ase-task-implement` later resumes at the
+                first open increment):
+
+                <template>
+                ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ➤ step: **<n/>/<m/>**, ▶ status: **paused for discussion -- re-invoke ase-task-implement to resume**
+                </template>
+
+            -   If <result/> is `DONE`:
+                Only output the following <template/> and then
+                immediately *STOP* processing the entire current skill
+                (the plan including the step progress is preserved):
+
+                <template>
+                ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ➤ step: **<n/>/<m/>**, ▶ status: **stopped -- plan and step progress preserved**
+                </template>
+            </if>
+
+    3.  Once no increment is open anymore: *remove* the
+        entire `##  IMPLEMENTATION STEPS` section from the plan in
+        <task-content/> again (the plan returns to its canonical format) and
+        call the `ase_task_save(id: "<ase-task-id/>", text: "<task-content/>")`
+        tool of the `ase` MCP server to save the updated plan.
+
+        Only output the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan implemented**
+        </template>
+
+    </if>
+
+6.  **Decide Next Step:**
 
     1.  *Determine next step*:
 
@@ -288,4 +579,3 @@ Procedure
             <template>
             ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **plan implemented -- hand-off to delete task**
             </template>
-
diff --git a/plugin/skills/ase-task-implement/help.md b/plugin/skills/ase-task-implement/help.md
index 184e6024..e9deecce 100644
--- a/plugin/skills/ase-task-implement/help.md
+++ b/plugin/skills/ase-task-implement/help.md
@@ -8,6 +8,7 @@
 `ase-task-implement`
     [`--help`|`-h`]
     [`--next`|`-n` *option*[,...]]
+    [`--mode`|`-m` *mode*]
     [`--worktree`|`-w`]
     [*id*]
 
@@ -32,12 +33,60 @@ before any artifact is touched, in addition to the always applying
 **GENERIC TENETS**. If a plan carries no such key, the kind is
 *inferred* from the plan content, defaulting to `CRAFTING`.
 
+The implementation can be performed in one of two *modes*. In mode
+`all`, the plan is implemented as one complete change set in a single
+pass. In mode `steps`, the plan is first *restructured* into small,
+self-contained, individually verifiable increments - each one the
+*smallest landable unit*: a reviewable diff of related code plus its
+corresponding test, ending "compiles + tests green + report". Besides
+regular code increments, `[measure]` increments are probes whose
+measured result decides whether a dependent increment is built or
+cancelled, and `[live]` increments are live verifications where the
+user runs the application and reports logs/screenshots back.
+
+The increment list is persisted as an `IMPLEMENTATION STEPS` section
+(a numbered checkbox list plus a `BASELINE` bullet naming the known
+pre-existing failures) inside the task plan itself, so progress
+survives discussion pauses and even session restarts. The section is a *living ledger*:
+increments may be resequenced, split, or merged when contact with the
+code demands it (rationale recorded beneath the affected item), and
+deferred work must name its target increment. After each increment,
+its checkbox is ticked, a step summary with findings is recorded
+beneath it, the plan is saved, and a *standardized step report* is
+emitted: a table of the changed production files (Status / File /
+What), tests named separately, the verification result citing the
+known pre-existing failures, and the explicit staging status. The
+skill *never* commits and stages only on an explicit `STAGE` gate
+choice - Git sovereignty remains with the user. Via a custom dialog
+carrying a one-line condensation of the report, the user then
+decides: `CONTINUE` (next increment), `STAGE` (stage the increment's
+not-yet-staged files, then continue), `DISCUSS` (pause for a free
+discussion in the chat), or `DONE` (stop and preserve plan and
+progress). The gate reviews *results*: implementing the next
+increment is the default; the skill asks again only on genuine scope
+changes.
+
+If the loaded plan already contains an `IMPLEMENTATION STEPS` section
+with at least one open checkbox, the skill *resumes* mode `steps` at
+the first open increment without asking for a mode again - this is the
+re-entry path after `DISCUSS` or a session restart. Once the last
+increment is implemented, the `IMPLEMENTATION STEPS` section is removed
+from the plan again, returning it to its canonical format.
+
+If the mode is neither pre-selected via `--mode` nor implied by a
+resumable `IMPLEMENTATION STEPS` section, the user is asked
+interactively for the mode (in headless contexts, mode `all` is used).
+
 If the task plan deliberately *omits* the `##  VERIFICATION` section
 (as produced by `ase-code-craft`, `ase-code-refactor`,
 `ase-code-resolve`, or `ase-task-edit` when invoked with `--dry`),
 the entire verification phase is strictly skipped: no build, tests,
 linter, type-checker, or program execution is performed once the
-source files have been modified.
+source files have been modified. In mode `steps`, this rule applies
+per increment. Otherwise the verification matches the increment type
+(unit, architecture/structure, measurement, or live verification) and
+checks *harness realism*: whether the test harness reflects the live
+conditions (advancing clock, concurrency, reconnects).
 
 With `--worktree`|`-w`, the change set is *not* applied to the current
 working copy: a *fresh Git WorkTree* `.ase/worktree/<id>` and its
@@ -63,7 +112,17 @@ delete the task plan, unless `--next` pre-selects this choice.
     downstream `ase-task-delete` skill accepts no `--next` option.
     Recognized tokens at this skill: `none` (default, interactive
     answer required), `DONE` (preserve task plan and stop), or
-    `DELETE` (hand off to `ase-task-delete`).
+    `DELETE` (hand off to `ase-task-delete`). The tokens apply only to
+    the *final* next-step dialog - the per-increment review gates of
+    mode `steps` are deliberately interactive, so `--mode steps --next
+    ...` is a valid combination (the tokens are consumed at the end).
+
+`--mode`|`-m` *mode*:
+    Select the implementation mode: `ask` (default, ask the user
+    interactively; in headless contexts mode `all` is used), `all`
+    (one complete change set in a single pass), or `steps`
+    (restructure into small review-ready increments and pause for
+    review after each one).
 
 `--worktree`|`-w`:
     Apply the change set inside a dedicated *Git WorkTree* instead of
@@ -100,6 +159,12 @@ Implement the task `hello` inside the isolated Git WorkTree
 ❯ /ase-task-implement --worktree hello
 ```
 
+Implement the current task plan in small review-ready increments:
+
+```text
+❯ /ase-task-implement --mode steps
+```
+
 ##  SEE ALSO
 
 [`ase-task-edit`](../ase-task-edit/help.md), [`ase-task-preflight`](../ase-task-preflight/help.md), [`ase-task-reboot`](../ase-task-reboot/help.md),