git:20261108.0382b8a to git:20261108.7e14cbb

- Organize commits into a clean, logical history following project conventions.

- `SPEC.md` and `SPEC.md.draft` stand for the spec file and its draft: resolve them first, per "The

- Specification File" in `${CLAUDE_PLUGIN_ROOT}/guidelines/specification.md`.

- Before organizing commits, load:

- - `${CLAUDE_PLUGIN_ROOT}/guidelines/git-workflow.md` — all commit conventions in that file **must** be respected

- - `${CLAUDE_PLUGIN_ROOT}/guidelines/project-conventions.md` — then gather the host repository's

- conventions as it describes; Step 1 needs them to place `SPEC.md`

- The default is to **revert** it, so the specification stays in the branch history but leaves no

- file behind. Before proposing the commit structure, ask whether the user would rather keep it in the

- 1. the host repository's `CLAUDE.md` or `AGENTS.md` — a place they name for specifications, design

- 2. an existing documentation folder — e.g. `docs/specs/`, `docs/design/`, `docs/adr/` or `docs/` —

- following how the files already there are named and organized

- Name the file after the feature, in the folder's own naming style (e.g.

- `docs/specs/shared-todo-lists.md`). Never overwrite an existing file.

- - **Move it to `<inferred path>`** — one option per location found above, up to two, each

- description saying why that location fits

- - if the spec file already lives in a documentation folder (chosen after a clash), offer **Keep it

- where it is** instead of a move — it then needs no last commit

- The chosen outcome becomes the **last** commit of the proposed structure below:

- - **move** → `git mv SPEC.md <path>`, committed as `docs: move feature specification to <path>`;

- the content stays as it is

- All commit-organization rules are defined in `git-workflow.md` (loaded above); this skill **applies** them to an existing working tree / history. Its "Before Every Commit" gate applies to every commit made here, except the test run. Run no tests for a commit made here, not even an outside-in slice's acceptance test: the commits were tested while they were built. Linting, the search for old references and the comment clean-up still apply to every commit. The tests run once, at the end, as "Run the Tests Once" describes. The very last commit is the `SPEC.md` outcome chosen in Step 1.

- This skill owns **final history shaping** (reordering, splitting, the `SPEC.md` outcome); `/aido:2-implement` produced the per-unit working commits.

- 1. `## Progress` — a mode change and the slices built, as "Modes and Slices in Progress" in

- 2. the plan — the mode the item names, and its slices

- 3. otherwise inside-out — a branch with no plan, specification or mode

- - if some commits are already pushed, **add** new commits instead of rewriting history

- - if history is not pushed, you may reset/reorganize the existing commits

- - **pushing or force pushing needs the user's approval**, which the permission prompt asks for, per "Pushing Changes" in `git-workflow.md`; say first when the push would rewrite history

- Before performing any rebase or history rewrite, analyze the current commits and use `AskUserQuestion` to present the proposed commit grouping:

- Options: **Approve the grouping** / **Adjust it** (ask what to change, update the proposal, show what changed as "Showing What Changed" in `${CLAUDE_PLUGIN_ROOT}/guidelines/language.md` describes, and ask again).

- In the same `AskUserQuestion` call, offer the next step, following "each approval also settles the choice that follows it" in `/aido:1-plan`. The answer counts only when the grouping is approved, and "Hand Off" acts on it:

- Read `## Progress` first, as "Acceptance in Progress" in `specification.md` describes. The question names each criterion recorded as `unchecked` or `deferred`, so the user doesn't continue without noticing it. Always mark **Open the PR in a fresh context** as recommended, whatever `## Progress` says: organizing the commits does its own job, and whether the plan is finished is not its call.

- When `/aido:resolve-migration-conflict` runs this skill, make no offer: ask only about the grouping, and return to its "Wrap Up" when the commits are organized.

- **Wait for user approval before starting the rebase.** The rebase is destructive and hard to undo — getting alignment first avoids rework.

- Once the new history is settled, run the relevant tests once, on the final commit. "Before Every

- Commit" in `git-workflow.md` says which tests are relevant. This is the only test run this skill

- makes.

- the `SPEC.md` outcome commit when that one is not pushed yet

- default branch, the failure is not this branch's: fix nothing, and tell the user. When the run still

- can't pass, stop, and tell the user which commit fails and why: the Final Checklist does not hold.

- After organizing commits, verify ALL of the following:

- - [ ] Docs commit message is EXACTLY "docs: feature specification" (if docs present)

- - [ ] The last commit carries the `SPEC.md` outcome chosen in Step 1: "revert: docs: feature specification" (default) or "docs: move feature specification to <path>" (if docs present)

- - [ ] No `SPEC.md.draft` is left in the working tree

- - [ ] Docs commit is the FIRST commit in history (if docs present)

- - [ ] Every commit message follows "Commit Message Format" in `git-workflow.md`

- - [ ] The order and grouping follow "Commit Organization Strategy" in `git-workflow.md`, with each part

- shaped by the mode "Follow What Was Actually Built" gives it

- - [ ] The relevant tests passed in the one run "Run the Tests Once" describes

- Continue as the user chose in Step 2, without asking again:

- - **Open the PR** → once the final checklist holds, invoke `/aido:4-open-pr`. This answer approves only starting that skill: its verification offer, the push approval and the review of the PR all still happen. If the checklist can't hold, do not start it, and tell the user why

- - **Open the PR in a fresh context** → once the final checklist holds, act as **Hand-off Outcomes** in `git-workflow.md` describes. If the checklist can't hold, tell the user why