code-ai-installer 1.3.0 → 1.4.0

package/locales/en/.agents/qa_regression_baseline/SKILL.md

@@ -1,217 +0,0 @@
----
-name: qa_regression_baseline
-description: >
-  Run regression tests against a saved baseline and report differences. Use this skill whenever
-  the user wants to: run regression tests, compare test results to a previous run, detect regressions
-  in code or software, update a baseline after verified changes, generate a diff report between
-  test runs, or check if recent changes broke anything. Trigger on phrases like "run regression",
-  "compare with baseline", "check regressions", "update baseline", "run regression", "compare with baseline",
-  "check for regressions", "regression report", "what broke", or any similar intent to test code
-  stability against a known-good reference point.
----
-
-# QA Regression Baseline Skill
-
-This skill helps run regression tests, save baseline results, and identify regressions by comparing the current run with the saved baseline.
-
----
-
-## Concept
-
-```
-Baseline (reference)        Current run
-      │                       │
-      └──────── diff ──────────┘
-                  │
-            Regressions / improvements / without changes
-```
-
-- **Baseline** — saved results previous «good» run
-- **Regression** ? a test that passed earlier and now fails (or got worse)
-- **Improvement** ? a test that failed earlier and now passes
-
----
-
-## Workflow
-
-### Step 1. Understand context
-
-First clarify with the user (or from the conversation context):
-
-1. **What are we testing?** ? project path, language/framework, team test startup
-2. **Is there already a baseline?** ? if no, propose creating it
-3. **Result format** ? JSON, JUnit XML, text logs, snapshots
-4. **What to do with mismatches?** — only report / block / update baseline
-
-If the user did not specify the format ? determine it yourself by file extension or structured logs.
-
----
-
-### Step 2. Determine format baseline
-
-Support form (read `references/formats.md` with need):
-
-| Format | Typical files | Frameworks |
-|--------|---------------|------------|
-| JSON | `baseline.json`, `results.json` | Universal |
-| JUnit XML | `*.xml` in `test-results/` | pytest, Jest, Maven |
-| Snapshot | `__snapshots__/*.snap` | Jest, Vitest |
-| Plain text | `*.log`, `*.txt` | Any |
-| CSV | `results.csv` | Custom scripts |
-
----
-
-### Step 3. Run tests
-
-If user asks run tests — use bash:
-
-```bash
-# Python / pytest
-pytest --tb=short -q 2>&1 | tee current_run.log
-pytest --junit-xml=current_results.xml
-
-# Node.js / Jest
-npx jest --json --outputFile=current_results.json 2>&1
-
-# Universal — run that, what specified user
-<team from config or messages user>
-```
-
-Save output to `current_run_<timestamp>.log` or `current_results.json`.
-
----
-
-### Step 4. Compare with baseline
-
-Use script `scripts/compare.py` for compare. If baseline not exists — propose creating it it from current run.
-
-```bash
-python scripts/compare.py \
-  --baseline baseline/results.json \
-  --current current_results.json \
-  --format json \
-  --output report.md
-```
-
-The script can work with JSON, JUnit XML, and plain-text logs.
-
-**If baseline not exists:**
-```bash
-python scripts/compare.py --create-baseline \
-  --source current_results.json \
-  --output baseline/results.json
-```
-
----
-
-### Step 5. Form report
-
-Report must contain:
-
-```
-## Regression Report ? <date/time>
-
-### Result
-- ✅ Went: N
-- ? Failed: N
-- 🔴 Regressions (was OK → became FAIL): N
-- 🟢 Fix (was FAIL → became OK): N
-- ➖ Without changes: N
-
-### 🔴 Regressions (critical!)
-| Test | Status earlier | Status now | Details |
-|------|--------------|--------------|--------|
-| test_login | PASS | FAIL | AssertionError: ... |
-
-### 🟢 Fix tests
-| Test | Earlier | Now |
-|------|--------|--------|
-
-### ℹ️ New tests (not was in baseline)
-| Test | Status |
-|------|--------|
-```
-
----
-
-### Step 6. Decide what to do with the baseline
-
-After analysis propose to the user:
-
-- **If there are no regressions** ? propose updating the baseline (`--update-baseline`)
-- **If is regressions** → show detail diff, not update automatically
-- **If the user confirmed the changes** ? update the baseline with a comment
-
-```bash
-# Update baseline (only after explicit confirmation user)
-cp current_results.json baseline/results.json
-echo "$(date): Updated baseline — <cause>" >> baseline/CHANGELOG.md
-```
-
----
-
-## File structure of the project
-
-Recommended structure for storing baselines in the project:
-
-```
-project/
-├── baseline/
-│   ├── results.json        # Reference results
-│   ├── CHANGELOG.md        # History update baseline
-?   ??? config.json         # Configuration (what to compare, tolerances)
-├── test-results/
-│   └── current_run.json    # Results last run
-??? qa_config.yaml          # Skill config (optional)
-```
-
----
-
-## Config file (qa_config.yaml)
-
-If the project contains `qa_config.yaml` ? read it first:
-
-```yaml
-test_command: "pytest --junit-xml=test-results/current.xml"
-baseline_path: "baseline/results.json"
-result_format: "junit_xml"   # json | junit_xml | snapshot | text
-on_regression: "report"      # report | fail | notify
-ignore_tests:                # tests that are always unstable
-  - "test_flaky_network"
-tolerance:                   # allowed deviation (for performance tests)
-  duration_ms: 200
-```
-
----
-
-## Special cases
-
-### Unstable (flaky) tests
-If a test fails irregularly ? add it to `ignore_tests` in the config or mark it in the report as "flaky, does not block".
-
-### Performance regressions
-If tests include time measurements ? compare with a tolerance. Read `references/performance.md` for details.
-
-### Snapshot-tests (Jest/Vitest)
-When updating snapshots use `jest --updateSnapshot` only after reviewing the diff. Never update automatically without confirmation.
-
----
-
-## Common commands user and what do
-
-| Phrase | Action |
-|-------|---------|
-| "run regression" | Steps 3 → 4 → 5 |
-| "create baseline" | Run tests, save how baseline |
-| "update baseline" | Only after explicit confirmation, Step 6 |
-| "show what broke" | Step 4 ? 5, focus on regressions |
-| "compare runs" | Step 4 with two provided files |
-| "is there regressions?" | Steps 3 → 4 → 5 |
-
----
-
-## Links to additional materials
-
-- `references/formats.md` — detail schemas form (JSON, JUnit XML, snapshot)
-- `references/performance.md` ? comparison of performance metrics with tolerances
-- `scripts/compare.py` ? main comparison script (read before running if customization is needed)

