code-ai-installer 2.4.0 → 2.5.0

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/SKILL.md

@@ -0,0 +1,325 @@
+---
+name: karpathy-guidelines
+description: Behavioral guidelines to reduce common LLM mistakes across all tasks — code, design, analytics, product. Apply always.
+license: MIT
+source: https://x.com/karpathy/status/2015883857489522876
+---
+
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876).
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+---
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them — don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+### Example: Hidden Assumptions
+
+**Request:** "Add a feature to export user data"
+
+❌ **What LLMs do** — silently assume format, fields, scope:
+
+```python
+def export_users(format='json'):
+    users = User.query.all()
+    with open('users.json', 'w') as f:
+        json.dump([u.to_dict() for u in users], f)
+    return f"Exported {len(users)} users"
+```
+
+✅ **What should happen** — surface assumptions and ask:
+
+```
+Before implementing, I need to clarify:
+
+1. Scope: Export all users or filtered subset? (privacy implications)
+2. Format: "export" — download file, background job, or API endpoint?
+3. Fields: Which user fields? (some might be sensitive)
+4. Volume: How many users? (affects approach)
+
+What's your preference?
+```
+
+### Example: Multiple Interpretations
+
+**Request:** "Make the search faster"
+
+❌ **What LLMs do** — silently pick one interpretation and write 200 lines of optimization.
+
+✅ **What should happen:**
+
+```
+"Make the search faster" could mean:
+
+1. Faster response time (< 100ms instead of 500ms)
+   → database indexes, cache | ~2h
+
+2. Handle more concurrent searches (throughput)
+   → async/await, connection pooling | ~4h
+
+3. Faster perceived speed (UX)
+   → show partial results immediately | ~3h
+
+Current search takes ~500ms. Which aspect matters most?
+```
+
+---
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+### Example: Over-abstraction
+
+**Request:** "Add a function to calculate discount"
+
+❌ **What LLMs do** — Strategy pattern, ABC, dataclass, configurator:
+
+```python
+class DiscountStrategy(ABC):
+    @abstractmethod
+    def calculate(self, amount: float) -> float: pass
+
+class PercentageDiscount(DiscountStrategy):
+    def __init__(self, percentage: float):
+        self.percentage = percentage
+    def calculate(self, amount: float) -> float:
+        return amount * (self.percentage / 100)
+
+@dataclass
+class DiscountConfig:
+    strategy: DiscountStrategy
+    min_purchase: float = 0.0
+    max_discount: float = float('inf')
+
+# 40 more lines to use one formula
+```
+
+✅ **What should happen:**
+
+```python
+def calculate_discount(amount: float, percent: float) -> float:
+    """Calculate discount amount. percent should be 0-100."""
+    return amount * (percent / 100)
+```
+
+When to add complexity: only when multiple discount types are actually needed.
+
+### Example: Speculative Features
+
+**Request:** "Save user preferences to database"
+
+❌ **What LLMs do** — cache, validator, merge flag, notifications:
+
+```python
+class PreferenceManager:
+    def __init__(self, db, cache=None, validator=None):
+        ...
+    def save(self, user_id, prefs, merge=True, validate=True, notify=False):
+        # 50 lines for what could be 3
+```
+
+✅ **What should happen:**
+
+```python
+def save_preferences(db, user_id: int, preferences: dict):
+    db.execute(
+        "UPDATE users SET preferences = ? WHERE id = ?",
+        (json.dumps(preferences), user_id)
+    )
+```
+
+Add caching, validation, merging later — only when actually needed.
+
+---
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it — don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+**The test:** Every changed line should trace directly to the user's request.
+
+### Example: Drive-by Refactoring
+
+**Request:** "Fix the bug where empty emails crash the validator"
+
+❌ **What LLMs do** — improve email validation beyond the bug fix, add username validation, change comment style, add docstring.
+
+✅ **What should happen — only the lines that fix empty email:**
+
+```diff
+  def validate_user(user_data):
+      # Check email format
+-     if not user_data.get('email'):
++     email = user_data.get('email', '')
++     if not email or not email.strip():
+          raise ValueError("Email required")
+
+      # Basic email validation
+-     if '@' not in user_data['email']:
++     if '@' not in email:
+          raise ValueError("Invalid email")
+
+      # Check username  ← untouched, not in scope
+      if not user_data.get('username'):
+          raise ValueError("Username required")
+
+      return True
+```
+
+### Example: Style Drift
+
+**Request:** "Add logging to the upload function"
+
+❌ **What LLMs do** — add type hints, change single quotes to double quotes, add docstring, reformat whitespace.
+
+✅ **What should happen — match existing style:**
+
+```diff
++ import logging
++
++ logger = logging.getLogger(__name__)
++
+  def upload_file(file_path, destination):
++     logger.info(f'Starting upload: {file_path}')
+      try:
+          with open(file_path, 'rb') as f:
+              data = f.read()
+
+          response = requests.post(destination, files={'file': data})
+
+          if response.status_code == 200:
++             logger.info(f'Upload successful: {file_path}')
+              return True
+          else:
++             logger.error(f'Upload failed: {file_path}, status={response.status_code}')
+              return False
+      except Exception as e:
+-         print(f"Error: {e}")
++         logger.exception(f'Upload error: {file_path}')
+          return False
+```
+
+Matched: single quotes, no type hints, existing boolean pattern, spacing style.
+
+---
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+### Example: Incremental with Verification
+
+**Request:** "Add rate limiting to the API"
+
+❌ **What LLMs do** — implement Redis, multiple strategies, config system, and monitoring in one 300-line commit with no clear verification steps.
+
+✅ **What should happen:**
+
+```
+Plan for rate limiting:
+
+1. Basic in-memory rate limiting (single endpoint)
+   Verify: 100 requests → first 10 succeed, rest get 429
+
+2. Extract to middleware (all endpoints)
+   Verify: existing endpoint tests still pass
+
+3. Redis backend (multi-server)
+   Verify: rate limit persists across app restarts
+
+4. Configuration (rates per endpoint)
+   Verify: /search allows 10/min, /users allows 100/min
+
+Start with step 1?
+```
+
+### Example: Reproduce Before Fixing
+
+**Request:** "The sorting breaks when there are duplicate scores"
+
+❌ **What LLMs do** — immediately change sort logic without reproducing the bug.
+
+✅ **What should happen:**
+
+```python
+# 1. First, write a test that reproduces the bug
+def test_sort_with_duplicate_scores():
+    scores = [
+        {'name': 'Alice', 'score': 100},
+        {'name': 'Bob', 'score': 100},
+        {'name': 'Charlie', 'score': 90},
+    ]
+    result = sort_scores(scores)
+    assert result[0]['score'] == 100
+    assert result[2]['score'] == 90
+    assert result[0]['name'] < result[1]['name']  # stable sort
+
+# Verify: test fails → bug reproduced
+
+# 2. Now fix with stable sort
+def sort_scores(scores):
+    return sorted(scores, key=lambda x: (-x['score'], x['name']))
+
+# Verify: test passes
+```
+
+---
+
+## Anti-Patterns Summary
+
+| Principle | Anti-Pattern | Fix |
+|---|---|---|
+| Think Before Coding | Silently assumes file format, fields, scope | List assumptions explicitly, ask for clarification |
+| Simplicity First | Strategy pattern for single discount calculation | One function until complexity is actually needed |
+| Surgical Changes | Reformats quotes, adds type hints while fixing bug | Only change lines that fix the reported issue |
+| Goal-Driven | "I'll review and improve the code" | "Write test for bug X → make it pass → verify no regressions" |
+
+## Key Insight
+
+The "overcomplicated" examples aren't obviously wrong — they follow design patterns and best practices. The problem is **timing**: they add complexity before it's needed.
+
+**Good code is code that solves today's problem simply, not tomorrow's problem prematurely.**

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/claude.json

