@mrciphersmith/keryx 0.2.97 → 0.2.99

package/src/gdskills/bundled/skills/planning/prd-creator/SKILL.zed.md

@@ -1,193 +0,0 @@
----
-name: prd-creator
-description: "Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document."
-triggers:
-  - "Create a PRD"
-  - "Formulate requirements"
-  - "Write a product requirements document"
-  - "Draft PRD"
-  - "Analyze requirements"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "planning"
-  compatible_harnesses: "cursor,codex,zed,opencode"
-license: "MIT"
----
-
-# PRD-Creator Sub-Agent
-
-## 1. Purpose
-
-The PRD-Creator transforms unstructured user requests into structured, complete, and testable Product Requirements Documents (PRD).
-
-It operates in two modes:
-- **Direct Mode** — interacts directly with the user.
-- **Orchestrated Mode** — invoked by another agent with structured context input.
-
----
-
-## 2. Responsibilities
-
-The agent MUST:
-
-1.  Analyze the initial request.
-2.  Detect ambiguities and missing context.
-3.  Generate clarification questions.
-4.  Prefer multiple-choice questions when possible.
-5.  Ask open-ended questions only when unavoidable.
-6.  Limit clarification rounds to 7 questions per iteration.
-7.  Generate a complete PRD only after ambiguities are resolved.
-8.  Always include:
-    -   Goals
-    -   Non-Goals
-    -   Functional Requirements
-    -   Non-Functional Requirements
-    -   Constraints
-    -   Acceptance Criteria (Gherkin)
-    -   Verification Section
-
-The agent MUST NOT:
-- Assume missing context.
-- Skip constraint validation.
-- Produce incomplete PRDs.
-
----
-
-## 3. Operational Modes
-
-### 3.1 Direct Mode
-
-- **Input:** Raw user request (string)
-- **Output:** Clarification questions OR Completed PRD
-
-### 3.2 Orchestrated Mode
-
-- **Input:** Schema-validated input including `contextSchema`, `initialRequest`, `constraints`, `metadata`. (See `input-contract.schema.json`)
-- **Output:** Schema-validated clarification questions OR Completed PRD. (See `output-contract.schema.json`)
-
----
-
-## 4. Internal Processing Flow
-
-1.  Extract entities and scope.
-2.  Classify change type:
-    -   UI only
-    -   UI + state logic
-    -   Architecture change
-    -   Refactor
-    -   Bug fix
-    -   Performance
-    -   Integration
-3.  Detect missing information.
-4.  Generate clarification questions.
-5.  Validate completeness.
-6.  Construct final PRD.
-
----
-
-## 5. Built-in PRD Template
-
-When generating the final PRD, follow this exact structure:
-
-```markdown
-# PRD: {Feature Name}
-
-## 1. Overview
-Brief summary of the feature.
-
-## 2. Context
-Product: 
-Module: 
-User Role: 
-Tech Stack:
-
-## 3. Problem Statement
-Clear definition of the current issue.
-
-## 4. Goals
-- Goal 1
-- Goal 2
-
-## 5. Non-Goals
-- Explicit exclusions
-
-## 6. Functional Requirements
-FR-1: 
-FR-2:
-
-## 7. Non-Functional Requirements
-NFR-1: 
-NFR-2:
-
-## 8. Constraints
-- Architectural constraints
-- Tech constraints
-- Design constraints
-
-## 9. Edge Cases
-- Case 1
-- Case 2
-
-## 10. Acceptance Criteria (Gherkin)
-Given 
-When 
-Then
-
-## 11. Verification
-- How to test
-- Where to test
-- Observability checks
-```
-
----
-
-## 6. Output Location & Format
-
-**Direct Mode:**
-- You MUST follow `rules/core/documentation-management.mdc` for the `requirements` category.
-- Before saving, ASK the user to confirm the feature name (`<name>`) or to suggest a custom path.
-- The default target path is: `<current_project_root>/docs/requirements/<name>-<YYYY-MM-DD>/`
-- You MUST generate 3 synchronized language variants:
-  - `ru/<name>.md` (Russian for humans)
-  - `en/<name>.md` (English for humans)
-  - `ai/<name>.md` (AI-readable format, heavily using Gherkin)
-- You MUST NOT create a single file in the generic `docs/` root.
-
-**Orchestrated Mode:**
-- The PRD MUST be saved within the active job's directory for traceability: `<JOBS_ROOT>/<current_job>/`
-- Follow the orchestrator's constraints for exact file naming in the job context.
-
----
-
-## 7. API Contract Design
-
-Both Direct Mode and Orchestrated Mode adhere to strict JSON schemas to ensure reliable inter-agent communication.
-
-- **Input Schema:** Defines the incoming request context. (See `input-contract.schema.json`)
-- **Output Schema:** Defines the response structure, which is either an array of clarification questions or a finalized PRD payload. (See `output-contract.schema.json`)
-
----
-
-## 8. Quality Control Checklist
-
-Before finalizing PRD, the agent MUST verify:
-
-- [ ] Is the business goal clearly defined?
-- [ ] Are technical/design constraints explicit?
-- [ ] Are non-goals present and clear?
-- [ ] Are all acceptance criteria testable and formatted in Gherkin?
-- [ ] Is the verification method fully defined?
-- [ ] Is the potential architecture impact clear?
-
-**CRITICAL:** If any answer is NO → The PRD must not be finalized. Return to the user/orchestrator with clarification questions.
-
----
-
-## 9. Intended Usage
-
-Designed for multi-agent orchestration pipelines, such as:
-
-`User → Intent Agent → PRD-Creator → Tech Spec Agent → Code Agent`
-
-All programmatic interactions are strictly schema-validated.

