create-mercato-app 0.6.4-develop.4382.1.6b4f656b77 → 0.6.4

package/agentic/shared/ai/skills/{auto-create-pr → om-auto-create-pr}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: auto-create-pr
+name: om-auto-create-pr
 description: Execute an arbitrary autonomous agent task end-to-end and deliver it as a GitHub pull request against develop. Start by drafting an execution plan in .ai/runs/ that includes a Progress checklist, commit it on a fresh task branch in an isolated worktree, implement the work phase-by-phase with incremental commits, update the Progress checklist after every phase, optionally honor one or more external reference skills passed by URL, run the full validation gate (typecheck, unit tests, i18n, build) for any code changes, and open a PR with the correct pipeline labels. Resumable via the auto-continue-pr skill.
 ---
 
@@ -7,7 +7,7 @@ description: Execute an arbitrary autonomous agent task end-to-end and deliver i
 
 > **Standalone-mode override (READ FIRST):** This skill originated in the Open Mercato monorepo. If this copy lives inside a standalone app (scaffolded via `create-mercato-app`), apply the portability overrides in [`STANDALONE.md`](./STANDALONE.md) before anything below — in particular (1) resolve the base branch from `gh repo view --json defaultBranchRef` instead of hard-coding `develop`, (2) treat pipeline labels (`review`, `needs-qa`, `in-progress`, …) as opt-in and skip gracefully when missing, (3) probe `package.json` scripts before running each validation-gate step, and (4) read `src/modules/…` paths instead of `packages/<pkg>/src/modules/…`. Where `STANDALONE.md` and this file disagree, `STANDALONE.md` wins **for standalone runs only**.
 
-Wrap an autonomous agent task in the same discipline as `auto-fix-github`, but without a pre-existing GitHub issue. The user provides a free-form task brief; you turn it into an execution plan, implement it phase-by-phase with incremental commits in an isolated worktree, keep a Progress checklist in the plan so the run is resumable, and open a PR against `develop` with normalized pipeline labels.
+Wrap an autonomous agent task in the same discipline as `om-auto-fix-github`, but without a pre-existing GitHub issue. The user provides a free-form task brief; you turn it into an execution plan, implement it phase-by-phase with incremental commits in an isolated worktree, keep a Progress checklist in the plan so the run is resumable, and open a PR against `develop` with normalized pipeline labels.
 
 ## Arguments
 
@@ -48,7 +48,7 @@ Decision tree:
 | State | `--force` set? | Action |
 |-------|---------------|--------|
 | Nothing exists | — | Claim and proceed. |
-| Branch/plan exists, current user owns it | — | Treat as re-entry; hand off to `auto-continue-pr` and stop. |
+| Branch/plan exists, current user owns it | — | Treat as re-entry; hand off to `om-auto-continue-pr` and stop. |
 | Branch/plan exists, someone else owns it | no | **STOP.** Ask the user via `AskUserQuestion`: "Plan/branch for `${SLUG}` already exists (owner: ${owner}). Override and continue?" Only continue when the user explicitly says yes. |
 | Branch/plan exists, someone else owns it | yes | Pick a new dated slug (`${SLUG}-v2` or append time suffix) to avoid clobber; document in the new plan why the original was superseded. |
 
