@mrciphersmith/keryx 0.2.97 → 0.2.99

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

@@ -1,84 +0,0 @@
----
-name: changelog
-description: "Use when generating a changelog, release notes, or summarizing what changed between tags, versions, or date ranges."
-triggers:
-  - "/changelog"
-  - "Generate changelog"
-  - "What changed since"
-  - "Release notes"
-  - "What's new"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "workflow"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Changelog Generator
-
-Generate structured changelog from git history.
-
-## Arguments
-
-- `/changelog` — latest tag to HEAD
-- `/changelog v1.0..v2.0` — between tags
-- `/changelog --since 2024-01-01` — since date
-- `/changelog --output <file>` — write to file
-- `/changelog --prepend` — prepend to existing CHANGELOG.md
-- `/changelog --format compact` — one-liner per change
-
-## Workflow
-
-### Step 1: Determine Range
-1. `git tag --sort=-version:refname` — list recent tags
-2. Default: from latest tag to HEAD
-3. Between tags or since date if specified
-
-### Step 2: Collect Commits
-```bash
-git log <range> --pretty=format:"%H|%s|%an|%ad" --date=short
-```
-
-### Step 3: Parse & Classify
-
-| Prefix | Section |
-|--------|---------|
-| feat: | Features |
-| fix: | Bug Fixes |
-| perf: | Performance |
-| refactor: | Refactoring |
-| docs: | Documentation |
-| test: | Tests |
-| chore: | Maintenance |
-| BREAKING CHANGE | Breaking Changes |
-
-Extract scope, PR references `(#123)`, issue references `fixes #456`.
-
-### Step 4: Enrich (optional)
-If `gh` CLI available: fetch PR titles for merge commits, get authors and labels.
-
-### Step 5: Generate Output
-
-```markdown
-# Changelog
-
-## [v1.3.0] - 2024-03-15
-
-### Breaking Changes
-- **auth**: Remove deprecated OAuth1 support (#234)
-
-### Features
-- **api**: Add batch processing endpoint (#220)
-
-### Bug Fixes
-- **db**: Fix connection pool leak under load (#228)
-```
-
-## Rules
-
-- Deduplicate identical commit messages
-- Skip merge commits (use PR title instead)
-- If no conventional commits found, fall back to plain list by date
-- Breaking changes always go first
-- One line per change

package/src/gdskills/bundled/skills/quality/commit/SKILL.codex.md

