@ooneex/cli 1.46.0 → 1.48.0

package/dist/index.js

@@ -21766,7 +21766,7 @@ var api_issue_fixer_md_default = `---
 name: api-issue-fixer
 description: Implements a single planned issue in a backend API module (\`type: "api"\`) \u2014 controllers and routes with correct HTTP semantics (status codes, request/response DTOs & validation, pagination, roles/permissions), plus the supporting services, repositories, entities, and migrations \u2014 following Clean Architecture, then lints, satisfies the Definition of Done, and marks the issue Done. Use proactively whenever a \`type: "api"\` issue needs implementing.
 tools: Read, Edit, Write, Bash, Grep, Glob, Skill
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -21885,7 +21885,7 @@ var api_issue_founder_md_default = `---
 name: api-issue-founder
 description: Audits a backend API module's source for issues \u2014 HTTP/REST contract design, status codes, request/response DTOs and validation, versioning, pagination, rate limiting, auth/authz on routes, error-response shape, and contract consistency \u2014 plus the standard backend categories (Security, Performance, Architecture, Missing Tests, Improvement, Code Quality, Database). Use proactively whenever a \`type: "api"\` module needs review. It only finds and reports \u2014 it never writes issue files or runs oo commands.
 tools: Read, Grep, Glob
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -21963,7 +21963,7 @@ var design_issue_fixer_md_default = `---
 name: design-issue-fixer
 description: Implements a single planned issue in a front-end design-system module (\`type: "design"\`) \u2014 components, hooks, icons, fonts, styles, and utils organized by asset kind \u2014 then lints, satisfies the Definition of Done, and marks the issue Done. Use proactively whenever a \`type: "design"\` issue needs implementing.
 tools: Read, Edit, Write, Bash, Grep, Glob, Skill
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22064,7 +22064,7 @@ var design_issue_founder_md_default = `---
 name: design-issue-founder
 description: Audits a front-end module's source for Design (UI/UX) issues \u2014 accessibility, contrast, responsiveness, design-system consistency, interaction states, localization, layout stability, and messaging \u2014 and returns the findings. Use proactively whenever a module's UI needs a design review, and especially when the /issue:found skill audits the Design category. It only finds and reports \u2014 it never writes issue files or runs oo commands.
 tools: Read, Grep, Glob
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22130,7 +22130,7 @@ var microservice_issue_fixer_md_default = `---
 name: microservice-issue-fixer
 description: Implements a single planned issue in a microservice module (\`type: "microservice"\`) \u2014 services, controllers, repositories, entities, migrations, and event/message handlers \u2014 with attention to idempotency, resilience, message contracts, and observability, following Clean Architecture, then lints, satisfies the Definition of Done, and marks the issue Done. Use proactively whenever a \`type: "microservice"\` issue needs implementing.
 tools: Read, Edit, Write, Bash, Grep, Glob, Skill
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22258,7 +22258,7 @@ var microservice_issue_founder_md_default = `---
 name: microservice-issue-founder
 description: Audits a microservice module's source for issues \u2014 service boundaries and data ownership, message/event contracts, idempotency, retries/timeouts/circuit breakers, distributed-transaction/saga handling, eventual consistency, health checks, graceful shutdown, config/secrets, and observability \u2014 plus the standard backend categories (Security, Performance, Architecture, Missing Tests, Improvement, Code Quality, Database). Use proactively whenever a \`type: "microservice"\` module needs review. It only finds and reports \u2014 it never writes issue files or runs oo commands.
 tools: Read, Grep, Glob
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22346,7 +22346,7 @@ var module_issue_fixer_md_default = `---
 name: module-issue-fixer
 description: Implements a single planned issue in a backend business-domain module (\`type: "module"\` or untyped) \u2014 entities, repositories, services, controllers/commands, migrations, and optional resources \u2014 following Clean Architecture, then lints, satisfies the Definition of Done, and marks the issue Done. Use proactively whenever a backend \`module\` issue needs implementing, and especially when the /issue:fix skill dispatches a backend module.
 tools: Read, Edit, Write, Bash, Grep, Glob, Skill
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22483,7 +22483,7 @@ var module_issue_founder_md_default = `---
 name: module-issue-founder
 description: Audits a backend business-domain module's source for issues across Security, Performance, Architecture (Clean Architecture), Missing Tests, Improvement, Code Quality, and Database \u2014 and returns the findings. Use proactively whenever a \`type: "module"\` (or untyped) backend module needs review, and especially when the /issue:found skill audits a backend module. It only finds and reports \u2014 it never writes issue files or runs oo commands.
 tools: Read, Grep, Glob
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22564,7 +22564,7 @@ var spa_issue_fixer_md_default = `---
 name: spa-issue-fixer
 description: Implements a single planned issue in a front-end SPA module (\`type: "spa"\`) \u2014 a TanStack Router + TanStack Query app organized as vertical feature slices (routes, features, shared) \u2014 then lints, satisfies the Definition of Done, and marks the issue Done. Use proactively whenever a \`type: "spa"\` issue needs implementing.
 tools: Read, Edit, Write, Bash, Grep, Glob, Skill
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22671,7 +22671,7 @@ var spa_issue_founder_md_default = `---
 name: spa-issue-founder
 description: Audits a front-end module's source for SPA (client-side) issues \u2014 unhandled async states, route guards, render performance, state mutation, effect lifecycles, shared state, API error handling, optimistic-update rollback, code-splitting, and navigation behavior \u2014 and returns the findings. Use proactively whenever a module's client-side behavior needs review, and especially when the /issue:found skill audits the SPA category. It only finds and reports \u2014 it never writes issue files or runs oo commands.
 tools: Read, Grep, Glob
-model: inherit
+model: opus
 memory: project
 ---
 
@@ -22758,29 +22758,15 @@ var AGENTS_md_default = `# AGENTS.md
 
 Guidance for AI coding agents working in this repository.
 
-This file holds only the always-on **rules**. Detailed reference and task
-workflows live in conditionally-activated **skills** (see the index below) so
-this file stays lean and avoids loading unused context.
+This file is a lean index. Coding conventions, reference, and task workflows
+all live in conditionally-activated **skills** (see the index below) so this
+file stays small and avoids loading unused context. Reach for a skill when you
+need the detail behind a task.
 
 ## Project Overview
 
 {{NAME}} is a modular, enterprise-grade TypeScript/Bun backend powered by the **@ooneex** ecosystem. Code lives in independent modules under \`modules/\`, each owning its controllers, services, repositories, entities, migrations, and seeds.
 
-## Core Rules
-
-These apply to every change. Reach for a skill when you need the detail behind one.
-
-- **Prefer @ooneex packages** over third-party alternatives, and inject their services via the DI container rather than instantiating them. Full catalog: the \`ooneex:packages\` skill.
-- **Dependency Injection** \u2014 every DI class is registered with a decorator (InversifyJS via \`@ooneex/container\`) and uses the matching suffix: Services \u2192 \`@decorator.service()\` / \`Service\`; Repositories \u2192 \`@decorator.repository()\` / \`Repository\`; Middlewares \u2192 \`@decorator.middleware()\` / \`Middleware\`; Crons \u2192 \`@decorator.cron()\` / \`Cron\`; Controllers \u2192 controller-specific decorators. Breaking these throws \`ContainerException\` at startup. Use constructor injection via \`@inject()\`.
-- **Environment variables** \u2014 never read \`process.env\` directly. Inject \`AppEnv\` from \`@ooneex/app-env\` and read typed properties.
-- **Exceptions** \u2014 throw typed exceptions extending \`Exception\` from \`@ooneex/exception\` (HTTP status + structured data) instead of returning \`null\` or error codes.
-- **TypeScript** \u2014 strict mode with \`noUncheckedIndexedAccess\` + \`exactOptionalPropertyTypes\`, decorators (\`emitDecoratorMetadata\`), ESNext modules with bundler resolution, target ES2022.
-- **Naming** \u2014 types end with \`Type\`; interfaces start with \`I\`.
-- **Arrow functions** everywhere except class methods.
-- **Visibility** \u2014 explicit \`public\` / \`private\` / \`protected\` on every method and property.
-- **No non-null assertions** \u2014 use defaults or optional types.
-- **Hygiene** \u2014 no unused imports, dead code, or bare \`TODO\` comments.
-
 ## Skills
 
 Skills load on demand based on the task \u2014 invoke or let them activate when relevant; do not duplicate their content here.
@@ -22936,12 +22922,13 @@ describe("<Name>Ai", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/analytics.create.md.txt
@@ -23037,12 +23024,13 @@ describe("<Name>Analytics", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/cache.create.md.txt
@@ -23182,12 +23170,13 @@ describe("<Name>Cache", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/command.create.md.txt
@@ -23326,12 +23315,13 @@ describe("<Name>Command", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/commit.md.txt
@@ -23641,13 +23631,14 @@ describe("<Name>Controller", () => {
 
 Add \`<Name>Controller\` to the \`controllers\` array in \`src/<PascalModuleName>Module.ts\` (see \`ooneex:scaffold\` for the \`ModuleType\` shape).
 
-### 7. Lint and format
+### 7. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
 
+Fix every failure before completing.
+
 ### 8. Create the service
 
 \`\`\`
@@ -24013,12 +24004,13 @@ describe("<Name>Cron", () => {
 
 Add \`<Name>Cron\` to the \`cronJobs\` array in \`src/<PascalModuleName>Module.ts\` (see \`ooneex:scaffold\` for the \`ModuleType\` shape).
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/database.create.md.txt
@@ -24143,12 +24135,13 @@ describe("<Name>Database", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/entity.create.md.txt
@@ -24483,12 +24476,13 @@ describe("<Name>Entity", () => {
 
 Add \`<Name>Entity\` to the \`entities\` array in \`src/<PascalModuleName>Module.ts\` (see \`ooneex:scaffold\` for the \`ModuleType\` shape).
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/flag.create.md.txt
@@ -24599,12 +24593,13 @@ describe("<Name>FeatureFlag", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/issue.fix.md.txt
@@ -24717,6 +24712,10 @@ Infer which modules the user wants audited from their input \u2014 this may be o
 
 ## Workflow
 
+### 0. Switch to Plan Mode
+
+Before doing anything else, switch to **plan mode**. This skill only reads and audits source code \u2014 it never writes YAML, creates issue files, or runs \`oo\` directly \u2014 so the whole audit must run as a read-only investigation. Stay in plan mode through steps 1\u20132 (resolving modules and delegating to founders); the hand-off to \`/issue:plan\` in step 3 is where any actual issue creation happens.
+
 ### 1. Resolve the Modules to Audit from the User Input
 
 The user does **not** have to pass explicit flags \u2014 infer the target modules from whatever they provide. The input may name one or more modules. Resolve it into a concrete list of modules to audit:
@@ -24784,7 +24783,7 @@ Once every resolved module has been audited, report a summary covering the whole
 `;
 
 // src/templates/llm/skills/issue.plan.md.txt
