@mrciphersmith/keryx 0.2.71 → 0.2.73

package/src/gdskills/bundled/skills/planning/interviewer/SKILL.claude.md

@@ -1,94 +0,0 @@
----
-description: Critical requirements interviewer — one question at a time with options, structured output
-allowed-tools: Read(*), Glob(*), Bash(git log:*), Bash(git branch:*), Bash(git status:*)
----
-
-## Your task
-
-You are a critical requirements interviewer. Your job is to ask the minimum number of focused questions to gather precise context before a complex task.
-
-**Input:** $ARGUMENTS
-Parse as JSON if provided by a calling skill, or treat as plain topic if entered by user.
-
----
-
-### Step 1 — Establish context
-
-**If called by another skill** (JSON input with `topic`, `goal`, `context`):
-- Parse the provided context
-- Identify what's unknown or ambiguous for the stated `goal`
-- Skip to Step 3
-
-**If called directly by user** (plain text topic):
-- If no topic given, ask: "What are we working on?"
-- Gather basic codebase context:
-  ```
-  git log --oneline -10
-  ls src/ 2>/dev/null || ls
-  ```
-- If significant ambiguity, run the `context-collector` skill first
-
----
-
-### Step 2 — Determine question scope
-
-Based on topic + goal, decide:
-- How many questions are truly needed? (aim for 2-6, max 8)
-- Which questions would most change the approach?
-- Which questions are already answered by context? → **skip those**
-
----
-
-### Step 3 — Interview loop
-
-Ask questions **one at a time**. For each question:
-
-1. Ask the question clearly
-2. Provide options (A/B/C/D) when the answer space is enumerable
-3. Wait for user response
-4. If answer reveals more unknowns, add follow-up
-5. If answer is clear and complete, proceed to next question
-
-Example format:
-```
-**Question 2 of 4:** What is the primary constraint for this feature?
-
-A) Delivery speed (ship in < 1 week)
-B) Performance (must handle 10k+ req/s)
-C) Correctness (zero tolerance for bugs)
-D) Other (describe)
-```
-
----
-
-### Step 4 — Confirm and output
-
-After all questions, output:
-
-```markdown
-## Gathered Context
-
-**Topic:** ...
-**Goal:** ...
-
-**Answers:**
-1. [Question] → [Answer] (confidence: certain/assumption)
-2. ...
-
-**Summary:**
-[2-3 sentences synthesizing the key constraints and requirements]
-
-**Blockers:** [any unresolved critical unknowns, or "none"]
-**Ready to proceed:** yes/no
-```
-
-Then ask: "Does this look correct? Should I proceed?"
-
----
-
-### Rules
-- One question at a time — never list multiple questions
-- Skip questions the context already answers
-- Be critical — focus on questions that change the approach
-- Provide options when the answer space has < 5 clear choices
-- Max 8 questions total

package/src/gdskills/bundled/skills/quality/changelog/SKILL.claude.md

@@ -1,45 +0,0 @@
----
-description: Generate changelog from commits between tags or releases
-allowed-tools: Bash(git log:*), Bash(git tag:*), Bash(git describe:*), Bash(git rev-list:*)
----
-
-## Context
-
-- All tags (latest first): !`git tag --sort=-creatordate | head -20`
-- Commits since last tag: !`git log $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --oneline 2>/dev/null | head -50`
-- Current branch: !`git branch --show-current`
-
-## Your task
-
-Generate changelog for: $ARGUMENTS
-
-- No args → last tag to HEAD
-- One arg (tag) → that tag to HEAD
-- Two args (e.g. `v1.0.0 v1.1.0`) → between those tags
-
-### Steps
-
-1. Determine commit range from arguments
-2. Get full log: `git log <from>..<to> --pretty=format:"%h %s (%an)" --no-merges`
-3. Categorize by conventional commit prefix:
-   - `feat:` → **Features**
-   - `fix:` → **Bug Fixes**
-   - `perf:` → **Performance**
-   - `refactor:` → **Refactoring**
-   - `docs:` → **Documentation**
-   - `chore:` / `build:` / `ci:` → **Maintenance**
-   - `test:` → **Tests**
-   - uncategorized → **Other Changes**
-
-4. Output:
-```markdown
-## [version] — YYYY-MM-DD
-
-### Features
-- Description (abc1234)
-
-### Bug Fixes
-- Description (abc1234)
-```
-
-5. Also output compact version for `gh release create --notes`

