code-ai-installer 1.5.6 → 2.0.1

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/claude.json

@@ -0,0 +1,19 @@
+{
+  "name": "code-review-checklist",
+  "display_name": "Universal Code Review Checklist",
+  "description": "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done.",
+  "default_prompt": "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill.",
+  "triggers": [
+    "code-review-checklist",
+    "code review checklist",
+    "Universal Code Review Checklist",
+    "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done"
+  ],
+  "capabilities": [
+    "code",
+    "review",
+    "checklist"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/copilot.json

@@ -0,0 +1,19 @@
+{
+  "name": "code-review-checklist",
+  "display_name": "Universal Code Review Checklist",
+  "description": "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done.",
+  "default_prompt": "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill.",
+  "triggers": [
+    "code-review-checklist",
+    "code review checklist",
+    "Universal Code Review Checklist",
+    "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done"
+  ],
+  "capabilities": [
+    "code",
+    "review",
+    "checklist"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/gemini.json

@@ -0,0 +1,19 @@
+{
+  "name": "code-review-checklist",
+  "display_name": "Universal Code Review Checklist",
+  "description": "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done.",
+  "default_prompt": "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill.",
+  "triggers": [
+    "code-review-checklist",
+    "code review checklist",
+    "Universal Code Review Checklist",
+    "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done"
+  ],
+  "capabilities": [
+    "code",
+    "review",
+    "checklist"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Universal Code Review Checklist"
+  short_description: "Universal review checklist — code quality, readability, testability, security, contracts, Defin…"
+  default_prompt: "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill."
+dependencies:
+  tools: []
+policy:
+  allow_implicit_invocation: true

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/qwen.json

@@ -0,0 +1,19 @@
+{
+  "name": "code-review-checklist",
+  "display_name": "Universal Code Review Checklist",
+  "description": "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done.",
+  "default_prompt": "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill.",
+  "triggers": [
+    "code-review-checklist",
+    "code review checklist",
+    "Universal Code Review Checklist",
+    "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done"
+  ],
+  "capabilities": [
+    "code",
+    "review",
+    "checklist"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/code-review-checklist/agents/skill.yaml

@@ -0,0 +1,23 @@
+version: 1
+name: "code-review-checklist"
+display_name: "Universal Code Review Checklist"
+description: "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done."
+default_prompt: "Use $code-review-checklist when the task matches the \"Universal Code Review Checklist\" skill."
+triggers:
+  - "code-review-checklist"
+  - "code review checklist"
+  - "Universal Code Review Checklist"
+  - "Universal review checklist — code quality, readability, testability, security, contracts, Definition of Done"
+capabilities:
+  - "code"
+  - "review"
+  - "checklist"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "en"
+  available_locales:
+    - "ru"
+    - "en"

package/domains/development/locales/en/.agents/skills/current-state-analysis/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: current-state-analysis
+description: Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.
+---
+
+# Skill: Current State Analysis
+
+How to audit a repository before making major architectural decisions or refactoring.
+
+**Sections:**
+1. [When to use](#1-when-to-use)
+2. [Workflow](#2-workflow)
+3. [Analysis Areas](#3-analysis-areas)
+4. [Output Template](#4-output)
+
+---
+
+## 1. When to use
+
+The Architect or Senior Full Stack agent uses this skill:
+- **During Discovery:** When taking over an existing repository.
+- **Before major refactoring:** To understand the baseline.
+- **Before system design:** To identify constraints and existing patterns that shouldn't be duplicated.
+
+---
+
+## 2. Workflow
+
+```
+1. Get the repository structure (find_by_name, ls)
+2. Identify the technology stack (package.json, go.mod, dockerfile)
+3. For each analysis area (Architecture, Data, UI, DX):
+   a. Sample 3-5 representative files
+   b. Look for consistency (e.g., are there 3 ways to fetch data?)
+   c. Identify red flags (hardcoded secrets, missing auth, god objects)
+4. Synthesize the findings into the Analysis Report
+5. Propose immediate remediation steps (if requested)
+```
+
+---
+
+## 3. Analysis Areas
+
+### 3.1 Architecture & Structure
+
+Check how the code is organized.
+
+| What to look for | Tooling / Pattern | Good | Bad |
+|------------------|-------------------|------|-----|
+| **Module boundaries** | `find_by_name`, structure | By feature (`features/products`) or layer (`src/controllers`) | Flat `src/` with 50 files, or `misc/` folder |
+| **Data flow** | `grep "fetch("` or `grep "axios"` | Through explicit services/API clients | Directly from UI components |
+| **State management** | `package.json`, React Context | Zustand, RTK Query, or well-scoped Context | Prop drilling 5 levels deep, redundant global state |
+| **Routing** | React Router / Next.js app dir | Centralized, lazy loaded where needed | Scattered `<Route>` definitions, no 404 handling |
+
+### 3.2 Code Quality & Consistency
+
+Check if the team is writing code the same way.
+
+| What to look for | Tooling / Pattern | Good | Bad |
+|------------------|-------------------|------|-----|
+| **Linting/Formatting**| `package.json` (ESLint, Biome, Prettier) | Strict CI checks, `biome.json` | Missing, or lots of `eslint-disable` |
+| **Naming Conventions**| Sampling files | `camelCase` for vars, `PascalCase` for React | Mixed `snake_case` and `camelCase` in JS |
+| **Component Size** | File sizes | < 200 lines, focused | 1000+ line God Components |
+| **Testing** | `__tests__` or `*.test.ts` | High coverage on business logic | No tests, or only empty generated tests |
+
+### 3.3 Security & Resiliency
+
+Check for obvious vulnerabilities and fragility.
+
+| What to look for | Tooling / Pattern | Good | Bad |
+|------------------|-------------------|------|-----|
+| **Secrets** | `grep "API_KEY"` or `grep "password"` | Environment variables (`process.env`) | Hardcoded tokens in source code |
+| **Authentication** | Middleware/HOCs | Centralized auth check / protected routes | Ad-hoc checks, leaked sensitive data |
+| **Error Handling** | `try/catch`, Error Boundaries | Global error boundary, unified API error format | Unhandled promise rejections, blank screens |
+| **Dependencies** | `npm audit`, `package.json` | Up-to-date, minimal external deps | Known vulnerabilities, 5 different date libraries |
+
+### 3.4 UI & Performance
+
+Check how the frontend is built and how it performs.
+
+| What to look for | Tooling / Pattern | Good | Bad |
+|------------------|-------------------|------|-----|
+| **Styling Strategy** | CSS Modules, Tailwind, WDS | Consistent use of one strategy | Mixed inline styles, global CSS, and Tailwind |
+| **Rendering** | Over-fetching, hydration | Memoization where needed, optimized images | 10MB bundle, `useEffect` infinite loops |
+| **Accessibility (a11y)**| `aria-`, semantic HTML | `<button>`, native focus, correct contrast | `onClick` on `<div>` without keyboard support |
+
+---
+
+## 4. Output Template
+
+```markdown
+# Current State Analysis: <Project/Module Name>
+
+**Date:** YYYY-MM-DD
+**Analyst:** <Agent Role>
+
+## 1. Executive Summary
+<2-3 sentences summarizing the overall health and major findings.>
+
+## 2. Tech Stack & Architecture
+- **Frontend:** React 18, Vite, Zustand
+- **Backend:** Node.js, Express (if monolithic repo)
+- **Styling:** CSS Modules
+- **Pattern:** Layered architecture (Controllers -> Services)
+
+## 3. Findings
+
+### 3.1 Architecture & Consistency
+- ✅ **Good:** Routing is centralized in `src/routes.tsx`.
+- ⚠️ **Warning:** Two different data fetching patterns found (raw `fetch` vs custom `apiClient`). Need to unify.
+- 🔴 **Red Flag:** `Dashboard.jsx` is 850 lines long and handles rendering, data fetching, and complex logic (God Object).
+
+### 3.2 Security & Error Handling
+- ✅ **Good:** Passwords are never sent to the client.
+- 🔴 **Red Flag:** Production API keys found hardcoded in `src/config/keys.js`. (Requires immediate rotation and .env extraction).
+- ⚠️ **Warning:** Missing global React Error Boundary. Unhandled exceptions crash the whole tree.
+
+### 3.3 UI & Code Quality
+- ✅ **Good:** ESLint is configured and running strictly.
+- ⚠️ **Warning:** Minimal unit test coverage (only 3 tests exist).
+
+## 4. Recommendations & Tech Debt
+
+**Immediate Remediation (P0):**
+1. Extract secrets from `src/config/keys.js` to `.env`.
+2. Refactor `Dashboard.jsx` into smaller pure components.
+
+**Short-term Tech Debt (P1):**
+1. Unify data fetching to use `apiClient` exclusively.
+2. Implement global Error Boundary.
+
+**Long-term Strategy (P2):**
+1. Introduce Vitest for unit testing critical services.
+```
+
+---
+
+## See also
+- `$architecture-doc` — Use the analysis to propose the new architecture.
+- `$system-design-checklist` — To ensure no areas are missed during redesign.
+- `$security-review-baseline` — For deeper security audits.

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/claude.json

@@ -0,0 +1,18 @@
+{
+  "name": "current-state-analysis",
+  "display_name": "Current State Analysis",
+  "description": "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.",
+  "default_prompt": "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill.",
+  "triggers": [
+    "current-state-analysis",
+    "current state analysis",
+    "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency"
+  ],
+  "capabilities": [
+    "current",
+    "state",
+    "analysis"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/copilot.json

@@ -0,0 +1,18 @@
+{
+  "name": "current-state-analysis",
+  "display_name": "Current State Analysis",
+  "description": "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.",
+  "default_prompt": "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill.",
+  "triggers": [
+    "current-state-analysis",
+    "current state analysis",
+    "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency"
+  ],
+  "capabilities": [
+    "current",
+    "state",
+    "analysis"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/gemini.json

@@ -0,0 +1,18 @@
+{
+  "name": "current-state-analysis",
+  "display_name": "Current State Analysis",
+  "description": "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.",
+  "default_prompt": "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill.",
+  "triggers": [
+    "current-state-analysis",
+    "current state analysis",
+    "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency"
+  ],
+  "capabilities": [
+    "current",
+    "state",
+    "analysis"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Current State Analysis"
+  short_description: "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bot…"
+  default_prompt: "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill."
+dependencies:
+  tools: []
+policy:
+  allow_implicit_invocation: true

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/qwen.json

@@ -0,0 +1,18 @@
+{
+  "name": "current-state-analysis",
+  "display_name": "Current State Analysis",
+  "description": "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency.",
+  "default_prompt": "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill.",
+  "triggers": [
+    "current-state-analysis",
+    "current state analysis",
+    "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency"
+  ],
+  "capabilities": [
+    "current",
+    "state",
+    "analysis"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/current-state-analysis/agents/skill.yaml

@@ -0,0 +1,22 @@
+version: 1
+name: "current-state-analysis"
+display_name: "Current State Analysis"
+description: "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency."
+default_prompt: "Use $current-state-analysis when the task matches the \"Current State Analysis\" skill."
+triggers:
+  - "current-state-analysis"
+  - "current state analysis"
+  - "Analysis of the current repository architecture — conventions, patterns, tech debt, scaling bottlenecks, security risks, and consistency"
+capabilities:
+  - "current"
+  - "state"
+  - "analysis"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "en"
+  available_locales:
+    - "ru"
+    - "en"

package/domains/development/locales/en/.agents/skills/data-model/SKILL.md

@@ -0,0 +1,284 @@
+---
+name: data-model
+description: Data model and storage strategy — normalization/denormalization, indexes, transactions, cache, (opt.) event sourcing/eventual consistency — with trade-offs and linked to UX flows.
+---
+
+# Skill: Data Model
+
+Data model: from entity definitions to query optimization.
+
+**Sections:**
+1. [Inputs](#1-inputs)
+2. [Entity Definition Template](#2-entity-definition-template)
+3. [ER Diagram](#3-er-diagram)
+4. [Data Patterns](#4-data-patterns)
+5. [Index Strategy](#5-index-strategy)
+6. [Query Pattern Mapping](#6-query-pattern-mapping)
+7. [Transactions](#7-transactions)
+8. [Migrations](#8-migrations)
+9. [Example: full model](#9-example-full-model)
+10. [Output Template](#10-output-template)
+
+---
+
+## 1. Inputs
+
+| Input | From where | What for |
+|------|--------|-------|
+| PRD | PM gate | Acceptance criteria → entities, constraints |
+| UX Spec | UX gate | Screens/flows → query patterns |
+| API Contracts | Architect | Request/Response → fields, types |
+| NFR | System Design | Volume, latency, retention |
+
+---
+
+## 2. Entity Definition Template
+
+For each entity:
+
+```markdown
+### Entity: Product
+
+**Collection:** `products`
+**Lifecycle:** Created by admin, read by public endpoint, deleted manually
+
+| Field | Type | Required | Default | Constraints | Description |
+|-------|------|----------|---------|-------------|-------------|
+| _id | ObjectId | auto | auto | unique | Primary key |
+| ownerId | string | ✅ | — | indexed | Owner/tenant reference |
+| name | string | ✅ | — | 3-100 chars | Product name |
+| price | number | ✅ | — | min: 0 | Product price |
+| category | string | ✅ | "general" | enum: general, premium, sale | Product category |
+| active | boolean | ⬜ | true | — | Is product visible |
+| viewCount | number | ⬜ | 0 | min: 0 | Times viewed |
+| createdAt | Date | auto | now | — | Timestamp |
+| updatedAt | Date | auto | now | — | Timestamp |
+
+**Unique constraints:** (ownerId, name)
+**Indexes:** See Index Strategy
+**Relationships:** belongs to Owner (via ownerId)
+**Storage pattern:** Reference (separate collection)
+**Rationale:** Products have independent lifecycle, unbounded per owner
+```
+
+---
+
+## 3. ER Diagram
+
+```mermaid
+erDiagram
+    OWNER ||--|| SETTINGS : "has one"
+    OWNER ||--o{ PRODUCT : "has many"
+
+    OWNER {
+        ObjectId _id PK
+        string ownerId UK
+        string email
+        string name
+        string status
+        Date createdAt
+    }
+
+    SETTINGS {
+        ObjectId _id PK
+        string ownerId UK "FK → Owner"
+        object general
+        object appearance
+        object notifications
+        string theme
+        string templateId
+        object templateSettings
+    }
+
+    PRODUCT {
+        ObjectId _id PK
+        string ownerId "FK → Owner"
+        string name
+        number price
+        string category
+        boolean active
+        number viewCount
+        Date createdAt
+    }
+```
+
+---
+
+## 4. Data Patterns
+
+### Embed vs Reference Decision
+
+| Criterion | Embed ✅ | Reference ✅ |
+|---------|---------|-------------|
+| Read together | Yes | No |
+| Independent lifecycle | No | Yes |
+| Bounded size | Yes (< 50 items) | Unbounded |
+| Atomic updates child | Needed | Not critical |
+
+### Decision table (for the project)
+
+| Parent | Child | Pattern | Rationale |
+|--------|-------|---------|-----------|
+| Owner | Settings | **Embed** (or 1:1 ref) | Always read together, 1 settings per owner |
+| Owner | Products | **Reference** | Independent CRUD, unbounded, own pagination |
+| Settings | general/appearance/notifications | **Embed** | Bounded subdocuments, always read together |
+
+> Every embed/reference choice = potential ADR. If not obvious — create an `$adr-log`.
+
+### Caching (if applicable)
+
+| Data | Cache? | Strategy | TTL | Invalidation |
+|------|--------|----------|-----|--------------|
+| Public content | ✅ | HTTP Cache-Control | 60s | PUT settings → purge |
+| Product list | ⬜ | No cache (small, dashboard only) | — | — |
+| Settings (dashboard) | ⬜ | No cache (always fresh) | — | — |
+
+---
+
+## 5. Index Strategy
+
+### Index → Query Pattern Mapping
+
+| Index | Fields | Type | Serves Query |
+|-------|--------|------|-------------|
+| `owners_ownerId` | `{ ownerId: 1 }` | unique | Lookup by ownerId |
+| `settings_ownerId` | `{ ownerId: 1 }` | unique | Lookup settings by owner |
+| `products_owner_name` | `{ ownerId: 1, name: 1 }` | unique | Duplicate check on create |
+| `products_owner_active_date` | `{ ownerId: 1, active: 1, createdAt: -1 }` | compound | List active products sorted by date |
+| `products_owner_date` | `{ ownerId: 1, createdAt: -1 }` | compound | List all products sorted |
+
+### Index rules
+
+| Rule | Description |
+|---------|---------|
+| **ESR** | Equality → Sort → Range (order of fields in compound) |
+| **Max 5-7** | Every index = write overhead |
+| **Verify** | `explain('executionStats')` → IXSCAN, not COLLSCAN |
+| **Partial** | If the index is not needed for all docs: `partialFilterExpression` |
+
+---
+
+## 6. Query Pattern Mapping
+
+Mapping UX screen → query:
+
+| UX Screen | Action | Query | Index Used |
+|-----------|--------|-------|------------|
+| Dashboard: Products list | Load page | `find({ ownerId }).sort({ createdAt: -1 }).limit(20)` | `products_owner_date` |
+| Dashboard: Products list | Filter active | `find({ ownerId, active: true }).sort({ createdAt: -1 })` | `products_owner_active_date` |
+| Dashboard: Products list | Search by name | `find({ ownerId, name: { $regex } })` | `products_owner_name` (prefix) |
+| Dashboard: Settings | Load | `findOne({ ownerId })` | `settings_ownerId` |
+| Dashboard: Settings | Save | `updateOne({ ownerId }, { $set: ... })` | `settings_ownerId` |
+| Public Content | Load config | `findOne({ ownerId })` + `findOne({ ownerId, active: true }).sort({ createdAt: -1 })` | `settings_ownerId` + `products_owner_active_date` |
+| Webhook: register | Create | `updateOne({ ownerId }, { ... }, { upsert: true })` | `owners_ownerId` |
+
+### Performance notes
+
+| Query | Expected latency | Volume | Notes |
+|-------|-----------------|--------|-------|
+| Public content | < 10ms | Every page view | Add cache header |
+| Products list | < 20ms | Dashboard only | Paginated |
+| Settings load | < 5ms | Dashboard only | Single doc |
+
+---
+
+## 7. Transactions
+
+### When needed
+
+| Scenario | Transaction? | Rationale |
+|----------|:---:|-----------|
+| Create product | ⬜ No | Single collection write |
+| Update settings | ⬜ No | Single document update |
+| Process order (if order system) | ✅ Yes | Multi-doc: update order + decrement stock |
+| Register webhook (upsert owner + settings) | ⬜ No | Idempotent upserts, eventual consistency OK |
+
+### Rule
+
+> MongoDB likes modeling where transactions are needed **rarely**. If a transaction is needed often — reconsider the schema (maybe you should embed).
+
+---
+
+## 8. Migrations
+
+### Strategy
+
+| When | How |
+|-------|-----|
+| New field (optional) | Add to schema + `$setOnInsert` default |
+| New field (required) | Migration script: `updateMany` + backfill |
+| Rename field | Migration script + update code + period with both fields |
+| Remove field | Migration script: `$unset` + remove from schema |
+| Change type | Two steps: add new field → migrate data → remove old |
+
+### Tool
+
+```bash
+npx migrate-mongo create add-templateId-to-settings
+npx migrate-mongo up
+npx migrate-mongo down   # rollback
+npx migrate-mongo status
+```
+
+---
+
+## 9. Example: full model
+
+```markdown
+# Data Model: SaaS Admin Panel
+
+## Entities
+1. Owner — registered account/tenant record
+2. Settings — Application configuration (1:1 with Owner)
+3. Product — Content items (1:N with Owner)
+
+## Storage
+- MongoDB 7 (single instance, Docker)
+- Mongoose ODM (strict: 'throw')
+- Timestamps on all collections
+
+## Key decisions
+- Settings embedded approach considered, but separate collection for independent API
+- Products always referenced (unbounded, independent CRUD)
+- See ADR-001 (MongoDB), ADR-003 (embed vs reference)
+```
+
+---
+
+## 10. Output Template
+
+```markdown
+# Data Model: <project-name>
+
+**Date:** YYYY-MM-DD
+**Database:** MongoDB 7 + Mongoose
+
+## ER Diagram
+<mermaid diagram>
+
+## Entities
+<for each entity: section 2 template>
+
+## Data Patterns
+<embed vs ref decisions with rationale>
+
+## Indexes
+<section 5 table>
+
+## Query Mapping
+<section 6 table>
+
+## Transactions
+<section 7 table>
+
+## Migration Strategy
+<section 8>
+```
+
+---
+
+## See also
+- `$api-contracts` — API endpoints (schemas match entity fields)
+- `$mongodb-mongoose-best-practices` — implementation patterns
+- `$architecture-doc` — Architecture Document (data model section)
+- `$adr-log` — ADR for embed/reference/DB decisions

package/domains/development/locales/en/.agents/skills/data-model/agents/claude.json

@@ -0,0 +1,17 @@
+{
+  "name": "data-model",
+  "display_name": "Data Model",
+  "description": "Data model and storage strategy — normalization/denormalization, indexes, transactions, cache, (opt.) event sourcing/eventual consistency — with trade-offs and linked to UX flows.",
+  "default_prompt": "Use $data-model when the task matches the \"Data Model\" skill.",
+  "triggers": [
+    "data-model",
+    "data model",
+    "Data model and storage strategy — normalization/denormalization, indexes, transactions, cache, (opt"
+  ],
+  "capabilities": [
+    "data",
+    "model"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}