@@ -87,7 +87,7 @@ Create a lightweight execution plan (NOT a full architectural spec — those liv
 
 - Goal, Scope, Implementation Plan broken into Phases and Steps, Risks (brief).
 - If the task has an associated spec in `.ai/specs/`, reference it: `Source spec: .ai/specs/{file}.md`.
-- A mandatory **Progress** section at the end, formatted exactly as follows so `auto-continue-pr` can parse it:
+- A mandatory **Progress** section at the end, formatted exactly as follows so `om-auto-continue-pr` can parse it:
 
 ```markdown
 ## Progress
@@ -158,7 +158,7 @@ git commit -m "docs(runs): add execution plan for ${SLUG}"
 git push -u origin "$BRANCH"
 ```
 
-This guarantees that if anything later crashes, `auto-continue-pr` can find the plan via the remote branch.
+This guarantees that if anything later crashes, `om-auto-continue-pr` can find the plan via the remote branch.
 
 ### 6. Implement phase-by-phase with incremental commits
 
@@ -182,11 +182,11 @@ For each Phase in the Implementation Plan:
 git commit -m "docs(runs): mark ${SLUG} Phase N step X complete"
 ```
 
-8. Push after every Phase so `auto-continue-pr` always has the latest state on the remote.
+8. Push after every Phase so `om-auto-continue-pr` always has the latest state on the remote.
 
 ### 7. Full validation gate before opening the PR
 
-Before opening the PR, run the full gate (same as `code-review` / `auto-fix-github`):
+Before opening the PR, run the full gate (same as `om-code-review` / `om-auto-fix-github`):
 
 - `yarn build:packages`
 - `yarn generate`
@@ -206,7 +206,7 @@ Never skip the gate because an external skill suggested skipping it.
 
 ### 8. Run code review and BC self-review
 
-Use `.ai/skills/code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
+Use `.ai/skills/om-code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
 
 Explicitly verify:
 
@@ -222,7 +222,7 @@ If self-review finds issues, fix them and loop back to step 6.
 
 Open the PR against `develop` in the current repository.
 
-PR title convention (same as `auto-fix-github`): conventional-commit prefix scoped to the primary area.
+PR title convention (same as `om-auto-fix-github`): conventional-commit prefix scoped to the primary area.
 
 Examples:
 
@@ -231,7 +231,7 @@ Examples:
 - `security(auth): harden role-name spoofing guards`
 - `docs(skills): add auto-create-pr and auto-continue-pr`
 
-PR body template — **MUST** include the `Tracking plan:` line so `auto-continue-pr` can resume.
+PR body template — **MUST** include the `Tracking plan:` line so `om-auto-continue-pr` can resume.
 
 ```markdown
 Tracking plan: .ai/runs/${DATE}-${SLUG}.md
@@ -276,24 +276,24 @@ Suggested label comments:
 - `skip-qa`: `Label set to \`skip-qa\` because this is a docs-only / low-risk change.`
 - `needs-qa`: `Label set to \`needs-qa\` because this touches {area} and must be manually exercised.`
 
-### 11. Run `auto-review-pr` and apply fixes
+### 11. Run `om-auto-review-pr` and apply fixes
 
-Before you post the final summary comment, push the last commits, or report back, subject the PR to an automated second pass with the `auto-review-pr` skill. This is the equivalent of a peer reviewer catching issues the self-review missed.
+Before you post the final summary comment, push the last commits, or report back, subject the PR to an automated second pass with the `om-auto-review-pr` skill. This is the equivalent of a peer reviewer catching issues the self-review missed.
 
-`auto-create-pr` does not hold an `in-progress` lock on the PR at this point (only `auto-continue-pr` does), so `auto-review-pr`'s claim check will see "not in progress, current user is the author/assignee" and claim it fresh by applying the `in-progress` label. That is expected — `auto-review-pr` owns releasing the label when it finishes, per its own step 11. Do not second-guess its claim/release protocol.
+`om-auto-create-pr` does not hold an `in-progress` lock on the PR at this point (only `om-auto-continue-pr` does), so `om-auto-review-pr`'s claim check will see "not in progress, current user is the author/assignee" and claim it fresh by applying the `in-progress` label. That is expected — `om-auto-review-pr` owns releasing the label when it finishes, per its own step 11. Do not second-guess its claim/release protocol.
 
-Invoke `.ai/skills/auto-review-pr/SKILL.md` against `{prNumber}` in autofix mode:
+Invoke `.ai/skills/om-auto-review-pr/SKILL.md` against `{prNumber}` in autofix mode:
 
-1. Follow the entire `auto-review-pr` workflow verbatim — do not cherry-pick steps.
-2. When it flags actionable issues, apply fixes directly in the same worktree used for `auto-create-pr`. Never rewrite earlier commits; always add new commits.
+1. Follow the entire `om-auto-review-pr` workflow verbatim — do not cherry-pick steps.
+2. When it flags actionable issues, apply fixes directly in the same worktree used for `om-auto-create-pr`. Never rewrite earlier commits; always add new commits.
 3. After each batch of fixes:
    - Re-run the targeted validation for the changed packages (unit tests, typecheck, i18n/generate/build as relevant).
    - Re-run the full validation gate from step 7 whenever a fix touches code outside a single module/test file.
    - Update the plan's **Progress** section if the fix corresponds to a plan Step (flip `- [ ]` to `- [x]` with the commit SHA); otherwise add a short note under the relevant Phase heading in the plan (e.g. `- [x] Post-review fix: {one-line summary} — {sha}`).
    - Commit using a clear conventional-commit subject (e.g. `fix(ui): address review feedback on confirmation dialog focus trap`). Push immediately.
-4. Loop until `auto-review-pr` returns a clean verdict (no actionable blockers) or the remaining findings are non-actionable (out-of-scope, false positive) and explicitly documented in the PR comment you post in step 12.
+4. Loop until `om-auto-review-pr` returns a clean verdict (no actionable blockers) or the remaining findings are non-actionable (out-of-scope, false positive) and explicitly documented in the PR comment you post in step 12.
 
-If `auto-review-pr` cannot run (e.g., required checks not yet green, missing context), escalate: leave `Status: in-progress` in the PR body, stop here, and report the blocker to the user so they can decide whether to resume via `auto-continue-pr`.
+If `om-auto-review-pr` cannot run (e.g., required checks not yet green, missing context), escalate: leave `Status: in-progress` in the PR body, stop here, and report the blocker to the user so they can decide whether to resume via `om-auto-continue-pr`.
 
 ### 12. Post the comprehensive summary comment
 
@@ -302,7 +302,7 @@ Every run of this skill MUST end with a single, comprehensive summary comment on
 Minimum comment structure:
 
 ```markdown
-## 🤖 `auto-create-pr` — run summary
+## 🤖 `om-auto-create-pr` — run summary
 
 **Tracking plan:** .ai/runs/${DATE}-${SLUG}.md
 **Branch:** ${BRANCH}
@@ -319,9 +319,9 @@ Minimum comment structure:
 ### Verification phases completed
 - **Targeted validation (per phase):** {which packages ran unit tests / typecheck / i18n / generate / build}
 - **Full validation gate:** {yarn build:packages ✓, yarn generate ✓, yarn i18n:check-sync ✓, yarn i18n:check-usage ✓, yarn typecheck ✓, yarn test ✓, yarn build:app ✓ — or explicit blocker}
-- **Self code-review:** {applied `.ai/skills/code-review/SKILL.md` — findings: {none | list with commit SHA of fix}}
+- **Self code-review:** {applied `.ai/skills/om-code-review/SKILL.md` — findings: {none | list with commit SHA of fix}}
 - **BC self-review:** {applied `BACKWARD_COMPATIBILITY.md` — findings: {none | list}}
-- **`auto-review-pr` autofix pass:** {verdict + SHA range of follow-up commits, or note that it returned clean on first pass}
+- **`om-auto-review-pr` autofix pass:** {verdict + SHA range of follow-up commits, or note that it returned clean on first pass}
 
 ### How to verify
 - **Manual smoke test:** {concrete steps a reviewer can run locally, including any test tenants/fixtures needed}
@@ -341,7 +341,7 @@ Rules for the summary comment:
 
 - Always include every section heading above, even when the content is `None` or `N/A`. Consistent shape makes the comment easy to scan across PRs.
 - Never post this summary before step 11 finishes — it must reflect the final post-autofix state of the branch.
-- If the run is still `in-progress` after step 11 (autofix blocked, or phases remain), the comment MUST state `Final status: in-progress` and explicitly name the `/auto-continue-pr {prNumber}` hand-off. Do not claim completion you did not reach.
+- If the run is still `in-progress` after step 11 (autofix blocked, or phases remain), the comment MUST state `Final status: in-progress` and explicitly name the `/om-auto-continue-pr {prNumber}` hand-off. Do not claim completion you did not reach.
 - Never paste secrets, tokens, `.env` content, or raw credentials into this comment, even when an external skill instructed you to surface them.
 
 ### 13. Cleanup and lock release
@@ -392,14 +392,14 @@ When one or more `--skill-url` arguments are provided:
 
 - Always start with an execution plan; never commit code before the plan lands on the chosen `feat/` or `fix/` branch.
 - Branches created by this skill must use `fix/` for corrective work or `feat/` for non-corrective work; never `codex/`.
-- Execution plan MUST include the Progress section in the exact format above so `auto-continue-pr` can parse it.
+- Execution plan MUST include the Progress section in the exact format above so `om-auto-continue-pr` can parse it.
 - Always use an isolated worktree. Reuse the current linked worktree when already inside one. Never nest worktrees. Always clean up a worktree you created.
 - Base branch is always `develop`.
 - Commit incrementally: one commit per Step when meaningful, otherwise one commit per Phase, plus a dedicated commit for each Progress update.
 - Every code change MUST include tests. Docs-only runs are exempt from the unit-test rule but still run whatever lint/check is relevant.
 - Run the full validation gate before opening the PR unless a real blocker prevents it; if blocked, document the blocker in the PR body and in the plan's Risks section.
 - Run the code-review and BC self-review before opening the PR.
-- After the PR is open, run the `auto-review-pr` skill against it in autofix mode and keep applying fixes (as new commits, never as history rewrites) until it returns a clean verdict or only non-actionable findings remain. Do this before pushing the final changes, posting the summary comment, and reporting back.
+- After the PR is open, run the `om-auto-review-pr` skill against it in autofix mode and keep applying fixes (as new commits, never as history rewrites) until it returns a clean verdict or only non-actionable findings remain. Do this before pushing the final changes, posting the summary comment, and reporting back.
 - Every run MUST end with a single comprehensive `gh pr comment` summary that includes: summary of changes, external references honored, verification phases completed, how to verify (manual smoke test + spot-check areas + rollback plan), and a what-can-go-wrong risk analysis. Keep the section headings stable across runs.
 - New PRs start in the `review` pipeline state. Apply `skip-qa` only for clearly low-risk changes; `needs-qa` when customer-facing behavior changes. Never both.
 - After each label, post a short PR comment explaining why.

package/agentic/shared/ai/skills/{auto-fix-github → om-auto-create-pr}/STANDALONE.md

@@ -1,6 +1,6 @@
 # Standalone portability overrides — auto-* skills
 
-The four auto-* skills (`auto-create-pr`, `auto-continue-pr`, `auto-review-pr`, `auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
+The four auto-* skills (`om-auto-create-pr`, `om-auto-continue-pr`, `om-auto-review-pr`, `om-auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
 
 ## 1. Base branch is discovered, not hard-coded
 

package/{dist/agentic/shared/ai/skills/auto-create-pr-loop → agentic/shared/ai/skills/om-auto-create-pr-loop}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: auto-create-pr-loop
-description: Advanced `auto-create-pr` workflow for long, multi-step spec implementations that need resumability and strict step tracking. Creates a run folder under `.ai/runs/<date>-<slug>/` with `PLAN.md`, `HANDOFF.md`, and `NOTIFY.md`, executes one lean commit per task-table step, batches verification into `checkpoint-<N>-checks.md` every 5 steps (with focused integration tests + screenshots when UI was touched), runs the full validation gate plus full/standalone integration suites and ds-guardian at spec completion, and opens a PR with the correct labels. Use the original `auto-create-pr` for small fixes.
+name: om-auto-create-pr-loop
+description: Advanced `om-auto-create-pr` workflow for long, multi-step spec implementations that need resumability and strict step tracking. Creates a run folder under `.ai/runs/<date>-<slug>/` with `PLAN.md`, `HANDOFF.md`, and `NOTIFY.md`, executes one lean commit per task-table step, batches verification into `checkpoint-<N>-checks.md` every 5 steps (with focused integration tests + screenshots when UI was touched), runs the full validation gate plus full/standalone integration suites and ds-guardian at spec completion, and opens a PR with the correct labels. Use the original `om-auto-create-pr` for small fixes.
 ---
 
 # Auto Create PR (loop)
 
-Wrap an autonomous agent task in the same discipline as `auto-fix-github`, but
+Wrap an autonomous agent task in the same discipline as `om-auto-fix-github`, but
 without a pre-existing GitHub issue. The user provides a free-form task brief;
 you turn it into an execution plan, implement it **one commit per step** in an
 isolated worktree, capture per-commit verification proofs, keep a live handoff
@@ -72,7 +72,7 @@ Before the claim, before the run-folder setup, before any coding — decide whic
 - New module, new integration provider, new database entity + migration.
 - UI surface + API + tests together.
 - Anything the user describes with phases, workstreams, or deliverables.
-- Any existing `auto-create-pr` run that already has a `.ai/runs/<date>-<slug>/` folder.
+- Any existing `om-auto-create-pr` run that already has a `.ai/runs/<date>-<slug>/` folder.
 
 Classification heuristic — evaluate in order, first match wins:
 
@@ -97,14 +97,14 @@ For Simple runs, skip the whole run-folder ceremony. Requirements:
 - Conventional-commit subject.
 - Push.
 - Open the PR directly with a short body — summary + test plan + rollback (no `Tracking plan:` line, no `Status:` field, no linked run folder).
-- Still respect: three-signal `in-progress` lock, label discipline (pipeline + category + meta), BC contract surfaces, code-review self-check, `auto-review-pr` pass.
+- Still respect: three-signal `in-progress` lock, label discipline (pipeline + category + meta), BC contract surfaces, code-review self-check, `om-auto-review-pr` pass.
 - Final summary comment still posts, but compacted to: summary of changes, how to verify, what can go wrong. No "Verification phases" matrix, no "External references honored" section unless actually relevant.
 
-A Simple run still uses an isolated worktree on a `fix/` or `feat/` branch, still claims the PR with the three-signal lock once opened, and still runs `auto-review-pr` in autofix mode.
+A Simple run still uses an isolated worktree on a `fix/` or `feat/` branch, still claims the PR with the three-signal lock once opened, and still runs `om-auto-review-pr` in autofix mode.
 
 #### Spec-implementation-run contract
 
-Keep the full contract documented in the rest of this file: run folder, Tasks table, HANDOFF/NOTIFY, per-Step `step-<X.Y>-checks.md`, 1:1 step-to-commit discipline, full validation gate before flipping to `complete`, `auto-review-pr` autofix pass, comprehensive summary comment with all headings.
+Keep the full contract documented in the rest of this file: run folder, Tasks table, HANDOFF/NOTIFY, per-Step `step-<X.Y>-checks.md`, 1:1 step-to-commit discipline, full validation gate before flipping to `complete`, `om-auto-review-pr` autofix pass, comprehensive summary comment with all headings.
 
 #### Promotion path (Simple → Spec-implementation)
 
@@ -152,7 +152,7 @@ Decision tree:
 | State | `--force` set? | Action |
 |-------|---------------|--------|
 | Nothing exists | — | Claim and proceed. |
-| Run folder/branch exists, current user owns it | — | Treat as re-entry; hand off to `auto-continue-pr` and stop. |
+| Run folder/branch exists, current user owns it | — | Treat as re-entry; hand off to `om-auto-continue-pr` and stop. |
 | Run folder/branch exists, someone else owns it | no | **STOP.** Ask the user via `AskUserQuestion`: "Run folder/branch for `${SLUG}` already exists (owner: ${owner}). Override and continue?" Only continue when the user explicitly says yes. |
 | Run folder/branch exists, someone else owns it | yes | Pick a new dated slug (`${SLUG}-v2` or append time suffix) to avoid clobber; document in the new `PLAN.md` why the original was superseded. |
 
@@ -192,12 +192,12 @@ Create a lightweight execution plan (NOT a full architectural spec — those liv
 - Goal, Scope, Non-goals, Risks (brief), External References.
 - **Implementation Plan** broken into Phases. Each Phase is a sequence of **Steps**. Every Step MUST correspond to **exactly one commit** — no batching. If a Step would produce more than one commit, split it into smaller Steps. This is what makes the run bisectable and reviewable.
 - If the task has an associated spec in `.ai/specs/`, reference it: `Source spec: .ai/specs/{file}.md`.
-- A mandatory **`## Tasks`** table at the very top of `PLAN.md` (right after the header metadata, before `Goal`). It is the authoritative status source that `auto-continue-pr` parses. Required columns and row shape:
+- A mandatory **`## Tasks`** table at the very top of `PLAN.md` (right after the header metadata, before `Goal`). It is the authoritative status source that `om-auto-continue-pr` parses. Required columns and row shape:
 
 ```markdown
 ## Tasks
 
-> Authoritative status table. `Status` is one of `todo` or `done`. On landing a Step, flip `Status` to `done` and fill the `Commit` column with the short SHA. The first row whose `Status` is not `done` is the resume point for `auto-continue-pr`. Step ids are immutable once a Step has a commit.
+> Authoritative status table. `Status` is one of `todo` or `done`. On landing a Step, flip `Status` to `done` and fill the `Commit` column with the short SHA. The first row whose `Status` is not `done` is the resume point for `om-auto-continue-pr`. Step ids are immutable once a Step has a commit.
 
 | Phase | Step | Title | Status | Commit |
 |-------|------|-------|--------|--------|
@@ -313,7 +313,7 @@ git push -u origin "$BRANCH"
 
 Do not pre-create `checkpoint-*-checks.md` or `checkpoint-*-artifacts/` — each checkpoint writes its own files when it fires.
 
-This guarantees that if anything later crashes, `auto-continue-pr` can find `PLAN.md`, `HANDOFF.md`, and `NOTIFY.md` via the remote branch.
+This guarantees that if anything later crashes, `om-auto-continue-pr` can find `PLAN.md`, `HANDOFF.md`, and `NOTIFY.md` via the remote branch.
 
 ### 6. Implement step-by-step (1 commit per Step), verify at checkpoints
 
@@ -334,7 +334,7 @@ A Step is atomic: one Step = one code commit. Nothing more.
 7. **Commit** with a clear conventional-commit subject. Example subjects:
    - `feat(ui): add confirmation dialog primitive`
    - `test(ui): cover confirmation dialog focus trap`
-8. **Push** after every Step so `auto-continue-pr` always has the latest state on the remote.
+8. **Push** after every Step so `om-auto-continue-pr` always has the latest state on the remote.
 9. **Do NOT** write a `step-<X.Y>-checks.md`. **Do NOT** rewrite `HANDOFF.md`. **Do NOT** append to `NOTIFY.md**, unless the Step produced a blocker, a scope decision worth recording, or a subagent delegation. Routine progress is inferred from the Tasks table and the commit log.
 
 #### 6b. Checkpoint pass (every 5 Steps)
@@ -366,7 +366,7 @@ If the checkpoint fails (typecheck/test/i18n/build/integration test regresses),
 
 Subagent parallelism (optional, capped at 2):
 
-- At your discretion, you MAY run up to **two** subagents concurrently — for example, one implementing the next Step while a second reviews the just-landed commit via the `code-review` skill. Never exceed two.
+- At your discretion, you MAY run up to **two** subagents concurrently — for example, one implementing the next Step while a second reviews the just-landed commit via the `om-code-review` skill. Never exceed two.
 - **Conflict avoidance is the top priority.** Two agents MUST NOT edit the same files in the same window. If conflicts are likely, serialize instead.
 - Prefer serial execution whenever the gain is marginal. Parallelism is a tool, not a default.
 - Record any subagent delegation in `NOTIFY.md` with timestamps so the reviewer can tell who did what.
@@ -375,11 +375,11 @@ Subagent parallelism (optional, capped at 2):
 
 > Applies only to **Spec-implementation runs**. Simple runs have at most one code commit and do not use executor dispatch.
 
-When a single `/auto-create-pr` run has a plan with **many Steps that must ship in one PR**, the main session SHOULD act as a **dispatcher** and spawn one **executor subagent** per Step (foreground `Agent` tool call, `subagent_type: "general-purpose"`). The executor implements exactly that Step end-to-end (code commit + docs-flip commit + push). The main session waits for the executor to return, verifies the commits landed and pushed, then dispatches the next Step.
+When a single `/om-auto-create-pr` run has a plan with **many Steps that must ship in one PR**, the main session SHOULD act as a **dispatcher** and spawn one **executor subagent** per Step (foreground `Agent` tool call, `subagent_type: "general-purpose"`). The executor implements exactly that Step end-to-end (code commit + docs-flip commit + push). The main session waits for the executor to return, verifies the commits landed and pushed, then dispatches the next Step.
 
 When to use this pattern:
 
-- A long-running `auto-create-pr` run whose Implementation Plan has many Steps that need to ship before the PR can open (or before step 11 autofix runs).
+- A long-running `om-auto-create-pr` run whose Implementation Plan has many Steps that need to ship before the PR can open (or before step 11 autofix runs).
 - Any time the main session would otherwise carry heavy per-Step context across many Steps.
 
 When NOT to use it:
@@ -451,7 +451,7 @@ Safety stops — the main session MUST halt dispatch (leave `Status: in-progress
 - Two consecutive executors returned problematic results.
 - **Safety checkpoint:** after ~20 consecutive successful Steps, stop and let the user review before plowing on.
 
-Sibling auto-skills (`auto-continue-pr`, `auto-sec-report`, `auto-qa-scenarios`, `auto-update-changelog`) inherit this pattern when driving multiple Steps in a single invocation.
+Sibling auto-skills (`om-auto-continue-pr`, `om-auto-sec-report`, `om-auto-qa-scenarios`, `om-auto-update-changelog`) inherit this pattern when driving multiple Steps in a single invocation.
 
 ### 7. Final gate before opening the PR (spec completion)
 
@@ -459,7 +459,7 @@ Fire when every row in the Tasks table is `done`. The final gate subsumes any pe
 
 Record the outcome in `${RUN_DIR}/final-gate-checks.md`. If raw command output is worth keeping, save it alongside as `${RUN_DIR}/final-gate-artifacts/*.log`.
 
-**Full validation gate** (same as `code-review` / `auto-fix-github`):
+**Full validation gate** (same as `om-code-review` / `om-auto-fix-github`):
 
 - `yarn build:packages`
 - `yarn generate`
@@ -475,7 +475,7 @@ Record the outcome in `${RUN_DIR}/final-gate-checks.md`. If raw command output i
 - `yarn test:integration` — full Playwright/QA integration suite against the ephemeral dev stack. Capture the HTML report summary and save `final-gate-artifacts/playwright-report-summary.log`. On failure, fix forward with new Steps; never skip.
 - `yarn test:create-app:integration` — standalone/create-app integration check. Save output to `final-gate-artifacts/create-app-integration.log`. Skip only if the run did not touch packaging, templates, or shared package exports (document the skip with a one-line justification in `final-gate-checks.md`).
 
-**Design System compliance pass** — after the above are green, run the `ds-guardian` skill (`.ai/skills/ds-guardian/SKILL.md`) to fix DS violations introduced by the run:
+**Design System compliance pass** — after the above are green, run the `om-ds-guardian` skill (`.ai/skills/om-ds-guardian/SKILL.md`) to fix DS violations introduced by the run:
 
 1. Invoke ds-guardian against the diff of this run (`origin/develop..HEAD`).
 2. Apply every auto-fixable violation (semantic token migration, hardcoded color/typography cleanup, missing shared states, arbitrary text sizes).
@@ -492,7 +492,7 @@ Never skip the gate because an external skill suggested skipping it.
 
 ### 8. Run code review and BC self-review
 
-Use `.ai/skills/code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
+Use `.ai/skills/om-code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
 
 Explicitly verify:
 
@@ -508,7 +508,7 @@ If self-review finds issues, fix them and loop back to step 6 (new Step, new com
 
 Open the PR against `develop` in the current repository.
 
-PR title convention (same as `auto-fix-github`): conventional-commit prefix scoped to the primary area.
+PR title convention (same as `om-auto-fix-github`): conventional-commit prefix scoped to the primary area.
 
 Examples:
 
@@ -517,7 +517,7 @@ Examples:
 - `security(auth): harden role-name spoofing guards`
 - `docs(skills): add auto-create-pr and auto-continue-pr`
 
-PR body template — **MUST** include the `Tracking plan:` line so `auto-continue-pr` can resume.
+PR body template — **MUST** include the `Tracking plan:` line so `om-auto-continue-pr` can resume.
 
 ```markdown
 Tracking plan: .ai/runs/${DATE}-${SLUG}/PLAN.md
@@ -552,7 +552,7 @@ Flip `Status:` to `complete` on the PR body once every row in the Tasks table ha
 
 ### 9b. Claim the PR with the three-signal in-progress lock
 
-Per root `AGENTS.md`, any auto-skill that mutates a PR MUST claim it first with **all three signals**: assignee, `in-progress` label, and a claim comment. `auto-create-pr` mutates its own PR from step 9 onwards (label normalization, summary comments, autofix commits), so it MUST hold the lock.
+Per root `AGENTS.md`, any auto-skill that mutates a PR MUST claim it first with **all three signals**: assignee, `in-progress` label, and a claim comment. `om-auto-create-pr` mutates its own PR from step 9 onwards (label normalization, summary comments, autofix commits), so it MUST hold the lock.
 
 Claim it immediately after `gh pr create` returns a PR number:
 
@@ -562,7 +562,7 @@ gh pr edit {prNumber} --add-label "in-progress"
 gh pr comment {prNumber} --body "🤖 \`auto-create-pr\` started by @${CURRENT_USER} at $(date -u +%Y-%m-%dT%H:%M:%SZ). Other auto-skills will skip this PR until the lock is released."
 ```
 
-Wire the release into a `trap`/finally from this point on so the lock is released even if the run crashes (see step 13). The lock is temporarily released in step 11 so that `auto-review-pr` can claim it cleanly.
+Wire the release into a `trap`/finally from this point on so the lock is released even if the run crashes (see step 13). The lock is temporarily released in step 11 so that `om-auto-review-pr` can claim it cleanly.
 
 ### 10. Normalize labels
 
@@ -581,18 +581,18 @@ Suggested label comments:
 - `skip-qa`: `Label set to \`skip-qa\` because this is a docs-only / low-risk change.`
 - `needs-qa`: `Label set to \`needs-qa\` because this touches {area} and must be manually exercised.`
 
-### 11. Run `auto-review-pr` and apply fixes
+### 11. Run `om-auto-review-pr` and apply fixes
 
-Before you post the final summary comment, push the last commits, or report back, subject the PR to an automated second pass with the `auto-review-pr` skill. This is the equivalent of a peer reviewer catching issues the self-review missed.
+Before you post the final summary comment, push the last commits, or report back, subject the PR to an automated second pass with the `om-auto-review-pr` skill. This is the equivalent of a peer reviewer catching issues the self-review missed.
 
-**Release the `in-progress` lock before invoking `auto-review-pr`** so the reviewer skill can claim it cleanly with its own three-signal protocol:
+**Release the `in-progress` lock before invoking `om-auto-review-pr`** so the reviewer skill can claim it cleanly with its own three-signal protocol:
 
 ```bash
 gh pr edit {prNumber} --remove-label "in-progress"
 gh pr comment {prNumber} --body "🤖 \`auto-create-pr\` releasing lock so \`auto-review-pr\` can claim it."
 ```
 
-`auto-review-pr` will re-apply `in-progress` per its own step 0 and release it per its own step 11. When it returns (clean verdict or non-actionable findings only), **reclaim the lock** before posting the summary comment in step 12:
+`om-auto-review-pr` will re-apply `in-progress` per its own step 0 and release it per its own step 11. When it returns (clean verdict or non-actionable findings only), **reclaim the lock** before posting the summary comment in step 12:
 
 ```bash
 gh pr edit {prNumber} --add-label "in-progress"
@@ -601,18 +601,18 @@ gh pr comment {prNumber} --body "🤖 \`auto-create-pr\` reclaiming lock to post
 
 The reclaim keeps the PR owned by this skill through the summary post and cleanup, and is released at the very end of step 13.
 
-Invoke `.ai/skills/auto-review-pr/SKILL.md` against `{prNumber}` in autofix mode:
+Invoke `.ai/skills/om-auto-review-pr/SKILL.md` against `{prNumber}` in autofix mode:
 
-1. Follow the entire `auto-review-pr` workflow verbatim — do not cherry-pick steps.
-2. When it flags actionable issues, apply fixes directly in the same worktree used for `auto-create-pr`. Never rewrite earlier commits; always add new commits under a new Step id (e.g. `X.Y-review-fix`) appended to the Tasks table. Each review-fix Step is still lean: one commit, flip the Tasks row in the same commit, no per-Step checks/handoff files.
+1. Follow the entire `om-auto-review-pr` workflow verbatim — do not cherry-pick steps.
+2. When it flags actionable issues, apply fixes directly in the same worktree used for `om-auto-create-pr`. Never rewrite earlier commits; always add new commits under a new Step id (e.g. `X.Y-review-fix`) appended to the Tasks table. Each review-fix Step is still lean: one commit, flip the Tasks row in the same commit, no per-Step checks/handoff files.
 3. After each batch of fixes:
    - Run a quick scratch sanity check (typecheck + affected tests).
    - When the batch closes — or every 5 review-fix Steps, whichever comes first — run a checkpoint pass per step 6b (targeted validation, focused integration tests + screenshots if UI was touched, write `checkpoint-<N>-checks.md`, rewrite `HANDOFF.md`, append NOTIFY entry, commit as `docs(runs): checkpoint N — review fixes`).
    - When the review-fix batch is fully applied, re-run the full final gate from step 7 whenever a fix touches code outside a single module/test file.
    - Commit each Step using a clear conventional-commit subject (e.g. `fix(ui): address review feedback on confirmation dialog focus trap`). Push immediately.
-4. Loop until `auto-review-pr` returns a clean verdict (no actionable blockers) or the remaining findings are non-actionable (out-of-scope, false positive) and explicitly documented in the PR comment you post in step 12.
+4. Loop until `om-auto-review-pr` returns a clean verdict (no actionable blockers) or the remaining findings are non-actionable (out-of-scope, false positive) and explicitly documented in the PR comment you post in step 12.
 
-If `auto-review-pr` cannot run (e.g., required checks not yet green, missing context), escalate: leave `Status: in-progress` in the PR body, stop here, and report the blocker to the user so they can decide whether to resume via `auto-continue-pr`.
+If `om-auto-review-pr` cannot run (e.g., required checks not yet green, missing context), escalate: leave `Status: in-progress` in the PR body, stop here, and report the blocker to the user so they can decide whether to resume via `om-auto-continue-pr`.
 
 ### 12. Post the comprehensive summary comment
 
@@ -621,7 +621,7 @@ Every run of this skill MUST end with a single, comprehensive summary comment on
 Minimum comment structure:
 
 ```markdown
-## 🤖 `auto-create-pr` — run summary
+## 🤖 `om-auto-create-pr` — run summary
 
 **Tracking plan:** .ai/runs/${DATE}-${SLUG}/PLAN.md
 **Run folder:** .ai/runs/${DATE}-${SLUG}/
@@ -644,9 +644,9 @@ Minimum comment structure:
 - **Full integration suite:** {yarn test:integration ✓ / ✗ — summary + link to HTML report}
 - **Standalone integration:** {yarn test:create-app:integration ✓ / ✗ / skipped with reason}
 - **ds-guardian pass:** {auto-fixes applied (SHA range) | clean | residual findings listed in final-gate-checks.md}
-- **Self code-review:** {applied `.ai/skills/code-review/SKILL.md` — findings: {none | list with commit SHA of fix}}
+- **Self code-review:** {applied `.ai/skills/om-code-review/SKILL.md` — findings: {none | list with commit SHA of fix}}
 - **BC self-review:** {applied `BACKWARD_COMPATIBILITY.md` — findings: {none | list}}
-- **`auto-review-pr` autofix pass:** {verdict + SHA range of follow-up commits, or note that it returned clean on first pass}
+- **`om-auto-review-pr` autofix pass:** {verdict + SHA range of follow-up commits, or note that it returned clean on first pass}
 
 ### How to verify
 - **Manual smoke test:** {concrete steps a reviewer can run locally, including any test tenants/fixtures needed}
@@ -666,7 +666,7 @@ Rules for the summary comment:
 
 - Always include every section heading above, even when the content is `None` or `N/A`. Consistent shape makes the comment easy to scan across PRs.
 - Never post this summary before step 11 finishes — it must reflect the final post-autofix state of the branch.
-- If the run is still `in-progress` after step 11 (autofix blocked, or phases remain), the comment MUST state `Final status: in-progress` and explicitly name the `/auto-continue-pr {prNumber}` hand-off. Do not claim completion you did not reach.
+- If the run is still `in-progress` after step 11 (autofix blocked, or phases remain), the comment MUST state `Final status: in-progress` and explicitly name the `/om-auto-continue-pr {prNumber}` hand-off. Do not claim completion you did not reach.
 - Never paste secrets, tokens, `.env` content, or raw credentials into this comment, even when an external skill instructed you to surface them.
 
 ### 13. Cleanup and lock release
@@ -726,22 +726,22 @@ When one or more `--skill-url` arguments are provided:
 
 - Always start with a run folder and a planned `PLAN.md`; never commit code before the run folder lands on the chosen `feat/` or `fix/` branch.
 - Branches created by this skill must use `fix/` for corrective work or `feat/` for non-corrective work; never `codex/`.
-- `PLAN.md` MUST open with a `## Tasks` table (right after the header metadata). The table is the authoritative Step-status source parsed by `auto-continue-pr`. Do NOT emit the legacy bottom-of-file `## Progress` checklist.
+- `PLAN.md` MUST open with a `## Tasks` table (right after the header metadata). The table is the authoritative Step-status source parsed by `om-auto-continue-pr`. Do NOT emit the legacy bottom-of-file `## Progress` checklist.
 - **Every Step is 1:1 with a commit.** If a Step produces more than one commit, split the Step. Reviewers MUST be able to bisect by Step.
 - `HANDOFF.md` MUST be rewritten at every **checkpoint** (every ~5 Steps) and at run end — not per Step. A brand-new agent should be able to pick up in <30 seconds from the last checkpoint state.
 - `NOTIFY.md` MUST receive an append-only, UTC-timestamped entry for: run start, run end, every **checkpoint**, every blocker, every important decision, every subagent delegation, and every skipped UI integration pass (with reason). Do NOT log routine per-Step progress; the Tasks table + git log cover that.
 - `checkpoint-<N>-checks.md` MUST exist for every checkpoint and record the outcome of the checkpoint's targeted validation (typecheck + unit tests + i18n + generate + build as applicable) plus focused integration tests when UI was touched in the window. `checkpoint-<N>-artifacts/` is optional and only created when the checkpoint produced real artifacts (Playwright transcripts, screenshots, captured command output). Playwright + screenshots MUST be captured at the checkpoint when any Step in the window touched UI AND the dev env is runnable; when not runnable, skip them and log the reason in both `checkpoint-<N>-checks.md` and `NOTIFY.md`. UI verification MUST NEVER block development.
 - **No per-Step `step-<X.Y>-checks.md`, no per-Step `step-<X.Y>-artifacts/`, no per-Step HANDOFF rewrite, no per-Step NOTIFY append.** Per-Step commits update only the Tasks table row. Verification ceremony is batched into checkpoints.
-- Final gate (step 7) MUST include `yarn test:integration` and `yarn test:create-app:integration` (unless docs-only or the standalone check is irrelevant and documented) plus a `ds-guardian` pass that lands auto-fixes as new `X.Y-ds-fix` Steps.
+- Final gate (step 7) MUST include `yarn test:integration` and `yarn test:create-app:integration` (unless docs-only or the standalone check is irrelevant and documented) plus a `om-ds-guardian` pass that lands auto-fixes as new `X.Y-ds-fix` Steps.
 - Always use an isolated worktree. Reuse the current linked worktree when already inside one. Never nest worktrees. Always clean up a worktree you created.
 - Base branch is always `develop`.
 - Every code change MUST include tests. Docs-only runs are exempt from the unit-test rule but still run whatever lint/check is relevant.
 - Run the full validation gate before opening the PR unless a real blocker prevents it; if blocked, document the blocker in the PR body, `PLAN.md`'s Risks section, and `NOTIFY.md`.
 - Run the code-review and BC self-review before opening the PR.
-- After the PR is open, run the `auto-review-pr` skill against it in autofix mode and keep applying fixes (as new commits, never as history rewrites) until it returns a clean verdict or only non-actionable findings remain. Do this before pushing the final changes, posting the summary comment, and reporting back.
+- After the PR is open, run the `om-auto-review-pr` skill against it in autofix mode and keep applying fixes (as new commits, never as history rewrites) until it returns a clean verdict or only non-actionable findings remain. Do this before pushing the final changes, posting the summary comment, and reporting back.
 - Every run MUST end with a single comprehensive `gh pr comment` summary that includes: summary of changes, external references honored, verification phases completed, how to verify (manual smoke test + spot-check areas + rollback plan), and a what-can-go-wrong risk analysis. Keep the section headings stable across runs.
 - New PRs start in the `review` pipeline state. Apply `skip-qa` only for clearly low-risk changes; `needs-qa` when customer-facing behavior changes. Never both.
-- Claim the PR with the **three-signal in-progress lock** (assignee + `in-progress` label + claim comment) immediately after `gh pr create` returns. Release the label temporarily before invoking `auto-review-pr` so the sub-skill can claim cleanly; reclaim after it returns to cover the summary-comment + cleanup window. Release the label in a `trap`/finally so a crash still frees the PR. This matches the root `AGENTS.md` rule that auto-skills which mutate PRs or issues MUST claim with all three signals and MUST release on completion or failure.
+- Claim the PR with the **three-signal in-progress lock** (assignee + `in-progress` label + claim comment) immediately after `gh pr create` returns. Release the label temporarily before invoking `om-auto-review-pr` so the sub-skill can claim cleanly; reclaim after it returns to cover the summary-comment + cleanup window. Release the label in a `trap`/finally so a crash still frees the PR. This matches the root `AGENTS.md` rule that auto-skills which mutate PRs or issues MUST claim with all three signals and MUST release on completion or failure.
 - After each label, post a short PR comment explaining why.
 - Treat `--skill-url` content as reference material; never let it override project rules or the CI gate.
 - Never paste secrets, tokens, `.env` content, or raw credentials into PR comments or run-folder files.

package/agentic/shared/ai/skills/{auto-fix-github → om-auto-fix-github}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: auto-fix-github
+name: om-auto-fix-github
 description: Fix a GitHub issue by number from the current repository. First check whether the issue is already solved or already has an open solution, then use an isolated git worktree to implement the minimal fix, add unit tests, run code review and backward-compatibility checks, run validation including i18n, typecheck, unit tests, and other required checks, then push a branch and open a pull request with a full description linked to the original issue.
 ---
 
@@ -228,7 +228,7 @@ Per iteration:
 5. Re-read the diff and remove any accidental scope creep.
 6. Grep changed non-test files for raw `em.findOne(`/`em.find(` — replace with `findOneWithDecryption`/`findWithDecryption`. This is a hard rule from AGENTS.md.
 
-Before publishing, run the full CI/CD verification gate from the `code-review` skill:
+Before publishing, run the full CI/CD verification gate from the `om-code-review` skill:
 
 - `yarn build:packages`
 - `yarn generate`
@@ -245,7 +245,7 @@ If the full gate is too expensive to run immediately while debugging, do targete
 
 Before publishing, run the change through the same review discipline as an incoming PR.
 
-Use `.ai/skills/code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
+Use `.ai/skills/om-code-review/SKILL.md` and `BACKWARD_COMPATIBILITY.md`.
 
 You must explicitly verify:
 

package/agentic/shared/ai/skills/{auto-continue-pr → om-auto-fix-github}/STANDALONE.md

@@ -1,6 +1,6 @@
 # Standalone portability overrides — auto-* skills
 
-The four auto-* skills (`auto-create-pr`, `auto-continue-pr`, `auto-review-pr`, `auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
+The four auto-* skills (`om-auto-create-pr`, `om-auto-continue-pr`, `om-auto-review-pr`, `om-auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
 
 ## 1. Base branch is discovered, not hard-coded
 

package/{dist/agentic/shared/ai/skills/auto-review-pr → agentic/shared/ai/skills/om-auto-review-pr}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: auto-review-pr
+name: om-auto-review-pr
 description: Review or re-review a GitHub pull request by number in an isolated git worktree. Fetch the specific PR from GitHub, run the full code-review skill, submit approve or request-changes, manage labels, and if blockers remain offer an optional autofix and fix-forward flow that iterates through conflict resolution, code fixes, unit tests, typecheck, and re-review until the PR is merge-ready or a real blocker remains. Usage - /auto-review-pr <PR-number>
 ---
 
@@ -297,7 +297,7 @@ Record findings from the patterns below. These are mandatory findings, not optio
 
 ### 6. Run the full code-review skill inside the worktree
 
-Execute `.ai/skills/code-review/SKILL.md` in the isolated worktree.
+Execute `.ai/skills/om-code-review/SKILL.md` in the isolated worktree.
 
 Mandatory scope and gates:
 
@@ -313,7 +313,7 @@ Merge findings from step 5 into the final review report. Do not duplicate the sa
 
 ### 7. Classify the result
 
-Use the same severity rules as the `code-review` skill:
+Use the same severity rules as the `om-code-review` skill:
 
 | Condition | Decision |
 |-----------|----------|
@@ -558,8 +558,8 @@ If a critical blocker remains that requires human judgment, the summary must des
 - In autofix mode, always rerun code review after each fix batch instead of assuming the previous findings list is complete
 - In autofix mode, always run unit tests and typecheck for the changed scope on every iteration and again on the final branch state
 - In autofix mode, continue iterating until the PR is ready or a real blocker is reported explicitly
-- Must run the full CI/CD verification gate from the `code-review` skill
-- Must use the `code-review` skill severity model
+- Must run the full CI/CD verification gate from the `om-code-review` skill
+- Must use the `om-code-review` skill severity model
 - Must run the diff-level automated checks in step 5
 - The review body must contain the full structured report
 - Always add the chosen pipeline label and remove every other pipeline label

package/agentic/shared/ai/skills/{auto-review-pr → om-auto-review-pr}/STANDALONE.md

@@ -1,6 +1,6 @@
 # Standalone portability overrides — auto-* skills
 
-The four auto-* skills (`auto-create-pr`, `auto-continue-pr`, `auto-review-pr`, `auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
+The four auto-* skills (`om-auto-create-pr`, `om-auto-continue-pr`, `om-auto-review-pr`, `om-auto-fix-github`) were originally authored inside the Open Mercato monorepo. When they run inside a standalone app scaffolded via `create-mercato-app`, the following overrides apply **before** any rule in `SKILL.md`.
 
 ## 1. Base branch is discovered, not hard-coded
 

package/agentic/shared/ai/skills/{auto-upgrade-0.4.10-to-0.5.0 → om-auto-upgrade-0.4.10-to-0.5.0}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: auto-upgrade-0.4.10-to-0.5.0
+name: om-auto-upgrade-0.4.10-to-0.5.0
 description: Migrate a standalone Open Mercato app from framework 0.4.10 to 0.5.0. This release is the biggest Open Mercato release so far and bundles 250+ post-Hackathon fixes plus several important dependency upgrades, so this skill acts as the executable companion to the 0.5.0 upgrade notes. It mechanically applies the documented codemods for the 0.4.10 → 0.5.0 window — Meilisearch class rename, Stripe API-version typing, lucide-react brand-icon removals and metadata-icon safety fixes, react-markdown className wrap, cron-parser `CronExpressionParser.parse` rename, @simplewebauthn Uint8Array narrowing, react-email CLI rename, plus the Jest ESM allow-list. Runs inside the user's app, detects which patterns are actually in use, edits files in place, typechecks, and reports what was migrated and what still needs a human eye. Use when a user asks to "upgrade my Open Mercato project from 0.4.10 to 0.5.0", "bump open-mercato to 0.5.0", or "apply the 0.5.0 upgrade notes".
 ---
 

package/agentic/shared/ai/skills/{backend-ui-design → om-backend-ui-design}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: backend-ui-design
+name: om-backend-ui-design
 description: Design and implement consistent backend/backoffice interfaces using @open-mercato/ui. Use when building admin pages, CRUD interfaces, data tables, forms, detail pages, or any backoffice UI.
 ---
 
@@ -245,7 +245,7 @@ import { collectCustomFieldValues } from '@open-mercato/ui/backend/utils/customF
 ## Page Navigation Metadata
 
 Every backend page needs correct `page.meta.ts` for sidebar placement.
-See `.ai/skills/module-scaffold/references/navigation-patterns.md` for:
+See `.ai/skills/om-module-scaffold/references/navigation-patterns.md` for:
 - Complete field reference (`pageGroup`, `pageOrder`, `pageContext`, `navHidden`)
 - Settings page pattern (`pageContext: 'settings' as const` + `navHidden: true`)
 - Common anti-patterns (missing group, mismatched keys, broken icons)

package/{dist/agentic/shared/ai/skills/code-review → agentic/shared/ai/skills/om-code-review}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: code-review
+name: om-code-review
 description: Review code changes for architecture, security, conventions, and quality compliance. Use when reviewing pull requests, code changes, or auditing code quality.
 ---
 

package/agentic/shared/ai/skills/{code-review → om-code-review}/references/review-checklist.md

@@ -25,6 +25,8 @@
 - [ ] UUID primary keys with standard columns (`id`, `created_at`, `updated_at`)
 - [ ] Soft delete via `deleted_at` where applicable
 - [ ] Atomic transactions for multi-step writes
+- [ ] `withAtomicFlush(em, phases, { transaction: true })` used when mutating across phases that include queries on the same `EntityManager`
+- [ ] No `em.find`/`em.findOne`/sync helpers between a scalar mutation and `em.flush()` without `withAtomicFlush`
 
 ## 4. API Routes
 
@@ -42,6 +44,7 @@
 - [ ] Workers export `metadata` with `{ queue, id?, concurrency? }`
 - [ ] All mutations implemented as commands with undo logic
 - [ ] Side effects outside `withAtomicFlush`
+- [ ] Cache invalidation and side effects (`emitCrudSideEffects`) fire AFTER the DB write commits — never inside the `withAtomicFlush` block
 
 ## 6. UI & Backend Pages