package/src/gdskills/bundled/skills/quality/db-migrate/SKILL.claude.md

@@ -1,40 +0,0 @@
----
-description: Create and apply database migrations (Drizzle, Prisma, Knex, raw SQL)
-allowed-tools: Bash(*), Read(*), Write(*), Glob(*)
----
-
-## Context
-
-- Migration tool: !`ls drizzle.config.* knexfile.* prisma/schema.prisma 2>/dev/null | head -3 || echo "none found"`
-- Existing migrations: !`ls migrations/ db/migrations/ prisma/migrations/ 2>/dev/null | tail -10 || echo "none"`
-- DB env: !`grep -E "DATABASE_URL|DB_HOST|POSTGRES" .env 2>/dev/null | sed 's/=.*/=***/' || echo "no .env"`
-- Migration scripts: !`cat package.json 2>/dev/null | python3 -c "import json,sys; d=json.load(sys.stdin); [print(k+':',v) for k,v in d.get('scripts',{}).items() if any(x in k for x in ['migrat','drizzle','prisma'])]" 2>/dev/null || echo "none"`
-
-## Your task
-
-Action: $ARGUMENTS (e.g. `create add_user_sessions_table`, `apply`, `status`, `rollback`)
-
-### Detect tool
-- `drizzle.config.*` → Drizzle ORM
-- `prisma/schema.prisma` → Prisma
-- `knexfile.*` → Knex
-- `migrations/*.sql` → Raw SQL
-
-### `create <name>`
-- Drizzle: `bunx drizzle-kit generate`
-- Prisma: `bunx prisma migrate dev --name <name>`
-- Knex: `npx knex migrate:make <name>`
-- Raw SQL: create `migrations/YYYYMMDD_HHMMSS_<name>.sql` with UP/DOWN, scaffold SQL from name
-
-### `apply` / empty
-- Drizzle: `bunx drizzle-kit migrate`
-- Prisma: `bunx prisma migrate deploy`
-- Knex: `npx knex migrate:latest`
-
-### `status`
-Show applied vs pending
-
-### `rollback`
-Roll back last migration
-
-Always show SQL before running, confirm success after.

package/src/gdskills/bundled/skills/quality/dependency-update/SKILL.claude.md

@@ -1,45 +0,0 @@
----
-description: Update dependencies with compatibility checks and test verification
-allowed-tools: Bash(*), Read(*), Edit(*), Write(*)
----
-
-## Context
-
-- Package manager: !`ls bun.lockb 2>/dev/null && echo "bun" || ls yarn.lock 2>/dev/null && echo "yarn" || echo "npm"`
-- Outdated packages: !`bun outdated 2>/dev/null || npm outdated 2>/dev/null | head -30`
-- Test script: !`cat package.json 2>/dev/null | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('scripts',{}).get('test','none'))" 2>/dev/null`
-
-## Your task
-
-Update dependencies: $ARGUMENTS (empty = all outdated)
-
-### Steps
-
-1. **Snapshot**: `cp package.json package.json.backup`
-
-2. **Categorize** updates: patch / minor (auto) vs major (manual analysis)
-
-3. **Apply patch + minor**:
-```bash
-bun update 2>/dev/null || npx npm-check-updates -u --target minor && npm install
-```
-
-4. **Run tests**:
-```bash
-bun test 2>/dev/null || npm test 2>/dev/null
-```
-If fail → identify breaking update → rollback that package
-
-5. **For major updates** (if in args or --major flag):
-   - Check CHANGELOG/GitHub releases for breaking changes
-   - Report: what needs updating in codebase
-   - Apply only if no breaking changes affect this project
-
-6. **Always update** packages with known CVEs regardless of version jump
-
-7. **Restore on failure**: `cp package.json.backup package.json && bun install`
-
-### Final report
-- Updated: old → new versions
-- Skipped: package + reason
-- Manual action: major changes requiring code updates