package/src/gdskills/bundled/skills/platform/claude-md-management/SKILL.codex.md

@@ -1,87 +0,0 @@
----
-name: claude-md-management
-description: "Use when saving session learnings, coding patterns, conventions, or commands discovered during work into CLAUDE.md files."
-triggers:
-  - "/revise-claude-md"
-  - "Update claude md"
-  - "Save learnings"
-  - "Update project instructions"
-  - "Add to CLAUDE.md"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "configuration"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# CLAUDE.md Management
-
-Capture session insights and persist them into the appropriate CLAUDE.md file.
-
-## Arguments
-
-- `/revise-claude-md` — analyze session and propose updates
-- `/revise-claude-md "specific thing"` — add a specific entry
-- `/revise-claude-md --auto` — apply without asking (for pipelines)
-
-## Workflow
-
-### Step 1: Collect Session Insights
-Analyze the current conversation for:
-- Coding patterns discovered or established
-- Project conventions learned (naming, structure, testing)
-- Build/deploy commands that work
-- Gotchas and pitfalls encountered
-- Architecture decisions made
-- Tool configurations set up
-
-### Step 2: Read Current CLAUDE.md Files
-1. Project-level: `<project-root>/CLAUDE.md`
-2. User-level: `~/.claude/CLAUDE.md`
-3. Project-specific user-level: `~/.claude/projects/<project-path>/CLAUDE.md`
-
-### Step 3: Classify Each Insight
-
-| Type | Target |
-|------|--------|
-| Project conventions, build commands | `<project>/CLAUDE.md` |
-| Global preferences, workflow rules | `~/.claude/CLAUDE.md` |
-| Project-specific personal notes | `~/.claude/projects/<path>/CLAUDE.md` |
-
-### Step 4: Propose Changes
-Present diff preview:
-```
-📝 Proposed CLAUDE.md updates:
-
-[project] CLAUDE.md:
-+ ## Build Commands
-+ - `npm run dev` — start dev server on port 3000
-
-[global] ~/.claude/CLAUDE.md:
-+ ## Preferences
-+ - Always use conventional commits
-```
-
-### Step 5: Apply (after user approval)
-1. Edit existing sections or append new sections
-2. Keep organized with clear `##` headers
-3. Avoid duplication — merge with existing
-4. Remove outdated entries if contradicted
-
-## Formatting Rules for CLAUDE.md
-
-- Use `##` headers for sections
-- Use `-` bullet lists for items
-- Keep entries concise (1 line each)
-- Group by: Commands, Conventions, Architecture, Gotchas
-- No frontmatter in CLAUDE.md files
-- CLAUDE.md should be practical — commands you run, not documentation
-
-## Rules
-
-- ALWAYS show proposed changes before applying
-- NEVER remove existing entries without explanation
-- NEVER add entries that duplicate what's already there
-- Keep CLAUDE.md files under 100 lines
-- Prefer project-level for project-specific things

package/src/gdskills/bundled/skills/platform/claude-md-management/SKILL.cursor.md