@@ -1,66 +0,0 @@
----
-name: commit
-description: "Use when committing code changes and a well-structured conventional commit message is needed, with optional amend or selective staging."
-triggers:
-  - "/commit"
-  - "Commit changes"
-  - "Commit this"
-  - "Save changes"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "workflow"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Smart Commit
-
-Create well-structured git commits from current changes.
-
-## Workflow
-
-### Phase 1: Analyze Changes
-1. Run `git status` and `git diff --staged` and `git diff` to understand all changes
-2. Run `git log --oneline -5` to match the repo's commit message style
-3. Check for conventional commit patterns in history
-
-### Phase 2: Stage Files
-If nothing is staged, intelligently stage relevant files:
-- Stage modified and new files that are part of the logical change
-- **NEVER** stage `.env`, credentials, secrets, or large binary files
-- Prefer `git add <specific files>` over `git add -A`
-- Ask the user before staging untracked files that look unrelated to recent work
-
-### Phase 3: Generate Commit Message
-Analyze the diff and generate a concise commit message:
-- First line: `<type>(<scope>): <description>` (under 72 chars)
-- Types: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`, `style:`, `perf:`
-- Optional body: explain "why" not "what" (the diff shows "what")
-- **NEVER** add "Co-Authored-By" or any co-authorship lines
-
-### Phase 4: Commit
-Create the commit using heredoc format:
-```bash
-git commit -m "$(cat <<'EOF'
-type(scope): description
-EOF
-)"
-```
-
-### Phase 5: Verify
-Show the result: `git log --oneline -1` and `git status`
-
-## Arguments
-
-- `/commit` — auto-generate message from diff
-- `/commit <message>` — use provided message as-is
-- `/commit --amend` — amend the last commit (only when explicitly requested)
-- `/commit -a` — stage all modified files before committing
-
-## Rules
-
-- NEVER use `--no-verify` or skip hooks
-- NEVER add Co-Authored-By lines
-- If pre-commit hook fails: fix the issue, re-stage, create a NEW commit (don't amend)
-- Follow existing commit message conventions in the repository

package/src/gdskills/bundled/skills/quality/commit/SKILL.cursor.md

@@ -1,66 +0,0 @@
----
-name: commit
-description: "Use when committing code changes and a well-structured conventional commit message is needed, with optional amend or selective staging."
-triggers:
-  - "/commit"
-  - "Commit changes"
-  - "Commit this"
-  - "Save changes"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "workflow"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Smart Commit
-
-Create well-structured git commits from current changes.
-
-## Workflow
-
-### Phase 1: Analyze Changes
-1. Run `git status` and `git diff --staged` and `git diff` to understand all changes
-2. Run `git log --oneline -5` to match the repo's commit message style
-3. Check for conventional commit patterns in history
-
-### Phase 2: Stage Files
-If nothing is staged, intelligently stage relevant files:
-- Stage modified and new files that are part of the logical change
-- **NEVER** stage `.env`, credentials, secrets, or large binary files
-- Prefer `git add <specific files>` over `git add -A`
-- Ask the user before staging untracked files that look unrelated to recent work
-
-### Phase 3: Generate Commit Message
-Analyze the diff and generate a concise commit message:
-- First line: `<type>(<scope>): <description>` (under 72 chars)
-- Types: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`, `style:`, `perf:`
-- Optional body: explain "why" not "what" (the diff shows "what")
-- **NEVER** add "Co-Authored-By" or any co-authorship lines
-
-### Phase 4: Commit
-Create the commit using heredoc format:
-```bash
-git commit -m "$(cat <<'EOF'
-type(scope): description
-EOF
-)"
-```
-
-### Phase 5: Verify
-Show the result: `git log --oneline -1` and `git status`
-
-## Arguments
-
-- `/commit` — auto-generate message from diff
-- `/commit <message>` — use provided message as-is
-- `/commit --amend` — amend the last commit (only when explicitly requested)
-- `/commit -a` — stage all modified files before committing
-
-## Rules
-
-- NEVER use `--no-verify` or skip hooks
-- NEVER add Co-Authored-By lines
-- If pre-commit hook fails: fix the issue, re-stage, create a NEW commit (don't amend)
-- Follow existing commit message conventions in the repository

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

@@ -1,66 +0,0 @@
----
-name: db-migrate
-description: "Use when creating, applying, rolling back, or checking the status of database migrations."
-triggers:
-  - "/db-migrate"
-  - "Create migration"
-  - "Run migrations"
-  - "Migration status"
-  - "Rollback migration"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "database"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Database Migration
-
-Create, apply, and manage database migrations.
-
-## Arguments
-
-- `/db-migrate create <name>` — create new migration
-- `/db-migrate apply` — apply pending migrations
-- `/db-migrate status` — show migration status
-- `/db-migrate rollback` — rollback last migration
-
-## Workflow
-
-### Step 1: Detect ORM/Migration Tool
-Search for: `prisma/schema.prisma`, `ormconfig.*`, `data-source.ts`, `knexfile.*`, `.sequelizerc`, `drizzle.config.ts`, `alembic.ini`, `migrations/` with raw SQL.
-
-### Step 2: Execute Command
-
-**Create:**
-
-| Tool | Command |
-|------|---------|
-| Prisma | `npx prisma migrate dev --name <name>` |
-| TypeORM | `npx typeorm migration:generate -n <name>` |
-| Knex | `npx knex migrate:make <name>` |
-| Sequelize | `npx sequelize-cli migration:generate --name <name>` |
-| Drizzle | `npx drizzle-kit generate:migration --name <name>` |
-| Alembic | `alembic revision --autogenerate -m "<name>"` |
-
-**Apply / Status / Rollback** — analogous commands per tool.
-
-### Step 3: If Creating — Help Write Migration
-1. Ask what schema changes are needed (or infer from context)
-2. For schema-based ORMs — edit schema first, then generate
-3. For code-based migrations — generate template and fill in up/down
-4. Review generated migration before applying
-
-### Step 4: Apply & Verify
-1. Show migration SQL preview if possible
-2. Apply migration
-3. Verify with status command
-
-## Rules
-
-- ALWAYS show migration content before applying in production
-- ALWAYS confirm before rollback operations
-- NEVER apply to production without explicit confirmation
-- For destructive operations (drop table, remove column), double-warn
-- If ORM can't be detected, ask the user

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

@@ -1,66 +0,0 @@
----
-name: db-migrate
-description: "Use when creating, applying, rolling back, or checking the status of database migrations."
-triggers:
-  - "/db-migrate"
-  - "Create migration"
-  - "Run migrations"
-  - "Migration status"
-  - "Rollback migration"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "database"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Database Migration
-
-Create, apply, and manage database migrations.
-
-## Arguments
-
-- `/db-migrate create <name>` — create new migration
-- `/db-migrate apply` — apply pending migrations
-- `/db-migrate status` — show migration status
-- `/db-migrate rollback` — rollback last migration
-
-## Workflow
-
-### Step 1: Detect ORM/Migration Tool
-Search for: `prisma/schema.prisma`, `ormconfig.*`, `data-source.ts`, `knexfile.*`, `.sequelizerc`, `drizzle.config.ts`, `alembic.ini`, `migrations/` with raw SQL.
-
-### Step 2: Execute Command
-
-**Create:**
-
-| Tool | Command |
-|------|---------|
-| Prisma | `npx prisma migrate dev --name <name>` |
-| TypeORM | `npx typeorm migration:generate -n <name>` |
-| Knex | `npx knex migrate:make <name>` |
-| Sequelize | `npx sequelize-cli migration:generate --name <name>` |
-| Drizzle | `npx drizzle-kit generate:migration --name <name>` |
-| Alembic | `alembic revision --autogenerate -m "<name>"` |
-
-**Apply / Status / Rollback** — analogous commands per tool.
-
-### Step 3: If Creating — Help Write Migration
-1. Ask what schema changes are needed (or infer from context)
-2. For schema-based ORMs — edit schema first, then generate
-3. For code-based migrations — generate template and fill in up/down
-4. Review generated migration before applying
-
-### Step 4: Apply & Verify
-1. Show migration SQL preview if possible
-2. Apply migration
-3. Verify with status command
-
-## Rules
-
-- ALWAYS show migration content before applying in production
-- ALWAYS confirm before rollback operations
-- NEVER apply to production without explicit confirmation
-- For destructive operations (drop table, remove column), double-warn
-- If ORM can't be detected, ask the user

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

@@ -1,81 +0,0 @@
----
-name: dependency-update
-description: "Use when checking for outdated packages or upgrading dependencies with compatibility verification."
-triggers:
-  - "/dependency-update"
-  - "Update dependencies"
-  - "Upgrade packages"
-  - "Check outdated"
-  - "Update npm packages"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "maintenance"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Dependency Update
-
-Safely update project dependencies with compatibility checks.
-
-## Arguments
-
-- `/dependency-update` — check and propose updates
-- `/dependency-update --patch` — only patch updates (safe)
-- `/dependency-update --minor` — patch + minor
-- `/dependency-update --all` — all including major
-- `/dependency-update --dry-run` — show what would update
-- `/dependency-update <package>` — update specific package
-
-## Workflow
-
-### Step 1: Check Outdated
-```bash
-npm outdated --json
-```
-
-### Step 2: Classify by Risk
-
-| Type | Risk | Action |
-|------|------|--------|
-| Patch (1.0.0 → 1.0.1) | Low | Batch update |
-| Minor (1.0.0 → 1.1.0) | Medium | Update & test |
-| Major (1.0.0 → 2.0.0) | High | One-by-one with tests |
-
-### Step 3: Present Update Plan
-Show grouped list with risk levels. Get user confirmation.
-
-### Step 4: Execute
-
-**Patch (batch):** `npm update`
-
-**Minor (batch):** `npm install pkg1@latest pkg2@latest && npm test`
-
-**Major (one at a time):**
-1. Check changelog/migration guide
-2. `npm install <package>@latest`
-3. Run lint + type-check + tests
-4. If fails (max 2 fix tries) → rollback
-5. If passes → commit: `chore(deps): update <package> to v<version>`
-
-### Step 5: Post-update Verification
-```bash
-npm run lint && npx tsc --noEmit && npm test && npm run build
-```
-
-### Step 6: Report
-```
-✅ Updated: 15 packages (10 patch, 4 minor, 1 major)
-⚠️ Skipped: 2 packages (tests fail)
-📋 Commits: 3
-```
-
-## Rules
-
-- NEVER update all major versions at once — one by one
-- ALWAYS run tests after each major update
-- Rollback if tests fail
-- Commit each group separately
-- Respect pinned versions
-- Check peer dependency warnings

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

@@ -1,81 +0,0 @@
----
-name: dependency-update
-description: "Use when checking for outdated packages or upgrading dependencies with compatibility verification."
-triggers:
-  - "/dependency-update"
-  - "Update dependencies"
-  - "Upgrade packages"
-  - "Check outdated"
-  - "Update npm packages"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "maintenance"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Dependency Update
-
-Safely update project dependencies with compatibility checks.
-
-## Arguments
-
-- `/dependency-update` — check and propose updates
-- `/dependency-update --patch` — only patch updates (safe)
-- `/dependency-update --minor` — patch + minor
-- `/dependency-update --all` — all including major
-- `/dependency-update --dry-run` — show what would update
-- `/dependency-update <package>` — update specific package
-
-## Workflow
-
-### Step 1: Check Outdated
-```bash
-npm outdated --json
-```
-
-### Step 2: Classify by Risk
-
-| Type | Risk | Action |
-|------|------|--------|
-| Patch (1.0.0 → 1.0.1) | Low | Batch update |
-| Minor (1.0.0 → 1.1.0) | Medium | Update & test |
-| Major (1.0.0 → 2.0.0) | High | One-by-one with tests |
-
-### Step 3: Present Update Plan
-Show grouped list with risk levels. Get user confirmation.
-
-### Step 4: Execute
-
-**Patch (batch):** `npm update`
-
-**Minor (batch):** `npm install pkg1@latest pkg2@latest && npm test`
-
-**Major (one at a time):**
-1. Check changelog/migration guide
-2. `npm install <package>@latest`
-3. Run lint + type-check + tests
-4. If fails (max 2 fix tries) → rollback
-5. If passes → commit: `chore(deps): update <package> to v<version>`
-
-### Step 5: Post-update Verification
-```bash
-npm run lint && npx tsc --noEmit && npm test && npm run build
-```
-
-### Step 6: Report
-```
-✅ Updated: 15 packages (10 patch, 4 minor, 1 major)
-⚠️ Skipped: 2 packages (tests fail)
-📋 Commits: 3
-```
-
-## Rules
-
-- NEVER update all major versions at once — one by one
-- ALWAYS run tests after each major update
-- Rollback if tests fail
-- Commit each group separately
-- Respect pinned versions
-- Check peer dependency warnings

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

@@ -1,70 +0,0 @@
----
-name: deploy
-description: "Use when deploying to any environment (staging, production) or when a deployment pipeline needs to run."
-triggers:
-  - "/deploy"
-  - "Deploy to"
-  - "Push to production"
-  - "Deploy staging"
-  - "Ship it"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "ops"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Deploy
-
-Automated deployment pipeline with pre-flight checks.
-
-## Arguments
-
-- `/deploy` — deploy to staging (default)
-- `/deploy production` — deploy to production (requires confirmation)
-- `/deploy --skip-tests` — skip test phase
-- `/deploy --dry-run` — show what would happen without executing
-- `/deploy <env> --rollback` — rollback to previous version
-
-## Workflow
-
-### Phase 1: Detect Project Type & Deploy Target
-1. Read `package.json`, `docker-compose.yml`, `Dockerfile`, `vercel.json`, `railway.json`, `ecosystem.config.js`, `Makefile`
-2. Detect stack: Node/Bun/Python/Go/Docker
-3. Detect deploy target: Docker Compose, PM2, SSH, Vercel, Railway, custom script
-4. Determine environment from argument (default: staging)
-
-### Phase 2: Pre-flight Checks
-Run in parallel where possible:
-1. **Git status**: working tree clean (warn if dirty)
-2. **Branch check**: correct branch for target env (production → main/master)
-3. **Tests**: `npm test` / `pytest` / `go test ./...` (skip with `--skip-tests`)
-4. **Lint**: `npm run lint` if available
-5. **Type-check**: `npx tsc --noEmit` if TypeScript
-6. **Build**: `npm run build` / `docker build`
-
-If any check fails → stop and report.
-
-### Phase 3: Deploy
-
-| Target | Command |
-|--------|---------|
-| Docker Compose | `docker compose build && docker compose up -d` |
-| PM2 | `pm2 reload ecosystem.config.js --env <env>` |
-| SSH | `ssh <host> "cd <path> && git pull && npm install && npm run build && pm2 reload all"` |
-| Vercel | `vercel --prod` or `vercel` (preview) |
-| Custom | `npm run deploy:<env>` or `make deploy` |
-
-### Phase 4: Post-deploy Verification
-1. Health check: curl the health endpoint
-2. Check logs for startup errors
-3. Report: deployed version, environment, status
-
-## Rules
-
-- ALWAYS require explicit confirmation for production deploys
-- NEVER deploy with failing tests (unless `--skip-tests`)
-- NEVER deploy from dirty working tree without warning
-- Show summary before deploying: branch, env, target, version
-- If deploy target can't be detected, ask the user

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

@@ -1,70 +0,0 @@
----
-name: deploy
-description: "Use when deploying to any environment (staging, production) or when a deployment pipeline needs to run."
-triggers:
-  - "/deploy"
-  - "Deploy to"
-  - "Push to production"
-  - "Deploy staging"
-  - "Ship it"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "ops"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Deploy
-
-Automated deployment pipeline with pre-flight checks.
-
-## Arguments
-
-- `/deploy` — deploy to staging (default)
-- `/deploy production` — deploy to production (requires confirmation)
-- `/deploy --skip-tests` — skip test phase
-- `/deploy --dry-run` — show what would happen without executing
-- `/deploy <env> --rollback` — rollback to previous version
-
-## Workflow
-
-### Phase 1: Detect Project Type & Deploy Target
-1. Read `package.json`, `docker-compose.yml`, `Dockerfile`, `vercel.json`, `railway.json`, `ecosystem.config.js`, `Makefile`
-2. Detect stack: Node/Bun/Python/Go/Docker
-3. Detect deploy target: Docker Compose, PM2, SSH, Vercel, Railway, custom script
-4. Determine environment from argument (default: staging)
-
-### Phase 2: Pre-flight Checks
-Run in parallel where possible:
-1. **Git status**: working tree clean (warn if dirty)
-2. **Branch check**: correct branch for target env (production → main/master)
-3. **Tests**: `npm test` / `pytest` / `go test ./...` (skip with `--skip-tests`)
-4. **Lint**: `npm run lint` if available
-5. **Type-check**: `npx tsc --noEmit` if TypeScript
-6. **Build**: `npm run build` / `docker build`
-
-If any check fails → stop and report.
-
-### Phase 3: Deploy
-
-| Target | Command |
-|--------|---------|
-| Docker Compose | `docker compose build && docker compose up -d` |
-| PM2 | `pm2 reload ecosystem.config.js --env <env>` |
-| SSH | `ssh <host> "cd <path> && git pull && npm install && npm run build && pm2 reload all"` |
-| Vercel | `vercel --prod` or `vercel` (preview) |
-| Custom | `npm run deploy:<env>` or `make deploy` |
-
-### Phase 4: Post-deploy Verification
-1. Health check: curl the health endpoint
-2. Check logs for startup errors
-3. Report: deployed version, environment, status
-
-## Rules
-
-- ALWAYS require explicit confirmation for production deploys
-- NEVER deploy with failing tests (unless `--skip-tests`)
-- NEVER deploy from dirty working tree without warning
-- Show summary before deploying: branch, env, target, version
-- If deploy target can't be detected, ask the user