package/src/gdskills/bundled/skills/quality/deploy/SKILL.claude.md

@@ -1,42 +0,0 @@
----
-description: Run tests, build, and deploy to target environment
-allowed-tools: Bash(*), Read(*), Edit(*)
----
-
-## Context
-
-- Current branch: !`git branch --show-current`
-- Git status: !`git status --short`
-- Recent commits: !`git log --oneline -5`
-- Config files: !`ls -1 .env* docker-compose*.yml Dockerfile pm2* ecosystem.config.* 2>/dev/null || echo "none"`
-- Package scripts: !`cat package.json 2>/dev/null | python3 -c "import json,sys; d=json.load(sys.stdin); [print(k+':',v) for k,v in d.get('scripts',{}).items()]" || echo "no package.json"`
-
-## Your task
-
-Deploy to environment: $ARGUMENTS (default: production if not specified)
-
-### Phase 1 — Pre-flight
-1. Verify git status — warn if dirty, continue if user confirms
-2. Check target env config exists
-3. Verify required env vars set
-
-### Phase 2 — Tests
-1. Run: `bun test` / `npm test` / `jest` / `vitest` (auto-detect)
-2. **STOP and report if any tests fail — do not deploy**
-
-### Phase 3 — Build
-1. Detect: `bun build` / `docker build` / `npm run build`
-2. **STOP and report if build fails**
-
-### Phase 4 — Deploy
-Detect method:
-- `docker-compose.yml` → `docker compose up -d --build`
-- `Dockerfile` only → build + run container
-- `ecosystem.config.*` → `pm2 reload`
-- Custom deploy script → run it
-
-### Phase 5 — Verify
-1. Check service running: `docker ps` / `pm2 status` / health endpoint
-2. Show last 20 log lines
-
-Report result of each phase clearly.

package/src/gdskills/bundled/skills/quality/perf-check/SKILL.claude.md

@@ -1,48 +0,0 @@
----
-description: Performance analysis — bundle size, slow queries, memory, async patterns
-allowed-tools: Bash(*), Read(*), Glob(*)
----
-
-## Context
-
-- Build output: !`du -sh dist/ build/ .next/ out/ 2>/dev/null | sort -h || echo "not built"`
-- Running containers: !`docker stats --no-stream 2>/dev/null | head -5 || echo "none"`
-- Package manager: !`ls bun.lockb 2>/dev/null && echo "bun" || echo "npm"`
-
-## Your task
-
-Performance analysis for: $ARGUMENTS (or full analysis if empty)
-
-### 1. Bundle size (frontend)
-List top 10 largest files in dist/build. Flag > 500KB uncompressed or > 150KB gzipped.
-
-### 2. Dependency weight
-```bash
-du -sh node_modules/*/ 2>/dev/null | sort -hr | head -20
-```
-
-### 3. Backend patterns (static analysis)
-Scan source files for:
-- `await` inside `forEach`/`map` loops → should use `Promise.all`
-- `SELECT *` patterns → should project columns
-- Missing `.limit()` on list queries
-- Loop with DB call (N+1 pattern)
-
-```bash
-grep -rn "\.forEach\|\.map" --include="*.ts" src/ 2>/dev/null | grep -i await | head -20
-grep -rn "SELECT \*" --include="*.ts" --include="*.sql" . 2>/dev/null | grep -v node_modules | head -10
-```
-
-### 4. Memory (if running)
-```bash
-docker stats --no-stream 2>/dev/null
-pm2 list 2>/dev/null
-```
-
-### Report
-Group by priority:
-- **Critical** (> 50% improvement possible)
-- **High** (significant impact)
-- **Medium** (worth fixing)
-
-Include file:line references.

package/src/gdskills/bundled/skills/quality/security-audit/SKILL.claude.md

