@mrciphersmith/keryx 0.2.98 → 0.2.99

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

@@ -1,105 +0,0 @@
----
-name: interviewer
-description: "Use when a request is ambiguous and must be pinned down BEFORE any context is collected — the entry-point interview that turns a vague or expensive ask into a scoped brief. This is the `custom`-intent gate job-orchestrator runs at 0.1.5. For clarifying implementation specifics AFTER context is already collected, use `interview` instead."
-triggers:
-  - "Interview me"
-  - "Ask me questions"
-  - "Clarify requirements"
-  - "Gather requirements"
-  - "What do you need to know"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "planning"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-<SUBAGENT-STOP>
-If you were dispatched as a subagent to execute a specific task, skip this skill entirely.
-This skill is for orchestrators and interactive session-level routing only.
-Proceed directly with your assigned task.
-</SUBAGENT-STOP>
-
-# Interviewer
-
-## Purpose
-
-Gathers precise context through focused, critical questions before a complex skill executes. Prevents wasted work from wrong assumptions. Asks **one question at a time**, provides options where possible, and skips questions the context already answers.
-
-**Input schema:**
-```
-topic: string           — what is being worked on
-goal: string            — which skill will use these answers
-context?: {             — optional, provided by calling skill
-  codebase_summary?: string
-  recent_changes?: string
-  relevant_files?: string[]
-  existing_analysis?: string
-}
-```
-
-**Output schema:**
-```
-answers: [{question, answer, confidence: "certain"|"assumption"|"unknown"}]
-derived_context: string   — all gathered info as one coherent block
-ready_to_proceed: boolean
-blockers?: string[]       — unresolved critical unknowns
-```
-
-## When to Use
-
-- Called by `job-orchestrator`, `brainstorm`, `feature-dev` at start of Phase 0
-- Directly by user: `/interviewer <topic>` — runs context-collector first if no context provided
-- When requirements are vague or ambiguous
-
-## Workflow
-
-### If called by another skill (context provided)
-1. Parse input context
-2. Determine what's still unknown or ambiguous for the stated goal
-3. Decide number of questions needed (typically 2-6)
-4. Skip questions already answered by context
-5. Ask questions one at a time
-6. Produce output schema
-
-### If called directly by user (no context)
-1. Ask: "What are we working on?" (if topic not in arguments)
-2. Run `context-collector` as sub-agent to gather codebase context
-3. Proceed as above with collected context
-
-## Question Rules
-
-- **One question at a time** — never ask multiple at once
-- **Provide options when possible**:
-  ```
-  What is the primary trigger for this feature?
-  A) User request / new requirement
-  B) Tech debt or refactor
-  C) Bug or incident in production
-  D) Other (describe)
-  ```
-- **Skip if already known** — if context answers a question, don't ask it
-- **Be critical** — focus on questions that would change the approach
-- **Max 8 questions** — stop when enough context is gathered
-- **Confirm before proceeding** — summarize gathered context and ask if correct
-
-## Question Bank by Goal Type
-
-### For implementation goals
-- What is the expected input/output?
-- What are the edge cases that must be handled?
-- Are there existing similar patterns in the codebase to follow?
-- What is the performance/scale requirement?
-- What should NOT be changed (constraints)?
-
-### For review goals
-- What specific concerns should the review focus on?
-- Are there known existing issues to watch for?
-- What is the acceptance criteria?
-
-### For architecture/design goals
-- What are the hard constraints (performance, compat, timeline)?
-- What does success look like in 6 months?
-- What are you most worried about?
-- Who else is affected by this decision?

package/src/gdskills/bundled/skills/planning/prd-creator/SKILL.codex.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,claude"
-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}
-
-Version: 0.1.0
-
-## 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/requirements-package-standard.mdc` (via `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>/prd.md` — no date-stamped folder.
-- If the requirements package (`README.md`, `prd.md`, `specification.md`) does not exist yet, create it; otherwise update `prd.md` in place and bump its `Version` field rather than creating a parallel copy.
-- Default to a single document in the project's documentation language (`en` unless the project states otherwise). Generate additional language variants only when the user explicitly asks for them, and keep any variants you create synchronized.
-- 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/planning/prd-creator/SKILL.cursor.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,claude"
-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}
-
-Version: 0.1.0
-
-## 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/requirements-package-standard.mdc` (via `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>/prd.md` — no date-stamped folder.
-- If the requirements package (`README.md`, `prd.md`, `specification.md`) does not exist yet, create it; otherwise update `prd.md` in place and bump its `Version` field rather than creating a parallel copy.
-- Default to a single document in the project's documentation language (`en` unless the project states otherwise). Generate additional language variants only when the user explicitly asks for them, and keep any variants you create synchronized.
-- 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/planning/prd-creator/SKILL.opencode.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,claude"
-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}
-
-Version: 0.1.0
-
-## 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/requirements-package-standard.mdc` (via `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>/prd.md` — no date-stamped folder.
-- If the requirements package (`README.md`, `prd.md`, `specification.md`) does not exist yet, create it; otherwise update `prd.md` in place and bump its `Version` field rather than creating a parallel copy.
-- Default to a single document in the project's documentation language (`en` unless the project states otherwise). Generate additional language variants only when the user explicitly asks for them, and keep any variants you create synchronized.
-- 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.