-var issue_plan_md_default = "---\nname: issue:plan\ndescription: Create and plan one or more YAML issues from the user's input. Infers the target issues and modules from whatever the user says \u2014 existing issue files/IDs and/or free-form descriptions, across one or more modules. For each description it first scaffolds the issue with oo issue:create (inferring the module name from the input), then plans it \u2014 restructuring into context, goal, definition of done, and dependencies, extracting labels, and optionally splitting into ordered sub-issues sharing that same structure. Reads from / writes to modules/<module>/issues/<ID>.yml.\n---\n\n# Issue Plan\n\nInfer which issues the user wants planned from their input \u2014 this may be one or more issues spread across one or more modules \u2014 and plan each one. Each input item is **either** an existing issue (ID or path) **or** a free-form description of work to do. Either way the result is a planned issue: restructured into `context` / `goal` / `dod` / `dependencies`, with suggested labels, set state and priority, and optionally broken into ordered, self-contained sub-issues (same structure) that read as a step-by-step implementation guide.\n\n## Workflow\n\n### 0. Resolve the Targets and Mode\n\nThe user does **not** have to plan a single issue. Infer the full set of issues to plan from their input \u2014 it may name several issues across several modules, mixing existing issues with new descriptions. Resolve the input into a list of targets, each tagged with its mode:\n\n- **Plan mode** \u2014 an existing issue ID (e.g. `OON-123456`) or a path to a `.yml` file under `modules/<module>/issues/`. If an ID is given without a module, glob `modules/*/issues/<ID>.yml` to find the owning module; if several match, plan each. Goes straight to step 1.\n- **Create mode** \u2014 a free-form description of work with no existing issue. Run step 0a to scaffold it first, then continue to step 1 to plan it.\n\nSplitting the input into targets:\n- Multiple IDs/paths (repeated, comma-separated, or listed) each become a plan-mode target.\n- A free-form description that covers **distinct, unrelated pieces of work \u2014 especially work spanning different modules** \u2014 becomes **one create-mode target per piece** (e.g. \"add an org create API and a billing settings page\" \u2192 a backend issue in the relevant module + a spa issue in another). Keep tightly related work as a single target; step 4 decides whether to split it into sub-issues.\n- When it's unclear whether a fragment is one issue or several, prefer fewer targets and let the splitting step (4\u20135) break them down; only ask the user when the grouping genuinely can't be inferred.\n\nWhen unclear whether a fragment is an existing issue or a description, treat anything that isn't a recognizable issue ID or existing file path as a description (create mode).\n\nBuild the full target list first, then run steps 0a\u20136 for **each** target in turn. If the input resolves to no targets at all, tell the user nothing matched and stop.\n\n### 0a. Create Mode \u2014 Scaffold the Issue First\n\n**Always run commands from the monorepo root**, not from inside individual packages.\n\nRun this for each create-mode target. Derive these fields from that target's slice of the description \u2014 infer reasonable values, ask only when a required value genuinely can't be inferred:\n\n| Field | Default | How to derive |\n|-------|---------|---------------|\n| `title` | \u2014 (required) | Concise, action-oriented (verb + noun). Use the user's wording; never invent. |\n| `module` | `shared` | **Infer from the input** \u2014 match domain nouns in the description to a module under `modules/` (e.g. \"user profile\" \u2192 `user`, \"checkout\" \u2192 `order`). Verify the module exists; if no match, default to `shared` and say so. |\n| `priority` | inferred (see step 3) | Infer from the description; honor any explicitly stated priority. |\n| `labels` | `[]` | Suggest from the description (see step 3 vocabulary); `/issue:plan` refines them below. |\n| `description` | `null` | The user's free-form text, as-is \u2014 the planning steps structure it. |\n\n`state` is **always** `Todo` at creation \u2014 never ask for it. The planning steps move it to `Planned`.\n\nRun:\n\n```bash\noo issue:create \\\n  --title=\"<title>\" \\\n  --module=<module> \\\n  --state=\"Todo\" \\\n  --priority=\"<priority>\" \\\n  [--labels=\"<label1>,<label2>\"] \\\n  [--description=\"<description>\"]\n```\n\nThis writes a YAML skeleton to `modules/<module>/issues/<ID>.yml` (`<ID>` auto-generated, e.g. `ABC-012345`). Note the created `<ID>` and `<module>`, then continue to step 1 to plan the issue you just created.\n\n### 1. Locate the Issue File and Module Type\n\nFor the current target \u2014 plan mode: use its resolved issue ID/path (if a plan-mode target's file can't be found, record the exact path checked, skip it, and continue with the remaining targets). Create mode: use the file just scaffolded in step 0a. Read `modules/<module>/issues/<ID>.yml` (default module: `shared`) with the Read tool.\n\nIf an existing (plan-mode) issue's `state` is already `Planned`, it has already been planned \u2014 skip it (do not re-plan or restructure it) and continue with the remaining targets. Note the skip for the step 7 summary. (Newly scaffolded create-mode issues are always `Todo`, so this never skips them.)\n\nThen read the module's config at `modules/<module>/<module>.yml` to find its `type`. This decides which technical vocabulary the `goal` uses (see **Technical Structure by Module Type** below):\n- `type: \"module\"`, `\"api\"`, `\"microservice\"` (or no `type`) \u2014 a backend module \u2192 `### Data Model` with TypeORM relations.\n- `type: \"spa\"` \u2014 a front-end single-page application \u2192 `### Front-End Structure` with features/routes/layouts/hooks/services.\n- `type: \"design\"` \u2014 a front-end design system \u2192 `### Design System Structure` with components/hooks/icons/styles.\n\n### 2. Restructure the Parent Issue\n\nReplace the parent's free-form `description` with the **same four fields used by sub-issues**, so the parent is structurally identical to a sub-issue:\n\n- `context` \u2014 relevant background and why the issue exists\n- `goal` \u2014 the concrete work to do, including any **Technical Notes** (constraints, hints) and the technical subsection that matches the module type (`### Data Model`, `### Front-End Structure`, or `### Design System Structure` \u2014 see **Technical Structure by Module Type**), when applicable\n- `dod` \u2014 acceptance criteria as checkboxes (`- [ ]`), all of which must be satisfied\n- `dependencies` \u2014 issue IDs that must be completed first (usually `[]` for a standalone parent)\n\nRules:\n- Preserve all factual information from the original description; keep fields concise and actionable.\n- `dod` items are checkboxes, never prose. When a `dod` item covers a data model, add indented sub-checkboxes per field: `  - [ ] \\`fieldName\\` \u2014 <description>`.\n- `dod` descriptions are plain English outcomes \u2014 no implementation syntax. For backend entities: `` `type` \u2014 b2b | school | internal `` (not `ENUM(...)`); `` `createdAt` \u2014 Created date `` (not `TIMESTAMPTZ via @CreateDateColumn`); `` `packs` \u2014 One organization has many packs `` (not the `@OneToMany` decorator). For spa/design: `` Profile page renders the user's avatar and name `` (not `<UserAvatar/> in features/user/components`).\n- Use the entity name, not an ID suffix: `` `address` \u2014 User has one address `` (not `addressId`); `` `organization` \u2014 Membership belongs to one organization `` (not `organizationId`).\n- Implementation specifics (TypeORM decorators, component/file paths, hook names) appear only in the `goal` field's technical subsection, never in `dod`.\n- This step only applies when the issue is **not** split \u2014 when split, the parent file is deleted (step 5) and its intent lives entirely in the sub-issues.\n\n### 3. Extract Labels, Set State and Priority\n\n**Labels** \u2014 Suggest relevant labels: short (1\u20133 words), Title Case for general terms, uppercase for acronyms. Deduplicate against labels already in the YAML. Common vocabulary (use these exact casings): `Feature`, `Bug`, `Improvement`, `Enhancement`, `Performance`, `Refactor`, `Security`, `Breaking Change`, `Documentation`, `Testing`, `Database`, `API`, `UI`, `Infrastructure`, `Cleanup`.\n\n**State** \u2014 Valid: `Todo`, `Planned`, `In Progress`, `Done`. This skill produces a plan, so always set `state: \"Planned\"` (on every sub-issue when split, or the parent when not). `Planned` means ready to pick up \u2014 `/issue:fix` takes it from there. Never set any other state.\n\n**Priority** \u2014 Always set/confirm `priority`. Valid: `Urgent`, `High`, `Medium`, `Low`. Infer from the title and description rather than asking:\n- `Urgent` \u2014 outages, security vulnerabilities, data loss, broken builds, blockers (\"critical\", \"asap\", \"broken\", \"down\", \"vulnerability\").\n- `High` \u2014 important bugs/features users are waiting on, regressions, time-sensitive work.\n- `Medium` \u2014 standard features, improvements, non-blocking bugs (fallback when no signal points elsewhere).\n- `Low` \u2014 nice-to-haves, polish, refactors, docs, chores.\n\nHonor an explicitly stated priority over the inferred value.\n\n### 4. Check Whether Splitting Is Needed\n\nSplit when the issue: spans multiple unrelated concerns/areas, can't be done in one focused session, or has several independent acceptance criteria that could ship separately. Skip splitting if it's already small and focused.\n\n### 5. Plan the Sub-Issues (if needed)\n\nBreak the issue into 3\u20137 small, self-contained, independently implementable sub-issues that read as an ordered implementation guide. For each:\n- Generate an ID in the format `XXX-000000` (3 uppercase letters + 6 digits).\n- Write a new YAML file to the same `modules/<module>/issues/` directory.\n- Inherit `priority` and `labels` from the parent; set `state: \"Planned\"`.\n- Order by implementation sequence, expressed through `dependencies`.\n\nEach sub-issue uses the same four fields as the parent (`context` scoped to the sub-issue plus how it fits the larger plan; `goal`; `dod`; `dependencies` = sub-issue IDs to complete first, `[]` when none).\n\nWhen a sub-issue needs implementation detail, the `goal` includes the technical subsection matching the module type (see **Technical Structure by Module Type** for the full vocabulary of each). For backend modules that means a `### Data Model` subsection listing every relation with the exact field name on the owning entity, the TypeORM decorator, and the inverse field / FK-or-join-table owner:\n\n```\n- `EntityA.fieldName` \u2192 `@OneToMany(() => EntityB, (b) => b.a)` \u2014 one A has many Bs\n- `EntityB.fieldName` \u2192 `@ManyToOne(() => EntityA, (a) => a.bs)` \u2014 many Bs belong to one A\n- `EntityA.fieldName` \u2192 `@ManyToMany(() => EntityB)` + `@JoinTable()` \u2014 pivot table owned by A\n- `EntityA.fieldName` \u2192 `@OneToOne(() => EntityB)` + `@JoinColumn()` \u2014 one-to-one, FK on A\n```\n\nFor spa modules use `### Front-End Structure` and for design modules use `### Design System Structure`, listing the concrete files/folders to add or change under that module's conventions.\n\nAfter writing all sub-issues, **delete the parent issue file** \u2014 the sub-issues fully replace it. First confirm every piece of the parent's intent is carried into at least one sub-issue's `context`, `goal`, or `dod`. List each created sub-issue (ID and title) so the user sees what replaced the parent.\n\nSub-issue YAML structure:\n```yaml\nid: \"<generated-id>\"\ntitle: \"<action-oriented title: verb + noun>\"\nstate: \"Planned\"\npriority: \"<parent priority>\"\nlabels:\n  - \"<label>\"\ncontext: |\n  <Details needed to understand this sub-issue \u2014 2\u20133 sentences scoped to it>\ngoal: |\n  <What this sub-issue specifically achieves>\n\n  ## Technical Notes\n  <Optional \u2014 omit if not applicable>\n\n  ### Data Model | Front-End Structure | Design System Structure\n  <Subsection matching the module type \u2014 omit if not applicable>\ndod: |\n  - [ ] <Condition 1>\n  - [ ] <\u2026>\ndependencies:\n  - \"<id of a sub-issue to complete first>\"\n```\n\n### 6. Save Changes\n\n- **If split:** write all sub-issue files, then `rm modules/<module>/issues/<ID>.yml` (Bash). Confirm each sub-issue written and the parent removed, showing relative paths.\n- **If not split:** rewrite the parent YAML with `context`/`goal`/`dod`/`dependencies` (replacing `description`) plus new labels, via Edit or Write. Confirm with the relative path.\n\n### 7. Confirm the Batch\n\nOnce every resolved target has been planned, report a summary covering the whole batch. For **each** issue: its `id`, `title`, module, mode (created vs. planned-in-place), final `priority`/`labels`, and whether it was split (listing the sub-issue IDs/titles that replaced it). Then list any targets that were skipped or could not be planned (e.g. an existing issue already in `Planned` state, a plan-mode file not found with the exact path checked, or an ambiguous grouping awaiting confirmation).\n\n## YAML Structure Reference\n\nParent issue when not split \u2014 same structure as a sub-issue, plus any existing `comments`:\n```yaml\nid: \"OON-123456\"\ntitle: \"Add user validation\"\nstate: \"Planned\"\npriority: \"High\"\nlabels:\n  - \"Enhancement\"\n  - \"API\"\ncontext: |\n  <Details needed to understand it>\ngoal: |\n  <What to do>\n\n  ## Technical Notes\n  <Optional \u2014 omit if not applicable>\n\n  ### Data Model | Front-End Structure | Design System Structure\n  <Subsection matching the module type \u2014 omit if not applicable>\ndod: |\n  - [ ] <Condition 1>\n  - [ ] <\u2026>\ndependencies: []\ncomments:\n  - author: \"Alice\"\n    message: \"Some comment\"\n```\n\n## Technical Structure by Module Type\n\nThe `goal` field's technical subsection follows the conventions of the module the issue lives in (from step 1's `<module>.yml` `type`). Use exactly one of the three, matching the type; omit it for issues with no structural component (pure bug fix, copy change, chore).\n\n### Backend module (`type: \"module\"`, `\"api\"`, `\"microservice\"`, or no `type`) \u2014 `### Data Model`\n\nThe module owns controllers, services, repositories, entities, migrations, and seeds under `src/`. List TypeORM relations with the exact field name on the owning entity, the decorator, and the inverse field / FK-or-join-table owner (see the block in step 5). Reference services, repositories, controllers, and DI by their `@ooneex` conventions; entities register in `SharedModule`.\n\n### SPA module (`type: \"spa\"`) \u2014 `### Front-End Structure`\n\nA front-end single-page app (TanStack Router + TanStack Query), **not** registered into `AppModule`/`SharedModule`. Code is organized as vertical slices \u2014 name the concrete files/folders to add or change:\n\n- `src/routes/<kebab>.tsx` \u2014 file-based route mapping to a URL; keep thin, delegate UI to features and data to services.\n- `src/features/<feature>/` \u2014 self-contained slice owning its `assets/`, `components/`, `hooks/` (data fetching / API calls / local UI state), `layouts/`, `services/` (the only layer that talks to the backend), `store/` (client state), `styles/`, `types/`, `utils/`. A feature must not import another feature's internals \u2014 promote anything shared to `src/shared/`.\n- `src/shared/<sub-layer>/` \u2014 the only place \u22652 features may import from in common (same sub-layout as a feature).\n\nWhen the work is a new feature, note that `oo spa:feature:create --name <Name> --module <module>` (skill `/spa:feature:create`) scaffolds the route, the page/skeleton/error/not-found layouts under `features/<feature>/layouts/`, and example query (`useGet<Name>`) + mutation (`useUpdate<Name>`) hooks under `features/<feature>/hooks/`. Describe the feature, its route path, the layouts, and the query/mutation hooks needed. Spell hooks as `useGet<Name>` / `useUpdate<Name>` and components/layouts in PascalCase.\n\n### Design module (`type: \"design\"`) \u2014 `### Design System Structure`\n\nA front-end design system (reusable UI primitives), **not** registered into `AppModule`/`SharedModule`. Code under `src/` is organized by asset kind \u2014 name the concrete files/folders to add or change:\n\n- `src/components/<component>/` \u2014 one folder per component grouping its variants (e.g. `button/` holds `Button.tsx`, `ButtonSave.tsx`, \u2026). Compose existing primitives instead of ad-hoc markup.\n- `src/hooks/` \u2014 generic presentation-layer hooks (state, DOM measurement, events); no domain/data-fetching logic.\n- `src/icons/` \u2014 SVG icons in `fill/` + `outline/` variants, grouped by category and size (`sm`, `md`, `lg`); add to the matching category folder, never inline SVG.\n- `src/fonts/` \u2014 bundled web fonts with their `@font-face` CSS; no external CDNs.\n- `src/styles/` \u2014 global stylesheets (`app.css`, `brand.css`, `typography.css`, \u2026) for app-wide tokens/themes; prefer shared styles + component-scoped classes over one-off CSS.\n- `src/utils/` \u2014 small pure presentation helpers (`cn`, `staleChunk`); no backend/business logic.\n\n## Notes\n\n- Never invent facts \u2014 only restructure and clarify what is already in the issue.\n- If the original description is missing or empty, tell the user and stop.\n- Only delete the parent after every sub-issue file is written \u2014 never leave the plan with neither parent nor sub-issues.\n- Keep dependencies acyclic \u2014 a sub-issue must never (directly or transitively) depend on itself.\n- When the batch spans related issues, wire `dependencies` across them \u2014 if one resolved issue must be implemented before another (even in a different module), reference the prerequisite's ID so `/issue:fix` picks them up in order.\n- Process targets independently \u2014 one target failing (missing file, empty description) skips only that target; continue planning the rest and report the skips in step 7.\n";
+var issue_plan_md_default = "---\nname: issue:plan\ndescription: Create and plan one or more YAML issues from the user's input. Infers target issues and modules from whatever the user says \u2014 existing issue files/IDs and/or free-form descriptions, across one or more modules. For each description it scaffolds the issue with oo issue:create (inferring the module), then plans it \u2014 restructuring into context, goal, definition of done, and dependencies, extracting labels, and optionally splitting into ordered sub-issues with the same structure. Reads/writes modules/<module>/issues/<ID>.yml.\n---\n\n# Issue Plan\n\nInfer which issues to plan from the user's input \u2014 one or more issues across one or more modules. Each input item is **either** an existing issue (ID or path) **or** a free-form description. Either way, the result is a planned issue: restructured into `context` / `goal` / `dod` / `dependencies`, labelled, with state and priority set, and optionally broken into ordered, self-contained sub-issues (same structure) that read as a step-by-step implementation guide.\n\n## Workflow\n\n### Switch to Plan Mode First\n\nBefore anything else, switch to **plan mode** (Claude Code's read-only mode \u2014 distinct from this skill's create/plan *target* modes in step 0). Do all investigation there: resolve targets, read existing issue files and module configs, work out how each issue is restructured, labelled, and split. Present the plan, then **exit plan mode to execute** \u2014 repo writes (`oo issue:create`, rewriting/Editing YAML, deleting a parent on split) only happen after you leave plan mode.\n\n### 0. Resolve the Targets and Mode\n\nThe input may name several issues across several modules, mixing existing issues with new descriptions. Resolve it into a list of targets, each tagged with its mode:\n\n- **Plan mode** \u2014 an existing issue ID (e.g. `OON-123456`) or path to a `.yml` under `modules/<module>/issues/`. If an ID is given without a module, glob `modules/*/issues/<ID>.yml`; plan each match. Goes straight to step 1.\n- **Create mode** \u2014 a free-form description with no existing issue. Run step 0a to scaffold, then step 1 to plan.\n\nSplitting input into targets:\n- Multiple IDs/paths (repeated, comma-separated, or listed) each become a plan-mode target.\n- A description covering **distinct, unrelated work \u2014 especially work spanning different modules** \u2014 becomes **one create-mode target per piece** (e.g. \"add an org create API and a billing settings page\" \u2192 a backend issue + a spa issue in another module). Keep tightly related work as one target; step 4 decides whether to split it.\n- When it's unclear whether a fragment is one issue or several, prefer fewer targets and let steps 4\u20135 break them down; only ask when the grouping genuinely can't be inferred.\n- Treat anything that isn't a recognizable issue ID or existing file path as a description (create mode).\n\nBuild the full target list first, then run steps 0a\u20136 for **each** target. If no targets resolve, tell the user nothing matched and stop.\n\n### 0a. Create Mode \u2014 Scaffold the Issue First\n\n**Always run commands from the monorepo root.** Run this per create-mode target. Derive fields from that target's slice of the description \u2014 infer reasonable values, ask only when a required value genuinely can't be inferred:\n\n| Field | Default | How to derive |\n|-------|---------|---------------|\n| `title` | \u2014 (required) | Concise, action-oriented (verb + noun). Use the user's wording; never invent. |\n| `module` | `shared` | **Infer from input** \u2014 match domain nouns to a module under `modules/` (e.g. \"user profile\" \u2192 `user`, \"checkout\" \u2192 `order`). Verify it exists; if no match, default to `shared` and say so. |\n| `priority` | inferred (step 3) | Infer from the description; honor any stated priority. |\n| `labels` | `[]` | Suggest from the description (step 3 vocabulary); refined below. |\n| `description` | `null` | The user's free-form text, as-is \u2014 planning steps structure it. |\n\n`state` is **always** `Todo` at creation \u2014 never ask. Planning moves it to `Planned`.\n\n```bash\noo issue:create \\\n  --title=\"<title>\" \\\n  --module=<module> \\\n  --state=\"Todo\" \\\n  --priority=\"<priority>\" \\\n  [--labels=\"<label1>,<label2>\"] \\\n  [--description=\"<description>\"]\n```\n\nThis writes a YAML skeleton to `modules/<module>/issues/<ID>.yml` (`<ID>` auto-generated, e.g. `ABC-012345`). Note the `<ID>` and `<module>`, then continue to step 1.\n\n### 1. Locate the Issue File and Module Type\n\nFor the current target \u2014 plan mode: use its resolved ID/path (if not found, record the exact path checked, skip it, continue with the rest). Create mode: use the file scaffolded in 0a. Read `modules/<module>/issues/<ID>.yml` (default module: `shared`).\n\nIf a plan-mode issue's `state` is already `Planned`, it's done \u2014 skip it (don't re-plan), note the skip for step 7, continue. (Create-mode issues are always `Todo`, so this never skips them.)\n\nThen read the module config `modules/<module>/<module>.yml` for its `type`, which decides the `goal`'s technical vocabulary (see **Technical Structure by Module Type**):\n- `type: \"module\"`, `\"api\"`, `\"microservice\"` (or none) \u2014 backend \u2192 `### Data Model` with TypeORM relations.\n- `type: \"spa\"` \u2014 front-end SPA \u2192 `### Front-End Structure` (features/routes/layouts/hooks/services).\n- `type: \"design\"` \u2014 design system \u2192 `### Design System Structure` (components/hooks/icons/styles).\n\n### 2. Restructure the Parent Issue\n\nReplace the free-form `description` with the **same four fields used by sub-issues**, so the parent is structurally identical to one:\n\n- `context` \u2014 relevant background and why the issue exists.\n- `goal` \u2014 concrete work to do, including any **Technical Notes** (constraints, hints) and the technical subsection matching the module type (`### Data Model` / `### Front-End Structure` / `### Design System Structure`), when applicable.\n- `dod` \u2014 acceptance criteria as checkboxes (`- [ ]`), all required.\n- `dependencies` \u2014 issue IDs to complete first (usually `[]` for a standalone parent).\n\nRules:\n- Preserve all factual information from the original; keep fields concise and actionable.\n- `dod` items are checkboxes, never prose. For data models, add indented sub-checkboxes per field: `  - [ ] \\`fieldName\\` \u2014 <description>`.\n- `dod` descriptions are plain-English outcomes \u2014 no implementation syntax. Backend: `` `type` \u2014 b2b | school | internal `` (not `ENUM(...)`); `` `createdAt` \u2014 Created date `` (not `TIMESTAMPTZ via @CreateDateColumn`); `` `packs` \u2014 One organization has many packs `` (not `@OneToMany`). SPA/design: `` Profile page renders the user's avatar and name `` (not `<UserAvatar/> in features/user/components`).\n- Use the entity name, not an ID suffix: `` `address` \u2014 User has one address `` (not `addressId`); `` `organization` \u2014 Membership belongs to one organization `` (not `organizationId`).\n- Implementation specifics (decorators, file paths, hook names) appear only in `goal`'s technical subsection, never in `dod`.\n- This step applies only when **not** split \u2014 when split, the parent is deleted (step 5) and its intent lives in the sub-issues.\n\n### 3. Extract Labels, Set State and Priority\n\n**Labels** \u2014 Suggest relevant labels: short (1\u20133 words), Title Case for general terms, uppercase for acronyms. Deduplicate against existing YAML labels. Vocabulary (exact casing): `Feature`, `Bug`, `Improvement`, `Enhancement`, `Performance`, `Refactor`, `Security`, `Breaking Change`, `Documentation`, `Testing`, `Database`, `API`, `UI`, `Infrastructure`, `Cleanup`.\n\n**State** \u2014 Valid: `Todo`, `Planned`, `In Progress`, `Done`. This skill produces a plan, so always set `state: \"Planned\"` (on every sub-issue when split, or the parent when not). `Planned` means ready to pick up \u2014 `/issue:fix` takes over. Never set any other state.\n\n**Priority** \u2014 Always set/confirm. Valid: `Urgent`, `High`, `Medium`, `Low`. Infer rather than ask:\n- `Urgent` \u2014 outages, security vulnerabilities, data loss, broken builds, blockers (\"critical\", \"asap\", \"broken\", \"down\", \"vulnerability\").\n- `High` \u2014 important bugs/features users await, regressions, time-sensitive work.\n- `Medium` \u2014 standard features, improvements, non-blocking bugs (fallback when no signal).\n- `Low` \u2014 nice-to-haves, polish, refactors, docs, chores.\n\nHonor an explicitly stated priority over the inferred value.\n\n### 4. Check Whether Splitting Is Needed\n\nSplit when the issue spans multiple unrelated concerns, can't be done in one focused session, or has several independent acceptance criteria that could ship separately. Skip if it's already small and focused.\n\n### 5. Plan the Sub-Issues (if needed)\n\nBreak into 3\u20137 small, self-contained, independently implementable sub-issues that read as an ordered guide. For each:\n- Generate an ID `XXX-000000` (3 uppercase letters + 6 digits).\n- Write a new YAML file to the same `modules/<module>/issues/` directory.\n- Inherit `priority` and `labels` from the parent; set `state: \"Planned\"`.\n- Order by implementation sequence, expressed through `dependencies`.\n\nEach sub-issue uses the same four fields (`context` scoped to it plus how it fits the larger plan; `goal`; `dod`; `dependencies` = sub-issue IDs to complete first, `[]` when none).\n\nWhen a sub-issue needs implementation detail, `goal` includes the technical subsection matching the module type (see **Technical Structure by Module Type**). For backend, `### Data Model` lists every relation with the exact field name on the owning entity, the TypeORM decorator, and the inverse field / FK-or-join-table owner:\n\n```\n- `EntityA.fieldName` \u2192 `@OneToMany(() => EntityB, (b) => b.a)` \u2014 one A has many Bs\n- `EntityB.fieldName` \u2192 `@ManyToOne(() => EntityA, (a) => a.bs)` \u2014 many Bs belong to one A\n- `EntityA.fieldName` \u2192 `@ManyToMany(() => EntityB)` + `@JoinTable()` \u2014 pivot table owned by A\n- `EntityA.fieldName` \u2192 `@OneToOne(() => EntityB)` + `@JoinColumn()` \u2014 one-to-one, FK on A\n```\n\nFor spa use `### Front-End Structure`, for design `### Design System Structure`, naming the concrete files/folders to add or change under that module's conventions.\n\nAfter writing all sub-issues, **delete the parent issue file** \u2014 the sub-issues fully replace it. First confirm every piece of the parent's intent is carried into at least one sub-issue's `context`, `goal`, or `dod`. List each created sub-issue (ID and title) so the user sees what replaced the parent.\n\nSub-issue YAML:\n```yaml\nid: \"<generated-id>\"\ntitle: \"<action-oriented title: verb + noun>\"\nstate: \"Planned\"\npriority: \"<parent priority>\"\nlabels:\n  - \"<label>\"\ncontext: |\n  <Details needed to understand this sub-issue \u2014 2\u20133 sentences scoped to it>\ngoal: |\n  <What this sub-issue specifically achieves>\n\n  ## Technical Notes\n  <Optional \u2014 omit if not applicable>\n\n  ### Data Model | Front-End Structure | Design System Structure\n  <Subsection matching the module type \u2014 omit if not applicable>\ndod: |\n  - [ ] <Condition 1>\n  - [ ] <\u2026>\ndependencies:\n  - \"<id of a sub-issue to complete first>\"\n```\n\n### 6. Save Changes\n\n- **If split:** write all sub-issue files, then `rm modules/<module>/issues/<ID>.yml` (Bash). Confirm each sub-issue written and the parent removed, with relative paths.\n- **If not split:** rewrite the parent YAML with `context`/`goal`/`dod`/`dependencies` (replacing `description`) plus new labels, via Edit or Write. Confirm with the relative path.\n\n### 7. Confirm the Batch\n\nOnce every target is planned, report a batch summary. Per issue: `id`, `title`, module, mode (created vs. planned-in-place), final `priority`/`labels`, and whether it was split (listing the sub-issue IDs/titles that replaced it). Then list any skipped or unplannable targets (already `Planned`, plan-mode file not found with the exact path checked, or an ambiguous grouping awaiting confirmation).\n\n## YAML Structure Reference\n\nParent issue when not split \u2014 same structure as a sub-issue, plus any existing `comments`:\n```yaml\nid: \"OON-123456\"\ntitle: \"Add user validation\"\nstate: \"Planned\"\npriority: \"High\"\nlabels:\n  - \"Enhancement\"\n  - \"API\"\ncontext: |\n  <Details needed to understand it>\ngoal: |\n  <What to do>\n\n  ## Technical Notes\n  <Optional \u2014 omit if not applicable>\n\n  ### Data Model | Front-End Structure | Design System Structure\n  <Subsection matching the module type \u2014 omit if not applicable>\ndod: |\n  - [ ] <Condition 1>\n  - [ ] <\u2026>\ndependencies: []\ncomments:\n  - author: \"Alice\"\n    message: \"Some comment\"\n```\n\n## Technical Structure by Module Type\n\nThe `goal`'s technical subsection follows the module's conventions (from step 1's `<module>.yml` `type`). Use exactly one of the three, matching the type; omit it for issues with no structural component (pure bug fix, copy change, chore).\n\n### Backend module (`type: \"module\"`, `\"api\"`, `\"microservice\"`, or none) \u2014 `### Data Model`\n\nThe module owns controllers, services, repositories, entities, migrations, and seeds under `src/`. List TypeORM relations with the exact field name on the owning entity, the decorator, and the inverse field / FK-or-join-table owner (see the block in step 5). Reference services, repositories, controllers, and DI by their `@ooneex` conventions; entities register in `SharedModule`.\n\n### SPA module (`type: \"spa\"`) \u2014 `### Front-End Structure`\n\nA front-end SPA (TanStack Router + TanStack Query), **not** registered into `AppModule`/`SharedModule`. Code is organized as vertical slices \u2014 name the concrete files/folders to add or change:\n\n- `src/routes/<kebab>.tsx` \u2014 file-based route mapping to a URL; keep thin, delegate UI to features and data to services.\n- `src/features/<feature>/` \u2014 self-contained slice owning its `assets/`, `components/`, `hooks/` (data fetching / API calls / local UI state), `layouts/`, `services/` (the only layer talking to the backend), `store/` (client state), `styles/`, `types/`, `utils/`. A feature must not import another feature's internals \u2014 promote shared code to `src/shared/`.\n- `src/shared/<sub-layer>/` \u2014 the only place \u22652 features may import from in common (same sub-layout as a feature).\n\nFor a new feature, note that `oo spa:feature:create --name <Name> --module <module>` (skill `/spa:feature:create`) scaffolds the route, the page/skeleton/error/not-found layouts under `features/<feature>/layouts/`, and example query (`useGet<Name>`) + mutation (`useUpdate<Name>`) hooks under `features/<feature>/hooks/`. Describe the feature, its route path, the layouts, and the hooks needed. Spell hooks as `useGet<Name>` / `useUpdate<Name>` and components/layouts in PascalCase.\n\n### Design module (`type: \"design\"`) \u2014 `### Design System Structure`\n\nA front-end design system (reusable UI primitives), **not** registered into `AppModule`/`SharedModule`. Code under `src/` is organized by asset kind \u2014 name the concrete files/folders to add or change:\n\n- `src/components/<component>/` \u2014 one folder per component grouping its variants (e.g. `button/` holds `Button.tsx`, `ButtonSave.tsx`, \u2026). Compose existing primitives instead of ad-hoc markup.\n- `src/hooks/` \u2014 generic presentation-layer hooks (state, DOM measurement, events); no domain/data-fetching logic.\n- `src/icons/` \u2014 SVG icons in `fill/` + `outline/` variants, grouped by category and size (`sm`, `md`, `lg`); add to the matching category folder, never inline SVG.\n- `src/fonts/` \u2014 bundled web fonts with their `@font-face` CSS; no external CDNs.\n- `src/styles/` \u2014 global stylesheets (`app.css`, `brand.css`, `typography.css`, \u2026) for app-wide tokens/themes; prefer shared styles + component-scoped classes over one-off CSS.\n- `src/utils/` \u2014 small pure presentation helpers (`cn`, `staleChunk`); no backend/business logic.\n\n## Notes\n\n- Never invent facts \u2014 only restructure and clarify what's already in the issue.\n- If the original description is missing or empty, tell the user and stop.\n- Only delete the parent after every sub-issue file is written \u2014 never leave the plan with neither parent nor sub-issues.\n- Keep dependencies acyclic \u2014 a sub-issue must never (directly or transitively) depend on itself.\n- When the batch spans related issues, wire `dependencies` across them \u2014 if one must be implemented before another (even in a different module), reference the prerequisite's ID so `/issue:fix` picks them up in order.\n- Process targets independently \u2014 one failing (missing file, empty description) skips only that target; continue with the rest and report skips in step 7.\n";
 
 // src/templates/llm/skills/logger.create.md.txt
 var logger_create_md_default = `---
@@ -24943,12 +24942,13 @@ describe("<Name>Logger", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/mailer.create.md.txt
@@ -25131,12 +25131,13 @@ describe("<Name>MailerTemplate", () => {
 });
 \`\`\`
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/middleware.create.md.txt
@@ -25258,12 +25259,13 @@ describe("<Name>Middleware", () => {
 
 Add \`<Name>Middleware\` to the \`middlewares\` array in \`src/<PascalModuleName>Module.ts\` (see \`ooneex:scaffold\` for the \`ModuleType\` shape).
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/migration.create.md.txt
@@ -25394,12 +25396,13 @@ describe("Migration<version>", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/ooneex.architecture.md.txt
@@ -25723,141 +25726,135 @@ var ooneex_scaffold_md_default = "---\nname: ooneex:scaffold\ndescription: Share
 // src/templates/llm/skills/optimize.md.txt
 var optimize_md_default = `---
 name: optimize
