code-ai-installer 2.4.1 → 3.0.0

package/locales/en/.agents/skills/testing-strategy-js/agents/qwen.json

@@ -1,19 +0,0 @@
-{
-  "name": "testing-strategy-js",
-  "display_name": "JS/TS Testing Strategy",
-  "description": "Testing strategy for JS/TS projects — unit (Vitest), integration (API/DB), e2e (Playwright). AAA pattern, Vitest config, React Testing Library, mocks of external services, coverage thresholds, naming conventions, CI pipeline. Activate when writing new tests, refactoring existing ones, or for questions \"how to properly test X\".",
-  "default_prompt": "Use $testing-strategy-js when the task matches the \"JS/TS Testing Strategy\" skill.",
-  "triggers": [
-    "testing-strategy-js",
-    "testing strategy js",
-    "JS/TS Testing Strategy",
-    "Testing strategy for JS/TS projects — unit (Vitest), integration (API/DB), e2e (Playwright)"
-  ],
-  "capabilities": [
-    "testing",
-    "strategy",
-    "js"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/testing-strategy-js/agents/skill.yaml

@@ -1,23 +0,0 @@
-version: 1
-name: "testing-strategy-js"
-display_name: "JS/TS Testing Strategy"
-description: "Testing strategy for JS/TS projects — unit (Vitest), integration (API/DB), e2e (Playwright). AAA pattern, Vitest config, React Testing Library, mocks of external services, coverage thresholds, naming conventions, CI pipeline. Activate when writing new tests, refactoring existing ones, or for questions \"how to properly test X\"."
-default_prompt: "Use $testing-strategy-js when the task matches the \"JS/TS Testing Strategy\" skill."
-triggers:
-  - "testing-strategy-js"
-  - "testing strategy js"
-  - "JS/TS Testing Strategy"
-  - "Testing strategy for JS/TS projects — unit (Vitest), integration (API/DB), e2e (Playwright)"
-capabilities:
-  - "testing"
-  - "strategy"
-  - "js"
-tools: []
-invocation:
-  explicit: true
-  implicit: true
-localization:
-  default_locale: "en"
-  available_locales:
-    - "ru"
-    - "en"

package/locales/en/.agents/skills/tests-quality-review/SKILL.md

@@ -1,279 +0,0 @@
----
-name: tests-quality-review
-description: Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test "magic". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality.
----
-
-# Skill: Tests Quality Review
-
-Structured quality review of tests: checklist, priorities, examples of bad → good, report template.
-
-**Sections:**
-1. [When to activate](#1-when-to-activate)
-2. [Review Checklist](#2-review-checklist)
-3. [Examples: bad → good](#3-examples-bad--good)
-4. [Flaky tests: diagnosis](#4-flaky-tests-diagnosis)
-5. [Output report template](#5-output-report-template)
-
----
-
-## 1. When to activate
-
-- REV gate — review tests as part of code review
-- After TDD iteration — check the quality of newly written tests
-- When stabilizing a flaky CI — find and fix fragile tests
-- During a coverage audit — focus on *what* is covered, not just the percentage
-
----
-
-## 2. Review Checklist
-
-### A. Scenario Coverage (P0)
-
-| # | Check | Verdict |
-|---|---------|---------|
-| A1 | Tests verify **behavior**, not implementation details | ✅/❌ |
-| A2 | There is a **happy path** for every public method/component | ✅/❌ |
-| A3 | There are **error paths** (invalid input, network error, empty data) | ✅/❌ |
-| A4 | There are **edge cases** / boundaries (0, null, undefined, empty string, max) | ✅/❌ |
-| A5 | Async logic is tested (timeouts, rejects, race conditions) | ✅/❌ |
-
-### B. Resilience (P0)
-
-| # | Check | Verdict |
-|---|---------|---------|
-| B1 | Tests are **independent** (no hidden execution order) | ✅/❌ |
-| B2 | No **shared mutable state** between tests | ✅/❌ |
-| B3 | Each `beforeEach` / `afterEach` correctly cleans up state | ✅/❌ |
-| B4 | No dependency on **real time** (Date.now, setTimeout) | ✅/❌ |
-| B5 | No dependency on **network / file system** (everything is mocked) | ✅/❌ |
-
-### C. Test Code Quality (P1)
-
-| # | Check | Verdict |
-|---|---------|---------|
-| C1 | Test names are readable: `should [verb] when [condition]` | ✅/❌ |
-| C2 | AAA pattern (Arrange → Act → Assert) is clearly followed | ✅/❌ |
-| C3 | No **magic numbers/strings** without explanations | ✅/❌ |
-| C4 | No **duplication** (factories, helpers, shared fixtures are used) | ✅/❌ |
-| C5 | Assertions are **specific** (not `toBeTruthy()`, but `toBe(true)` / `toEqual(...)`) | ✅/❌ |
-
-### D. Integration Tests (P1)
-
-| # | Check | Verdict |
-|---|---------|---------|
-| D1 | **Actually** test integration (API/DB/contracts) | ✅/❌ |
-| D2 | Not "over-mocked" (mocks only on external boundaries) | ✅/❌ |
-| D3 | Contract tests verify **response shape**, not business logic | ✅/❌ |
-| D4 | Test data is **isolated** (no garbage from previous runs) | ✅/❌ |
-
-### E. Snapshot Tests (P2)
-
-| # | Check | Verdict |
-|---|---------|---------|
-| E1 | Snapshot is used **consciously** (for stable output) | ✅/❌ |
-| E2 | Snapshot is **compact** (not 500 lines) — inline preferred | ✅/❌ |
-| E3 | Snapshot update is not "auto-accept" (diff is reviewed) | ✅/❌ |
-
----
-
-## 3. Examples: bad → good
-
-### A1. Behavior vs Implementation
-
-```js
-// ❌ Tests implementation: checks that internal method is called
-it('should call _processInternal', () => {
-  const spy = vi.spyOn(service, '_processInternal');
-  service.process(data);
-  expect(spy).toHaveBeenCalled();
-});
-
-// ✅ Tests behavior: checks result
-it('should return processed data with status "done"', () => {
-  const result = service.process({ items: [1, 2, 3] });
-  expect(result.status).toBe('done');
-  expect(result.processedCount).toBe(3);
-});
-```
-
-### B1. Test Independence
-
-```js
-// ❌ Test depends on previous — if first fails, second fails too
-let createdId;
-it('should create', () => { createdId = create(); });
-it('should read', () => { read(createdId); }); // dependency!
-
-// ✅ Each test is self-contained
-it('should read created item', () => {
-  const id = create({ name: 'test' });
-  const item = read(id);
-  expect(item.name).toBe('test');
-});
-```
-
-### B4. Time Dependency
-
-```js
-// ❌ Flaky — depends on execution speed
-it('should be within 1 second', () => {
-  const start = Date.now();
-  doWork();
-  expect(Date.now() - start).toBeLessThan(1000);
-});
-
-// ✅ Mock time
-it('should expire after timeout', () => {
-  vi.useFakeTimers();
-  const onExpire = vi.fn();
-
-  startTimer(onExpire, 5000);
-  vi.advanceTimersByTime(5000);
-
-  expect(onExpire).toHaveBeenCalledOnce();
-  vi.useRealTimers();
-});
-```
-
-### C3. Magic Values
-
-```js
-// ❌ What is 42?
-expect(calc(x)).toBe(42);
-
-// ✅ Value explained
-const BASE = 100;
-const TAX_RATE = 0.12;
-const DISCOUNT = 50;
-const EXPECTED = (BASE - DISCOUNT) * (1 + TAX_RATE); // 56
-expect(calcTotal(BASE, TAX_RATE, DISCOUNT)).toBe(EXPECTED);
-```
-
-### C5. Specific Assertions
-
-```js
-// ❌ toBeTruthy — undefined, 0, "" are also falsy → false negative test
-expect(result).toBeTruthy();
-expect(array.length).toBeTruthy(); // 0 is falsy, test will fail
-
-// ✅ Specific assertion
-expect(result).toBe(true);
-expect(array).toHaveLength(3);
-expect(obj).toMatchObject({ name: 'test', active: true });
-```
-
-### D2. Over-mocked integration tests
-
-```js
-// ❌ Mocked everything — this is no longer an integration test
-vi.mock('../db.js');
-vi.mock('../validator.js');
-vi.mock('../queue.js');
-
-it('should process order', async () => {
-  db.save.mockResolvedValue({ id: 1 });
-  validator.check.mockReturnValue(true);
-  queue.push.mockResolvedValue(undefined);
-
-  await processOrder({ item: 'X' });
-  expect(db.save).toHaveBeenCalled(); // testing mock, not logic
-});
-
-// ✅ Mock only external boundary (HTTP), rest is real
-vi.mock('../services/payment-gateway.js'); // only mock
-
-it('should process order and save to DB', async () => {
-  paymentGateway.charge.mockResolvedValue({ txnId: 'TX123' });
-
-  const result = await processOrder({ item: 'X', amount: 100 });
-
-  expect(result.status).toBe('completed');
-  const stored = await db.orders.findById(result.id);
-  expect(stored.paymentTxnId).toBe('TX123');
-});
-```
-
----
-
-## 4. Flaky tests: diagnosis
-
-### Common Causes
-
-| Cause | Symptom | Fix |
-|---------|--------|-------------|
-| **Time dependency** | Passes/fails randomly | `vi.useFakeTimers()` |
-| **Shared state** | Fails with `--shuffle` or parallel run | Isolate state in `beforeEach` |
-| **External services** | Fails on slow network / offline run | Mock all HTTP |
-| **Race conditions** | Occasional timeouts | `await` / `waitFor` instead of `sleep` |
-| **Random data** | `Math.random()` in tests gives different results | Seed or mock random |
-| **Order dependency** | Passes solo, fails in suite | Remove shared state |
-| **Timer leaks** | `setTimeout` not cleared, affects next test | `afterEach(() => vi.clearAllTimers())` |
-
-### Flaky Check
-
-```bash
-# Run test 10 times — if at least 1 failure → flaky
-for i in $(seq 1 10); do npx vitest run --reporter=dot; done
-
-# Or via Vitest repeat
-npx vitest run --repeat=10
-```
-
----
-
-## 5. Output report template
-
-```markdown
-# Tests Quality Review Report
-
-## Summary
-- **Module/Feature:** [name]
-- **Total tests:** [N]
-- **Coverage:** [X]% statements, [Y]% branches
-- **Verdict:** PASS ✅ / PASS with findings ⚠️ / FAIL ❌
-
-## Findings
-
-### P0 — Blockers
-| # | Checklist item | Problem | Recommendation |
-|---|----------------|---------|-------------|
-| 1 | A3 (error paths) | No tests for network errors in fetchItems | Add test with reject mock |
-
-### P1 — Important
-| # | Checklist item | Problem | Recommendation |
-|---|----------------|---------|-------------|
-| 1 | C3 (magic) | `expect(result).toBe(42)` without explanation | Extract to const with name |
-
-### P2 — Improvements
-| # | Checklist item | Problem | Recommendation |
-|---|----------------|---------|-------------|
-| 1 | E2 (snapshot size) | 200 line snapshot in ProductForm.test | Switch to inline snapshot or RTL assertion |
-
-## Missing Test Cases
-- [ ] `fetchItems` — error path (network failure)
-- [ ] `updateRecord` — edge case (empty name)
-- [ ] `CountdownTimer` — boundary (0 seconds remaining)
-
-## Fragile Tests
-| Test | Fragility cause | Recommendation |
-|------|-------------------|-------------|
-| `pricing.test.js:42` | Depends on Date.now | vi.useFakeTimers |
-```
-
----
-
-## Verdict Criteria
-
-| Verdict | Conditions |
-|---------|---------|
-| **PASS ✅** | All P0 ✅, P1 ≤ 2 findings, no flaky |
-| **PASS with findings ⚠️** | All P0 ✅, but has P1 findings or missing cases | 
-| **FAIL ❌** | Any P0 ❌ (no error paths, tests dependent, flaky) |
-
----
-
-## See also
-- `$testing-strategy-js` — strategy and patterns for writing tests
-- `$code-review-checklist` — general code review checklist
-- `$qa-e2e-playwright` — E2E via Playwright
-- `$dev-reference-snippets` — code examples

package/locales/en/.agents/skills/tests-quality-review/agents/claude.json

@@ -1,18 +0,0 @@
-{
-  "name": "tests-quality-review",
-  "display_name": "Tests Quality Review",
-  "description": "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality.",
-  "default_prompt": "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill.",
-  "triggers": [
-    "tests-quality-review",
-    "tests quality review",
-    "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\""
-  ],
-  "capabilities": [
-    "tests",
-    "quality",
-    "review"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/tests-quality-review/agents/copilot.json

@@ -1,18 +0,0 @@
-{
-  "name": "tests-quality-review",
-  "display_name": "Tests Quality Review",
-  "description": "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality.",
-  "default_prompt": "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill.",
-  "triggers": [
-    "tests-quality-review",
-    "tests quality review",
-    "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\""
-  ],
-  "capabilities": [
-    "tests",
-    "quality",
-    "review"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/tests-quality-review/agents/gemini.json

@@ -1,18 +0,0 @@
-{
-  "name": "tests-quality-review",
-  "display_name": "Tests Quality Review",
-  "description": "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality.",
-  "default_prompt": "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill.",
-  "triggers": [
-    "tests-quality-review",
-    "tests quality review",
-    "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\""
-  ],
-  "capabilities": [
-    "tests",
-    "quality",
-    "review"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/tests-quality-review/agents/openai.yaml

@@ -1,8 +0,0 @@
-interface:
-  display_name: "Tests Quality Review"
-  short_description: "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence o…"
-  default_prompt: "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill."
-dependencies:
-  tools: []
-policy:
-  allow_implicit_invocation: true

package/locales/en/.agents/skills/tests-quality-review/agents/qwen.json

@@ -1,18 +0,0 @@
-{
-  "name": "tests-quality-review",
-  "display_name": "Tests Quality Review",
-  "description": "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality.",
-  "default_prompt": "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill.",
-  "triggers": [
-    "tests-quality-review",
-    "tests quality review",
-    "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\""
-  ],
-  "capabilities": [
-    "tests",
-    "quality",
-    "review"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/tests-quality-review/agents/skill.yaml

@@ -1,22 +0,0 @@
-version: 1
-name: "tests-quality-review"
-display_name: "Tests Quality Review"
-description: "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\". Prioritized checklist, good/bad test examples, output report template. Activate when reviewing existing tests, stabilizing flaky tests, or auditing test suite quality."
-default_prompt: "Use $tests-quality-review when the task matches the \"Tests Quality Review\" skill."
-triggers:
-  - "tests-quality-review"
-  - "tests quality review"
-  - "Quality review of unit/integration tests — scenario coverage, boundaries, resilience, absence of flakes and test \"magic\""
-capabilities:
-  - "tests"
-  - "quality"
-  - "review"
-tools: []
-invocation:
-  explicit: true
-  implicit: true
-localization:
-  default_locale: "en"
-  available_locales:
-    - "ru"
-    - "en"

package/locales/en/.agents/skills/threat-model-baseline/SKILL.md

@@ -1,210 +0,0 @@
----
-name: threat-model-baseline
-description: Base threat model (threat baseline) for MVP — assets, attack vectors, measures. Considers OWASP risks and roles/permissions.
----
-
-# Skill: Threat Model Baseline
-
-Embed security into the design before coding.
-
-**Sections:**
-1. [Principles](#1-principles)
-2. [Assets](#2-assets)
-3. [Attack Surfaces](#3-attack-surfaces)
-4. [Threat Table](#4-threat-table)
-5. [Risk Matrix](#5-risk-matrix)
-6. [OWASP Top 10 Checklist](#6-owasp)
-7. [Security Requirements](#7-requirements)
-8. [Example](#8-example)
-9. [Output Template](#9-output)
-
----
-
-## 1. Principles
-
-| Principle | Description | Example |
-|---------|---------|--------|
-| **Defense in depth** | Multiple layers of defense | Validation + auth + sanitization |
-| **Least privilege** | Minimal permissions | DB user: readWrite only, no admin |
-| **Input validation at boundaries** | Trust no input | Zod schema on every endpoint |
-| **Secure by default** | Secure "out of the box" | CORS whitelist, Helmet on, strict CSP |
-| **Fail securely** | Error → secure state | Don't expose stack/DB errors |
-| **Audit trail** | Log critical operations | Install, settings change, content create |
-
----
-
-## 2. Assets
-
-What we are protecting:
-
-| Asset | Sensitivity | Impact if compromised |
-|-------|-----------|----------------------|
-| **App settings** | Medium | Widget shows incorrect data |
-| **Sensitive content** | Medium | Unauthorized access to business data |
-| **appInstanceId/tokens** | High | Unauthorized access to any installation |
-| **Wix OAuth tokens** | High | Full API access to user's Wix site |
-| **DB credentials** | Critical | Full data access + modification |
-| **Webhook secrets** | High | Spoofed install/uninstall events |
-| **User PII (email)** | High (GDPR) | Compliance violation, reputation damage |
-| **Admin access** | Critical | Full system control |
-
----
-
-## 3. Attack Surfaces
-
-| Surface | Endpoints/Components | Risk Level |
-|---------|---------------------|-----------|
-| **Public API** | Widget endpoint (no auth) | Medium |
-| **Dashboard API** | Settings/Content CRUD | High |
-| **Webhooks** | Install/Uninstall | High |
-| **Embedded Script** | JS on Wix sites | Medium |
-| **Dashboard UI** | Wix iframe | Medium |
-| **Database** | MongoDB connection | High |
-| **Docker/Infra** | Ports, volumes, certs | Medium |
-
----
-
-## 4. Threat Table
-
-For each threat: description, impact, likelihood, severity, mitigation.
-
-| # | Threat | Surface | Impact | Likelihood | Severity | Mitigation | Status |
-|---|--------|---------|--------|-----------|----------|-----------|--------|
-| T-01 | **NoSQL Injection** | Dashboard API | High | Medium | 🔴 P0 | Safe filter builder, Zod validation, `strictQuery: true` | ☐ |
-| T-02 | **XSS via settings** | Embedded Script | High | Medium | 🔴 P0 | Sanitize all user input before rendering, CSP headers | ☐ |
-| T-03 | **Webhook spoofing** | Webhook endpoint | High | Low | 🟠 P1 | Verify JWT signature, validate payload structure | ☐ |
-| T-04 | **IDOR (Insecure Direct Object Reference)** | Dashboard API | High | Medium | 🔴 P0 | Verify appInstanceId belongs to authenticated user | ☐ |
-| T-05 | **Secrets in code/logs** | All | Critical | Medium | 🔴 P0 | Env vars only, pino redact, .gitignore | ☐ |
-| T-06 | **Brute force enumeration** | Widget endpoint | Medium | Low | 🟡 P2 | Rate limiting on widget endpoint | ☐ |
-| T-07 | **CSRF** | Dashboard API | Medium | Low | 🟠 P1 | SameSite cookies, origin check | ☐ |
-| T-08 | **Dependency supply chain** | npm packages | High | Low | 🟠 P1 | `npm audit`, lockfile, minimal deps | ☐ |
-| T-09 | **Man-in-the-middle** | All HTTP | High | Low | 🟠 P1 | HTTPS everywhere (Caddy), HSTS | ☐ |
-| T-10 | **Embed script injection** | Wix site | High | Low | 🟠 P1 | Script src from trusted origin only, no eval() | ☐ |
-
----
-
-## 5. Risk Matrix
-
-### Impact × Likelihood
-
-```
-              │ Low Likelihood │ Medium │ High
-──────────────┼────────────────┼────────┼──────
-High Impact   │ 🟠 P1          │ 🔴 P0  │ 🔴 P0
-Medium Impact │ 🟡 P2          │ 🟠 P1  │ 🔴 P0
-Low Impact    │ 🟡 P2          │ 🟡 P2  │ 🟠 P1
-```
-
-### Severity actions
-
-| Severity | Action | Timeline |
-|----------|--------|----------|
-| 🔴 **P0** | Must fix before release | This sprint |
-| 🟠 **P1** | Fix in current iteration | Next 2 sprints |
-| 🟡 **P2** | Track in backlog | When resources allow |
-
----
-
-## 6. OWASP Top 10 Checklist
-
-| # | OWASP Category | Relevant? | Mitigation | Status |
-|---|---------------|:---------:|-----------|--------|
-| A01 | **Broken Access Control** | ✅ | Auth middleware, IDOR check, role validation | ☐ |
-| A02 | **Cryptographic Failures** | ✅ | HTTPS, bcrypt for passwords, no secrets in logs | ☐ |
-| A03 | **Injection** | ✅ | Zod validation, safe filter builder, no eval() | ☐ |
-| A04 | **Insecure Design** | ✅ | Threat model (this doc), defense in depth | ☐ |
-| A05 | **Security Misconfiguration** | ✅ | Helmet, CORS whitelist, strict CSP, no debug in prod | ☐ |
-| A06 | **Vulnerable Components** | ✅ | npm audit, lockfile, minimal dependencies | ☐ |
-| A07 | **Auth Failures** | ⬜ | Wix handles auth (OAuth flow) | N/A |
-| A08 | **Data Integrity Failures** | ✅ | Webhook signature verification, input validation | ☐ |
-| A09 | **Logging Failures** | ✅ | Structured logs, request correlation, no PII in logs | ☐ |
-| A10 | **SSRF** | ⬜ | No user-controlled URL fetching | N/A |
-
----
-
-## 7. Security Requirements
-
-### For implementation (DEV gate)
-
-| Requirement | Where | How to verify |
-|------------|-------|--------------|
-| Input validation on every endpoint | API middleware | Unit test: invalid input → 400 |
-| Auth check on protected endpoints | Auth middleware | Test: no token → 401 |
-| IDOR prevention | Controllers | Test: wrong appInstanceId → 403 |
-| Secure error responses | Error handler | Test: 500 → no stack in response |
-| Secrets via env only | Config module | grep: no hardcoded secrets |
-| Helmet + CORS | Express setup | Integration test: check headers |
-| PII redaction in logs | Pino config | Log output: no passwords/tokens |
-
-### For review (REV gate)
-
-| Requirement | How to verify |
-|------------|--------------|
-| No `eval()`, `Function()`, `dangerouslySetInnerHTML` without sanitize | grep |
-| No `eslint-disable-next-line` for security rules | grep |
-| `npm audit` clean (no high/critical) | `npm audit --audit-level=high` |
-| No TODO/FIXME related to security | grep `TODO.*secur\|FIXME.*auth` |
-
----
-
-## 8. Example
-
-```markdown
-# Threat Model: SaaS Admin Panel
-
-## Key Assets
-- Admin credentials (sessions, API tokens)
-- Product/content data, user settings
-- DB credentials, external API keys
-
-## Top Threats (prioritized)
-1. 🔴 T-01: NoSQL injection via admin API → Zod + safe filter
-2. 🔴 T-04: IDOR on resources → verify ownership middleware
-3. 🔴 T-05: Secrets in code/logs → env vars + pino redact
-4. 🟠 T-03: CSRF on state-changing endpoints → SameSite + tokens
-5. 🟠 T-10: XSS in public content → sanitize user input
-
-## OWASP Coverage: 8/10 categories addressed (A07, A10 N/A)
-```
-
----
-
-## 9. Output Template
-
-```markdown
-# Threat Model Baseline: <project-name>
-
-**Date:** YYYY-MM-DD
-**Scope:** <what's covered>
-
-## Assets
-<section 2 table>
-
-## Attack Surfaces
-<section 3 table>
-
-## Threats
-<section 4 table — prioritized by severity>
-
-## Risk Matrix
-<section 5>
-
-## OWASP Top 10
-<section 6 checklist>
-
-## Security Requirements
-<section 7 tables>
-
-## Summary
-- P0 threats: X (must fix before release)
-- P1 threats: Y (fix in current iteration)
-- P2 threats: Z (backlog)
-```
-
----
-
-## See also
-- `$security-baseline-dev` — implementation patterns (Zod, Helmet, bcrypt)
-- `$security-review` — AppSec review checklist
-- `$api-contracts` — auth/error conventions
-- `$observability-logging` — PII redaction, audit logging

package/locales/en/.agents/skills/threat-model-baseline/agents/claude.json

@@ -1,18 +0,0 @@
-{
-  "name": "threat-model-baseline",
-  "display_name": "Threat Model Baseline",
-  "description": "Base threat model (threat baseline) for MVP — assets, attack vectors, measures. Considers OWASP risks and roles/permissions.",
-  "default_prompt": "Use $threat-model-baseline when the task matches the \"Threat Model Baseline\" skill.",
-  "triggers": [
-    "threat-model-baseline",
-    "threat model baseline",
-    "Base threat model (threat baseline) for MVP — assets, attack vectors, measures"
-  ],
-  "capabilities": [
-    "threat",
-    "model",
-    "baseline"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/locales/en/.agents/skills/threat-model-baseline/agents/copilot.json

@@ -1,18 +0,0 @@
-{
-  "name": "threat-model-baseline",
-  "display_name": "Threat Model Baseline",
-  "description": "Base threat model (threat baseline) for MVP — assets, attack vectors, measures. Considers OWASP risks and roles/permissions.",
-  "default_prompt": "Use $threat-model-baseline when the task matches the \"Threat Model Baseline\" skill.",
-  "triggers": [
-    "threat-model-baseline",
-    "threat model baseline",
-    "Base threat model (threat baseline) for MVP — assets, attack vectors, measures"
-  ],
-  "capabilities": [
-    "threat",
-    "model",
-    "baseline"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}