@openora/create 0.4.1-canary.35 → 0.4.1-canary.350

package/template/__dot__rulesync/rules/overview.md

@@ -8,94 +8,30 @@ globs:
 
 # Agent instructions
 
-Canonical brief for AI agents (Claude Code, GitHub Copilot, Codex) and humans working on
-this repo. Every per-tool instruction file (`AGENTS.md` - shared, also Codex's brief;
-`CLAUDE.md`; `.github/copilot-instructions.md`) plus Codex's `.codex/config.toml` and the
-subagent and command mirrors are generated by
-[rulesync](https://github.com/dyoshikawa/rulesync) from the single source in `.rulesync/`
-(`rules/`, `subagents/`, `commands/`, `mcp.json`). Edit the source under `.rulesync/`, then
-run `pnpm gen:agents`. Do not hand-edit the generated files.
+This repo is a downstream igaming operator built on the OSS platform (`@openora/*`). Every per-tool instruction file (`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.codex/config.toml`) and the subagent and command mirrors are generated by [rulesync](https://github.com/dyoshikawa/rulesync) from `.rulesync/`. Edit the source, run `pnpm gen:agents`, never hand-edit a generated file.
 
-This repo is a downstream igaming operator built on the OSS platform (`@openora/*`).
+Sibling rules (load on demand; don't reopen settled questions):
 
-Apply every rule file in `.rulesync/rules/`:
+- `conventions` - the always-on code standard, with a table routing each kind of change to its deep-dive file in `docs/standards/`.
+- `oss-boundaries` - never patch `@openora/*` in place; core changes go through an OSS worktree; enforced import/module boundaries.
+- `e2e-conventions` - Playwright specs against the real stack, fixtures, page objects, API specs.
+- `db-conventions` - SQL / Drizzle rules for the tables an overlay owns.
+- `frontend-conventions` - React/UI rules for the operator's apps and shared UI package.
 
-- `conventions` - the code standard (naming, types, functions, frontend, module + package structure, errors, testing, git).
-- `oss-boundaries` - OSS core is read-only; enforced import/module boundaries.
-- `db-conventions` - SQL / Drizzle rules for tables an overlay owns.
-- `e2e-conventions` - dual-mode Playwright specs, fixtures, mocks, page objects.
+## Agent files: generated from the template, or owned here
 
-## HARD RULE: never modify OSS core
+Most of `.rulesync/` (skills, subagents, commands, hooks, the shared rules) and `docs/standards/` are generated: `pnpm install` renders them from `@openora/create`'s consumer template at the pinned `@openora/*` version, using the variables in `.rulesync/sync.json`. They are gitignored via the managed `synced-agents` block in `.gitignore`, so they never appear in a diff and cannot drift - editing one locally is pointless, the next install overwrites it. Change it upstream in the template instead. This repo owns and tracks the rules and skills the template does not ship, plus the `consumerOwned` overrides in `.rulesync/sync.json`; operator-specific facts belong there or in `sync.json` vars.
 
-`@openora/*` is a third-party dependency - treat it like any published npm package. You may READ it for reference, never write to it.
+## How you work here
 
-- Do NOT edit anything in `node_modules/**` or in the linked OSS checkout. Edit/Write to those paths is denied in `.claude/settings.json`; do not try to work around it with `sed`, shell redirection, or a script.
-- Locally patching a dependency is an anti-pattern: it is lost on reinstall and diverges from the published package every other operator uses.
-- You extend the platform from the OUTSIDE only - overlay plugins, adapter rebindings, UI plugins, config. Never fork or hand-edit core.
-- If something can only be fixed in core, STOP and report it as an upstream bug/feature request for the OSS repo (describe the problem, expected behavior, where you think it lives). Do not patch it here.
-
-## Getting started
-
-When the user opens Claude Code or asks to build something, call the `start` MCP tool (server: `oss`) and follow the script it returns.
-
-Trigger phrases: "start", "help", "what can I build", "what can I do", "I want to build X", "how do I begin", "getting started".
-
-## Enhance the ask first (pre-step)
-
-Before acting on any non-trivial request - and before delegating to an agent - run the `enhance-prompt` skill on the raw ask: restate the intent, gather scoped context (your tracker / roadmap / team chat / local docs), surface the blocking ambiguities, and produce the brief you actually execute. Skip it only when the ask is already precise. Subagents act on the brief they are handed - they do not re-enhance it.
-
-## How you work here: collect requirements, delegate everything else
-
-Your one human-facing job is to **gather thorough requirements** from the user - interview them (goal, actors, value flow, rules, lifecycle, compliance, UI, edge cases, success criteria, out of scope) until you could hand a stranger a buildable spec. The `start` / `enhance-intent` tools give you the checklist.
-
-Once requirements are confirmed, **delegate the rest to the agents** via the Task tool - you orchestrate, you do not implement feature code yourself:
-
-1. `expert` - formalizes the requirements into acceptance criteria, flags compliance/gaps.
-2. `builder` - implements (`pnpm gen ...`, code, wiring).
-3. `qa` - writes/runs the E2E test against the acceptance criteria.
-
-Only return to the user to resolve genuine decisions they alone can make.
+- Before acting on a non-trivial request, and before delegating, run the `enhance-prompt` skill on the raw ask. Skip it only when the ask is already precise. Subagents act on the brief they are handed; they do not re-enhance it.
+- Your human-facing job is gathering requirements until a stranger could build from them; the `start` / `enhance-intent` MCP tools give the checklist. Then delegate to the subagents (`expert` -> `builder` -> `tester`) and return to the user only for decisions they alone can make.
+- A task that names a ticket key starts by reading the whole ticket per `docs/agents/issue-tracker.md`. Never write to the tracker unless the user asks for that exact write.
+- `pnpm verify` on the committed tree is the gate before a merge/pull request; the `guard-mr` hook refuses to open one until it has passed on HEAD.
 
 ## What this repo is
 
-- `apps/api/` - thin Hono + oRPC API entry, your own `extensions.config.ts`
-- this is a headless api consumer; build your frontend in its own repo and consume the api over HTTP via `@openora/react`
-- `@openora/*` packages are linked from a sibling OSS checkout via `pnpm.overrides`
-
-## How to extend
-
-| What you want                                | Command            |
-| -------------------------------------------- | ------------------ |
-| New behavior / routes                        | `pnpm gen plugin`  |
-| Swap a vendor (payment / KYC / notification) | `pnpm gen adapter` |
-
-Register new plugins in `apps/api/src/extensions.config.ts`. Adapters must be listed AFTER the module that owns the default binding (last registration of a DI token wins).
-
-## Agents (spawn via the Task tool)
-
-Delegate work to these scoped agents - the `start` / `enhance-intent` playbooks tell you when to use each:
-
-- `expert` - turns a fuzzy product ask into requirements + acceptance criteria (jurisdiction rules, player journey). Advisory, writes no code. Use BEFORE building anything non-obvious.
-- `builder` - senior fullstack engineer. Implements overlays, swaps adapters, mounts UI pages.
-- `qa` - writes/runs Playwright E2E tests; triages whether a bug is in OSS core (upstream) or your overlay (local fix).
-- `debugger` - root-causes failures, build-time (Next/Turbopack, tsc, module resolution) and runtime (Chrome DevTools: console/network/DOM). Spawn it whenever something errors or behaves wrong; it finds the cause and routes the fix.
-- `quality-reviewer` - reviews a diff: boundaries, conventions, frontend rules, perf, duplication. Findings only.
-- `security-reviewer` - reviews a diff: authz, secrets/PII, money paths, input validation. Findings only.
-
-This repo consumes OSS core as linked packages - never edit `@openora/*` source. If a bug is in core, report it upstream; extend from the outside via plugins.
-
-## MCP tools available (server: `oss`)
-
-This server reads the platform CATALOG (not OSS source) - it tells you what exists so you extend without forking. Call these instead of grepping:
-
-- `start` - onboarding flow (call when the user asks what to build)
-- `enhance-intent` - turn a fuzzy ask into a grounded spec + playbook
-- `dev:infra` - start/stop/status docker compose (postgres :5432)
-- `catalog-overview` - START HERE: counts + adapter seams + config fields
-- `list-adapters` - vendor swap seams (interface + token + status)
-- `list-routes [module]` - oRPC route namespaces
-- `list-events` - cross-module domain events you can subscribe to
-- `list-slots` - named UI slots you can fill from a UI plugin
-- `describe-module <name>` - one module's group, tables, routes
-- `schema-get <name>` - locate a Zod contract schema's file
-- `get-config-schema` - the igaming-config fields a consumer can set
+- `apps/api/` - thin Hono + oRPC API entry, your own `extensions.config.ts`.
+- This is a headless API consumer; build your frontend in its own repo and consume the API over HTTP via `@openora/react`.
+- `@openora/*` packages are pinned npm dependencies.
+- New behaviour, a vendor swap or a mounted page: the `create-plugin` skill picks the generator.

package/template/__dot__rulesync/skills/create-plugin/{SKILL.md → SKILL.md.tpl}

@@ -1,19 +1,17 @@
 ---
 name: create-plugin
-
+targets: ['*']
 description: >
-  Guided creation of an extension - the right way to add behavior or swap a vendor without
+  Guided creation of a {{name}} extension - the right way to add behavior or swap a vendor without
   touching `@openora/*` core. Interviews for intent, classifies the seam (plugin / adapter /
   page / route), runs the matching scaffold command, wires extensions.config.ts, and enforces
   boundaries + audit + db rules. Use on "create plugin", "add an extension", "swap KYC/PSP",
   "mount a page", "/create-plugin <name>".
 ---
 
-# create-plugin
+# create-plugin ({{name}})
 
-The platform is extended from the **outside only** (overlay plugin / adapter rebind / UI page /
-config) - never by editing `@openora/*`. This skill picks the correct seam and scaffolds it.
-Domain questions go to `expert` first; review the result with `review`.
+The platform is extended from the **outside only** (overlay plugin / adapter rebind / UI page / config) - never by editing `@openora/*`. This skill picks the correct seam and scaffolds it. Domain questions go to `expert` first; review the result with `review`.
 
 ## 1. Classify the seam (ask if unclear)
 
@@ -24,23 +22,17 @@ Domain questions go to `expert` first; review the result with `review`.
 | Mount a react-sdk page on a route           | page    | `pnpm gen page <route>`                    |
 | Add one route to an existing add-on/overlay | route   | `/scaffold-route <add-on> <METHOD> <path>` |
 
-If the behavior genuinely cannot be expressed from the outside, STOP - it's an OSS-core change.
-Hand off via the `add-feature` skill's `handoff.md`. Do not patch the linked OSS checkout.
+If the behavior genuinely cannot be expressed from the outside, STOP - it's an OSS-core change. Hand off via the `ship` skill's `handoff.md`. Never patch `{{ossDir}}`.
 
 ## 2. Ground first
 
-- Read `.claude/rules/overview.md` (what you may and may not touch) and
-  `.claude/rules/db-conventions.md` (if the extension owns tables).
-- Inspect what already exists with the `oss` MCP: `catalog-overview`, `list-adapters` (token +
-  default binding to swap), `list-routes` (collision check), `list-slots`, `list-events`.
-- For a domain rule you can't safely assume (a limit, a KYC threshold, a jurisdiction behavior),
-  spawn `expert` before scaffolding.
+- Read `CLAUDE.md` / `AGENTS.md` (the rendered `overview` rule: what you may and may not touch), `.claude/rules/oss-boundaries.md`, and `.claude/rules/db-conventions.md` + `docs/standards/database.md` (if the extension owns tables).
+- Inspect what already exists with the `oss` MCP: `catalog-overview`, `list-adapters` (token + default binding to swap), `list-routes` (collision check), `list-slots`, `list-events`.
+- For a domain rule you can't safely assume (a limit, a KYC threshold, a jurisdiction behavior), spawn `expert` before scaffolding.
 
 ## 3. Scaffold + wire
 
-Run the command from step 1, then fill the `// AGENT: implement here` regions. Register the plugin
-in `apps/api/src/extensions.config.ts`. **Order matters for adapters** - last registration of a DI
-token wins, so list a swap AFTER the module that owns the default binding.
+Run the command from step 1, then fill the `// AGENT: implement here` regions. Register the plugin in `apps/api/src/extensions.config.ts`. **Order matters for adapters** - last registration of a DI token wins, so list a swap AFTER the module that owns the default binding.
 
 ```ts
 // good - swap binds after the owning module, so it replaces the default
@@ -52,12 +44,9 @@ plugins: [myCustomPspAdapter, walletModule];
 
 ## 4. Non-negotiables
 
-- **Boundaries**: import only package entrypoints (`@openora/core`, not `.../src` or `.../dist`).
-  No imports between extensions; cross-extension data goes through the oRPC client or a schema subpath.
-- **Tables**: live in the overlay's own `src/schema/index.ts`; follow `db-conventions` (snake_case,
-  `timestamp({ withTimezone: true })`). Run `pnpm db:migrate` after.
-- **Audit every mutation**: each state-changing action emits a domain event the `audit` add-on
-  subscribes to, or resolves `AUDIT_WRITER` and calls `record(...)`. A mutation with no audit is not done.
+- **Boundaries**: import only package entrypoints (`@openora/core`, not `.../src` or `.../dist`). No imports between extensions; cross-extension data goes through the oRPC client or a schema subpath.
+- **Tables**: live in the overlay's own `src/schema/index.ts`; follow `docs/standards/database.md` (snake_case, `timestamp({ withTimezone: true })`). Run `pnpm db:migrate` after.
+- **Audit every mutation**: each state-changing action emits a domain event the `audit` add-on subscribes to, or resolves `AUDIT_WRITER` and calls `record(...)`. A mutation with no audit is not done.
 - **Validate at the edge**: Zod schemas for every route input/output; no inline `fetch`/SQL in handlers.
 
 ## 5. Verify

package/template/__dot__rulesync/skills/create-pr/SKILL.md.tpl

@@ -0,0 +1,38 @@
+---
+name: create-pr
+targets: ['*']
+description: Commit, push, and open a pull request on this repo's forge, targeting the branch `docs/agents/forge.md` names. Use on "create pr", "create mr", "open a pr/mr", "/create-pr", or "promote <branch>".
+---
+
+# create-pr ({{name}})
+
+`docs/agents/forge.md` is the source of truth for this repo's forge: which CLI to use, how to open and read a pull request, and where a change lands. Read it first - the steps below never hardcode a forge command.
+
+## Steps
+
+1. **Determine source + target.** `git branch --show-current`, then take the target from the "Where a change lands" section of `docs/agents/forge.md`.
+2. **Land the paired OSS change first, if there is one.** It is paired when `{{ossDir}}/.worktrees/<branch, / as +>` exists or `git -C {{ossDir}} branch --list <branch>` matches. First finish step 3 of "Changing OSS core" in the `oss-boundaries` rule (verify, OSS review, no open BLOCK). Then run steps 3-7 inside that worktree under the OSS repo's own delivery rules (`<worktree>/docs/standards/skills/delivery.md`: `gh`, its PR template, `pnpm verify`, public-record rules), with its own explicit push confirmation. Reuse an open OSS PR (`gh pr list --head <branch>` in the worktree).
+3. **Scope the commit.** `git status -s`. Commit ONLY changes that belong to this unit of work. If unrelated/pre-existing edits are present, do NOT bundle them - stage your files explicitly and tell the user what you left out. Never `git add -A` blindly when foreign changes are in the tree.
+4. **Commit.** Conventional-commit message (`feat:`, `fix:`, `docs:`, `refactor:`, `chore:`); the scope is a commitlint-enum package or app, never the ticket key; for ticket work the key goes at the END of the subject (e.g. `feat(web): add deposit limits ({{trackerKey}}-123)`). No "Co-Authored-By" / "Generated with" trailers.
+5. **Verify the commit.** Run `pnpm verify` on the committed, clean tree: it is the pre-MR gate and records the verified commit. The `guard-mr` hook refuses to open the pull request until that record matches HEAD. Don't push a red tree.
+6. **Push** the current branch - but STOP and get an explicit per-action "yes push" from the user FIRST. The one exception: run by `ship` without `--ask`, the `/ship` invocation is that yes for its ticket branch only. Report the commit SHA, then ask. Invoking this skill is NOT push authorization. Pushing to a shared/env branch (`{{mrTarget}}`, `stage`, `prod`) without that explicit yes is forbidden. Only after the yes: `git push -u origin <current>`.
+7. **Open the pull request** using the command in `docs/agents/forge.md` (only after the push is confirmed and done). Reuse an open request for the same source -> target instead of creating a duplicate, and never delete a long-lived branch on merge.
+8. **Report** the pull-request URL back to the user, and the OSS PR URL when paired.
+
+## Pull-request description
+
+- State the user-facing change and its reason briefly.
+- Add short, reproducible local test steps for the changed behavior (for example, `pnpm dev` then the relevant URLs or user flow).
+- Close the ticket by key at the end: `Closes <KEY>-n` if this PR finishes it, else `Refs <KEY>-n` (see `docs/agents/issue-tracker.md`).
+- Do not include a generic verification-command list: CI already reports those checks.
+- **Attach the manual-verification evidence.** The videos are what a reviewer reads as proof of a user-visible change: one short clip per acceptance criterion, embedded under that criterion, the before/after pair on a fix. A screenshot only where a clip adds nothing, such as a second theme. Upload each file to the forge and embed the markdown it returns - `docs/agents/forge.md` says how (its "Attach evidence" section). A local path under `apps/e2e/test-results/` shows a reviewer nothing; never put one in a description. An API-only change attaches the request/response trace instead. Paste the `tester` pass's verdict table next to it. Skip this only when nothing user-visible changed.
+- **Diagram the flow.** A change that adds or changes a flow across components (a request path through gates and a vendor, a state machine, an async job or webhook, a new module or overlay) embeds a fenced `mermaid` block (`flowchart` or `sequenceDiagram`), right after the summary - GitHub and GitLab both render it. Name nodes as the code does, keep it under ~15 nodes, include the refusal and failure branches. No flow (copy, styling, deps, a one-file fix): no diagram.
+- **End with a "Tests" list** - one line per test this PR adds, drawn from what the manual pass exercised (happy path, the hostile paths, the authz negatives), naming its tier (unit / API E2E / browser E2E) and path. A change that needs none says why in one line.
+- A paired change links neither way: the shared branch name pairs the two requests. The OSS repo is public, so its PR never names this repo or the operator; this request may be read by people outside the team, so it never names or links the OSS repo.
+
+## Rules
+
+- NEVER push without an explicit per-action "yes push" from the user (or `/ship` on its ticket branch, see step 6). Invoking this skill does NOT authorize a push. Report the commit SHA, ask, then push only on yes.
+- `pnpm verify` must pass on the commit you push.
+- Keep the pull request scoped to one concern; split unrelated changes into separate ones.
+- No AI-attribution trailers anywhere - not in the commit, not in the pull-request title or description. No "Generated with", no "Co-Authored-By: Claude", no robot-emoji footer.

package/template/__dot__rulesync/skills/create-task/{SKILL.md → SKILL.md.tpl}

@@ -1,38 +1,33 @@
 ---
 name: create-task
-
-description: Create or rewrite this operator's Jira tickets in a lean, bulleted, easy-to-scan format. Use on "create task", "new ticket", "rewrite ticket", "/create-task", or any ticket-key description work.
+targets: ['*']
+description: Create or rewrite this operator's Jira tickets in a lean, bulleted, easy-to-scan format. Use on "create task", "new ticket", "rewrite ticket", "/create-task", or any {{trackerKey}}-XXX description work.
 ---
 
-# create-task
+# create-task ({{name}})
 
-Template and clean up Jira tickets for this operator's project so they are short,
-scannable, and free of filler. Use for new tasks and for rewriting bloated ones.
+Template and clean up Jira tickets for this operator's project so they are short, scannable, and free of filler. Use for new tasks and for rewriting bloated ones.
 
 ## Jira coordinates
 
 - Tool: the **Atlassian** MCP - read the issue, create/edit the issue.
-- `cloudId`: `<your-jira-cloud-id>`
-- Project key: `<your-project-key>` (ticket keys look like `<KEY>-XXX`)
+- `cloudId`: `{{jiraCloudId}}` (`{{jiraSite}}`)
+- Project key: `{{trackerKey}}` (ticket keys look like `{{trackerKey}}-XXX`)
 - Always pass `contentFormat: "markdown"` and `responseContentFormat: "markdown"`.
 
 ## Writing rules
 
 - Lead with **Goal** (1-2 lines). Reader should get the point in 5 seconds.
 - Everything else is **bullets**. No long prose paragraphs.
-- Cut: progress logs, "we decided to instead", history, anything not actionable.
-  State the current decision, not how we got there.
+- Cut: progress logs, "we decided to instead", history, anything not actionable. State the current decision, not how we got there.
 - Short dashes `-` only, never long dashes. ASCII only.
 - Use `->` for flows, `x3` for counts, backticks for commands/env vars/paths.
-- Name the owner-confirmed decisions inline with date + who (e.g. "confirmed with
-  <owner> 2026-06-15") so they are not relitigated.
-- Scope tightly. Push anything bigger into a separate ticket and say so in
-  **Out of scope**.
+- Name the owner-confirmed decisions inline with date + who (e.g. "confirmed with <owner> 2026-06-15") so they are not relitigated.
+- Scope tightly. Push anything bigger into a separate ticket and say so in **Out of scope**.
 
-## Gotchas
+## Jira gotchas
 
-- **No markdown checkboxes.** `- [ ]` renders as literal `\[ \]` in Jira. Use plain
-  `-` bullets for task lists and acceptance criteria.
+- **No markdown checkboxes.** `- [ ]` renders as literal `\[ \]` in Jira. Use plain `-` bullets for task lists and acceptance criteria.
 - Markdown `##` headings and `**bold**` convert cleanly; tables convert too.
 - Re-read the issue via the **Atlassian** MCP after writing only if the render looked off.
 
@@ -64,14 +59,11 @@ scannable, and free of filler. Use for new tasks and for rewriting bloated ones.
 - <observable, testable outcomes>
 ```
 
-For infra/DevOps tickets, swap **Scope** for **Provision** (AWS services as bullets)
-
-- **One-time bootstrap**. Link a prior infra ticket as a worked example if one exists.
+Infra/DevOps tickets: swap **Scope** for **Provision** (services as bullets) + a **One-time bootstrap** section. Link a prior infra ticket as a worked example if one exists.
 
 ## Flow
 
-1. If rewriting: read the issue via the **Atlassian** MCP (markdown) for current state + summary.
+1. If rewriting: read the issue whole per `docs/agents/issue-tracker.md` (`atlassian-read`; comments and images included) - a rewrite that drops a decision buried in a comment or a screenshot is a regression.
 2. Pull any missing context the ticket references (Slack decision, sibling ticket).
-3. Draft against the template. Confirm scope splits with the user before creating
-   new tickets.
+3. Draft against the template. Confirm scope splits with the user before creating new tickets.
 4. Create or edit the issue via the **Atlassian** MCP. Report the ticket key + URL.

package/template/__dot__rulesync/skills/create-ui-module/{SKILL.md → SKILL.md.tpl}

@@ -2,15 +2,17 @@
 name: create-ui-module
 targets: ['*']
 description: >
-  Create a frontend feature module in apps/backoffice or apps/web following ADR-0001's
-  modular architecture: standard folder shape, co-located locales, DI hooks, pure
-  components, barrel entry, route wiring. Use on "create module", "new feature module",
+  Create a frontend feature module in apps/backoffice or apps/web following the modular
+  architecture in the `frontend-conventions` rule: standard folder shape, co-located
+  locales, DI hooks, pure components, barrel entry, route wiring. Use on "create module", "new feature module",
   "add a backoffice/web module", "/create-ui-module <app> <name>".
 ---
 
-# create-ui-module (consumer)
+# create-ui-module ({{name}})
 
-Scaffold a feature module under `src/modules/<name>/` per ADR-0001 (`docs/adr/0001-modular-architecture.md`). The shape is lint-enforced (`tools/oxlint-module-structure.mjs`: folder structure, `use-` hook naming, kebab-case files, client-component naming). Copy an existing module as the reference - `apps/backoffice/src/modules/roles/` is canonical.
+Applies once this repo has UI apps (`apps/web` / `apps/backoffice`); an api-only repo has no `src/modules/` to scaffold into.
+
+Scaffold a feature module under `src/modules/<name>/` per the modular architecture in `frontend-conventions` and `docs/standards/frontend.md`. Where the repo ships a module-structure lint rule, it enforces the shape (folder structure, `use-` hook naming, kebab-case files, client-component naming). Copy an existing module in the same app as the reference.
 
 ## 1. Resolve input
 
@@ -32,7 +34,7 @@ src/modules/<name>/
 `locales/index.ts` pattern (exact):
 
 ```ts
-import { registerTranslations } from '@<scope>/ui';
+import { registerTranslations } from '{{scope}}/ui';
 import en from './en.json';
 
 export const locales = { en };
@@ -43,16 +45,16 @@ Components use `useTranslation(ns)`; no hardcoded copy. Non-`en` files mirror `e
 
 ## 3. Wire the route
 
-- backoffice: `src/routes/_authed/<name>.tsx` -> `createFileRoute` with `component` imported from `@/modules/<name>` (see `src/routes/_authed/roles.tsx`).
+- backoffice: `src/routes/_authed/<name>.tsx` -> `createFileRoute` with `component` imported from `@/modules/<name>`; mirror a sibling route file.
 - web: the App Router page under `app/(shell)/<name>/` imports from `@/modules/<name>`; client components get `'use client'` line 1 + `.client.tsx` suffix.
 
 ## 4. Non-negotiables
 
 - No cross-module imports - cross-module effects go through query cache invalidation, never a direct import.
 - Outside code imports ONLY the barrel via `@/modules/<name>`; inside the module use relative paths.
-- Hooks take their clients (oRPC/API) as parameters (see `roles/hooks/use-iam-client-deps.ts`) so they're testable without global mocks.
-- Follow the conventions rule's Frontend + Modular architecture sections (daisyUI, theme tokens, hoisted `styles` const, React Compiler - no manual memo).
+- Hooks take their clients (oRPC/API) as parameters via a `use-<domain>-client-deps.ts` hook so they're testable without global mocks.
+- Follow the `frontend-conventions` rule + `docs/standards/frontend.md` (daisyUI, theme tokens, hoisted `styles` const, React Compiler - no manual memo).
 
 ## 5. Verify
 
-`/check` green (the structure lint runs inside `pnpm check:lint`); route renders (`pnpm dev`). Hand to `review` before an MR.
+`/check` green (any structure lint runs inside `pnpm check:lint`); route renders (`pnpm dev`). Hand to `review` before an MR.

package/template/__dot__rulesync/skills/enhance-prompt/{SKILL.md → SKILL.md.tpl}

@@ -3,14 +3,14 @@ name: enhance-prompt
 targets: ['*']
 description: >
   Normalize any raw request into a grounded, structured brief before acting. The auto pre-step
-  for orchestration skills and subagents: extract the real intent, gather scoped context (your
-  tracker + roadmap + team chat + local docs), surface only blocking ambiguities, and emit
+  for orchestration skills and subagents: extract the real intent, gather scoped context (Jira +
+  Confluence + Slack + roadmap + local docs), surface only blocking ambiguities, and emit
   objective / scope / constraints / deliverables / guardrails. Routes build-type asks into
   `enhance-intent`. Skips asks that are already precise. Use on any fuzzy, broad, or multi-part
   request, or at the start of a skill or agent that received a raw ask.
 ---
 
-# enhance-prompt
+# enhance-prompt ({{name}})
 
 Turn a raw, rambling ask into a brief a stranger could execute - before any file is touched. A one-line ask is a starting point, not a spec; a wrong reading executed confidently wastes far more than the enhancement costs.
 
@@ -27,7 +27,7 @@ Match effort to the ask: a small task gets a one-line restatement, not a full br
 
 1. **Restate the intent** in one line. If your restatement might be wrong, gather context or ask - don't guess.
 2. **Classify**: build (feature / adapter / page / route) · review or audit · debug · refactor · docs · research · ops. For a **build** ask, hand off to the `enhance-intent` MCP tool (server `oss`) - it adds the platform catalog, requirements checklist, and `pnpm gen` playbook - and stop here.
-3. **Gather scoped context** - targeted, never a data dump (token budget matters). Pull only what changes the plan: your issue tracker / roadmap, product specs and design decisions, recent team-chat decisions, local `docs/` + ADRs, past sessions. Scope first (which project, epic, timeframe), then fetch. Roadmap and known-issue threads are signal; general chatter is noise.
+3. **Gather scoped context** - targeted, never a data dump (token budget matters). Pull only what changes the plan: Jira + Confluence via `atlassian-read` per `docs/agents/issue-tracker.md` (roadmap + related tickets, specs / decisions - comments and images included), Slack (recent decisions, `slack-reader`), local `docs/` + ADRs, past sessions. Scope first (which project, epic, timeframe), then fetch. Roadmap and known-issue threads are signal; general chatter is noise.
 4. **Surface blocking ambiguities only** - the questions whose answers change what you build. Resolve the rest with stated defaults. Don't interrogate.
 5. **Emit the brief**, sized to the task.
 

package/template/__dot__rulesync/skills/handoff/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: handoff
+description: >
+  Package the current task into a self-contained prompt another agent (a
+  teammate, or a fresh Claude session in another repo) can execute without this
+  conversation. Gathers context from the chat so far plus live repo/environment
+  state, then emits a copy-pasteable handoff. Use on "hand this off", "prompt for
+  another agent", "write a handoff", when routing an OSS-core change into the
+  platform repo, or /handoff [what to hand off | target agent/repo]. Produces a
+  copy-pasteable prompt and may use any tool to gather context; the one hard line
+  is never force-push.
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Write
+  - Edit
+  - Bash
+disallowed-tools:
+  - Bash(git push --force:*)
+  - Bash(git push -f:*)
+  - Bash(git push --force-with-lease:*)
+  - Bash(git push --force-with-lease)
+  - Bash(git push -f)
+---
+
+# handoff - write a self-contained prompt for another agent
+
+Turn "what we're doing" into a prompt a _stranger_ agent can act on with zero access to this
+chat. The receiver has none of our context, so the prompt must carry all of it.
+
+Common use here: an OSS-core change that should run in a separate session. Any paired change can
+be made here, in an OSS worktree - see "Changing OSS core" in the `oss-boundaries` rule. When it
+runs elsewhere, the receiver is a teammate or a new agent session rooted in the platform
+checkout, and either way it needs a standalone brief.
+
+Optional argument = what to hand off / who to (e.g. `the OSS core publish fix`, `to a teammate in
+the platform repo`, a repo path, an issue/MR#). No argument -> hand off the current in-flight task.
+
+## Rules
+
+- **One hard line: never force-push** (`git push --force` / `-f` / `--force-with-lease`), in any
+  repo, ever - it rewrites shared history. Every other tool is fair game. The skill's main output
+  is still the prompt; take further action (commit, push, spawn, launch) only on explicit confirmation.
+- **Self-contained.** The receiver can't see this conversation. Inline every fact they need:
+  exact paths, branch/remote names, IDs (MR/PR/ticket), commands, versions, error strings.
+  No "as discussed", no "the file we changed", no unresolved pronouns.
+- **Facts over memory.** Verify the moving parts against live state (git, files, CLIs) before
+  writing them - don't trust half-remembered branch names or versions.
+- **No secrets.** Never inline tokens, passwords, or `.env` values. Reference the env var name.
+- **Scope, don't dump.** Include what's load-bearing for the task; link/name the rest.
+
+## Step 1 - Resolve scope
+
+From the argument + the conversation, state in one line: the goal, the target repo/dir, and (if
+known) the agent type or persona best suited. If genuinely ambiguous, ask one clarifying question;
+otherwise proceed with the obvious reading and note the assumption.
+
+## Step 2 - Gather live context
+
+Pull only what the task touches (skip irrelevant ones):
+
+- Repo/env: `pwd`; `git -C <dir> remote -v`; `git -C <dir> branch --show-current`;
+  `git -C <dir> status --short`; recent `git log --oneline -5`. Note default/target branch.
+- Work state: relevant file paths (verify they exist), functions/symbols, versions/pins,
+  exact error messages or failing job names, IDs (MR/PR/ticket/pipeline).
+- Conventions the receiver must follow: point at the repo's rules (`CLAUDE.md`,
+  `.rulesync/`, `AGENTS.md`) rather than restating them; call out any that bit us.
+- What's already done vs. what remains (so they don't redo or undo work).
+
+## Step 3 - Emit the handoff
+
+Output one fenced markdown block (so it copy-pastes cleanly), using these headings - drop any
+that don't apply, never pad:
+
+- **Task** - one imperative sentence: the outcome wanted.
+- **Environment** - repo(s), absolute path(s), remote(s), current + target branch, sibling deps.
+- **Background** - the why + current state + root cause/findings already established. This is
+  where prior investigation goes so it isn't repeated.
+- **Do this** - ordered, concrete steps. Name files/symbols/commands. Mark decisions that need
+  a human ("report the plan first, don't push").
+- **Verify** - the exact commands/gates that must pass, and the expected green result.
+- **Constraints** - boundaries (read-only zones, "never push without explicit yes", conventional
+  commits, branch-off-target, don't touch X). Inherit the repo's rules; restate only the sharp edges.
+
+After the block, in <=2 lines: state the key assumption you made, and offer to (a) tweak the
+prompt, (b) save it to a file, or (c) launch it now (spawn a teammate with a suitable agent type,
+or hand it to the operator to paste into a session rooted in the target repo). Only save or launch
+on explicit confirmation.
+
+## Quality bar
+
+A good handoff passes this test: **hand it to someone who has never seen this repo or chat, and
+they can start in under a minute and finish without asking you anything.** If a step assumes
+context the block doesn't contain, fix the block.