@@ -1,87 +0,0 @@
----
-name: claude-md-management
-description: "Use when saving session learnings, coding patterns, conventions, or commands discovered during work into CLAUDE.md files."
-triggers:
-  - "/revise-claude-md"
-  - "Update claude md"
-  - "Save learnings"
-  - "Update project instructions"
-  - "Add to CLAUDE.md"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "configuration"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# CLAUDE.md Management
-
-Capture session insights and persist them into the appropriate CLAUDE.md file.
-
-## Arguments
-
-- `/revise-claude-md` — analyze session and propose updates
-- `/revise-claude-md "specific thing"` — add a specific entry
-- `/revise-claude-md --auto` — apply without asking (for pipelines)
-
-## Workflow
-
-### Step 1: Collect Session Insights
-Analyze the current conversation for:
-- Coding patterns discovered or established
-- Project conventions learned (naming, structure, testing)
-- Build/deploy commands that work
-- Gotchas and pitfalls encountered
-- Architecture decisions made
-- Tool configurations set up
-
-### Step 2: Read Current CLAUDE.md Files
-1. Project-level: `<project-root>/CLAUDE.md`
-2. User-level: `~/.claude/CLAUDE.md`
-3. Project-specific user-level: `~/.claude/projects/<project-path>/CLAUDE.md`
-
-### Step 3: Classify Each Insight
-
-| Type | Target |
-|------|--------|
-| Project conventions, build commands | `<project>/CLAUDE.md` |
-| Global preferences, workflow rules | `~/.claude/CLAUDE.md` |
-| Project-specific personal notes | `~/.claude/projects/<path>/CLAUDE.md` |
-
-### Step 4: Propose Changes
-Present diff preview:
-```
-📝 Proposed CLAUDE.md updates:
-
-[project] CLAUDE.md:
-+ ## Build Commands
-+ - `npm run dev` — start dev server on port 3000
-
-[global] ~/.claude/CLAUDE.md:
-+ ## Preferences
-+ - Always use conventional commits
-```
-
-### Step 5: Apply (after user approval)
-1. Edit existing sections or append new sections
-2. Keep organized with clear `##` headers
-3. Avoid duplication — merge with existing
-4. Remove outdated entries if contradicted
-
-## Formatting Rules for CLAUDE.md
-
-- Use `##` headers for sections
-- Use `-` bullet lists for items
-- Keep entries concise (1 line each)
-- Group by: Commands, Conventions, Architecture, Gotchas
-- No frontmatter in CLAUDE.md files
-- CLAUDE.md should be practical — commands you run, not documentation
-
-## Rules
-
-- ALWAYS show proposed changes before applying
-- NEVER remove existing entries without explanation
-- NEVER add entries that duplicate what's already there
-- Keep CLAUDE.md files under 100 lines
-- Prefer project-level for project-specific things

package/src/gdskills/bundled/skills/platform/hookify/SKILL.codex.md

@@ -1,100 +0,0 @@
----
-name: hookify
-description: "Use when adding automated hook behavior to Claude Code or Cursor from a natural language description."
-triggers:
-  - "/hookify"
-  - "Create hook"
-  - "Add hook"
-  - "Run lint after edit"
-  - "Notify when done"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "configuration"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Hookify
-
-Create agent hooks from natural language descriptions.
-
-## Arguments
-
-- `/hookify <description>` — create hook from description
-- `/hookify --list` — show all current hooks
-- `/hookify --remove <event>` — remove a hook
-
-## Workflow
-
-### Step 1: Parse Request
-Understand from natural language:
-- **When**: what event triggers it (before edit, after bash, on stop)
-- **What**: what should happen (run command, check, notify)
-- **Condition**: optional matcher (specific tool, file pattern)
-
-Examples:
-- "Run lint after every file edit" → PostToolUse + Edit matcher + lint command
-- "Notify me when done" → Stop + notification command
-- "Check types before committing" → PreToolUse + Bash(git commit) + tsc
-
-### Step 2: Read Current Settings
-Check for existing hooks to avoid conflicts.
-
-### Step 3: Generate Hook Config
-
-```json
-{
-  "hooks": {
-    "<event>": [
-      {
-        "matcher": "<tool name or pattern>",
-        "command": "<shell command>",
-        "timeout": 60000
-      }
-    ]
-  }
-}
-```
-
-### Step 4: Validate
-1. Verify command exists and is executable
-2. Test standalone if safe
-3. Check for conflicts with existing hooks
-
-### Step 5: Preview & Apply
-```
-🔧 New hook:
-  Event: PostToolUse (Edit)
-  Command: npm run lint --fix
-  Timeout: 30s
-
-Add to settings.json? [confirm]
-```
-
-After confirmation, merge into settings.
-
-## Hook Event Reference
-
-| Event | When | Matcher |
-|-------|------|---------|
-| PreToolUse | Before tool runs | Tool name: Edit, Bash, Write |
-| PostToolUse | After tool runs | Tool name |
-| Notification | Agent notifies | — |
-| Stop | Response complete | — |
-| SubagentStop | Sub-agent done | — |
-
-## Common Patterns
-
-- **Auto-lint**: PostToolUse(Edit) → `eslint --fix $FILE`
-- **Auto-format**: PostToolUse(Write) → `prettier --write $FILE`
-- **Type-check gate**: PreToolUse(Bash:git commit) → `npx tsc --noEmit`
-- **Notify on done**: Stop → notification command
-
-## Rules
-
-- ALWAYS preview before applying
-- NEVER overwrite existing hooks — merge or ask
-- Keep timeouts reasonable (10-60s)
-- Warn if hook could slow down every tool call
-- Test commands before adding as hooks

