git:20260901.c512bc0 to git:20260901.c9d3298

---

name: mobpro

description: Learning-oriented development workflow (mob-programming style) that runs the SAME quality gates as dev-workflow — plan review, checks/tests, rules-compliance review, code review, interactive commits, rule maintenance, scaled to the task's assessed difficulty the same way — while pausing after every implementation unit for a diff review, so a junior engineer can follow WHAT is being built and WHY. The AI is always the driver (it writes all code) and narrates what it is doing and why; the junior navigates, reads each diff, asks questions, and approves commits. Use this instead of dev-workflow when the goal is to develop a feature WHILE a junior learns from it, not merely to ship efficiently.

---

# mobpro

A learning-oriented development workflow. The AI is always the driver — it writes every edit and narrates what it is doing and why — while the junior navigates, reviewing each implementation unit's diff, asking whatever the narration left open, and judging commits. Pedagogy is never scaled down: every learning stop fires on every run, whatever the task. The quality machinery does scale, along two axes and no others — the difficulty tier `mobpro` assesses at M2, and the run mode the caller selects (§ Run modes).

## Usage

```text

/mobpro [--fast|--deep] [--artifact <value>] <task> # Execute a learning session (Normal sub-mode)

/mobpro --resume <state-file> [--fast|--deep] [--artifact <value>] # Resume a subtask from a decomposition state file

```

There is no `--init` and no `--executor` (see [`references/configuration.md`](references/configuration.md)). It takes two modifiers: the run-mode flags `--fast` / `--deep` (§ Run modes), and `--artifact <value>`, which overrides the resolved `plan_artifact` for that run alone ([`references/configuration.md`](references/configuration.md) § Resolution procedure step 1.5).

## Relationship to dev-workflow

`mobpro` shares dev-workflow's quality machinery:

- **Same sibling callees**: the reviewer (`ask-peer` etc.), `simplify` / `tidy`, `prose-polish`, `rules-review`, `run-tests`, `extract-rules` — invoked with the same conventions.

- **Same project-characteristic settings**: `reviewer` / `check_commands` / `test_commands` / `language` and the other fallback keys are read from dev-workflow's config layers (see [`references/configuration.md`](references/configuration.md)). `mobpro` never writes to those files.

- **Same state-file schema and path** (`.claude/plans/dev-workflow.<slug>.md`): a parent task started under `mobpro` can be resumed with `/dev-workflow --resume <slug>`, and vice versa.

- **Install requirement**: `mobpro` MUST be installed via the `dev-workflow-bundle` plugin.

## Runtime reads (closed list)

`mobpro` reads **only** the files in the table below, via the sibling-relative path `../dev-workflow/references/<name>.md`. It never reads any other `dev-workflow` file at runtime — in particular, never `dev-workflow/SKILL.md`.

**Each file is read once**, at the earliest **Read at** point its row names, and reused for the rest of the run. `mobpro`'s own `references/` follow the same rule; the ones reached from more than one M-step name their read point in their own preamble (§ Constraint scope).

| File | Read at | Purpose |

| --- | --- | --- |

| `tier-assessment.md` | M2 (Normal: before the decomposition proposal; Resume: after the subtask picker) | § Tier criteria and § Resolution procedure — the difficulty tier and the express lane it selects. Read it through M2 sub-step 1's adjustments list, which names what `mobpro` does not adopt |

| `tier-escalation.md` | M3 / M6 (only when a re-assessment came out strictly higher) | § Tier-change sites and § What an escalation does — the one-way rise M3 sub-step 4's **Confirm difficulty** and M6 sub-step 6's **Tier escalation checkpoint** hand off to |

| `task-decomposition.md` | M2 (Resume sub-mode always; Normal sub-mode on the full lane only) | The shared core both sub-modes need — § State file schema / § Canonical state-file path / § Parent-task progress row |

| `task-decomposition-normal.md` | M2 (Normal sub-mode, full lane only — the express lane proposes no decomposition) | § B decomposition procedure — the yes / adjust / no gate and state-file creation |

| `task-decomposition-resume.md` | M2 (Resume sub-mode only) | § A resume procedure — state-file validation and the subtask picker |

| `prerequisites.md` | M1 / M7 | Callee retry / fallback protocol (reviewer 3-option fallback, `simplify`→`tidy` resolution, etc.). M4 and M9 apply the same protocol when a reviewer call fails, working from this read rather than taking one of their own |

| `localization.md` | M3 | The localization boundary every user-facing output follows — the plan's shape is mobpro's own `references/plan-shape.md` |

| `plan-format.md` | M9 / M12 (only when a user gate emits a summary preamble) | § User-gate summary preamble only — M9's unresolved-findings gate (sub-step 4), the persistent-violations gate its sub-step 5 reuse reaches, and M12's workability disposition gate each ask for it by name |

| `step3-plan-review.md` | M4 | The review payload definition — its **Review scope branch**, plus whichever shape that branch selects: categories a–d and the groups they split across, or § Rules-only single unit (sub-step 1 payload only; pass / stop discipline follows M4 below) |

| `visual-plan-review.md` | M5 (when the browser-reachability probe clears, or when `plan-artifact.md` § Team-review gate step 3 re-enters it — that re-entry carries no caller-side probe) | The whole file — § Procedure plus the § serve.mjs contract flags, the § Prev snapshot `cp` discipline, and § Conversation thread's write-back duties it depends on |

| `plan-figures.md` | M5 (only when the visual gate writes figures) | The whole file — the figure conventions and the SVG skeletons `visual-plan-review.md` § Figures layer sends the figure author to |