-description: Optimize a module's codebase for quality, performance, and clean conventions. Enforces arrow functions (except class methods), type/interface naming, removes duplication, and ensures only important tests remain.
+description: Optimize a module's codebase for quality, performance, and clean conventions. Enforces arrow functions (except class methods), Type/I naming, explicit visibility, nullable columns; removes duplication and dead code; prunes trivial tests. Use to optimize/clean up/refactor a module \u2014 not for new features, bug fixes, or issues.
 ---
 
 # Optimize Codebase
 
-Optimize a module's codebase for quality, performance, and clean conventions.
+Bring a module in line with project conventions: clean code, no duplication, only meaningful tests. Not for new features, bug fixes, or issues \u2014 use the matching workflow instead.
 
-## When to use
+## Rules
 
-Use this skill when:
+- Run every command from the **monorepo root**, never from inside a package.
+- Start clean: no uncommitted changes before you begin (\`git status\`). Refactor only \u2014 never alter behavior or public APIs without checking callers first.
+- Tests must pass before and after. If they were failing before, say so; don't claim a fix you didn't make.
 
-- The user asks to optimize, clean up, or refactor a module's codebase.
-- A module needs to be brought in line with the project conventions (arrow functions, \`Type\`/\`I\` naming, explicit visibility, nullable columns).
-- You want to remove code duplication, dead code, or unused imports across a module.
-- A module's tests need pruning \u2014 dropping trivial existence checks while keeping meaningful behavior, edge-case, and error-handling tests.
-- React modules (\`design\`, \`spa\`) need to adopt the recommended patterns (custom hooks, compound components, Zustand, TanStack Query/Virtual/Pacer/Hotkeys).
+## Routing \u2014 load on demand
 
-Do **not** use this skill for adding new features, fixing a specific bug, or implementing an issue \u2014 use the relevant feature/issue workflow instead.
+Invoke each sub-skill only at the step that needs it; skip ones that don't apply.
 
-## Important
+| Invoke | Before | When |
+|---|---|---|
+| \`optimize:conventions\` | steps 3\u20135 | always |
+| \`optimize:testing\` | step 6 | the module has tests |
+| \`optimize:react\` | step 7 | module is \`design\` or \`spa\` only |
 
-Always run all commands from the **root of the project** (the monorepo root), not from inside individual packages.
+## Steps
 
-## Coding Conventions
+1. **Target** \u2014 work in \`modules/<module>/\`; ask if unspecified.
+
+2. **Map (sub-agent)** \u2014 reading every file inline floods context. Spawn one read-only \`Explore\` sub-agent scoped to \`modules/<module>/\` and have it return *only* a digest, not file contents:
+   - **Inventory** \u2014 each type, interface, class, standalone function + path.
+   - **Naming violations** \u2014 type not ending \`Type\`; interface not starting \`I\`; non-arrow standalone function; method/property missing visibility; non-null assertion (\`!\`); optional entity property missing \`null\`/\`nullable\`.
+   - **Duplication** \u2014 repeated logic, types, or utilities + paths.
+   - **Dead code** \u2014 unused imports, unreachable branches, unused vars, empty files.
+
+   Apply every fix yourself in the steps below.
+
+3. **Conventions** \u2014 invoke the \`optimize:conventions\` skill, then fix each reported violation; rename and update all references.
+
+4. **Duplication & dead code** \u2014 extract shared logic into helper arrows or base classes; consolidate types; merge near-duplicate utilities; delete dead code.
+
+5. **Performance** \u2014 apply the performance rules from \`optimize:conventions\`.
+
+6. **Tests** \u2014 invoke \`optimize:testing\`, then prune trivial tests, keep/improve meaningful ones, consolidate redundancy.
+
+7. **React** \u2014 if \`design\`/\`spa\`, invoke \`optimize:react\` and adopt its patterns.
+
+8. **Verify** \u2014 from the root:
+
+   \`\`\`bash
+   bun run fmt && bun run lint && bun run test
+   \`\`\`
+
+   Fix every failure before completing.
+`;
+
+// src/templates/llm/skills/optimize.conventions.md.txt
+var optimize_conventions_md_default = `---
+name: optimize:conventions
+description: Project coding conventions \u2014 explicit visibility, arrow functions vs class methods, Type/I naming (DI-enforced), no non-null assertions, nullable entity columns, DI wiring, code hygiene, duplication/dead-code removal, and performance rules. Use when enforcing conventions, refactoring, or reviewing a module's code style.
+---
+
+# Coding Conventions
+
+Used by the \`optimize\` skill (steps 3\u20135) for enforcing conventions and removing duplication/dead code.
 
-### Visibility Modifiers
+## Visibility
 
-Always explicitly declare visibility on every class method and property.
+Declare explicit visibility (\`public\`/\`private\`/\`protected\`) on every class method and property.
 
 \`\`\`typescript
-// correct
 export class UserService {
   private readonly repository: UserRepository;
   public async execute(data?: ServiceDataType): Promise<void> {}
   protected validate(): boolean {}
 }
-
-// incorrect \u2014 visibility is implicit
-export class UserService {
-  repository: UserRepository;
-  async execute() {}
-}
 \`\`\`
 
-### Functions vs Class Methods
+## Arrow Functions vs Class Methods
 
-Use arrow functions everywhere except class methods.
+Arrow functions everywhere, except class methods (use regular method syntax).
 
 \`\`\`typescript
-// correct \u2014 arrow function for standalone function
-const formatName = (name: string): string => name.trim();
-
-// correct \u2014 regular method syntax inside a class
-export class UserService {
-  public async execute(data?: ServiceDataType): Promise<void> {
-    const formatted = formatName(data?.name ?? "");
-  }
-}
+const formatName = (name: string): string => name.trim(); // standalone: arrow
 
-// incorrect \u2014 arrow function as class method
 export class UserService {
-  public execute = async (data?: ServiceDataType): Promise<void> => {};
+  public async execute(): Promise<void> {} // method: regular syntax, NOT \`execute = async () =>\`
 }
 \`\`\`
 
-### Type and Interface Naming
+## Type & Interface Naming
 
-- Type aliases **must** end with \`Type\`
-- Interface names **must** start with \`I\`
+Type aliases **must** end with \`Type\`; interfaces **must** start with \`I\`. **Strictly enforced by DI decorators \u2014 violations throw at startup:**
 
-\`\`\`typescript
-// correct
-type ServiceDataType = Record<string, unknown>;
-interface IService { execute(): Promise<void>; }
-
-// incorrect
-type ServiceData = Record<string, unknown>;
-interface Service { execute(): Promise<void>; }
-\`\`\`
-
-**Strictly enforced** by DI decorators \u2014 violations throw at startup:
-
-| Artefact | Must end/start with | Example |
+| Artefact | Convention | Example |
 |---|---|---|
-| Service | \`Service\` | \`UserService\` |
-| Repository | \`Repository\` | \`UserRepository\` |
-| Middleware | \`Middleware\` | \`AuthMiddleware\` |
-| Cron | \`Cron\` | \`ExpiredTokenCleanupCron\` |
-| Type alias | \`Type\` | \`ServiceDataType\` |
-| Interface | \`I\` (prefix) | \`IService\` |
+| Service | ends \`Service\` | \`UserService\` |
+| Repository | ends \`Repository\` | \`UserRepository\` |
+| Middleware | ends \`Middleware\` | \`AuthMiddleware\` |
+| Cron | ends \`Cron\` | \`ExpiredTokenCleanupCron\` |
+| Type alias | ends \`Type\` | \`ServiceDataType\` |
+| Interface | starts \`I\` | \`IService\` |
 
-### Non-null Assertions
+## Non-null Assertions
 
-Never use \`!\` on class properties. Use a default value or optional type instead.
+Never use \`!\` on class properties \u2014 use a default value or optional type.
 
 \`\`\`typescript
-// correct
 export class UserEntity {
-  public name: string = "";
+  public name: string = "";      // not \`name!: string\`
   public email?: string | null;
 }
-
-// incorrect
-export class UserEntity {
-  public name!: string;
-}
 \`\`\`
 
-### Optional Entity Properties
+## Optional Entity Properties
 
-- Optional properties (\`?\`) must include \`null\` in their type union
-- Do NOT use \`= undefined\` as an initializer
-- Always specify \`nullable\` explicitly in every \`@Column\`
+- Optional (\`?\`) types must include \`null\` in the union.
+- Never initialize with \`= undefined\`.
+- Always set \`nullable\` explicitly in every \`@Column\`.
 
 \`\`\`typescript
-// correct
 export class BookEntity {
   @Column({ name: "title", type: "varchar", length: 255, nullable: false })
   public title: string = "";
 
   @Column({ name: "subtitle", type: "varchar", length: 255, nullable: true })
-  public subtitle?: string | null;
-}
-
-// incorrect
-export class BookEntity {
-  @Column({ name: "title", type: "varchar", length: 255 })  // nullable missing
-  public title: string = "";
-
-  @Column({ name: "subtitle", type: "varchar", length: 255, nullable: true })
-  public subtitle?: string;  // null missing from type union
+  public subtitle?: string | null; // not \`subtitle?: string\`, and not \`nullable\` omitted
 }
 \`\`\`
 
-### Dependency Injection
+## Dependency Injection
 
 \`\`\`typescript
 import { inject } from "@ooneex/container";
@@ -25871,25 +25868,44 @@ export class BookSeed implements ISeed {
 }
 \`\`\`
 
-### Code Hygiene
+## Code Hygiene
 
-- Remove all unused imports
-- Remove dead code: unreachable branches, unused variables, empty files
-- Never leave \`TODO\` comments without a corresponding task
+- Remove unused imports and dead code (unreachable branches, unused variables, empty files).
+- No \`TODO\` comments without a corresponding task.
 
-### Testing Conventions
+## Duplication & Dead Code
 
-- Test files mirror \`src/\` under \`tests/\` with the \`.spec.ts\` suffix.
-- Run \`bun run test\` (all modules) or \`bun test tests\` (inside a module).
-- Every public method with logic needs \u22651 happy-path + \u22651 edge-case test.
-- Avoid trivial existence checks \u2014 test actual behavior.
-- Keep tests deterministic: no random values, no time-dependent data.
+- Extract shared logic into helper arrow functions or base classes.
+- Consolidate repeated type definitions; merge similar utilities.
+
+## Performance
+
+- Replace inefficient loops with single-pass approaches.
+- Use \`Map\`/\`Set\` instead of arrays for lookups.
+- Prefer early returns to reduce nesting.
+- Drop unnecessary \`async\`/\`await\` where a direct return suffices.
+- Eliminate redundant null/undefined checks.
+`;
 
-## React (design & spa modules)
+// src/templates/llm/skills/optimize.react.md.txt
+var optimize_react_md_default = `---
+name: optimize:react
+description: Recommended React patterns for design and spa modules \u2014 custom hooks, compound components, Zustand state, and TanStack Query/Virtual/Pacer/Hotkeys. Use only when building or optimizing a React module (design or spa).
+---
+
+# React Patterns (design & spa modules)
+
+Apply **only** to a React module (\`design\` or \`spa\`) \u2014 \`optimize\` calls this for step 7.
+
+Install missing deps at the project root:
+
+\`\`\`bash
+bun add zustand @tanstack/react-query @tanstack/react-virtual @tanstack/react-pacer @tanstack/react-hotkeys
+\`\`\`
 
-### Hooks pattern
+## Hooks
 
-Extract stateful, reusable logic into custom hooks (\`useXxx\`) instead of duplicating it across components or reaching for HOCs/render props.
+Extract reusable stateful logic into custom hooks (\`useXxx\`) instead of duplicating it or using HOCs/render props.
 
 \`\`\`typescript
 import { useEffect, useState } from "react";
@@ -25907,13 +25923,12 @@ const useWindowWidth = (): number => {
 };
 
 // usage
-const width = useWindowWidth();
-const isMobile = width < 768;
+const isMobile = useWindowWidth() < 768;
 \`\`\`
 
-### Compound pattern
+## Compound components
 
-Build flexible components as a set of related parts that share implicit state via context, instead of passing many props to one monolith.
+Build flexible components as related parts sharing state via context, instead of one prop-heavy monolith.
 
 \`\`\`tsx
 import { createContext, useContext, useState } from "react";
@@ -25950,15 +25965,13 @@ Tabs.Panel = TabPanel;
 // usage
 <Tabs defaultValue="overview">
   <Tabs.Tab value="overview">Overview</Tabs.Tab>
-  <Tabs.Tab value="settings">Settings</Tabs.Tab>
   <Tabs.Panel value="overview">Overview content</Tabs.Panel>
-  <Tabs.Panel value="settings">Settings content</Tabs.Panel>
 </Tabs>;
 \`\`\`
 
-### State management \u2014 Zustand
+## Global state \u2014 Zustand
 
-Use Zustand for global/shared state. Keep stores small and colocated; expose selectors to avoid re-renders. https://zustand.docs.pmnd.rs/learn/getting-started/introduction
+Keep stores small and colocated; use selectors to avoid re-renders. https://zustand.docs.pmnd.rs/learn/getting-started/introduction
 
 \`\`\`typescript
 import { create } from "zustand";
@@ -25973,13 +25986,13 @@ const useCounterStore = create<CounterStoreType>((set) => ({
   increment: () => set((state) => ({ count: state.count + 1 })),
 }));
 
-// select only what you need to minimize re-renders
+// select only what you need
 const count = useCounterStore((state) => state.count);
 \`\`\`
 
-### Data fetching \u2014 TanStack Query
+## Server state \u2014 TanStack Query
 
-Use TanStack Query for server state. Wrap each query/mutation in a custom hook. https://tanstack.com/query/latest
+Wrap each query/mutation in a custom hook. https://tanstack.com/query/latest
 
 \`\`\`typescript
 import { useQuery } from "@tanstack/react-query";
@@ -25997,9 +26010,9 @@ const useUsers = () =>
 const { data, isLoading, error } = useUsers();
 \`\`\`
 
-### Long lists \u2014 virtualization
+## Long lists \u2014 TanStack Virtual
 
-Use TanStack Virtual to render only visible rows in long lists. https://tanstack.com/virtual/latest
+Render only visible rows. https://tanstack.com/virtual/latest
 
 \`\`\`typescript
 import { useVirtualizer } from "@tanstack/react-virtual";
@@ -26014,21 +26027,21 @@ const virtualizer = useVirtualizer({
 virtualizer.getVirtualItems().map((item) => rows[item.index]);
 \`\`\`
 
-### Debounce, Throttle, Queue, Batch \u2014 TanStack Pacer
+## Debounce / throttle / queue / batch \u2014 TanStack Pacer
 
-Use TanStack Pacer for rate-limiting expensive work (search input, scroll handlers, API calls). https://tanstack.com/pacer/latest
+Rate-limit expensive work (search input, scroll handlers, API calls). https://tanstack.com/pacer/latest
 
 \`\`\`typescript
 import { useDebouncedValue } from "@tanstack/react-pacer";
 
 const [search, setSearch] = useState("");
 const [debouncedSearch] = useDebouncedValue(search, { wait: 300 });
-// debouncedSearch updates 300ms after the user stops typing
+// updates 300ms after the user stops typing
 \`\`\`
 
-### Hotkeys (Shortcut, Mod, ...) \u2014 TanStack Hotkeys
+## Keyboard shortcuts \u2014 TanStack Hotkeys
 
-Use TanStack Hotkeys for keyboard shortcuts. https://tanstack.com/hotkeys/latest
+https://tanstack.com/hotkeys/latest
 
 \`\`\`typescript
 import { useHotkeys } from "@tanstack/react-hotkeys";
@@ -26039,72 +26052,31 @@ useHotkeys("mod+s", (event) => {
   save();
 });
 \`\`\`
+`;
 
-If dependencies are not installed, install them in the root of the project using \`bun add\`:
-
-\`\`\`bash
-bun add zustand @tanstack/react-query @tanstack/react-virtual @tanstack/react-pacer @tanstack/react-hotkeys
-\`\`\`
-
-## Steps
-
-### 1. Identify the target
-
-Work in \`modules/<module>/\`. Ask the user if no module is specified.
-
-### 2. Analyze the module
-
-Reading every \`src/**/*.ts\` and \`tests/**/*.ts\` file inline floods the conversation with file dumps you do not need to keep. Delegate this read-heavy mapping to a sub-agent and act on the digest it returns.
-
-Spawn an \`Explore\` sub-agent (read-only) scoped to \`modules/<module>/\`, asking it to map all types, interfaces, classes, functions, and their dependencies, and to return only:
-
-- **Inventory** \u2014 every type, interface, class, and standalone function with its file path.
-- **Naming violations** \u2014 types not ending with \`Type\`, interfaces not starting with \`I\`, non-arrow standalone functions, methods/properties missing visibility modifiers, non-null assertions, optional entity properties missing \`null\`/\`nullable\`.
-- **Duplication candidates** \u2014 repeated logic, type definitions, or utilities that could be consolidated, with file paths.
-- **Dead code** \u2014 unused imports, unreachable branches, unused variables, empty files.
-
-The sub-agent returns the map, not the file contents \u2014 keep the main context clean. Apply every fix yourself in the steps below, where the full conventions above are in context.
-
-### 3. Enforce conventions
-
-Apply every rule from [Coding Conventions](#coding-conventions) across all files \u2014 fix each violation the sub-agent reported, renaming and updating all references where naming changes.
+// src/templates/llm/skills/optimize.testing.md.txt
+var optimize_testing_md_default = `---
+name: optimize:testing
+description: Project testing conventions and test-pruning rules \u2014 tests mirror src/ under tests/ as .spec.ts, every public method needs happy-path + edge-case coverage, drop trivial existence checks, keep deterministic behavior tests, consolidate redundancy. Use when writing, pruning, or improving a module's tests.
+---
 
-### 4. Remove duplication & dead code
+# Testing Conventions
 
-Beyond the [Code Hygiene](#code-hygiene) cleanup:
-- Extract shared logic into helper arrow functions or base classes
-- Consolidate repeated type definitions
-- Merge similar utility functions
+Apply when pruning or improving a module's tests (the \`optimize\` skill calls this for step 6).
 
-### 5. Optimize for performance
+## Conventions
 
-- Replace inefficient loops with single-pass approaches
-- Use \`Map\`/\`Set\` instead of arrays for lookups
-- Prefer early returns to reduce nesting
-- Remove unnecessary \`async\`/\`await\` where a direct return suffices
-- Eliminate redundant null/undefined checks
+- Test files mirror \`src/\` under \`tests/\` with the \`.spec.ts\` suffix.
+- Run \`bun run test\` (all modules) or \`bun test tests\` (inside a module).
+- Every public method with logic needs \u22651 happy-path + \u22651 edge-case test.
+- Avoid trivial existence checks \u2014 test actual behavior.
+- Keep tests deterministic: no random values, no time-dependent data.
 
-### 6. Optimize tests
+## Pruning tests
 
-Bring tests in line with [Testing Conventions](#testing-conventions), and:
 - Remove trivial tests (class name checks, method existence) unless they are smoke tests for generated code
 - Keep and improve tests that verify actual business logic, edge cases, error handling
 - Consolidate redundant test cases into parameterized patterns
-
-### 7. Lint and format
-
-\`\`\`bash
-bun run fmt
-bun run lint
-\`\`\`
-
-### 8. Run tests
-
-\`\`\`bash
-bun run test
-\`\`\`
-
-Fix any failures before completing.
 `;
 
 // src/templates/llm/skills/permission.create.md.txt
@@ -26239,12 +26211,13 @@ describe("<Name>Permission", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/pubsub.create.md.txt
@@ -26381,12 +26354,13 @@ describe("<Name>Event", () => {
 
 Add \`<Name>Event\` to the \`events\` array in \`src/<PascalModuleName>Module.ts\` (see \`ooneex:scaffold\` for the \`ModuleType\` shape).
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/repository.create.md.txt
@@ -26636,12 +26610,13 @@ describe("<Name>Repository", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/sdk.create.md.txt
@@ -26794,12 +26769,13 @@ stream: (input: {
 },
 \`\`\`
 
-### 7. Lint and format
+### 7. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/seed.create.md.txt
@@ -26918,12 +26894,13 @@ describe("<Name>Seed", () => {
 });
 \`\`\`
 
-### 5. Lint and format
+### 5. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/service.create.md.txt
@@ -27027,16 +27004,17 @@ describe("<Name>Service", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/spa.feature.create.md.txt
-var spa_feature_create_md_default = "---\nname: spa:feature:create\ndescription: Generate a new SPA feature (route, layout, error/not-found/skeleton boundaries, and TanStack Query hooks), then complete the generated code. Use when adding a feature to a SPA module built on @tanstack/react-router and @tanstack/react-query.\n---\n\n# Make SPA Feature\n\nGenerate a SPA feature \u2014 a route, its page layout, the route's pending/error/not-found boundaries, and example TanStack Query read/write hooks \u2014 then complete the implementation. Follow the shared workflow in the `ooneex:scaffold` skill (run-from-root, `--name`/`--module` inference, lint/format, and coding conventions); this skill covers only the SPA-feature-specific parts.\n\n## Important\n\nA SPA feature only makes sense inside a **SPA module** (a module whose `type` is `spa` in its `<name>.yml`). Create the SPA first with `spa:create` if it does not exist. The SPA is a standalone Vite front-end: keep features focused on presentation and client state, and reach the backend through HTTP APIs rather than importing server modules. Reuse UI primitives from the linked `design` module instead of duplicating them.\n\n**Place code in the canonical SPA folders \u2014 do not invent new ones.** The `### SPA Structure` section of `AGENTS.md` is the source of truth. A feature folder (`features/<feature>/`) and `shared/` share the same fixed sub-layout, and every artefact has exactly one home:\n\n| Sub-folder | What goes there |\n|---|---|\n| `assets/` | Images/SVG/media used only by this feature |\n| `components/` | Presentational + container React components scoped to the feature |\n| `hooks/` | Feature React hooks \u2014 data fetching, API calls, local UI state |\n| `layouts/` | Layout wrappers arranging this feature's pages/sections |\n| `services/` | Feature business logic + API clients; the only layer that talks to the backend |\n| `store/` | Feature-local client state (signals/store slices), not server data |\n| `styles/` | CSS/style modules scoped to this feature |\n| `types/` | TypeScript types/interfaces for the feature's domain |\n| `utils/` | Pure helper functions used within the feature |\n\n**Split, don't cram.** As you complete a file, break it into the smallest sensible pieces and move each into its logical folder above rather than leaving everything inside one layout or hook. Reuse the existing folders the generator created and add sibling folders **only** from this fixed list when a piece needs one \u2014 never a new name. Anything reused by \u22652 features moves up to `shared/` (same sub-layout); never import another feature's internals.\n\n**One file per element.** Give every component, hook, service, store slice, and util its own `.ts`/`.tsx` file named after it. The **only** exceptions are `types/` and `styles/`: group those **by logic**, not one file per item \u2014 e.g. all of the feature's domain types in `types/<kebab>.ts` and its related style rules in `styles/<kebab>.css`, splitting into a second file only when a distinct concern warrants it.\n\n## Steps\n\n### 1. Infer the options from the request, then run the generator\n\nMap the user's request to the options below, then run:\n\n```bash\nbunx @ooneex/cli@latest spa:feature:create --name=<name> --module=<module>\n```\n\n**Inferring options from the user's request:**\n\n- `--name` \u2014 the feature name, taken from the screen or resource it represents (e.g., \"a settings page\" \u2192 `Settings`, \"the user profile feature\" \u2192 `UserProfile`). Pass it in any casing; the CLI normalizes to PascalCase and strips a trailing `Feature` or `Layout` suffix, so omit those suffixes.\n- `--module` \u2014 the target SPA module, inferred from phrasing like \"in the `dashboard` SPA\" or \"for the admin app\". There is **no default** \u2014 the generator prompts for it when omitted.\n- `--override` \u2014 pass when the request is to regenerate an existing feature. Without it, the generator prompts before overwriting and aborts if declined.\n\nAlso installs `@tanstack/react-query` if it is not already a dependency.\n\n**Files generated** (under `modules/<module>/src/`, with `<kebab>` the kebab-case feature name and `<Name>` the PascalCase name):\n\n- `routes/<kebab>.tsx` \u2014 the TanStack Router file route, wiring the layout and boundaries together\n- `features/<kebab>/layouts/<Name>Layout.tsx` \u2014 the page layout (the route `component`)\n- `features/<kebab>/layouts/<Name>SkeletonLayout.tsx` \u2014 the route `pendingComponent`\n- `features/<kebab>/layouts/<Name>ErrorLayout.tsx` \u2014 the route `errorComponent`\n- `features/<kebab>/layouts/<Name>NotFoundLayout.tsx` \u2014 the route `notFoundComponent`\n- `features/<kebab>/hooks/useGet<Name>.ts` \u2014 example TanStack Query read hook + query-key factory\n- `features/<kebab>/hooks/useUpdate<Name>.ts` \u2014 example TanStack Query mutation hook\n\n### 2. Resolve the linked design module and discover its components\n\nBefore writing any UI, find which design module this SPA builds on and what it offers \u2014 the layouts must be composed from its components, not styled from scratch.\n\n1. Read the SPA module's yml config at `modules/<module>/<module>.yml` and read the `design:` field. Its value is the kebab-case name of the design module (e.g. `design: \"ui\"`).\n   - If there is **no** `design:` field, the SPA was created without a linked design module. Skip the design-specific guidance below and build the UI with plain elements (suggest the user run `oo spa:create --design <name>` or `oo design:create` if they want a shared design system).\n2. List the design module's source to learn the available primitives:\n\n   ```bash\n   ls modules/<design>/src/components 2>/dev/null && cat modules/<design>/src/index.ts 2>/dev/null\n   ```\n\n   Inspect the component files / barrel exports to see what exists (buttons, cards, inputs, layout primitives, etc.) and their props.\n3. Import design components through the module path alias \u2014 `@module/<design>/...`:\n\n   ```typescript\n   import { Button } from \"@module/<design>/components/Button\";\n   // or, if the design module re-exports from a barrel:\n   import { Button, Card } from \"@module/<design>\";\n   ```\n\n   Match the actual export style you found in step 2 (named exports per file vs. a barrel `index.ts`).\n\n### 3. Complete the route\n\nRead `modules/<module>/src/routes/<kebab>.tsx`, then:\n\n- Adjust the route path passed to `createFileRoute` if the feature should not live at `/<kebab>` (e.g. a nested or parameterized path like `/<kebab>/$id`).\n- Add a `loader` and `pendingMs` when the page needs data before it renders \u2014 the generated `pendingComponent`, `errorComponent`, and `notFoundComponent` exist to cover that loader's pending, failure, and `notFound()` states.\n- Keep the boundary components wired to the generated layouts.\n\n### 4. Complete the layouts\n\nRead each file in `modules/<module>/src/features/<kebab>/layouts/` and fill in the real UI, composing the design module's components (resolved in step 2) instead of re-implementing primitives. Keep the layouts as thin arrangers: extract every reusable piece into the canonical folders rather than inlining it.\n\n- `<Name>Layout` \u2014 the page content, arranged from design components and the feature's own components. It renders `children ?? <Outlet />`, so leave the `<Outlet />` in place if the route has children. Pull each presentational block out into `features/<kebab>/components/` (one component per file) and compose them here.\n- `<Name>SkeletonLayout` \u2014 a skeleton that mirrors the loaded layout's shape; reuse the design's skeleton/placeholder primitive if it has one, and keep the `aria-busy`/`aria-live` attributes for accessibility.\n- `<Name>ErrorLayout` \u2014 render a useful message from `error` using the design's alert/feedback components, and keep the `reset` retry action (wire it to the design's button).\n- `<Name>NotFoundLayout` \u2014 the empty/missing-resource state, using the design's empty-state primitives where available.\n\nAs you split (one file per element, except types/styles which group by logic):\n- presentational/container components \u2192 `features/<kebab>/components/` (one component per file)\n- feature-local client state \u2192 `features/<kebab>/store/` (one slice per file)\n- pure helpers (formatting, guards) \u2192 `features/<kebab>/utils/` (one helper per file)\n- domain types (props/view-model types) \u2192 grouped in `features/<kebab>/types/`\n- scoped styles \u2192 grouped in `features/<kebab>/styles/`\n- media \u2192 `features/<kebab>/assets/`\n\nIf the design module lacks a primitive you need, prefer adding it to the design module (`@module/<design>`) so it stays reusable, rather than styling it inline in the feature.\n\n### 5. Complete the hooks\n\nRead the two hooks in `modules/<module>/src/features/<kebab>/hooks/` and adapt the examples to the real resource, splitting each into its logical folder so the hook stays a thin TanStack Query wrapper:\n\n- Move the resource type (the placeholder `<Name>Type`) out of the hook into the feature's grouped types file (`features/<kebab>/types/<kebab>.ts`) and import it back.\n- Move the `fetch`/API-call functions (`get<Name>`, `update<Name>`) into an API client in `features/<kebab>/services/` \u2014 services are the only layer that talks to the backend. Keep one service file per element and have the hooks import these instead of calling `fetch` directly.\n- `useGet<Name>.ts` \u2014 keep only the `useQuery` wiring and the `<camel>Keys` query-key factory; extend the factory with any list/filtered keys the feature needs. The factory is the single source of truth for this feature's keys \u2014 reads and invalidations must go through it so they always agree.\n- `useUpdate<Name>.ts` \u2014 keep only the `useMutation` wiring; keep `onSuccess` seeding the cache via `setQueryData` then returning the `invalidateQueries` promise so the mutation stays pending until the refetch settles.\n- Forward the query's `signal` from the hook into the service call to `fetch` so in-flight requests cancel on unmount/refetch.\n\nAdd further hooks (lists, additional mutations) in the same folder following these patterns, keeping their fetch logic in `services/` and their types in `types/`.\n\n### 6. Lint and format\n\n```bash\nbun run fmt\nbun run lint\n```\n";
+var spa_feature_create_md_default = "---\nname: spa:feature:create\ndescription: Generate a new SPA feature (route, layout, error/not-found/skeleton boundaries, and TanStack Query hooks), then complete the generated code. Use when adding a feature to a SPA module built on @tanstack/react-router and @tanstack/react-query.\n---\n\n# Make SPA Feature\n\nGenerate a SPA feature \u2014 a route, its page layout, the route's pending/error/not-found boundaries, and example TanStack Query read/write hooks \u2014 then complete the implementation. Follow the shared workflow in the `ooneex:scaffold` skill (run-from-root, `--name`/`--module` inference, lint/format, and coding conventions); this skill covers only the SPA-feature-specific parts.\n\n## Important\n\nA SPA feature only makes sense inside a **SPA module** (a module whose `type` is `spa` in its `<name>.yml`). Create the SPA first with `spa:create` if it does not exist. The SPA is a standalone Vite front-end: keep features focused on presentation and client state, and reach the backend through HTTP APIs rather than importing server modules. Reuse UI primitives from the linked `design` module instead of duplicating them.\n\n**Place code in the canonical SPA folders \u2014 do not invent new ones.** The `### SPA Structure` section of `AGENTS.md` is the source of truth. A feature folder (`features/<feature>/`) and `shared/` share the same fixed sub-layout, and every artefact has exactly one home:\n\n| Sub-folder | What goes there |\n|---|---|\n| `assets/` | Images/SVG/media used only by this feature |\n| `components/` | Presentational + container React components scoped to the feature |\n| `hooks/` | Feature React hooks \u2014 data fetching, API calls, local UI state |\n| `layouts/` | Layout wrappers arranging this feature's pages/sections |\n| `services/` | Feature business logic + API clients; the only layer that talks to the backend |\n| `store/` | Feature-local client state (signals/store slices), not server data |\n| `styles/` | CSS/style modules scoped to this feature |\n| `types/` | TypeScript types/interfaces for the feature's domain |\n| `utils/` | Pure helper functions used within the feature |\n\n**Split, don't cram.** As you complete a file, break it into the smallest sensible pieces and move each into its logical folder above rather than leaving everything inside one layout or hook. Reuse the existing folders the generator created and add sibling folders **only** from this fixed list when a piece needs one \u2014 never a new name. Anything reused by \u22652 features moves up to `shared/` (same sub-layout); never import another feature's internals.\n\n**One file per element.** Give every component, hook, service, store slice, and util its own `.ts`/`.tsx` file named after it. The **only** exceptions are `types/` and `styles/`: group those **by logic**, not one file per item \u2014 e.g. all of the feature's domain types in `types/<kebab>.ts` and its related style rules in `styles/<kebab>.css`, splitting into a second file only when a distinct concern warrants it.\n\n## Steps\n\n### 1. Infer the options from the request, then run the generator\n\nMap the user's request to the options below, then run:\n\n```bash\nbunx @ooneex/cli@latest spa:feature:create --name=<name> --module=<module>\n```\n\n**Inferring options from the user's request:**\n\n- `--name` \u2014 the feature name, taken from the screen or resource it represents (e.g., \"a settings page\" \u2192 `Settings`, \"the user profile feature\" \u2192 `UserProfile`). Pass it in any casing; the CLI normalizes to PascalCase and strips a trailing `Feature` or `Layout` suffix, so omit those suffixes.\n- `--module` \u2014 the target SPA module, inferred from phrasing like \"in the `dashboard` SPA\" or \"for the admin app\". There is **no default** \u2014 the generator prompts for it when omitted.\n- `--override` \u2014 pass when the request is to regenerate an existing feature. Without it, the generator prompts before overwriting and aborts if declined.\n\nAlso installs `@tanstack/react-query` if it is not already a dependency.\n\n**Files generated** (under `modules/<module>/src/`, with `<kebab>` the kebab-case feature name and `<Name>` the PascalCase name):\n\n- `routes/<kebab>.tsx` \u2014 the TanStack Router file route, wiring the layout and boundaries together\n- `features/<kebab>/layouts/<Name>Layout.tsx` \u2014 the page layout (the route `component`)\n- `features/<kebab>/layouts/<Name>SkeletonLayout.tsx` \u2014 the route `pendingComponent`\n- `features/<kebab>/layouts/<Name>ErrorLayout.tsx` \u2014 the route `errorComponent`\n- `features/<kebab>/layouts/<Name>NotFoundLayout.tsx` \u2014 the route `notFoundComponent`\n- `features/<kebab>/hooks/useGet<Name>.ts` \u2014 example TanStack Query read hook + query-key factory\n- `features/<kebab>/hooks/useUpdate<Name>.ts` \u2014 example TanStack Query mutation hook\n\n### 2. Resolve the linked design module and discover its components\n\nBefore writing any UI, find which design module this SPA builds on and what it offers \u2014 the layouts must be composed from its components, not styled from scratch.\n\n1. Read the SPA module's yml config at `modules/<module>/<module>.yml` and read the `design:` field. Its value is the kebab-case name of the design module (e.g. `design: \"ui\"`).\n   - If there is **no** `design:` field, the SPA was created without a linked design module. Skip the design-specific guidance below and build the UI with plain elements (suggest the user run `oo spa:create --design <name>` or `oo design:create` if they want a shared design system).\n2. List the design module's source to learn the available primitives:\n\n   ```bash\n   ls modules/<design>/src/components 2>/dev/null && cat modules/<design>/src/index.ts 2>/dev/null\n   ```\n\n   Inspect the component files / barrel exports to see what exists (buttons, cards, inputs, layout primitives, etc.) and their props.\n3. Import design components through the module path alias \u2014 `@module/<design>/...`:\n\n   ```typescript\n   import { Button } from \"@module/<design>/components/Button\";\n   // or, if the design module re-exports from a barrel:\n   import { Button, Card } from \"@module/<design>\";\n   ```\n\n   Match the actual export style you found in step 2 (named exports per file vs. a barrel `index.ts`).\n\n### 3. Complete the route\n\nRead `modules/<module>/src/routes/<kebab>.tsx`, then:\n\n- Adjust the route path passed to `createFileRoute` if the feature should not live at `/<kebab>` (e.g. a nested or parameterized path like `/<kebab>/$id`).\n- Add a `loader` and `pendingMs` when the page needs data before it renders \u2014 the generated `pendingComponent`, `errorComponent`, and `notFoundComponent` exist to cover that loader's pending, failure, and `notFound()` states.\n- Keep the boundary components wired to the generated layouts.\n\n### 4. Complete the layouts\n\nRead each file in `modules/<module>/src/features/<kebab>/layouts/` and fill in the real UI, composing the design module's components (resolved in step 2) instead of re-implementing primitives. Keep the layouts as thin arrangers: extract every reusable piece into the canonical folders rather than inlining it.\n\n- `<Name>Layout` \u2014 the page content, arranged from design components and the feature's own components. It renders `children ?? <Outlet />`, so leave the `<Outlet />` in place if the route has children. Pull each presentational block out into `features/<kebab>/components/` (one component per file) and compose them here.\n- `<Name>SkeletonLayout` \u2014 a skeleton that mirrors the loaded layout's shape; reuse the design's skeleton/placeholder primitive if it has one, and keep the `aria-busy`/`aria-live` attributes for accessibility.\n- `<Name>ErrorLayout` \u2014 render a useful message from `error` using the design's alert/feedback components, and keep the `reset` retry action (wire it to the design's button).\n- `<Name>NotFoundLayout` \u2014 the empty/missing-resource state, using the design's empty-state primitives where available.\n\nAs you split (one file per element, except types/styles which group by logic):\n- presentational/container components \u2192 `features/<kebab>/components/` (one component per file)\n- feature-local client state \u2192 `features/<kebab>/store/` (one slice per file)\n- pure helpers (formatting, guards) \u2192 `features/<kebab>/utils/` (one helper per file)\n- domain types (props/view-model types) \u2192 grouped in `features/<kebab>/types/`\n- scoped styles \u2192 grouped in `features/<kebab>/styles/`\n- media \u2192 `features/<kebab>/assets/`\n\nIf the design module lacks a primitive you need, prefer adding it to the design module (`@module/<design>`) so it stays reusable, rather than styling it inline in the feature.\n\n### 5. Complete the hooks\n\nRead the two hooks in `modules/<module>/src/features/<kebab>/hooks/` and adapt the examples to the real resource, splitting each into its logical folder so the hook stays a thin TanStack Query wrapper:\n\n- Move the resource type (the placeholder `<Name>Type`) out of the hook into the feature's grouped types file (`features/<kebab>/types/<kebab>.ts`) and import it back.\n- Move the `fetch`/API-call functions (`get<Name>`, `update<Name>`) into an API client in `features/<kebab>/services/` \u2014 services are the only layer that talks to the backend. Keep one service file per element and have the hooks import these instead of calling `fetch` directly.\n- `useGet<Name>.ts` \u2014 keep only the `useQuery` wiring and the `<camel>Keys` query-key factory; extend the factory with any list/filtered keys the feature needs. The factory is the single source of truth for this feature's keys \u2014 reads and invalidations must go through it so they always agree.\n- `useUpdate<Name>.ts` \u2014 keep only the `useMutation` wiring; keep `onSuccess` seeding the cache via `setQueryData` then returning the `invalidateQueries` promise so the mutation stays pending until the refetch settles.\n- Forward the query's `signal` from the hook into the service call to `fetch` so in-flight requests cancel on unmount/refetch.\n\nAdd further hooks (lists, additional mutations) in the same folder following these patterns, keeping their fetch logic in `services/` and their types in `types/`.\n\n### 6. Lint, format, and test\n\n```bash\nbun run fmt && bun run lint && bun run test\n```\n\nFix every failure before completing.\n";
 
 // src/templates/llm/skills/storage.create.md.txt
 var storage_create_md_default = `---
@@ -27204,12 +27182,13 @@ describe("<Name>Storage", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/vector-database.create.md.txt
@@ -27347,12 +27326,13 @@ describe("<Name>VectorDatabase", () => {
 });
 \`\`\`
 
-### 4. Lint and format
+### 4. Lint, format, and test
 
 \`\`\`bash
-bun run fmt
-bun run lint
+bun run fmt && bun run lint && bun run test
 \`\`\`
+
+Fix every failure before completing.
 `;
 
 // src/templates/llm/skills/index.ts
@@ -27387,7 +27367,10 @@ var skills = {
   "issue.found": issue_found_md_default,
   "issue.plan": issue_plan_md_default,
   commit: commit_md_default,
-  optimize: optimize_md_default
+  optimize: optimize_md_default,
+  "optimize.conventions": optimize_conventions_md_default,
+  "optimize.testing": optimize_testing_md_default,
+  "optimize.react": optimize_react_md_default
 };
 
 // src/commands/ClaudeInitCommand.ts
@@ -27482,7 +27465,7 @@ class AppInitCommand {
     return "Initialize an application";
   }
   async run(options) {
-    let { name, destination, silent, appType } = options;
+    let { name, destination, silent } = options;
     if (!name) {
       name = await askName({ message: "Enter application name" });
     }
@@ -27510,13 +27493,8 @@ class AppInitCommand {
     envData.rate_limit.redis.url = "redis://localhost:6379";
     envData.database.url = "postgresql://ooneex:ooneex@localhost:5432/ooneex";
     envData.database.redis.url = "redis://localhost:6379";
-    if (appType === "api") {
-      await Bun.write(join8(destination, "modules", "shared", ".env.yml"), `${toYaml(envData)}
-`);
-    } else {
-      await Bun.write(join8(destination, ".env.yml"), `${toYaml(envData)}
+    await Bun.write(join8(destination, ".env.yml"), `${toYaml(envData)}
 `);
-    }
     const addDevDeps = Bun.spawn([
       "bun",
       "add",
@@ -112965,6 +112943,21 @@ ${item}`;
     }
     await Bun.write(appYmlPath, content);
   }
+  async nextAvailablePort(cwd) {
+    const used = new Set([3000]);
+    const modulesDir = join25(cwd, "modules");
+    const glob = new Bun.Glob("*/.env.yml");
+    for await (const match of glob.scan({ cwd: modulesDir, onlyFiles: true })) {
+      const content = await Bun.file(join25(modulesDir, match)).text();
+      const portMatch = content.match(/^\s*port:\s*(\d+)/m);
+      if (portMatch)
+        used.add(Number(portMatch[1]));
+    }
+    let port = 3001;
+    while (used.has(port))
+      port++;
+    return port;
+  }
   async addToEnvYml(envYmlPath, kebabName) {
     let content = await Bun.file(envYmlPath).text();
     const entry = `  ${kebabName}:
@@ -113009,12 +113002,16 @@ ${entry}`;
     await Bun.write(join25(srcDir, "OnAppStart.ts"), OnAppStart_ts_default);
     const dockerfileContent = Dockerfile_default.replace(/{{NAME}}/g, snakeName).replace(/modules\/app\//g, `modules/${kebabName}/`);
     await Bun.write(join25(moduleDir, "Dockerfile"), dockerfileContent);
+    const envData = structuredClone(env_default);
+    envData.app.port = await this.nextAvailablePort(cwd);
+    await Bun.write(join25(moduleDir, ".env.yml"), `${toYaml(envData)}
+`);
     if (kebabName !== "app") {
       const appYmlPath = join25(cwd, "modules", "app", "app.yml");
       if (await Bun.file(appYmlPath).exists()) {
         await this.declareInAppYml(appYmlPath, kebabName, snakeName.toUpperCase());
       }
-      const envYmlPath = join25(cwd, "modules", "shared", ".env.yml");
+      const envYmlPath = join25(cwd, ".env.yml");
       if (await Bun.file(envYmlPath).exists()) {
         await this.addToEnvYml(envYmlPath, kebabName);
       }
@@ -115146,4 +115143,4 @@ VectorDatabaseCreateCommand = __legacyDecorateClassTS([
 // src/index.ts
 await run();
 
-//# debugId=89D60FAB309DA44564756E2164756E21
+//# debugId=365BCB542AC44A9064756E2164756E21