@@ -1,40 +0,0 @@
----
-description: Security audit — npm/bun audit, dependency vulnerabilities, secrets scan
-allowed-tools: Bash(*)
----
-
-## Context
-
-- Package manager: !`ls bun.lockb yarn.lock pnpm-lock.yaml package-lock.json 2>/dev/null | head -1 || echo "unknown"`
-- Bun version: !`bun --version 2>/dev/null || echo "n/a"`
-- Dependencies: !`cat package.json 2>/dev/null | python3 -c "import json,sys; d=json.load(sys.stdin); print(len(d.get('dependencies',{})), 'prod,', len(d.get('devDependencies',{})), 'dev')" 2>/dev/null || echo "unknown"`
-
-## Your task
-
-Run a comprehensive security audit.
-
-### Step 1 — Dependency vulnerabilities
-- `bun.lockb` → `bun audit`
-- `package-lock.json` → `npm audit --json`
-- `yarn.lock` → `yarn audit`
-
-Group: **critical → high → moderate → low**
-
-### Step 2 — Outdated packages
-`bun outdated 2>/dev/null || npm outdated` — flag 2+ major versions behind
-
-### Step 3 — Secrets scan
-```bash
-git log --all --full-history -- "*.env" "*.key" "*.pem" 2>/dev/null | head -20
-grep -r "password\s*=\s*['\"][^'\"]\|api_key\s*=\s*['\"][^'\"]\|secret\s*=\s*['\"][^'\"]" \
-  --include="*.ts" --include="*.js" -l . 2>/dev/null | grep -v node_modules
-```
-
-### Step 4 — Docker image scan (if Dockerfile present)
-`docker scout cves $(docker build -q .) 2>/dev/null || echo "Docker Scout not available"`
-
-### Report
-- Total by severity
-- Top 3 critical/high with CVE
-- Immediate actions
-- Packages safe to ignore (dev-only)

package/src/gdskills/bundled/skills/quality/test-gen/SKILL.claude.md

@@ -1,30 +0,0 @@
----
-description: Auto-generate tests for a specified file or module
-allowed-tools: Bash(*), Read(*), Write(*), Glob(*)
----
-
-## Context
-
-- Test framework: !`cat package.json 2>/dev/null | python3 -c "import json,sys; d=json.load(sys.stdin); deps={**d.get('dependencies',{}),**d.get('devDependencies',{})}; print(next((k for k in ['bun:test','vitest','jest'] if k in str(deps)), 'unknown'))" 2>/dev/null || echo "unknown"`
-- Existing tests: !`find . -name "*.test.ts" -not -path "*/node_modules/*" 2>/dev/null | head -5 || echo "none"`
-- Sample test style: !`find . -name "*.test.ts" -not -path "*/node_modules/*" 2>/dev/null | head -1 | xargs head -30 2>/dev/null || echo "none"`
-
-## Your task
-
-Generate tests for: $ARGUMENTS
-
-1. **Read** the target file completely
-2. **Check** for existing tests (`<name>.test.ts` or `__tests__/<name>.ts`)
-3. **Plan** test cases:
-   - Happy path for each export
-   - Edge cases: empty, null, boundary values
-   - Error cases: invalid input, exceptions, DB errors
-   - API routes: each method + auth + 200/400/401/404/500
-4. **Write** tests matching existing style:
-   - bun:test → `import { describe, test, expect, mock } from "bun:test"`
-   - jest/vitest → respective imports
-   - Mock external dependencies at correct boundary
-5. **Write** test file to `<name>.test.ts` (same dir) or `__tests__/` if that's the convention
-6. **Run** and fix: `bun test <file> 2>/dev/null || npx jest <file> 2>/dev/null`
-
-Report: tests generated, estimated coverage, cases needing manual work.

package/src/gdskills/bundled/skills/review/code-b091-review/SKILL.codex.md