| `plan-artifact.md` | M5 (when `plan_artifact` is not `off`) | The whole file — § Publish and § Team-review gate (publishing the approved plan as a claude.ai artifact, and the gate that waits on the team's review of it), plus the § Entry condition / § Republish / § When it fails dispositions M5 sub-step 5 relies on |

| `step7.5-rules-compliance.md` | M9 | Persistent-violations gate + 2nd-cycle procedure |

| `code-review-payload.md` | M9 (only when `code_review_enabled` — M9 sub-step 3 (code review) is skipped when `code_review: false`) | § Sub-step 1 code-review payload definition (payload only; the payload carries a pointer to `review-categories.md § Code review categories` that the **reviewer** reads) |

| `step9-completion-hooks.md` | M10 | Hook execution / review-class classification / failure-continue / post-hook re-check |

| `diff-presentation.md` | M6 loop entry, both surfaces (M11 reuses it) | § Detached review object (the `<base>`..`<head>` scoping technique) + § Rendering ladder (verbatim / condensed / skeleton) |

| `interactive-commits.md` | M11 | its preamble in full, plus its § Procedure in full, from § Collect changes through § Per-commit loop and the sections after it |

| `crit-commit-review.md` | M6 / M11 (only when `commit_review_gate` resolves to `crit` **and** that gate's two crit-availability probes clear) | Diff review via crit — CLI contract, story prologue, launch. That gate stages nothing and has no unstage step (its § Procedure step 4). M11 also takes its per-commit outcome mapping; M6 substitutes its own and clears its own staged paths at M6 exit (`references/crit-diff-review.md`, reached from `references/diff-review.md` § crit path) |

| `update-rules.md` | M11.5 / M12 | § Sub-step 4 — Commit rule updates (procedure) at M11.5, for the additional commit's Build / Present / Land mechanics; at M12 both the Step 11 procedure body and § Step 11.7 sub-step 2 — PR extraction, the body M12's PR sub-phase runs |

| `session-scan.md` | M12 | Shared session-scan dispatch-once contract |

| `self-retrospective.md` | M12 (when `self_retrospective.feedback` is set, **or** as the session-jsonl resolution source below) | Step 11.5-equivalent procedure; its §1.4 owns the shared session-jsonl resolution — the only copy of that procedure |

| `workability-retrospective.md` | M12 (when `workability_retrospective.enabled`) | Step 11.6-equivalent procedure; its §1.3 does not restate the session-jsonl resolution — it defers to `self-retrospective.md` §1.4, adding two Step 11.6 substitutions |

| `finish-phase.md` | M11.5 (only when its third sub-step reaches the commit proposal) | § Step 10.5's third sub-step alone — the additional commit's fixings, which point on to `update-rules.md` § Sub-step 4 for the mechanics themselves. No other part of that file is read: M10 / M12 / M13 carry their own definitions |

| `completion.md` | M13 | § Completion reminders render bodies + staging-artifact cleanup |

**Session-jsonl resolution**: `update-rules.md` resolves the session jsonl through `self-retrospective.md` §1.4 / `workability-retrospective.md` §1.3. On a run where rule-extraction is active but **neither** retrospective is configured, M12 reads `self-retrospective.md` for that procedure alone and stops at §1.4.

**Script carve-out**: the visual gate's viewer, `../dev-workflow/scripts/plan-review/serve.mjs`, is **executed**, not read, so it falls outside this table's scope. Resolve its path by the same sibling-relative rule (and by the NEEDS-FALLBACK path below when that does not resolve) — never under `mobpro`'s own directory.

**Constraint scope**: this "read only the table" rule binds the orchestrator (this SKILL.md) and covers **dev-workflow** files only — `mobpro` freely reads its **own** `references/` (`configuration.md`, `inline-defs.md`, `learning-gates.md`, `diff-review.md`, `crit-diff-review.md`, `plan-shape.md`, `m5-plan-approval.md`, `m9-rules-code-review.md`, `m11-commit.md`) as normal skill-internal reads. It does **not** bind reviewer subagents dispatched at M4 / M9 — a reviewer following `step3-plan-review.md`'s instructions to read `review-categories.md` / the two `simplicity-self-audit*.md` files — whichever of them its own group's Reads column names — is normal and out of scope.

**NEEDS-FALLBACK path**: if the sibling-relative read cannot resolve in a given install, resolve `dev-workflow`'s source directory absolutely via `jq -r '(.plugins[] | select(.name == "dev-workflow") | .source)' <marketplace.json>` and read from there instead.

## M ↔ Step remap directive

`mobpro`'s M1–M13 map onto `dev-workflow`'s Step 1–11 / Completion one-to-one. Every reference file read at runtime is written in `dev-workflow` vocabulary, so **remap as you read it**: a `Step N` reference maps to the corresponding M below; a task-row instruction (e.g. "mark `Step 1.5` as `completed`") targets the corresponding M row; a resume-command hint (`/dev-workflow --resume <slug>`) maps to M13's two-command presentation.

| mobpro | dev-workflow Step | mobpro | dev-workflow Step |

| --- | --- | --- | --- |

| M1 Load settings | Step 1 | M8 Check / test | Step 7 |

| M2 Kickoff | Step 1.5 | M9 Rules + code review | Step 7.5 / Step 8 / Step 8.5 |

| M3 Design dialogue | Step 2 | M10 Completion hooks | Step 9 |

| M4 Plan review | Step 3 | M11 Commit | Step 10 |

| M5 Plan approval | Step 4 | M11.5 Post-commit verification | Step 10.5 |

| M6 Implementation loop | Step 5 | M12 Rule update / retrospective | Step 11 / 11.5 / 11.6 / 11.7 |

| M7 Tidy + prose polish | Step 6 / 6.5 | M13 Wrap-up | Completion |

## Learning-Stop Principle

`mobpro`'s core discipline, the pedagogical counterpart to dev-workflow's `§ No-Stall Principle`. It is a two-sided rule: `mobpro` stops **only** at the two closed lists below, and nowhere else. It takes effect once M2 has settled the effective task — so M1's reviewer-fallback prompt and M2's decomposition / leftover-picker dialogues precede the principle and are not listed here.

**(1) Learning stops (closed list).** The deliberate learning-stop points are:

- The M6 diff review — one after **each** implementation unit, always (no setting gates it). It **blocks on the junior's turn** and ends once that turn carries no further question and no change request; procedures per M6 sub-step 2 (d)'s delegation.

- A junior's question raised after M11's "point of this diff" note (respond, then continue; if no question comes, do not stop).

**Narration is not a stop.** M3's design approach, M8's error read, and M9's prediction plus cross-check ([`references/learning-gates.md`](references/learning-gates.md) § B (M8 error narration) / § C (M9 pre-review prediction narration + cross-check)) ask the junior nothing, so they never pause the run. M3's checkpoints in list (2) do stop, but what they ask for is whatever the junior still finds unclear — a gap they report, never a question they have to answer correctly: `mobpro` holds **no** quiz-style comprehension check, and no setting revives one.

**Primary-pass rule**: M9's prediction narration fires only on M9's primary pass — its post-pass aggregate re-verification and the M11.5 rules re-run do not re-fire it. M8's error narration is exempt.

**(2) User gates (closed list — approval / judgment).** M3 plan-building checkpoints (M3 sub-step 2.5's **Plan-building checkpoints** gate); M5 plan approval and, when `plan_artifact` is `review`, the M5 team-review gate that follows it (`../dev-workflow/references/plan-artifact.md` § Team-review gate); M8 check/test fail-stop (error-stop after 3 retries) and the two scope stops; M9 persistent-violations gate (not under the `fast` run mode — § Run modes — and not on the express lane, whose skip of M9's rules half takes the gate with it) and unresolved-findings gate (the latter only when `code_review_enabled`); M11 commit gates (stashing-hook incompatibility / commit-plan approval / per-commit accept — minus the commits the already-reviewed skip option covers / fold-or-defer / ambiguous-adjust); the M11.5 post-commit fix commit gate and the fold-or-defer sub-gate it inherits (both skipped by M11.5 sub-step 3's own two skip cases); M12 gates (confirm-remaining-steps, which always fires since the PR sub-phase is always enabled / rule-update commit, only where the rule-update sub-phase runs, so not on the express lane / workability disposition / the PR-spec prompt and the PR rule-update commit gate that follows it, both only on the branches that chose to run the PR sub-phase); M13 deferral-exclusion gate and PR-URL prompt.

Every stop in list (1) fires at every tier without exception, and so does every gate in list (2) but the ones annotated above: M9's persistent-violations gate, M9's unresolved-findings gate, and M12's rule-update commit gate. M12's PR-spec prompt and the PR rule-update commit gate behind it are outside this paragraph's subject: they turn on the junior's answer at sub-step 1's gate, not on the tier or the run mode. A change that would let the tier or the run mode reach a further entry is checked against this paragraph before it lands anywhere else.

## Cross-step state variables (initialized at M1)

`base_commit` (recorded at M3) / `plan_review_enabled` / `plan_review_scope` (both resolved at M1 sub-step 3's review-phase resolution) / `code_review_enabled` / `bundle_skills_unavailable = []` / `landed_count = 0` (incremented by M11 on a landed commit) / `implementation_diff_paths` (recorded by M6 step 5's implementation-diff snapshot) / `implementation_boundaries = []` (appended by M6's per-unit review as each unit's object is accepted — [`references/diff-review.md`](references/diff-review.md) § Per-unit review range step 3; read by M11 as the Build-order boundary chain that `../dev-workflow/references/interactive-commits.md` § Propose commit plan consumes) / `m9_fix_files = []` (files edited by M9's rules-compliance fixes and its code-review fixes alike; read by M9's post-pass aggregate re-verification) / `commit_fix_files = []` / `deferred_commit_fixes = []` / `post_commit_fix_landed = false` (the commit phase's three, written across M11 and M11.5 — `commit_fix_files` accumulates every applied commit-phase edit — each `crit` round's, per `../dev-workflow/references/crit-commit-review.md` § Round verification and fix accumulation, the junior's own gate-time edits per that file's sibling `interactive-commits.md` § Mid-loop adjust branch **g**, and M11.5's own, `deferred_commit_fixes` queues the requests `../dev-workflow/references/interactive-commits.md` § Deferred commit-phase fixes could not answer in the commit under review, and `post_commit_fix_landed` is written at M11.5 alone, recording its additional commit and leaving `landed_count` alone, and is read at M13. All three keep their dev-workflow names; only `review_fix_files` is renamed below) / `session_scan_dispatched = false` / `session_scan_result = null` (M12 dispatch-once contract) / `state_file_path = null` (the decomposition state file's **resolved absolute path**, set at M2 in both sub-modes — `../dev-workflow/references/task-decomposition-resume.md` § A step 2 on Resume, state-file creation on Normal — and read by M4's subtask scope and M13's lifecycle; **never** re-derived from `slug`; stays `null` on an undecomposed run). `run_mode` (set at M1 sub-step 1's settings resolution; read by every skip site § Run modes lists) / `fast_mode_skipped_steps = []` (the ledger those sites append to — both are initialized at that same sub-step 1, so M1 sub-step 5's init pass leaves them as it finds them rather than clearing the record sub-step 3 already appended). `tier = null` / `difficulty_skipped_steps = []` (the difficulty tier and the ledger of rows it skipped, both written by M2 sub-step 1's tier resolution through `../dev-workflow/references/tier-assessment.md` § Resolution procedure and § Row marking; read by every skip site M2 sub-step 1's express-lane list names, and rendered by M13's Difficulty-skip reminder. An escalation re-runs that procedure and rebuilds both. `tier` stays `null` only before M2 has settled it). `mobpro` does **not** carry dev-workflow's `review_fix_files` — the M9 fix aggregate uses `m9_fix_files`.

## Configuration

`mobpro` has **no configuration of its own**. It reads dev-workflow's three config layers for the project-characteristic keys, plus `~/.claude/settings.json` as the last link in `language`'s fallback chain. The full schema is in [`references/configuration.md`](references/configuration.md). Every pedagogical choice is fixed rather than configurable (§ Learning-Stop Principle).

**Settings merge strategy**: the fallback keys merge across the dev-workflow layers with dev-workflow's per-class semantics — read [`references/inline-defs.md`](references/inline-defs.md) § (a).

## Run modes

`--fast` and `--deep` are **invocation modifiers**, not config keys: M1 sub-step 1 sets `run_mode` from this invocation's flags — `--fast` → `fast`, `--deep` → `deep`, neither → `normal`. **Passing both is a fatal error**: halt with a diagnostic naming both, rather than picking one.

M4 (Plan review) is what the axis decides, and **this is the derivation M1 sub-step 3 applies**: `fast` → `plan_review_enabled` disabled, scope `full`; `normal` → enabled, `rules-only`; `deep` → enabled, `full`. The difficulty tier is the other axis, resolved later at M2 sub-step 1, and M1 sub-step 3's **Where each phase can still be turned off after this sub-step** paragraph holds what it does to these two flags. Neither run-mode flag touches `code_review_enabled`.

Beyond M4 (Plan review), `deep` changes nothing today, and `fast` trades the passes below and **nothing else** — every learning stop in § Learning-Stop Principle list (1) still fires, M6's per-unit diff review included, and so does every list (2) gate but the M9 persistent-violations one, M3's plan-building checkpoints included.

The closed list of what the `fast` run mode skips, each with the site that performs the skip and the `fast_mode_skipped_steps` record it appends:

| Skipped | Site | Ledger record |

| --- | --- | --- |

| M4 (Plan review) | M1 sub-step 3 derives `plan_review_enabled = false` from `run_mode` | `M4 — Plan review skipped (fast mode)` |

| M5's plan-body prose polish | [`references/m5-plan-approval.md`](references/m5-plan-approval.md)'s **Plan-body prose polish** paragraph | none — a silent skip, since the user gate follows immediately |

| M7's `prose-polish` pass | M7 sub-step 3's `prose-polish` call | `Prose polish skipped (fast mode)` |

| M9's rules re-verification (2nd cycle + persistent-violations gate) | [`references/m9-rules-code-review.md`](references/m9-rules-code-review.md) sub-step 5's **`fast` run mode's 1-pass cap** paragraph, and M11.5 sub-step 2's re-run of it | `Aggregate rules re-verification skipped (fast mode)` at M9's own site; `Post-commit rules re-verification skipped (fast mode)` at M11.5 |

Every record lands in `fast_mode_skipped_steps` (§ Cross-step state variables), which M13 renders through the Fast-mode-skip reminder. That reminder renders each record's **phase-name part** and supplies the cause itself, so a record must identify its site inside that part rather than in a trailing parenthetical.

## Workflow artifacts (cross-step fixed exclusion)

The full definition is transcribed in [`references/inline-defs.md`](references/inline-defs.md) § (b) Workflow artifacts. M6 / M7 / M9 / M11 / M11.5 apply that single shared exclusion when building any changed-file set.

## Comment discipline

Binds every edit this run makes — M6's unit edits, M7's cleanup, M9's rules-compliance and code-review fixes, and any fix applied from an M10 hook's findings.

**Writing one**: the default is no comment. Write one only where the *why* is non-obvious — a hidden constraint, a subtle invariant, a workaround for a specific bug, behavior that would surprise a reader — and hold it to a single line. A comment that restates what the adjacent code already expresses is deleted, or condensed to the why it does carry. An explanation for the junior belongs in the M6 walkthrough, never in a comment.

**Taking a finding**: a review finding whose fix is to add a comment, lengthen one, or restore one an earlier layer deleted is **rejected with that reason** — whatever severity it carries, and whichever callee raised it. Correcting a comment that states something untrue about the code is not an addition: replace it with the shorter true statement, or delete it. The junior's own request is not a callee finding — when they ask for a comment, write it.

## Phase naming in user-facing output

`M1`–`M13` are **internal identifiers**. Never let a bare identifier stand alone in anything the junior reads: chat prose, status lines, gate prompts, skip notes, ledger records, the wrap-up summary, and the task rows themselves. Pair it with what that phase does, or **drop the number** and name the phase. The test is one question: **could the reader recover the meaning from this line alone?** Take the name from that M-step's own heading, minus any trailing parenthetical — so `## M8 — Check / test (quality gate, max 3 retries)` yields `M8 — Check / test` for a task-row subject, and `M8 (Check / test)` in prose. The three ledgers M13 renders are the carve-outs where the **drop the number** option is available. `bundle_skills_unavailable`'s `<context>` slot takes it (`extract-rules unavailable (rule update)`, per [`references/inline-defs.md`](references/inline-defs.md) § (f)). `fast_mode_skipped_steps` records are written out in full at § Run modes' table, each already resolved against this rule. `difficulty_skipped_steps` records are written out in full at M2 sub-step 1's express-lane table, each already resolved against this rule; `../dev-workflow/references/tier-assessment.md` § Row marking's own examples name dev-workflow's steps and are not the form to copy. M13's Difficulty-skip reminder renders each record's **phase-name part** and supplies the tier itself, the same way the Fast-mode-skip reminder does — so a record's `(<tier> tier)` suffix is the reminder's, not the phase name's. That file's § Difficulty log line takes the same M-name substitution. The same holds for any **drop the number** label authored inside a shared `dev-workflow` reference file (`Check / Test:` at M11, `the rule-update phase` at M13): that wording belongs to the file, not to this heading list. The name itself stays in English on every `language`. This governs output only — it leaves untouched the identifiers this file uses in its own cross-references, which follow their own number-plus-stable-descriptor rule.

The parenthesized prose form takes the resolved language's own parentheses. Paired bilingual sample (runtime rendering demonstration):

- `language: ja`: `M8（Check / test）`

- `language: en`: `M8 (Check / test)`

## Direct Agent dispatch sites

`mobpro` reaches for the `Agent` tool at exactly these sites — a closed list; everything else delegates through `Skill(<name>)` or launches a process via background Bash. `Counterpart of dev-workflow SKILL.md § Configuration's Agent tool usage bullet; the two lists differ by design and are kept in sync only in shape.`

- **M9's two review dispatches** — `rules-review` and the code reviewer, launched together when background dispatch is available ([`references/m9-rules-code-review.md`](references/m9-rules-code-review.md) § **Concurrent dispatch of both reviews**).

- **M10's review-class `hooks.on_complete` entries** — dispatched concurrently by `../dev-workflow/references/step9-completion-hooks.md` when background dispatch is available. This site is per-project: it exists only where `hooks.on_complete` names at least one review-class skill.

- **M12's shared session scan** — one dispatch per run (M12 sub-step 3).

M5's visual gate and the M6 / M11 `crit` gates launch a process too, but via **background Bash**, so they are not on this list.

## Dispatch authorization

This skill's procedure dispatches subagents, so invoking the skill **is** the request to use that mechanism: an ambient instruction allowing subagent dispatch only when the user asked for it — a **permission-shaped restriction** — is already satisfied by this invocation. Do not ask the user to re-confirm the dispatch, and do not silently substitute inline execution for a dispatch this procedure specifies. Only two things justify that substitution: **technical availability** (the dispatch tool is not present and callable on the current tool surface), and an **explicit contract term from the caller** bounding this skill to its own thread. A permission-shaped restriction is neither.

## M1 — Load settings

1. **Resolve settings**: read [`references/configuration.md`](references/configuration.md) § Resolution procedure and follow it from top to bottom, applying its step 1.5 `--artifact` override to the `plan_artifact` that step 1 resolved. Resolve `run_mode` here too — it comes from this invocation's flags rather than from any of those files (§ Run modes) — and initialize `fast_mode_skipped_steps = []` alongside it.

2. Read `../dev-workflow/references/prerequisites.md`. Probe the resolved reviewer with a one-word `ping`; on failure retry once; on persistent failure present that file's three-option fallback prompt (switch reviewer / self-review / pause at the gate). Failure is the criterion that file's § Prerequisite skills' **Cleanup skill** bullet states for every callee: a `Skill()` call that returns is a pass, and the probe does not additionally verify that a review would run. Initialize `bundle_skills_unavailable = []` (append discipline per that file).

3. Derive `plan_review_enabled` / `plan_review_scope` from `run_mode` per § Run modes, and resolve `code_review_enabled` from config `code_review` (a boolean, default on; a non-boolean warns and falls back to on, per [`references/configuration.md`](references/configuration.md) § Resolution procedure step 1). `Source of truth for the run-mode derivation: dev-workflow references/step1-load-settings.md § Sub-step 4 — review-phase resolution; keep in sync.` **Where each phase can still be turned off after this sub-step**: only M2 sub-step 1's tier resolution, and only on the **Trivial** tier, which lowers both (`../dev-workflow/references/tier-assessment.md` § Resolution procedure step 2). Every other tier leaves both as this sub-step set them, and the only thing that raises one back is an escalation re-deriving them (M3 sub-step 4's **Confirm difficulty**, M6 sub-step 6's **Tier escalation checkpoint**). **A configured `code_review: false` is honored**: it turns the code phase off (M9's code review — that step's own entry condition below). When `run_mode == "fast"`, append the record § Run modes' M4 row defines to `fast_mode_skipped_steps`. `code_review_enabled` is untouched — of the two review phases the axis reaches the plan one only (§ Run modes).

**Disabled review phases** are a separate case. When `plan_review_enabled` is `false`, register the `M4` row directly as `completed`. When `code_review_enabled` is `false`, register the `M9` row `pending` as usual — M9 still runs, since its rules-compliance work is not gated on the code phase (M9's "Entry condition — the step is entered on every run" paragraph).

**Rows the tier skips are not decided here.** The tier is not resolved until M2, so register every row this burst covers as it stands and let M2 sub-step 1's tier resolution mark the skipped ones `completed` through `../dev-workflow/references/tier-assessment.md` § Row marking.

**Pre-completed row guard**: a step that finds its own row already settled on arrival — `completed`, or, on the progress-file surface, that row's last line being a skip — takes the skip rather than its procedure, and does not re-mark the row `in_progress`. A row whose last line reopened it is not settled. This is the label § Row marking's opening sentence points at.

5. Initialize the § Cross-step state variables.

6. Emit the Language checkpoint (`Output language: <lang>`).

## M2 — Kickoff

1. **Resolve the difficulty tier**: read `../dev-workflow/references/tier-assessment.md` and run its § Resolution procedure (that file's, not the same-named section in [`references/configuration.md`](references/configuration.md)), remapping every `Step N` it names per § M ↔ Step remap directive. **What it is assessed against, and when**: in Normal sub-mode, the user's request, here — sub-step 2 branches on the result. In Resume sub-mode, the subtask sub-step 3's picker selects, so run it once that pick has settled rather than here. Four adjustments and one non-adoption:

- **Two of § Lanes' rows name files `mobpro` never reads.** Its Step 2 plan-authoring row and its Step 2 Simplicity self-audit row both point at dev-workflow plan machinery: `mobpro` writes every plan from [`references/plan-shape.md`](references/plan-shape.md) § Template at every tier, and adopts no self-audit (M3's non-adoption list). Ignore both rows.

- **Its Step 4 approval-surface row does not transfer either.** M5 keeps the browser gate at every tier, Trivial included — the plan is written for the junior to read, so the approval surface is a learning surface and the tier does not reach it.

- **§ Row marking's two fast-mode bullets do not transfer, with one part of them that does.** `mobpro` appends its own `fast_mode_skipped_steps` records at the sites § Run modes' table names — the M4 record at M1 sub-step 3, the polish record at M7 — so applying the bullets whole would append a second copy of each. What does transfer is the first bullet's **On the Trivial tier append nothing** carve-out, which those sites cannot apply for themselves because M1 sub-step 3 runs before the tier exists: **when the tier comes out Trivial, remove the M4 record M1 sub-step 3 appended**, and **re-append it whenever a later run of this procedure leaves the tier above Trivial with `run_mode == "fast"` and the record is not already in the ledger** — an escalation re-derives the phase off the run mode again, so the skip is a fast-mode one from that point on. An escalation out of **Simple** never removed the record, so it re-appends nothing. § Row marking's remaining bullets apply, with the rows remapped per the table below.

- **Pointers out of the closed list are not followed.** Both tier files cite `dev-workflow` files § Runtime reads does not carry, several of them as a source of truth for a condition. Read none of them, whatever the citation calls itself, and take each condition as the citing file states it. Two such pointers do resolve in this tree: § Row marking's **Pre-completed row guard**, which M1 sub-step 4 carries under that label; and both tier files' pointers to `step1-load-settings.md` § Sub-step 7 — registration mechanics for the progress-file form of a skip or a reopen, which [`references/inline-defs.md`](references/inline-defs.md) § (h) carries.

- **`subagent_model` is not adopted** ([`references/configuration.md`](references/configuration.md) § Not-adopted keys): skip that file's § Resolution procedure step 4 and leave the key unresolved. Steps 1–3 and 5 apply as written; step 5's log line names its phases per § Phase naming in user-facing output.

**What the express lane skips in `mobpro`** — this table replaces § Difficulty-skip matrix's list, and its Ledger record column replaces the record § Row marking's express-lane bullet would otherwise derive — one per table row, whether or not that row is a task row. `<tier>` is the assessed tier's own name.

| Skipped | Site | Ledger record |

| --- | --- | --- |

| M7 (Tidy + prose polish), whole | M7's entry condition | `M7 — Tidy + prose polish skipped (<tier> tier)` |

| M9's rules-compliance half — its sub-step 2, and with it sub-step 5's second gate | M9's entry condition | `M9 — Rules + code review: rules compliance skipped (<tier> tier)` |

| M12's rule-update sub-phase — its sub-step 2 | M12 sub-step 2 | `M12 — Rule update skipped (<tier> tier)` |

**Only `M7`'s row is marked `completed` here.** The other two skips are halves of steps that keep running, so their rows stay `pending` and each skip is taken at the Site the table names, from `tier`. Applying § Row marking's express-lane bullet to the `M9` or `M12` row would take the whole step out — with M12 that removes both retrospectives and the PR sub-phase, which § Learning-Stop Principle keeps outside what the tier reaches at any tier.

A **Trivial** tier turns both review phases off on top of that, reaching **M4 (Plan review)** and **M9's code half**. § Row marking's own Trivial bullet marks rows without appending, so neither takes a record here — and of the three rows it names, only the one that maps to `M4` exists in this tree: `mobpro` has no counterpart to `Step 8` / `Step 8-1`, since the `M9` row stays `pending` on every run (M9's entry condition). Everything else runs at every tier — M3's plan-building checkpoints, M6's per-unit diff review, M8, M11, M13, both retrospectives, and M12's PR sub-phase included. **The tier scales the quality machinery and never a learning stop**: what § Learning-Stop Principle's two closed lists hold does not vary by tier, and that section's closing paragraph is where a change touching either is checked.

**The express lane also skips the decomposition proposal**: sub-step 2 then reads neither decomposition reference, sets the effective task to the original request, and hands straight to sub-step 6. Resume sub-mode is untouched by that — its state file already exists.

2. **Normal sub-mode**: on the **express** lane take the skip the sub-step above defines and go to sub-step 6. On the **full** lane, read `../dev-workflow/references/task-decomposition.md` for the shared core, then `../dev-workflow/references/task-decomposition-normal.md` § B and follow it. Consider the walking-skeleton decomposition axis as the default candidate and shape the first proposed subtask as "get the minimal happy path working" (proposal-priority only — the § B.1 one-line rationale label still follows that axis's discriminator). The yes / adjust / no gate, state-file creation, and progress row are used verbatim from that reference.

3. **Resume sub-mode** (`--resume <state-file>`): read `../dev-workflow/references/task-decomposition.md` for the shared core it depends on — § State file schema (validate the invariants on every read), § Canonical state-file path (this is what sets `state_file_path`), and § Parent-task progress row — then `../dev-workflow/references/task-decomposition-resume.md` § A and follow it. Two notes: § A step 5's all-subtasks-completed branch routes to the Completion cleanup path (M13 territory), not to M3 — § A's own delete-report-stop applies verbatim there, so none of M13's lifecycle chain runs on a run that executed nothing; and § A step 3a's planning-draft recovery continues in **Normal sub-mode** as written. **Reset `state_file_path` to `null` when 3a fires.** **Then run sub-step 1's tier resolution**, which this sub-mode deferred to here: assess it against the subtask the picker settled on, or — when 3a fired — against the request the Normal continuation is now planning. The run has no tier until this happens, so it is owed on every path out of here that reaches M3.

4. On decompose-accept, add a `Created by: mobpro` line to the state-file body (frontmatter schema unchanged).

5. **Deliberately not adopted**: an up-front learning-goal question.

6. Settle the effective task and proceed to M3.

## M3 — Design dialogue

1. Record `base_commit`: `git rev-parse HEAD`.

2. **Design-approach narration**: state in 2–3 lines how you intend to build it, name the obvious alternative, and say why this shape beat it. Ask the junior nothing — this is narration, so it does not pause the run (§ Learning-Stop Principle's "Narration is not a stop" paragraph).

2.5. **Plan-building checkpoints (USER GATES)**. Before the plan document is written, do the research the plan rests on and hand it to the junior in installments rather than all at once. Run this **once per run**. When a checkpoint's findings undercut sub-step 2's approach narration, say so at that checkpoint and restate the approach.

- **Explain the existing code before what you concluded from it.** Walk the code each checkpoint rests on first: what the relevant part does today and how it is put together, then what follows from it for the plan.

- **Segment that walk into 2–5 checkpoints** by how much the junior has to hold at once rather than by how much you found — one coherent piece each: the part of the codebase a decision turns on, a constraint that rules an approach out, the Build order you propose.

- **Do the reading on the main thread**, narrating as you go. Never delegate this research to a subagent.

- **Each checkpoint is a partial approval**, covering only what was shared at that point. Per checkpoint: explain, then ask in chat what is still unclear, and wait for the reply. **Only a reply saying nothing was left open advances past a checkpoint** — on anything else, do not advance; take the action § E's matching reply bucket names. Keep it in sync with § E's "One reply closes a checkpoint" paragraph. Read [`references/learning-gates.md`](references/learning-gates.md) here and follow § E (M3 plan-building checkpoints) for the prompt wording, the reply classification, and the length.

3. Author the plan document and `Write` it to `.claude/plans/<slug>.md`, following [`references/plan-shape.md`](references/plan-shape.md) § Template. **Keep any YAML frontmatter the document already carries** and replace the body beneath it, on an M5 re-entry as on the first write (`../dev-workflow/references/plan-format.md` § Step 4 presentation order's plan-document bullet). Localization follows `../dev-workflow/references/localization.md`. Apply `custom_instructions` to plan priorities. **Resolve `<slug>` once per run and reuse it verbatim on any M5 re-entry**: take the state file's `slug` when `state_file_path` is non-`null`, else derive a kebab-case slug from the effective task (transliterate non-ASCII where reasonable, strip punctuation, lowercase), suffixing `-2`, `-3`, … only on collision with an existing `.claude/plans/<slug>.md` from a **prior** run (`Keep in sync with dev-workflow references/step4-finalize-plan.md's Establish the plan document paragraph.`). M5's `visual` gate derives its own paths from the same slug (§ Workflow artifacts), so re-resolving it mid-run would orphan them.

4. **Confirm difficulty**: re-assess the drafted plan against `../dev-workflow/references/tier-assessment.md` § Tier criteria. Act **only when the new assessment is strictly higher** than `tier`; an unchanged or lower assessment writes nothing, and the tier never falls. When it is higher, read `../dev-workflow/references/tier-escalation.md` and follow § What an escalation does with the four adjustments below. This is the **first of two escalation checkpoints** — the other is M6 sub-step 6's **Tier escalation checkpoint**, once every unit has landed — and the two are the whole of that file's § Tier-change sites here. `mobpro` has no counterpart to its third, independent site: M5's adjust bucket never re-derives the tier itself, it routes back into this checkpoint (see below).

M2 sub-step 1's adjustments carry over unchanged; these four are the escalation's own.

- **Its step 1 does not reset `fast_mode_skipped_steps`.** That ledger is appended at `mobpro`'s own sites (§ Run modes' table), not by § Row marking, so clearing it would drop records nothing re-appends. Reset `difficulty_skipped_steps` alone.

- **Its step 2 reverses only rows the express-lane table marked, plus `M4`** — so `M7` today, and `M4` only when a Trivial tier marked it and the re-derived `plan_review_enabled` comes out `true`. M9's row is registered `pending` on every run and is never a skip to reverse; M12's rule-update sub-phase is not a row of its own, so it simply returns to sub-step 1's gate listing.

- **Its step 3 does not transfer** — restructuring the plan for the full lane has no target here, since M2 sub-step 1's first adjustment holds the plan shape and the self-audit at every tier.

- **Its steps 4 and 5 apply**, with the note naming its phases per § Phase naming in user-facing output. Resume from here: into M4 when the re-derived `plan_review_enabled` is `true`, into M5 when it is `false`.

Where § Escalation's invariants send something to a `Risks` entry, write it to the plan's `Watch-outs` section instead ([`references/plan-shape.md`](references/plan-shape.md) § Review lens holds that mapping).

**The M5 gate reaches this checkpoint too.** A material change accepted at M5's adjust bucket ordinarily re-opens M4, which re-reviews the revised plan — but [`references/m5-plan-approval.md`](references/m5-plan-approval.md) skips that leg whenever the plan phase is off, which a Trivial tier guarantees. So when the adjust bucket applies a material change and `plan_review_enabled` is `false`, return here and re-assess before going back to M5.

5. **Deliberately not adopted**: the Simplicity self-audit and the Plan self-check. dev-workflow's Step 2 codebase research happens in sub-step 2.5's **Plan-building checkpoints** gate instead.

6. Do not show the plan document to the user or ask for approval of it here — go straight to M4. What sub-step 2.5 shared is the research behind the document, not the document itself. This is where `mobpro` parts from dev-workflow's Step 2, whose matching prohibition also bars any "shall I go on?" question at this phase: sub-step 2.5's checkpoints ask exactly that, by design.

## M4 — Plan review (quality gate)

**Entry condition — skipped entirely when `plan_review_enabled` is `false`**. Two causes, and no others: `run_mode == "fast"`, which M1 sub-step 3's derivation turns the phase off for (§ Run modes), and a **Trivial** tier, which M2 sub-step 1's tier resolution turns both review phases off for. Either way this step's row is already `completed` on arrival — from M1 sub-step 4's registration burst on the first cause, from § Row marking on the second — so do not re-mark it: go straight to M5, whose presentation carries no "open points".

Otherwise, run the single review pass:

1. Reuse `../dev-workflow/references/step3-plan-review.md` sub-step 1's review payload definition and pass the full plan + `custom_instructions` + the state-file subtask scope (when decomposed) to `Skill(<reviewer>)`. That sub-step's **Review scope branch** applies here as written and picks the shape: on `full`, categories a–d split across the groups that file's table draws, dispatched in parallel; on `rules-only`, its § Rules-only single unit request, whose `.claude/rules/` paths you enumerate yourself as that section directs. Three adjustments and one non-adoption:

- **The mapping rule goes to every group.** [`references/plan-shape.md`](references/plan-shape.md) § Review lens translates the section names a `dev-workflow` plan uses into the ones a `mobpro` plan uses (`Decisions` → `Choices I made`, and so on). Hand it to **every** group, not only the one holding category (d).

- **The `plan-authoring.md` substitution**: in whichever group's Reads column names `plan-authoring.md` for the `Decisions` (a)+(b) criterion and § Step 3 (d) content-quality rubric, hand it `references/plan-shape.md` § Template instead.

- **The Empty-Decisions drop**: in whichever group's Reads column names `plan-format.md` § Empty-Decisions fixed sentences, omit that item rather than mapping it.

- **Deliberately not adopted**: anything in that file beyond sub-step 1's payload definition — in particular sub-step 3's **Approach-reconsideration self-audit (fires at most once per run)** bullet: do not rewrite the plan and re-dispatch the review on its threshold.

**On `rules-only`** hand [`references/plan-shape.md`](references/plan-shape.md) § Review lens to the single unit for its mapping rule, writing that path into the enumerated Reads list alongside the `.claude/rules/` paths and `review-categories.md` so that section's tool restriction covers the read rather than barring it; the other two adjustments find no target in its Reads column and no-op.

2. Judge the response semantically: no actionable findings → mark the `M4` row `completed` and go to M5.

3. Findings → apply to the plan (reject unreasonable ones with a stated reason), then **teach**: explain each applied finding as "what review lens this is" in 1–2 lines, then mark the `M4` row `completed`. Do not re-dispatch the reviewer here. **The one exception** is M5's adjust bucket, which re-opens this row and re-runs the pass against a *revised* plan rather than iterating on the same one.

4. Carry any unresolved points into M5's presentation as "open points".

## M5 — Plan approval (USER GATE)

The plan-body prose-polish pass, the approval surface (the visual gate degrading to chat), the plan narration, the accept / adjust / withdraw outcome classification, and the plan-artifact publish that follows an accept are in [`references/m5-plan-approval.md`](references/m5-plan-approval.md); `Read` it and follow the procedure from top to bottom.

## M6 — Implementation loop

1. **Unit segmentation**: each `Build order` step in the plan is one unit — register them as implementation sub-rows (additions, not a replacement of the M6 row), splitting any step that covers more than one meaningful change into one row per change as you register it. If the plan carries no `Build order` section, segment it into 3–10 units yourself under the same rule. Initialize the loop-local state [`references/diff-review.md`](references/diff-review.md) defines — `m6_review_base` (to `base_commit`), `m6_staged_paths` (to `[]`), and `m6_crit_available` (unset until its probe runs). All three are M6-loop-local, so none is a § Cross-step state variables member.

2. Per unit: (a) **preview** ≤ 6 lines (what / why / which files) → (b) **AI edits** (main-thread; never delegate to a subagent — the junior must see the edit as it happens) → (c) **walkthrough** per changed file → (d) **diff review** — read [`references/diff-review.md`](references/diff-review.md) at loop entry and apply it per unit together with [`references/learning-gates.md`](references/learning-gates.md) § A (M6 diff review), which M3 read at its sub-step 2.5's **Plan-building checkpoints** gate. `diff-review.md`'s preamble sends you to a third loop-invariant file, `../dev-workflow/references/diff-presentation.md` — read it at the same point. Preview and walkthrough lengths follow [`references/learning-gates.md`](references/learning-gates.md) § D (explanation length discipline).

3. Apply `custom_instructions` throughout. Per the § Workflow artifacts exclusion, treat `.claude/`-internal state files as excluded from every downstream changed-file enumeration.

4. After the last unit's review resolves, run the **M6-exit unstage** defined in [`references/diff-review.md`](references/diff-review.md) § Per-unit review range.

5. After all units land, record `implementation_diff_paths = git diff <base_commit> --name-only` (read by M11's Post-hook attribution check).

6. **Tier escalation checkpoint**: with every planned edit landed and sub-step 5's snapshot recorded, re-assess the finished change against `../dev-workflow/references/tier-assessment.md` § Tier criteria. This is the second of the two checkpoints M3 sub-step 4's **Confirm difficulty** names. Its first three adjustments apply here as written — the second under § What an escalation does step 2's own **forward of the checkpoint only** proviso, which leaves `M4`'s row alone here since this run has passed it. Its fourth applies with **the resume point set to M7**, so the note names only the phases still ahead of that.

## M7 — Tidy + prose polish (quality gate)

**Entry condition — skipped entirely on the express lane** (Trivial or Simple), where M2 sub-step 1's express-lane list drops the whole step and § Row marking has already left its row `completed`. Do not re-mark it `in_progress` and go straight to M8. On the full lane the step runs, and only sub-step 3's polish is skippable — by the run mode alone.

1. Call `Skill(simplify)`; if unavailable, `Skill(tidy)` (pass `Base ref: <base_commit>`). Resolution / both-unavailable skip / ledger append follow `../dev-workflow/references/prerequisites.md`'s Cleanup skill bullet.

2. If cleanup changed anything, explain why in 1–2 lines (e.g. "this duplication was a future maintenance hazard, so it was pulled into one function").

3. If `polish_prose` is true **and `run_mode` is not `fast`** (§ Run modes), call `Skill(prose-polish)` in file mode (`Language:` = resolved language, no `Model:`). On failure retry once, then skip and append `prose-polish unavailable (prose polish pass)` to `bundle_skills_unavailable`. When the run mode is what skips it, append the record § Run modes' M7 row defines to `fast_mode_skipped_steps`. A `polish_prose: false` skip records nothing.

## M8 — Check / test (quality gate, max 3 retries)

1. Run `check_commands` in order; on all-pass, run `test_commands` in order (each entry must be of the form `Skill(<name>)`). **Missing test skill**: when a `test_commands` entry names a skill that does not exist (the `Skill()` call fails as not-found, after one retry), that is **not** a test failure — emit the note below, skip that entry, and continue; the retry budget is untouched and the error narration does not fire.

- `language: ja`: `test_commands の \`Skill(<name>)\` が見つかりませんでした — このエントリを skip します。テストを走らせるには test_commands にこのプロジェクトに存在するスキルを設定してください（設定方法は README § Configuration）。`

- `language: en`: `test_commands entry \`Skill(<name>)\` was not found — skipping it. To run tests, point \`test_commands\` at a skill that exists in this project (see README § Configuration).`

2. **On failure**: narrate the read of the error — which part of the message you read and what it says — then fix it without stopping to ask the junior anything (prompt shape and the every-failure rule in [`references/learning-gates.md`](references/learning-gates.md) § B (M8 error narration)). Fix → re-run, up to 3 retries; exceeding that reports and stops (error-stop).

3. **Scope stops**: two step-internal USER GATES apply during `check_commands` (the only non-completing exits here) — the pre-execution scope-narrowing stop and the scope-drift stop. Read [`references/inline-defs.md`](references/inline-defs.md) § (c) and apply both.

## M9 — Rules + code review (quality gate)

**Entry condition — the step is entered on every run**, including when `code_review_enabled` is `false`; what it finds to do is what varies. Two independent gates decide that, and the row is never pre-`completed`:

- **`code_review_enabled: false`** gates **only** sub-steps 3 and 4 (the code-review pass and its unresolved-findings gate). Both causes reach it — a configured `code_review: false`, and a **Trivial** tier.

- **The express lane** (Trivial or Simple) drops sub-step 2's rules-compliance work, and sub-step 5's second gate goes with it.

Sub-step 1's pre-review prediction narration and sub-step 5's first gate stay in force under both, with one consequence worth naming: on a **Trivial** run both gates have fired, so there is no dispatch left to predict for and nothing lands in `m9_fix_files`. Say in one line that neither review ran and why, mark the row `completed`, and go to M10 — the narration has no target to invent one for.

The pre-review prediction narration, the concurrent dispatch of both reviews, the rules-compliance and code-review passes, the unresolved-findings USER GATE, and the post-pass aggregate re-verification are in [`references/m9-rules-code-review.md`](references/m9-rules-code-review.md); `Read` it and follow the procedure from top to bottom.

## M10 — Completion hooks

Skip (and do not register) when `hooks.on_complete` is unset. Otherwise, before executing any entry, apply the **task-derived-change gate** transcribed in [`references/inline-defs.md`](references/inline-defs.md) § (d) — skip the whole `hooks.on_complete` list (marking M10 `completed` with a skip-reason line) when there are no task-derived changes since `<base_commit>`. When the gate passes, read `../dev-workflow/references/step9-completion-hooks.md` and run each entry in order (review-class classification, failure-record-and-continue, post-hook re-check).

## M11 — Commit (USER GATES)

**Read [`references/m11-commit.md`](references/m11-commit.md) first** — the Procedure below consumes its definitions as it runs, not after it. Then read `../dev-workflow/references/interactive-commits.md` and follow its **Procedure** from top to bottom, verbatim — starting at § Collect changes, not at § Propose commit plan. Its preamble binds M11 as well: `§ Output language` governs every line M11 presents, including the two learning extensions below, and the deferred-bookkeeping paragraph runs before § Collect changes does. Two learning extensions: a 1–2 line "point of this diff" note added to each per-commit presentation, and the already-reviewed skip option [`references/m11-commit.md`](references/m11-commit.md)'s **Already-reviewed skip option (commit-plan gate)** paragraph defines. The procedure and the presented elements are otherwise unchanged. `git push` is never performed by any step.

## M11.5 — Post-commit verification

M11.5 is the commit phase's **single** verification cycle plus the commit that carries what the cycle and the deferred queue produce — dev-workflow's Step 10.5 in `mobpro` vocabulary. What an M11 `crit` round still owes, and what it defers here, is stated once in [`references/m11-commit.md`](references/m11-commit.md)'s **Diff surface (`commit_review_gate` branch)** paragraph.

1. **Apply the deferred queue.** Skip when `deferred_commit_fixes` is empty. Otherwise apply what each entry's `request` asks for, in the order they were queued, appending every edited path to `commit_fix_files`, then set `deferred_commit_fixes = []`. An entry the tree already satisfies, and one whose target no longer exists, are not forced — say which in one line each, and carry the second kind into M13's wrap-up as unapplied.

2. **Verify once**, when `commit_fix_files` is non-empty after sub-step 1. Re-run **M8 (check / test)** in full, then — only when M9 sub-step 2's rules-compliance pass actually ran this run — re-run that sub-step alone, scoped to `Files: <commit_fix_files>`, continuing into `../dev-workflow/references/step7.5-rules-compliance.md`'s sub-steps (b)–(d) rather than stopping after (a) and taking that file's **`fast` run mode's 1-pass cap** with the ledger record § Run modes' table names for this site. **M9's code review is not re-run** — the junior reviewed each unit's diff at M6 and each commit at M11. Any fix applied here appends its paths to `commit_fix_files`.

3. **Land one additional commit (USER GATE).** Read `../dev-workflow/references/finish-phase.md` § Step 10.5's third sub-step first — the one part of that file M11.5 consults — and derive this commit's path set exactly as it describes. Skip the commit in either of two cases — when M11 stopped at `../dev-workflow/references/interactive-commits.md` § Mid-loop cancel, and when that derived path set comes out empty; say which in one line and leave the work in the working tree. Otherwise propose the single commit exactly as it describes, with one substitution: judge the reply per [`references/inline-defs.md`](references/inline-defs.md) § (e)'s **Approval token closed list** bullet.

§ Learning-Stop Principle's explanation duty applies to each gate here as it does at M11: say what is being fixed and why before asking.

## M12 — Rule update / retrospective

1. **confirm-remaining-steps entry gate**: ask whether to run the remaining rule-maintenance / retrospective / PR-rule-extraction work — listing only the sub-phases this run enabled and naming each by what it does, since M12's sub-phases are not registered as rows of their own, so take § Phase naming in user-facing output's **drop the number** option — or skip to M13 (Wrap-up). The PR sub-phase (sub-step 4) is always enabled, so the list is never empty and the gate always fires. The list splits by where a sub-phase's input comes from — the first three read this session, the PR one reads a PR — so **offer a third option running the externally-sourced sub-phases alone** when the list holds at least one of each, and two options when every member falls on the same side. Each option states what it does and carries the reply token its branch accepts. On skip, mark those `completed` without running and note the skip, naming the sub-phases skipped and the junior's own choice as the cause; on the third option, do the same for the session-derived ones and continue at sub-step 4.

2. Read `../dev-workflow/references/update-rules.md` and run the Step 11 procedure body (`Skill(extract-rules)` and the rule-update commit gate). **Skipped on the express lane** (Trivial or Simple), where M2 sub-step 1's express-lane list drops this sub-phase alone: leave it out of sub-step 1's gate listing, read nothing, and go to sub-step 3. The two retrospectives there are never skipped by the tier — each is governed by its own configuration key.

3. When `self_retrospective.feedback` is set, read `self-retrospective.md`; when `workability_retrospective.enabled`, read `workability-retrospective.md`; run each in kind. The shared session scan follows `session-scan.md` § Dispatch-once contract — in `mobpro` the participants are **M12's first three sub-phases** — the PR sub-phase reads a PR, not the session, so it is not one (`session_scan_dispatched` / `session_scan_result` are the M1-declared cross-step variables, and the first sub-phase that needs the scan dispatches it once). This scan dispatch is one of the sites in § Direct Agent dispatch sites. `session-scan.md` § Inputs asks the caller to thread `subagent_model` into the scan subagent's `model`; `mobpro` does not adopt that key (`references/configuration.md` § Not-adopted keys), so omit the parameter and let the scan inherit the session model.

4. **PR rule extraction** — the sub-phase sub-step 1's third option isolates. Ask which reviewed PR to extract rules from, listing the accepted forms in the question itself and saying there that an empty answer declines, then read `../dev-workflow/references/update-rules.md` § Step 11.7 sub-step 2 — PR extraction and run it, `Read`ing that file first unless this run has already read it (the rule-update sub-phase at sub-step 2 does, but the express lane skips it), followed by the same rule-update commit gate sub-step 2 uses. Never skipped by the tier. An empty answer to the prompt is a decline — say so in one line, naming the PR rule extraction as what was skipped, and go to M13 (Wrap-up).

5. `mobpro` is itself a bundle member, so it is one of self-retrospective's improvement-signal targets (registered via that file's Purpose line).

**Step 11 / Step 11.7 skeleton**: the `rule-extraction-active` gate, session-scan wiring, the extract-rules-unavailable candidates fallback, the rule-update commit gate firing condition and its second firing, and the PR sub-phase's prompt are transcribed in [`references/inline-defs.md`](references/inline-defs.md) § (f) — apply them.

## M13 — Wrap-up (Completion)

1. Read `../dev-workflow/references/completion.md` and run the staging-artifact cleanup. All **8** of dev-workflow's § Completion reminders now have state to render from: Unfinished-phase (the run's own rows), Difficulty-skip (`difficulty_skipped_steps`), Fast-mode-skip (`fast_mode_skipped_steps`), Bundle-skill availability (`bundle_skills_unavailable`), M11 partial-state, and rule-update / examples-dir / staging-dir each fire on their own condition. The reminders' `uncommitted_*` partition scan follows [`references/inline-defs.md`](references/inline-defs.md) § (g).

2. **Learning summary**: from the units the junior reviewed and the reasoning that came with them, summarize "what was worth learning here" in ≤ 3 one-line points, plus one line each for the quality-gate outcomes (tests / review / rules).

3. When `state_file_path` is non-`null`, run the state-file lifecycle in this order, applying [`references/inline-defs.md`](references/inline-defs.md) § (g) in full for each item's discipline: deferral/exclusion gate — promote anything excluded or deferred during M6 / M8 into a tracked subtask entry → `completed` write-back → PR-URL prompt → progress-row refresh → find the next runnable subtask (smallest-id `pending` whose `depends_on` are all `completed`; when none remains, every subtask is `completed`) → then **exactly one** of two mutually-exclusive branches. **(i) A next runnable subtask exists**: next-subtask guidance (the **commit phase landed something** predicate — `landed_count > 0` **or** `post_commit_fix_landed`, transcribed at [`references/inline-defs.md`](references/inline-defs.md) § (g)'s **State-file lifecycle** bullet, since § Runtime reads never reads `dev-workflow/SKILL.md`: true → "open a PR for the landed commits, then resume"; false → "commit and open a PR first, then resume", adding the extract-rules residue warning when step 1's `uncommitted_*` sets are non-empty), rendered together with step 4's resume-command pair. **(ii) None remains (every subtask is `completed`)**: emit **no** resume guidance at all, and instead report the parent task as fully done, listing every subtask's title and its recorded `pr` (if any), the same roll-up `../dev-workflow/references/task-decomposition-resume.md` § A step 5's all-completed branch gives; **then** remove the progress row and delete the state file at `state_file_path` — the roll-up must come first, since the deletion destroys the `pr` records.

4. **Only when step 3 ran and it found a next runnable subtask** — so never on an undecomposed run, and never once the last subtask completed and the state file was deleted — render that step's next-subtask guidance as **both** resume commands (per § M ↔ Step remap directive, dev-workflow's single `/dev-workflow --resume <slug>` hint becomes the pair below):

- `language: ja`: `学びながら続けるなら /mobpro --resume <slug>、シニアに通常ワークフローで引き継ぐなら /dev-workflow --resume <slug> を実行してください。`

- `language: en`: `To keep learning through the rest, run /mobpro --resume <slug>; to hand off to a senior on the standard workflow, /dev-workflow --resume <slug>.`