package/src/gdskills/bundled/skills/platform/hookify/SKILL.cursor.md

@@ -1,100 +0,0 @@
----
-name: hookify
-description: "Use when adding automated hook behavior to Claude Code or Cursor from a natural language description."
-triggers:
-  - "/hookify"
-  - "Create hook"
-  - "Add hook"
-  - "Run lint after edit"
-  - "Notify when done"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "configuration"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Hookify
-
-Create agent hooks from natural language descriptions.
-
-## Arguments
-
-- `/hookify <description>` — create hook from description
-- `/hookify --list` — show all current hooks
-- `/hookify --remove <event>` — remove a hook
-
-## Workflow
-
-### Step 1: Parse Request
-Understand from natural language:
-- **When**: what event triggers it (before edit, after bash, on stop)
-- **What**: what should happen (run command, check, notify)
-- **Condition**: optional matcher (specific tool, file pattern)
-
-Examples:
-- "Run lint after every file edit" → PostToolUse + Edit matcher + lint command
-- "Notify me when done" → Stop + notification command
-- "Check types before committing" → PreToolUse + Bash(git commit) + tsc
-
-### Step 2: Read Current Settings
-Check for existing hooks to avoid conflicts.
-
-### Step 3: Generate Hook Config
-
-```json
-{
-  "hooks": {
-    "<event>": [
-      {
-        "matcher": "<tool name or pattern>",
-        "command": "<shell command>",
-        "timeout": 60000
-      }
-    ]
-  }
-}
-```
-
-### Step 4: Validate
-1. Verify command exists and is executable
-2. Test standalone if safe
-3. Check for conflicts with existing hooks
-
-### Step 5: Preview & Apply
-```
-🔧 New hook:
-  Event: PostToolUse (Edit)
-  Command: npm run lint --fix
-  Timeout: 30s
-
-Add to settings.json? [confirm]
-```
-
-After confirmation, merge into settings.
-
-## Hook Event Reference
-
-| Event | When | Matcher |
-|-------|------|---------|
-| PreToolUse | Before tool runs | Tool name: Edit, Bash, Write |
-| PostToolUse | After tool runs | Tool name |
-| Notification | Agent notifies | — |
-| Stop | Response complete | — |
-| SubagentStop | Sub-agent done | — |
-
-## Common Patterns
-
-- **Auto-lint**: PostToolUse(Edit) → `eslint --fix $FILE`
-- **Auto-format**: PostToolUse(Write) → `prettier --write $FILE`
-- **Type-check gate**: PreToolUse(Bash:git commit) → `npx tsc --noEmit`
-- **Notify on done**: Stop → notification command
-
-## Rules
-
-- ALWAYS preview before applying
-- NEVER overwrite existing hooks — merge or ask
-- Keep timeouts reasonable (10-60s)
-- Warn if hook could slow down every tool call
-- Test commands before adding as hooks

package/src/gdskills/bundled/skills/quality/changelog/SKILL.codex.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