@@ -1,209 +0,0 @@
----
-name: code-b091-review
-description: "Performs strict b091-style code review following code-review-b091-profile.mdc. Reviews current branch changes from merge-base. Direct, no-fluff feedback focused on logic correctness. Use when: b091 review requested, strict validation needed."
-triggers:
-  - "Review as b091"
-  - "b091 style review"
-  - "b091 review"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "review"
-  compatible_harnesses: "cursor,codex,zed,opencode"
-license: "MIT"
----
-
-
-# Code Review as b091 (только текущая ветка)
-
-## Workflow
-
-Copy this checklist and track progress:
-
-```
-b091 Review Progress:
-- [ ] Step 1: Determine parent branch and calculate merge-base
-- [ ] Step 2: Collect git diff (committed + local changes)
-- [ ] Step 3: Apply b091 principles (logic in correct layer, no ducttape)
-- [ ] Step 4: Check types (no any, typed mocks)
-- [ ] Step 5: Verify conventions (currentState, I prefix, etc.)
-- [ ] Step 6: Challenge all assumptions
-- [ ] Step 7: Generate direct report with patches
-```
-
-## Обязательные правила
-
-1) **Скоуп по умолчанию (без commit hash/range в запросе)**: ревью включает **все** изменения в текущей ветке от точки ответвления (merge-base) от родительской ветки:
-   - закоммиченные (`BASE_SHA..HEAD`)
-   - локальные незакоммиченные (staged/unstaged/untracked)
-2) **Скоуп при явном commit hash/range**: если пользователь явно передал hash или диапазон, ревьюй только запрошенный диапазон; локальные незакоммиченные изменения не добавляй, если это отдельно не попросили.
-3) **Стиль/принципы b091**: ревью строго по `.metaproject/rules/core/code-review-b091-profile.mdc` (разделы правил и промпт).
-4) **Результат**: подробный отчёт по проблемам с объяснением и предложением исправлений (минимальные патчи там, где это просто).
-
-## Определение parent ref (детерминированно, именно родитель ветки)
-
-Используй первый существующий вариант:
-
-1. `origin/main`
-2. `origin/master`
-3. `main`
-4. `master`
-5. `@{upstream}` **только если это не текущая feature-ветка**
-
-```bash
-BRANCH="$(git rev-parse --abbrev-ref HEAD)"
-UPSTREAM_REF="$(git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || true)"
-
-PARENT=""
-if git rev-parse --verify -q "origin/main" >/dev/null; then
-  PARENT="origin/main"
-elif git rev-parse --verify -q "origin/master" >/dev/null; then
-  PARENT="origin/master"
-elif git rev-parse --verify -q "main" >/dev/null; then
-  PARENT="main"
-elif git rev-parse --verify -q "master" >/dev/null; then
-  PARENT="master"
-elif [ -n "$UPSTREAM_REF" ] && [ "$UPSTREAM_REF" != "$BRANCH" ] && [ "$UPSTREAM_REF" != "origin/$BRANCH" ]; then
-  PARENT="@{upstream}"
-else
-  echo "Cannot determine parent ref" >&2
-  exit 1
-fi
-
-BASE_SHA="$(git merge-base HEAD "$PARENT")"
-```
-
-## Команды, чтобы собрать “срез” для ревью
-
-### A) Режим по умолчанию (пользователь НЕ дал hash/range)
-
-```bash
-git status
-
-# Закоммиченная часть ветки
-git log --oneline "${BASE_SHA}..HEAD"
-git diff --stat "${BASE_SHA}..HEAD"
-git diff --name-status "${BASE_SHA}..HEAD"
-git diff "${BASE_SHA}..HEAD"
-
-# Полный текущий срез от merge-base до рабочего дерева:
-# включает commit'ы + staged + unstaged
-# (untracked смотри через git status / git ls-files)
-git diff --stat "${BASE_SHA}"
-git diff --name-status "${BASE_SHA}"
-git diff "${BASE_SHA}"
-git ls-files --others --exclude-standard
-```
-
-### B) Режим с явным hash/range
-
-Если пользователь дал конкретный hash/range, используй его буквально:
-
-```bash
-# Примеры:
-git show --stat --name-status --patch <COMMIT_SHA>
-git log --oneline <FROM_SHA>..<TO_SHA>
-git diff --stat <FROM_SHA>..<TO_SHA>
-git diff --name-status <FROM_SHA>..<TO_SHA>
-git diff <FROM_SHA>..<TO_SHA>
-```
-
-## Как ревьюить (по b091)
-
-Применяй чек-лист и промпт из `.metaproject/rules/core/code-review-b091-profile.mdc`. Ключевые акценты b091:
-
-- Логика должна жить в правильном слое (часто — в store), чтобы её можно было нормально тестировать.
-- Против “patch/glue/ducttape”: требуй чинить причину, а не маскировать симптомы.
-- В новом коде никаких `any`, `as any`, небезопасных кастов; моки — типизированные и не наследуются от реальных реализаций.
-- Не плодить дублирование правил/проверок: один источник правды, переиспользовать сеттеры/методы.
-- Конвенции проекта обязательны (например, `currentState`, `I` для интерфейсов, консистентные типы).
-- Магические числа / `setTimeout(0)` / "страшные" хаки — только с чётким "почему", либо перепроектировать.
-- **Accessibility модификаторы в сторах**: inter-store callbacks (`onChangeX`, `onFireX`, `handleX`, `syncX`) обязаны быть `private`. Публичный метод допустим только если он вызывается из React-компонента. Спросить: "Вызывается ли этот метод из JSX?" Если нет — `private`.
-- С MobX по умолчанию **не добавлять** `useCallback`/`useMemo` без явной необходимости.
-- Предложения должны проходить линт; не нитпикать автоформатирование.
-- Не раздувать scope: большие рефакторы “not today”, если вне задачи.
-
-## Формат вывода (подробный отчёт + тон b091)
-
-Пиши по-русски, но допускай короткие b091-маркеры (например, `not today ;P`, “ducttape”, “broken thinking”) только по делу и без перехода на личности.
-
-Используй структуру:
-
-```markdown
-## Вердикт (b091)
-<OK / needs work / fundamentally wrong> + 1–3 самых важных тезиса.
-
-## Скоуп ревью (только текущая ветка)
-- Ветка: `<BRANCH>`
-- Parent ref: `<PARENT>`
-- Merge-base: `<BASE_SHA>`
-- Режим скоупа: `<default-with-uncommitted | explicit-hash-range>`
-- Коммиты (merge-base..HEAD): <N>
-- Изменённые файлы: <список или количество>
-
-## Находки (подробно)
-### Архитектура и место логики
-<находки>
-
-### Типы, касты, моки
-<находки>
-
-### Корректность и семантика состояний
-<находки>
-
-### Конвенции и консистентность
-<находки>
-
-### Линт/формат/шум
-<находки>
-
-### UX/edge cases
-<находки>
-
-### Тестируемость
-<находки>
-
-## Предложенные исправления (patches)
-<минимальные unified diff-патчи для очевидных правок>
-```
-
-### Формат каждой находки (обязательно)
-
-Для каждой находки укажи:
-
-- **Severity**: `blocker` / `major` / `minor`
-- **Location**: путь файла + релевантный hunk/фрагмент из diff
-- **Problem**: что не так
-- **Why it matters**: почему это важно (корректность/тестируемость/конвенции/поддерживаемость)
-- **Suggested fix**: что конкретно сделать (точечно, без раздувания scope)
-- **Optional patch**: если фикс простой — unified diff
-
-Пример блока патча:
-
-```diff
-diff --git a/path/file.ts b/path/file.ts
-index 0000000..1111111 100644
---- a/path/file.ts
-+++ b/path/file.ts
-@@ -1,3 +1,3 @@
--const x = 1;
-+const x = 2;
-```
-
----
-
-## Job Context Awareness
-
-When dispatched by `job-orchestrator` as part of a job pipeline, the prompt MAY include:
-
-```
-JOB_NAME:     <job-name>
-CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
-```
-
-If provided and the file exists, read the context document before starting the review. Use it to:
-- Understand which libraries and patterns were intentionally chosen for the implementation
-- Avoid flagging correct library usage as issues
-- Provide more accurate findings by understanding the project's architectural decisions
-
-If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.