@@ -0,0 +1,22 @@
+{
+  "name": "karpathy-guidelines",
+  "display_name": "Karpathy Guidelines",
+  "description": "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution.",
+  "default_prompt": "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design.",
+  "triggers": [
+    "karpathy-guidelines",
+    "karpathy",
+    "Karpathy Guidelines",
+    "think before coding",
+    "simplicity first",
+    "surgical changes",
+    "goal-driven execution"
+  ],
+  "capabilities": [
+    "quality",
+    "guidelines",
+    "best-practices"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/copilot.json

@@ -0,0 +1,22 @@
+{
+  "name": "karpathy-guidelines",
+  "display_name": "Karpathy Guidelines",
+  "description": "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution.",
+  "default_prompt": "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design.",
+  "triggers": [
+    "karpathy-guidelines",
+    "karpathy",
+    "Karpathy Guidelines",
+    "think before coding",
+    "simplicity first",
+    "surgical changes",
+    "goal-driven execution"
+  ],
+  "capabilities": [
+    "quality",
+    "guidelines",
+    "best-practices"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/gemini.json

@@ -0,0 +1,22 @@
+{
+  "name": "karpathy-guidelines",
+  "display_name": "Karpathy Guidelines",
+  "description": "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution.",
+  "default_prompt": "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design.",
+  "triggers": [
+    "karpathy-guidelines",
+    "karpathy",
+    "Karpathy Guidelines",
+    "think before coding",
+    "simplicity first",
+    "surgical changes",
+    "goal-driven execution"
+  ],
+  "capabilities": [
+    "quality",
+    "guidelines",
+    "best-practices"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/kimi.yaml

@@ -0,0 +1,18 @@
+name: "karpathy-guidelines"
+display_name: "Karpathy Guidelines"
+description: "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution."
+default_prompt: "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design."
+triggers:
+  - "karpathy-guidelines"
+  - "karpathy"
+  - "Karpathy Guidelines"
+  - "think before coding"
+  - "simplicity first"
+  - "surgical changes"
+  - "goal-driven execution"
+capabilities:
+  - "quality"
+  - "guidelines"
+  - "best-practices"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/openai.yaml

@@ -0,0 +1,8 @@
+interface:
+  display_name: "Karpathy Guidelines"
+  short_description: "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution."
+  default_prompt: "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design."
+dependencies:
+  tools: []
+policy:
+  allow_implicit_invocation: true

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/qwen.json

@@ -0,0 +1,22 @@
+{
+  "name": "karpathy-guidelines",
+  "display_name": "Karpathy Guidelines",
+  "description": "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution.",
+  "default_prompt": "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design.",
+  "triggers": [
+    "karpathy-guidelines",
+    "karpathy",
+    "Karpathy Guidelines",
+    "think before coding",
+    "simplicity first",
+    "surgical changes",
+    "goal-driven execution"
+  ],
+  "capabilities": [
+    "quality",
+    "guidelines",
+    "best-practices"
+  ],
+  "tools": [],
+  "implicit_invocation": true
+}

package/domains/development/locales/en/.agents/skills/karpathy-guidelines/agents/skill.yaml

@@ -0,0 +1,25 @@
+version: 1
+name: "karpathy-guidelines"
+display_name: "Karpathy Guidelines"
+description: "Behavioral guidelines to reduce common LLM mistakes — think before coding, simplicity first, surgical changes, goal-driven execution."
+default_prompt: "Use $karpathy-guidelines when the task requires quality discipline: writing code, reviewing, refactoring, analysis, or design."
+triggers:
+  - "karpathy-guidelines"
+  - "karpathy"
+  - "Karpathy Guidelines"
+  - "think before coding"
+  - "simplicity first"
+  - "surgical changes"
+  - "goal-driven execution"
+capabilities:
+  - "quality"
+  - "guidelines"
+  - "best-practices"
+tools: []
+invocation:
+  explicit: true
+  implicit: true
+localization:
+  default_locale: "en"
+  available_locales:
+    - "en"

package/domains/development/locales/en/.agents/skills/memory/agents/kimi.yaml

@@ -0,0 +1,12 @@
+name: "memory"
+display_name: "Memory (context between sessions)"
+description: "Project context management — what to store, how to retrieve it, how to avoid decision conflicts and context loss between sessions."
+default_prompt: "Use $memory when the task matches the \"Memory (context between sessions)\" skill."
+triggers:
+  - "memory"
+  - "Memory (context between sessions)"
+  - "Project context management — what to store, how to retrieve it, how to avoid decision conflicts and context loss between sessions"
+capabilities:
+  - "memory"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/mongodb-mongoose-best-practices/agents/kimi.yaml

@@ -0,0 +1,16 @@
+name: "mongodb-mongoose-best-practices"
+display_name: "MongoDB + Mongoose Best Practices"
+description: "Best practices for MongoDB + Mongoose — schemas, indexes, validation, transactions, migrations, performance, security, testing, anti-patterns, and examples."
+default_prompt: "Use $mongodb-mongoose-best-practices when the task matches the \"MongoDB + Mongoose Best Practices\" skill."
+triggers:
+  - "mongodb-mongoose-best-practices"
+  - "mongodb mongoose best practices"
+  - "MongoDB + Mongoose Best Practices"
+  - "Best practices for MongoDB + Mongoose — schemas, indexes, validation, transactions, migrations, performance, security, testing, anti-patterns, and examples"
+capabilities:
+  - "mongodb"
+  - "mongoose"
+  - "best"
+  - "practices"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/n8n-pinecone-qdrant-supabase/agents/kimi.yaml

@@ -0,0 +1,16 @@
+name: "n8n-pinecone-qdrant-supabase"
+display_name: "n8n + Pinecone + Qdrant + Supabase"
+description: "Integration patterns for n8n (workflow automation) with Vector DBs Pinecone and Qdrant and with Supabase (PostgreSQL + Auth + Storage + Realtime). Use this skill when building AI pipelines, RAG systems, data automation, working with embeddings, semantic search, or any orchestration between these tools. Activate for questions about n8n workflows, vector search, embedding upsert, Supabase RLS, or building RAG on top of this stack."
+default_prompt: "Use $n8n-pinecone-qdrant-supabase when the task matches the \"n8n + Pinecone + Qdrant + Supabase\" skill."
+triggers:
+  - "n8n-pinecone-qdrant-supabase"
+  - "n8n pinecone qdrant supabase"
+  - "n8n + Pinecone + Qdrant + Supabase"
+  - "Integration patterns for n8n (workflow automation) with Vector DBs Pinecone and Qdrant and with Supabase (PostgreSQL + Auth + Storage + Realtime)"
+capabilities:
+  - "n8n"
+  - "pinecone"
+  - "qdrant"
+  - "supabase"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/node-express-beast-practices/agents/kimi.yaml

@@ -0,0 +1,16 @@
+name: "node-express-beast-practices"
+display_name: "Node/Express Beast Practices"
+description: "Node.js + Express — REST API, middleware pipeline, service layer, repositories, centralized error handling, validation (Zod), graceful shutdown, health checks, security headers. Activate when writing an API, refactoring Express applications, or for questions on \"how to properly organize a backend on Express\"."
+default_prompt: "Use $node-express-beast-practices when the task matches the \"Node/Express Beast Practices\" skill."
+triggers:
+  - "node-express-beast-practices"
+  - "node express beast practices"
+  - "Node/Express Beast Practices"
+  - "Node"
+capabilities:
+  - "node"
+  - "express"
+  - "beast"
+  - "practices"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/observability-logging/agents/kimi.yaml

@@ -0,0 +1,14 @@
+name: "observability-logging"
+display_name: "Observability (Implementation)"
+description: "Implementation of observability at the code level — structured logs (pino), request_id/trace_id correlation, log levels, prevention of PII/secrets leaks, basic metrics, health checks. DO/DON'T examples. Activate when configuring logging, adding metrics, or for questions on \"how to log properly\"."
+default_prompt: "Use $observability-logging when the task matches the \"Observability (Implementation)\" skill."
+triggers:
+  - "observability-logging"
+  - "observability logging"
+  - "Observability (Implementation)"
+  - "Implementation of observability at the code level — structured logs (pino), request_id/trace_id correlation, log levels, prevention of PII/secrets leaks, basic metrics, health checks"
+capabilities:
+  - "observability"
+  - "logging"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/observability-plan/agents/kimi.yaml

@@ -0,0 +1,13 @@
+name: "observability-plan"
+display_name: "Observability Plan"
+description: "Observability plan — what logs/metrics/traces to collect, request correlation, log levels, alerts. Without leaking PII/secrets."
+default_prompt: "Use $observability-plan when the task matches the \"Observability Plan\" skill."
+triggers:
+  - "observability-plan"
+  - "observability plan"
+  - "Observability plan — what logs/metrics/traces to collect, request correlation, log levels, alerts"
+capabilities:
+  - "observability"
+  - "plan"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/observability-review/agents/kimi.yaml

@@ -0,0 +1,14 @@
+name: "observability-review"
+display_name: "🟠 P1: Unstructured logging"
+description: "Review observability — structured logs, request_id/trace_id, levels logs, ban leaks PII/secrets, compliance Observability Plan."
+default_prompt: "Use $observability-review when the task matches the \"🟠 P1: Unstructured logging\" skill."
+triggers:
+  - "observability-review"
+  - "observability review"
+  - "🟠 P1: Unstructured logging"
+  - "Review observability — structured logs, request_id/trace_id, levels logs, ban leaks PII/secrets, compliance Observability Plan"
+capabilities:
+  - "observability"
+  - "review"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/performance-review-baseline/agents/kimi.yaml

@@ -0,0 +1,14 @@
+name: "performance-review-baseline"
+display_name: "Performance Review Baseline"
+description: "Basic perf review — N+1, pagination, batches, redundant queries, cache by architecture, heavy operations in the request path."
+default_prompt: "Use $performance-review-baseline when the task matches the \"Performance Review Baseline\" skill."
+triggers:
+  - "performance-review-baseline"
+  - "performance review baseline"
+  - "Basic perf review — N+1, pagination, batches, redundant queries, cache by architecture, heavy operations in the request path"
+capabilities:
+  - "performance"
+  - "review"
+  - "baseline"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/pm-backlog/agents/kimi.yaml

@@ -0,0 +1,13 @@
+name: "pm-backlog"
+display_name: "PM Backlog"
+description: "Decomposition of PRD into an initial backlog — epics, features, and tasks with priorities, dependencies, and iteration proposals (MVP → v1)."
+default_prompt: "Use $pm-backlog when the task matches the \"PM Backlog\" skill."
+triggers:
+  - "pm-backlog"
+  - "pm backlog"
+  - "Decomposition of PRD into an initial backlog — epics, features, and tasks with priorities, dependencies, and iteration proposals (MVP → v1)"
+capabilities:
+  - "pm"
+  - "backlog"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/pm-interview/agents/kimi.yaml

@@ -0,0 +1,14 @@
+name: "pm-interview"
+display_name: "PM Interview / Discovery"
+description: "Structured interview/documentation review — gather goals, audience, MVP, constraints, integrations, and success criteria to write a PRD."
+default_prompt: "Use $pm-interview when the task matches the \"PM Interview / Discovery\" skill."
+triggers:
+  - "pm-interview"
+  - "pm interview"
+  - "PM Interview / Discovery"
+  - "Structured interview/documentation review — gather goals, audience, MVP, constraints, integrations, and success criteria to write a PRD"
+capabilities:
+  - "pm"
+  - "interview"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/pm-prd/agents/kimi.yaml

@@ -0,0 +1,14 @@
+name: "pm-prd"
+display_name: "PRD (Product Requirements Document)"
+description: "Generate a PRD — Vision, MVP, out-of-scope, user stories, acceptance criteria, NFR, risks, and open questions. The result must be verifiable."
+default_prompt: "Use $pm-prd when the task matches the \"PRD (Product Requirements Document)\" skill."
+triggers:
+  - "pm-prd"
+  - "pm prd"
+  - "PRD (Product Requirements Document)"
+  - "Generate a PRD — Vision, MVP, out-of-scope, user stories, acceptance criteria, NFR, risks, and open questions"
+capabilities:
+  - "pm"
+  - "prd"
+tools: []
+implicit_invocation: true

package/domains/development/locales/en/.agents/skills/qa-api-contract-tests/agents/kimi.yaml

@@ -0,0 +1,15 @@
+name: "qa-api-contract-tests"
+display_name: "QA API Contract Tests"
+description: "Test API compliance against contracts — schemas, codes, errors, validation, pagination; perform smoke testing via curl/scripts."
+default_prompt: "Use $qa-api-contract-tests when the task matches the \"QA API Contract Tests\" skill."
+triggers:
+  - "qa-api-contract-tests"
+  - "qa api contract tests"
+  - "Test API compliance against contracts — schemas, codes, errors, validation, pagination"
+capabilities:
+  - "qa"
+  - "api"
+  - "contract"
+  - "tests"
+tools: []
+implicit_invocation: true