code-ai-installer 2.4.1 → 3.0.0

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

@@ -1,19 +0,0 @@
-{
-  "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/locales/en/.agents/skills/code-review-checklist/agents/copilot.json

@@ -1,19 +0,0 @@
-{
-  "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/locales/en/.agents/skills/code-review-checklist/agents/gemini.json

@@ -1,19 +0,0 @@
-{
-  "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/locales/en/.agents/skills/code-review-checklist/agents/openai.yaml

@@ -1,8 +0,0 @@
-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/locales/en/.agents/skills/code-review-checklist/agents/qwen.json

@@ -1,19 +0,0 @@
-{
-  "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/locales/en/.agents/skills/code-review-checklist/agents/skill.yaml

@@ -1,23 +0,0 @@
-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/locales/en/.agents/skills/current-state-analysis/SKILL.md

@@ -1,141 +0,0 @@
----
-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/locales/en/.agents/skills/current-state-analysis/agents/claude.json

@@ -1,18 +0,0 @@
-{
-  "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/locales/en/.agents/skills/current-state-analysis/agents/copilot.json

@@ -1,18 +0,0 @@
-{
-  "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/locales/en/.agents/skills/current-state-analysis/agents/gemini.json

@@ -1,18 +0,0 @@
-{
-  "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/locales/en/.agents/skills/current-state-analysis/agents/openai.yaml

@@ -1,8 +0,0 @@
-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/locales/en/.agents/skills/current-state-analysis/agents/qwen.json

@@ -1,18 +0,0 @@
-{
-  "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/locales/en/.agents/skills/current-state-analysis/agents/skill.yaml

@@ -1,22 +0,0 @@
-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/locales/en/.agents/skills/data-model/SKILL.md

@@ -1,284 +0,0 @@
----
-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/locales/en/.agents/skills/data-model/agents/claude.json

@@ -1,17 +0,0 @@
-{
-  "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
-}