package/locales/en/.agents/qa_security_smoke_tests/SKILL.md

@@ -1,188 +0,0 @@
----
-name: qa_security_smoke_tests
-description: Basic security smoke tests — auth/authz, validation, leaks in errors/logs, rate limiting (if enabled), SSRF/XSS where relevant.
----
-
-# Skill: QA Security Smoke Tests
-
-Run security smoke: auth, validation, error exposure, rate limiting.
-
-**Sections:**
-1. [Workflow](#1-workflow)
-2. [Test Cases](#2-test-cases)
-3. [Curl Commands](#3-curl)
-4. [Log Inspection](#4-logs)
-5. [Output Template](#5-output)
-
----
-
-## 1. Workflow
-
-```
-1. Determine protected endpoints (from $api_contracts)
-2. For each protected endpoint:
-   a. Request without auth → expect 401
-   b. Request with someone else's auth → expect 403/404
-   c. Invalid input → expect 400 (not 500!)
-   d. Check error response: no stack/DB/PII
-3. For public endpoints:
-   a. Check rate limiting (if enabled)
-4. Check logs: no PII/secrets
-5. Fill in results table
-```
-
----
-
-## 2. Test Cases
-
-| TC-ID | Category | Test | Request | Expected | Priority |
-|-------|----------|------|---------|----------|:--------:|
-| SEC-TC-01 | **Auth** | No token on protected endpoint | POST /coupons (no Authorization) | 401 | P0 |
-| SEC-TC-02 | **Auth** | Invalid token | POST /coupons (garbage token) | 401 | P0 |
-| SEC-TC-03 | **Auth** | Expired token | POST /coupons (expired JWT) | 401 | P1 |
-| SEC-TC-04 | **IDOR** | Access other user's data | GET /settings/other-app-id | 403 or 404 | P0 |
-| SEC-TC-05 | **IDOR** | Modify other user's data | PUT /settings/other-app-id | 403 or 404 | P0 |
-| SEC-TC-06 | **IDOR** | Delete other user's data | DELETE /coupons/other-user-coupon | 403 or 404 | P0 |
-| SEC-TC-07 | **Validation** | Empty body | POST /coupons `{}` | 400 (not 500!) | P0 |
-| SEC-TC-08 | **Validation** | Malicious field types | POST /coupons `{"code": 12345}` | 400 | P0 |
-| SEC-TC-09 | **Validation** | Oversized input | POST /coupons `{"code": "A".repeat(10000)}` | 400 | P1 |
-| SEC-TC-10 | **NoSQL** | Operator injection | GET /coupons?code[$gt]= | 400 (not data leak!) | P0 |
-| SEC-TC-11 | **Error leak** | Trigger 500 | Cause server error | No stack/DB in response | P0 |
-| SEC-TC-12 | **Error leak** | Check error format | Any 4xx/5xx | `{ error: { code, message } }` only | P0 |
-| SEC-TC-13 | **Rate limit** | Flood endpoint | 100+ requests/min | 429 (if enabled) | P1 |
-| SEC-TC-14 | **Headers** | Check security headers | Any response | X-Content-Type-Options, etc. | P1 |
-| SEC-TC-15 | **XSS** | Script input | POST /settings `{"title": "<script>alert(1)</script>"}` | Stored sanitized or rejected | P0 |
-
----
-
-## 3. Curl Commands
-
-### No auth (SEC-TC-01)
-
-```bash
-curl -s -o /dev/null -w "%{http_code}" \
-  -X POST https://localhost:5173/api/v1/coupons \
-  -H "Content-Type: application/json" \
-  -d '{"code":"TEST","discount":10}'
-# Expected: 401
-```
-
-### IDOR check (SEC-TC-04)
-
-```bash
-curl -s -w "\n%{http_code}" \
-  -X GET https://localhost:5173/api/v1/settings/OTHER_APP_INSTANCE_ID \
-  -H "Authorization: Bearer <my_token>"
-# Expected: 403 or 404 (NOT 200 with other user's data!)
-```
-
-### NoSQL injection (SEC-TC-10)
-
-```bash
-curl -s -w "\n%{http_code}" \
-  "https://localhost:5173/api/v1/coupons?code[\$gt]="
-# Expected: 400 (NOT 200 with all coupons!)
-```
-
-### Error exposure check (SEC-TC-11)
-
-```bash
-curl -s -X POST https://localhost:5173/api/v1/coupons \
-  -H "Content-Type: application/json" \
-  -H "Authorization: Bearer <token>" \
-  -d '{"code": null}' | python3 -m json.tool
-# Check: no "stack", no "MongoError", no file paths in response
-```
-
-### XSS input (SEC-TC-15)
-
-```bash
-curl -s -X PUT https://localhost:5173/api/v1/settings/MY_ID \
-  -H "Content-Type: application/json" \
-  -H "Authorization: Bearer <token>" \
-  -d '{"title": "<script>alert(1)</script>"}'
-# Check: title should be sanitized/escaped, NOT stored as raw HTML
-```
-
-### Security headers (SEC-TC-14)
-
-```bash
-curl -sI https://localhost:5173/api/v1/health/live | grep -iE "x-content-type|x-frame|strict-transport|referrer-policy"
-# Expected: security headers present
-```
-
----
-
-## 4. Log Inspection
-
-### After running tests, check logs for PII/secrets
-
-```bash
-# Check application logs (Docker)
-docker compose logs api --tail 100 | grep -iE "password|token|secret|apiKey|authorization"
-# Expected: ZERO matches (all should be [REDACTED])
-
-# Check for stack traces in response bodies
-docker compose logs api --tail 100 | grep -i "stack"
-# Expected: internal logs only, never in HTTP responses
-
-# Check for PII
-docker compose logs api --tail 100 | grep -iE "email.*@|phone.*\d{7}"
-# Expected: masked or absent
-```
-
----
-
-## 5. Output Template
-
-```markdown
-# Security Smoke Test Report
-
-**Date:** YYYY-MM-DD
-**Tester:** Tester Agent
-**Environment:** <URL>
-
-## Results
-
-| TC-ID | Category | Test | Expected | Actual | Status |
-|-------|----------|------|:--------:|:------:|:------:|
-| SEC-TC-01 | Auth | No token | 401 | 401 | ✅ |
-| SEC-TC-04 | IDOR | Other user's data | 403/404 | 200 😱 | ❌ |
-| SEC-TC-07 | Validation | Empty body | 400 | 500 | ❌ |
-| SEC-TC-10 | NoSQL | Operator injection | 400 | 200 | ❌ |
-| SEC-TC-11 | Error leak | Trigger 500 | No stack | Has stack | ❌ |
-| SEC-TC-14 | Headers | Security headers | Present | Missing | ⚠️ |
-
-## Log Inspection
-| Check | Result |
-|-------|--------|
-| Secrets in logs | ✅ Clean |
-| Stack traces in logs | ✅ Internal only |
-| PII in logs | ⚠️ Email unmasked |
-
-## Summary
-| Status | Count |
-|--------|:-----:|
-| ✅ PASS | X |
-| ❌ FAIL | Y |
-| ⚠️ WARN | Z |
-
-## Critical Findings
-| # | Severity | Finding | Impact | Fix |
-|---|----------|---------|--------|-----|
-| 1 | 🔴 P0 | IDOR: other user's settings accessible | Data breach | Add ownership check |
-| 2 | 🔴 P0 | NoSQL injection: $gt operator not filtered | Data leak | Add input sanitization |
-
-## Verdict
-- ✅ SECURE — all security smoke tests pass
-- ⚠️ ISSUES — P1 findings to address
-- ❌ VULNERABLE — P0 security findings, block release
-```
-
----
-
-## See also
-- `$security_review` — deep AppSec review (code level)
-- `$security_review_baseline` — quick security checklist
-- `$qa_api_contract_tests` — functional API tests
-- `$qa_test_plan` — test plan (references this skill)

package/locales/en/.agents/qa_test_plan/SKILL.md

@@ -1,203 +0,0 @@
----
-name: qa_test_plan
-description: Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria.
----
-
-# Skill: QA Test Plan
-
-Test plan with coverage matrix by PRD/UX flows.
-
-**Sections:**
-1. [Workflow](#1-workflow)
-2. [Test Plan Structure](#2-structure)
-3. [Coverage Matrix](#3-matrix)
-4. [Risk-Based Prioritization](#4-priority)
-5. [Entry/Exit Criteria](#5-criteria)
-6. [Example: Smart Cart Rescue](#6-example)
-7. [Output Template](#7-output)
-
----
-
-## 1. Workflow
-
-```
-1. Read PRD / UX Spec / Architecture Doc
-   └── Highlight user flows and acceptance criteria
-
-2. Determine scope:
-   ├── What test (in scope)
-   └── What Not test (out of scope + why)
-
-3. Break it down into test suites by category:
-   ├── Functional (happy + edge + error paths)
-   ├── API contracts
-   ├── Security smoke
-   ├── UI/a11y smoke
-   └── Performance baseline
-
-4. For each flow → test cases (section 3)
-
-5. Prioritization (section 4)
-
-6. Determine entry/exit criteria (section 5)
-```
-
----
-
-## 2. Test Plan Structure
-
-| Section | Content |
-|---------|---------|
-| **Scope** | What's included, what's excluded (with rationale) |
-| **Assumptions** | Prerequisites, test environment conditions |
-| **Test suites** | Groups of test cases by feature/area |
-| **Coverage matrix** | Flow → test cases mapping |
-| **Test data** | Required data setup / seed / fixtures |
-| **Environment** | URLs, credentials, infra requirements |
-| **Blockers/Risks** | What could prevent testing |
-| **Schedule** | When each suite runs (CI / manual / release) |
-
----
-
-## 3. Coverage Matrix
-
-### Test case format
-
-| Field | Description | Example |
-|-------|-------------|---------|
-| **TC-ID** | Unique ID | TC-COUPON-01 |
-| **Flow** | User flow being tested | Create coupon |
-| **Type** | happy / edge / error / security | happy |
-| **Preconditions** | Required state | User logged in, app installed |
-| **Steps** | Numbered actions | 1. Open settings 2. Fill form 3. Click Save |
-| **Expected Result** | What should happen | Coupon saved, toast shown |
-| **Priority** | P0 / P1 / P2 | P0 |
-| **Automation** | Unit / Integration / E2E / Manual | Integration |
-
-### Coverage matrix example
-
-| Flow | Happy | Edge | Error | Security | Total |
-|------|:-----:|:----:|:-----:|:--------:|:-----:|
-| Install webhook | TC-01 | TC-02 | TC-03, TC-04 | TC-05 | 5 |
-| Settings CRUD | TC-06 | TC-07, TC-08 | TC-09, TC-10 | TC-11 | 6 |
-| Coupon create | TC-12 | TC-13, TC-14 | TC-15, TC-16, TC-17 | TC-18 | 7 |
-| Widget render | TC-19 | TC-20 | TC-21 | TC-22 | 4 |
-| **Total** | 4 | 6 | 7 | 4 | **22** |
-
----
-
-## 4. Risk-Based Prioritization
-
-| Priority | Criteria | Example |
-|----------|---------|---------|
-| 🔴 **P0** | Core functionality, data loss, security | Auth flow, payment, CRUD on main entities |
-| 🟠 **P1** | Important but recoverable, edge cases | Duplicate handling, pagination, error states |
-| 🟡 **P2** | Nice-to-have, cosmetic, rare paths | Tooltip text, animation timing, unusual screen sizes |
-
-### Priority distribution guideline
-
-| Priority | % of total test cases |
-|----------|:-----:|
-| P0 | 40-50% |
-| P1 | 30-40% |
-| P2 | 10-20% |
-
----
-
-## 5. Entry/Exit Criteria
-
-### Entry criteria (start testing when)
-
-| # | Criterion | Status |
-|---|----------|--------|
-| 1 | Build successful | ☐ |
-| 2 | CI lint + unit tests pass | ☐ |
-| 3 | Environment accessible (dev/staging) | ☐ |
-| 4 | Test data seeded | ☐ |
-| 5 | All P0 dev tasks completed | ☐ |
-
-### Exit criteria (release when)
-
-| # | Criterion | Status |
-|---|----------|--------|
-| 1 | All P0 test cases PASS | ☐ |
-| 2 | All P1 test cases PASS (or waiver) | ☐ |
-| 3 | No open P0 bugs | ☐ |
-| 4 | Security smoke PASS | ☐ |
-| 5 | API contract compliance PASS | ☐ |
-
----
-
-## 6. Example: Smart Cart Rescue
-
-```markdown
-# Test Plan: Smart Cart Rescue — Template v2
-
-## Scope
-- IN: Settings CRUD, Coupon CRUD, Widget rendering, Install webhook
-- OUT: Wix marketplace publishing, multi-language (not in MVP)
-
-## Test Suites
-1. API Contract Tests (8 cases) → $qa_api_contract_tests
-2. Manual Functional (12 cases) → $qa_manual_run
-3. Security Smoke (6 cases) → $qa_security_smoke_tests
-4. UI/a11y Smoke (4 cases) → $qa_ui_a11y_smoke
-
-## Coverage: 30 test cases (P0: 12, P1: 13, P2: 5)
-## Entry: CI green, staging up, test app installed
-## Exit: All P0 pass, no open P0 bugs
-```
-
----
-
-## 7. Output Template
-
-```markdown
-# QA Test Plan: <feature/sprint>
-
-**Date:** YYYY-MM-DD
-**PRD:** <reference>
-**UX Spec:** <reference>
-
-## Scope
-- **In scope:** <list>
-- **Out of scope:** <list + rationale>
-
-## Assumptions
-- <list>
-
-## Test Suites
-| Suite | Cases | Priority mix | Method |
-|-------|:-----:|-------------|--------|
-| Functional | 15 | 6×P0, 6×P1, 3×P2 | Manual + Unit |
-| API Contract | 8 | 4×P0, 4×P1 | Integration |
-| Security Smoke | 6 | 4×P0, 2×P1 | Manual + Grep |
-| UI/a11y | 4 | 1×P0, 2×P1, 1×P2 | Manual |
-
-## Coverage Matrix
-<section 3 table>
-
-## Test Data
-- <required fixtures/seed data>
-
-## Environment
-- URL: <staging URL>
-- Credentials: <how to get>
-
-## Entry/Exit Criteria
-<section 5 tables>
-
-## Risks & Blockers
-| Risk | Impact | Mitigation |
-|------|--------|-----------|
-| Wix API down | P0: Install flow blocked | Skip, retest later |
-```
-
----
-
-## See also
-- `$qa_manual_run` — execute manual test cases
-- `$qa_api_contract_tests` — API contract test execution
-- `$qa_security_smoke_tests` — security smoke execution
-- `$qa_ui_a11y_smoke` — UI/a11y smoke execution
-- `$qa_browser_testing` — browser-based visual testing

package/locales/en/.agents/qa_test_plan/agents/claude.json

@@ -1,18 +0,0 @@
-{
-  "name": "qa_test_plan",
-  "display_name": "QA Test Plan",
-  "description": "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria.",
-  "default_prompt": "Use $qa_test_plan when the task matches the \"QA Test Plan\" skill.",
-  "triggers": [
-    "qa_test_plan",
-    "qa test plan",
-    "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria"
-  ],
-  "capabilities": [
-    "qa",
-    "test",
-    "plan"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/qa_test_plan/agents/copilot.json

@@ -1,18 +0,0 @@
-{
-  "name": "qa_test_plan",
-  "display_name": "QA Test Plan",
-  "description": "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria.",
-  "default_prompt": "Use $qa_test_plan when the task matches the \"QA Test Plan\" skill.",
-  "triggers": [
-    "qa_test_plan",
-    "qa test plan",
-    "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria"
-  ],
-  "capabilities": [
-    "qa",
-    "test",
-    "plan"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/qa_test_plan/agents/gemini.json

@@ -1,18 +0,0 @@
-{
-  "name": "qa_test_plan",
-  "display_name": "QA Test Plan",
-  "description": "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria.",
-  "default_prompt": "Use $qa_test_plan when the task matches the \"QA Test Plan\" skill.",
-  "triggers": [
-    "qa_test_plan",
-    "qa test plan",
-    "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria"
-  ],
-  "capabilities": [
-    "qa",
-    "test",
-    "plan"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/qa_test_plan/agents/openai.yaml

@@ -1,8 +0,0 @@
-interface:
-  display_name: "QA Test Plan"
-  short_description: "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negati…"
-  default_prompt: "Use $qa_test_plan when the task matches the \"QA Test Plan\" skill."
-dependencies:
-  tools: []
-policy:
-  allow_implicit_invocation: true

package/locales/en/.agents/qa_test_plan/agents/qwen.json

@@ -1,18 +0,0 @@
-{
-  "name": "qa_test_plan",
-  "display_name": "QA Test Plan",
-  "description": "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria.",
-  "default_prompt": "Use $qa_test_plan when the task matches the \"QA Test Plan\" skill.",
-  "triggers": [
-    "qa_test_plan",
-    "qa test plan",
-    "Compose test plan and coverage matrix by PRD/UX — roles, critical user flows, states UI, negative cases, acceptance criteria"
-  ],
-  "capabilities": [
-    "qa",
-    "test",
-    "plan"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}