@mrciphersmith/keryx 0.2.98 → 0.2.99

package/src/gdskills/bundled/skills/planning/brainstorm/SKILL.codex.md

@@ -1,90 +0,0 @@
----
-name: brainstorm
-description: "Use when exploring architecture decisions, tech choices, feature ideas, or any open-ended problem that benefits from multiple perspectives."
-triggers:
-  - "/brainstorm"
-  - "Brainstorm"
-  - "Let's think about"
-  - "What are options for"
-  - "How should we approach"
-  - "Compare approaches"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "planning"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Brainstorm
-
-Structured brainstorming that explores a topic from multiple angles and converges on actionable options.
-
-## Arguments
-
-- `/brainstorm <topic>` — full brainstorm with 3 parallel agents
-- `/brainstorm --quick <topic>` — inline fast brainstorm (no agents, for simple decisions)
-- `/brainstorm --deep <topic>` — 5 agents (+Security Analyst, +UX Advocate)
-- `/brainstorm --code` — focus on code architecture (reads codebase for context)
-
-## Workflow
-
-### Step 1: Frame the Problem
-1. Restate the user's challenge in clear terms
-2. Identify constraints: technical, business, quality
-3. If in a project directory, scan codebase for relevant context
-
-### Step 2: Diverge — Generate Ideas (3 Parallel Agents)
-
-Launch 3 agents simultaneously:
-
-**Agent 1 — Pragmatist**
-> "Propose 2-3 solutions optimizing for speed of delivery, simplicity, and maintainability. Use boring, proven technology. For each: approach, pros/cons, effort (S/M/L)."
-
-**Agent 2 — Innovator**
-> "Propose 2-3 unconventional or cutting-edge solutions. Think new patterns, emerging tools, or approaches from other domains. For each: approach, pros/cons, effort."
-
-**Agent 3 — Critic**
-> "What are the hidden risks? What will break at scale? What will be painful to maintain? Produce 5-7 critical questions any solution must address."
-
-### Step 3: Converge — Synthesize
-
-```markdown
-## Ideas Map
-### Option A: [Name]
-**Approach:** ... | **Pros:** ... | **Cons:** ...
-**Effort:** S/M/L | **Risk:** Low/Med/High
-
-## Critical Questions
-(from Critic — apply to ALL options)
-
-## Comparison Matrix
-| Criteria        | Option A | Option B | Option C |
-|-----------------|----------|----------|----------|
-| Effort          | S        | M        | L        |
-| Risk            | Low      | Med      | High     |
-| Scalability     | ★★★      | ★★★★     | ★★★★★    |
-| Time to ship    | 1 week   | 3 weeks  | 6 weeks  |
-```
-
-### Step 4: Recommend
-1. **Recommended option** with reasoning
-2. **Runner-up** and when you'd pick it instead
-3. **Next steps** — concrete action items
-
-### Step 5: Discuss
-Offer to go deeper on any option or kick off `/feature-dev` / `/prd-creator`.
-
-## Quick Mode (--quick)
-Skip agents. Inline: 3-5 options in table, score each, recommend one.
-
-## Deep Mode (--deep)
-Add: **Security Analyst** (auth, data exposure, compliance) and **UX Advocate** (complexity, learning curve, accessibility).
-
-## Rules
-
-- Ground ideas in the project's actual tech stack and constraints
-- Include effort estimates — ideas without estimates aren't actionable
-- The Critic's questions must be answered by the recommendation
-- Don't dismiss "boring" solutions — they often win
-- End with concrete next steps, not just analysis

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

@@ -1,90 +0,0 @@
----
-name: brainstorm
-description: "Use when exploring architecture decisions, tech choices, feature ideas, or any open-ended problem that benefits from multiple perspectives."
-triggers:
-  - "/brainstorm"
-  - "Brainstorm"
-  - "Let's think about"
-  - "What are options for"
-  - "How should we approach"
-  - "Compare approaches"
-metadata:
-  author: "MrCipherSmith"
-  version: "1.0.0"
-  category: "planning"
-  compatible_harnesses: "cursor,codex,zed,opencode,claude"
-license: "MIT"
----
-
-# Brainstorm
-
-Structured brainstorming that explores a topic from multiple angles and converges on actionable options.
-
-## Arguments
-
-- `/brainstorm <topic>` — full brainstorm with 3 parallel agents
-- `/brainstorm --quick <topic>` — inline fast brainstorm (no agents, for simple decisions)
-- `/brainstorm --deep <topic>` — 5 agents (+Security Analyst, +UX Advocate)
-- `/brainstorm --code` — focus on code architecture (reads codebase for context)
-
-## Workflow
-
-### Step 1: Frame the Problem
-1. Restate the user's challenge in clear terms
-2. Identify constraints: technical, business, quality
-3. If in a project directory, scan codebase for relevant context
-
-### Step 2: Diverge — Generate Ideas (3 Parallel Agents)
-
-Launch 3 agents simultaneously:
-
-**Agent 1 — Pragmatist**
-> "Propose 2-3 solutions optimizing for speed of delivery, simplicity, and maintainability. Use boring, proven technology. For each: approach, pros/cons, effort (S/M/L)."
-
-**Agent 2 — Innovator**
-> "Propose 2-3 unconventional or cutting-edge solutions. Think new patterns, emerging tools, or approaches from other domains. For each: approach, pros/cons, effort."
-
-**Agent 3 — Critic**
-> "What are the hidden risks? What will break at scale? What will be painful to maintain? Produce 5-7 critical questions any solution must address."
-
-### Step 3: Converge — Synthesize
-
-```markdown
-## Ideas Map
-### Option A: [Name]
-**Approach:** ... | **Pros:** ... | **Cons:** ...
-**Effort:** S/M/L | **Risk:** Low/Med/High
-
-## Critical Questions
-(from Critic — apply to ALL options)
-
-## Comparison Matrix
-| Criteria        | Option A | Option B | Option C |
-|-----------------|----------|----------|----------|
-| Effort          | S        | M        | L        |
-| Risk            | Low      | Med      | High     |
-| Scalability     | ★★★      | ★★★★     | ★★★★★    |
-| Time to ship    | 1 week   | 3 weeks  | 6 weeks  |
-```
-
-### Step 4: Recommend
-1. **Recommended option** with reasoning
-2. **Runner-up** and when you'd pick it instead
-3. **Next steps** — concrete action items
-
-### Step 5: Discuss
-Offer to go deeper on any option or kick off `/feature-dev` / `/prd-creator`.
-
-## Quick Mode (--quick)
-Skip agents. Inline: 3-5 options in table, score each, recommend one.
-
-## Deep Mode (--deep)
-Add: **Security Analyst** (auth, data exposure, compliance) and **UX Advocate** (complexity, learning curve, accessibility).
-
-## Rules
-
-- Ground ideas in the project's actual tech stack and constraints
-- Include effort estimates — ideas without estimates aren't actionable
-- The Critic's questions must be answered by the recommendation
-- Don't dismiss "boring" solutions — they often win
-- End with concrete next steps, not just analysis

package/src/gdskills/bundled/skills/planning/interview/SKILL.codex.md

@@ -1,187 +0,0 @@
----
-name: interview
-description: "Use to clarify implementation-specific ambiguities AFTER context has already been collected and the goal is known — the questions that sharpen a plan, not the ones that scope the request. This is the `implement`-intent interview job-orchestrator runs at 0.3. To pin down a vague request before any context is gathered, use `interviewer` instead."
-triggers:
-  - "/interview"
-  - "Interview"
-  - "Clarify requirements"
-  - "Ask questions first"
-  - "What do you need to know"
-  - "Gather requirements"
-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>
-
-# Interview
-
-Critical requirements interviewer that asks targeted clarifying questions before expensive operations begin. The goal is to eliminate ambiguity and gather precise context so downstream skills (job-orchestrator, feature-dev, prd-creator) produce accurate results.
-
-## Input Contract
-
-When called by another skill (orchestrated mode):
-```json
-{
-  "goal": "what needs to be done (issue title, feature description, task)",
-  "context": "collected context from context-collector or another agent",
-  "domain": "implement | review | design | migrate | custom",
-  "caller": "job-orchestrator | feature-dev | user | prd-creator",
-  "known_facts": ["already known facts or decisions"],
-  "max_questions": null
-}
-```
-
-When called standalone: input is the user's free-text description.
-
-## Output Contract
-
-```json
-{
-  "decisions": [
-    {"question": "...", "answer": "...", "impact": "high | medium"}
-  ],
-  "constraints": ["identified constraints"],
-  "assumptions": ["confirmed assumptions"],
-  "risks": ["identified risks"],
-  "refined_goal": "refined, unambiguous goal statement"
-}
-```
-
-## Workflow
-
-### Phase 1: Context Acquisition
-
-**Orchestrated mode** (called with context):
-- Parse the input contract
-- Proceed directly to Phase 2
-
-**Standalone mode** (called by user):
-1. Ask the user: "What are you trying to accomplish?"
-2. If in a project directory, launch `context-collector` as sub-agent to gather codebase context
-3. Wait for context, then proceed to Phase 2
-
-### Phase 2: Uncertainty Analysis
-
-Analyze goal + context to identify "uncertainty zones" — areas where:
-- Multiple valid approaches exist
-- Requirements are ambiguous or contradictory
-- Technical constraints are unclear
-- Scope boundaries are undefined
-- Dependencies or impacts are unknown
-
-Each uncertainty zone becomes a potential question. Skip questions where the answer is already clear from context or known_facts.
-
-Determine question count dynamically:
-- Simple task with good context → 2-3 questions
-- Complex task with sparse context → 5-7 questions
-- Stop when remaining uncertainty is low enough to proceed confidently
-
-### Phase 3: Interactive Interview
-
-Ask questions **one at a time**, each with answer options where possible:
-
-```
-❓ Question 1/~N: [Topic — e.g., "Authentication approach"]
-
-[Brief context why this matters for the task]
-
-  A) Option one (brief explanation)
-  B) Option two (brief explanation)
-  C) Option three
-  D) Need more context — tell me more
-
-> answer with letter or free text
-```
-
-**Adaptation rules:**
-- If user picks an option → record decision, move to next question
-- If user answers in free text → extract the decision, confirm understanding
-- If user picks "Need more context" (D) → provide deeper explanation or trigger a mini `/brainstorm --quick` on this specific point, then re-ask
-- If user says "skip" or "don't care" → record as assumption with medium confidence, move on
-- Adjust remaining questions based on answers (some questions become irrelevant after certain decisions)
-
-### Phase 4: Synthesis
-
-After all questions are answered:
-
-1. Compile the output contract:
-   - **decisions**: all Q&A pairs with impact level
-   - **constraints**: technical and business constraints identified
-   - **assumptions**: things assumed true but not explicitly confirmed
-   - **risks**: potential issues surfaced during interview
-   - **refined_goal**: clear, unambiguous restatement of the goal
-
-2. Present summary to user:
-```markdown
-## Interview Summary
-
-### Goal (refined)
-[Clear statement]
-
-### Key Decisions
-1. [Decision] — impact: high
-2. [Decision] — impact: medium
-
-### Constraints
-- [Constraint]
-
-### Assumptions (please verify)
-- [Assumption]
-
-### Risks
-- [Risk]
-```
-
-3. Ask: "Does this look right? Anything to correct before we proceed?"
-
-### Phase 5: Handoff
-
-Return the output contract to the calling skill, or if standalone — ask what the user wants to do next:
-- "Start implementing? I can run `/feature-dev`"
-- "Create a PRD? I can run `/prd-creator`"
-- "Need more brainstorming? Try `/brainstorm`"
-
-## Question Design Principles
-
-Good interview questions are:
-- **Specific**: "Should auth use JWT or session cookies?" not "How should auth work?"
-- **Impactful**: the answer meaningfully changes the implementation
-- **Non-obvious**: don't ask things derivable from the codebase
-- **Ordered by dependency**: ask foundational questions first (they may make later questions unnecessary)
-
-Provide answer options when:
-- There are 2-4 clear alternatives
-- The user might not know all options available
-- You want to speed up the interview
-
-Skip options when:
-- The question requires a free-text answer (e.g., "What's the deadline?")
-- The space of answers is too large
-
-## Integration with Other Skills
-
-```
-job-orchestrator → context-collector → interview → plan → execute
-feature-dev → interview (Phase 1) → design → implement
-prd-creator → interview → requirements document
-```
-
-The interview skill is designed to be composable — any skill that needs user input before proceeding can call it.
-
-## Rules
-
-- NEVER ask more than 7 questions (keep it focused)
-- NEVER ask questions whose answers are already in the provided context
-- ALWAYS provide answer options when 2-4 clear alternatives exist
-- ALWAYS adapt subsequent questions based on previous answers
-- If the user seems impatient or says "just do it" — stop interviewing, document remaining unknowns as assumptions, and proceed
-- One question at a time — never dump all questions at once

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

@@ -1,187 +0,0 @@
----
-name: interview
-description: "Use to clarify implementation-specific ambiguities AFTER context has already been collected and the goal is known — the questions that sharpen a plan, not the ones that scope the request. This is the `implement`-intent interview job-orchestrator runs at 0.3. To pin down a vague request before any context is gathered, use `interviewer` instead."
-triggers:
-  - "/interview"
-  - "Interview"
-  - "Clarify requirements"
-  - "Ask questions first"
-  - "What do you need to know"
-  - "Gather requirements"
-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>
-
-# Interview
-
-Critical requirements interviewer that asks targeted clarifying questions before expensive operations begin. The goal is to eliminate ambiguity and gather precise context so downstream skills (job-orchestrator, feature-dev, prd-creator) produce accurate results.
-
-## Input Contract
-
-When called by another skill (orchestrated mode):
-```json
-{
-  "goal": "what needs to be done (issue title, feature description, task)",
-  "context": "collected context from context-collector or another agent",
-  "domain": "implement | review | design | migrate | custom",
-  "caller": "job-orchestrator | feature-dev | user | prd-creator",
-  "known_facts": ["already known facts or decisions"],
-  "max_questions": null
-}
-```
-
-When called standalone: input is the user's free-text description.
-
-## Output Contract
-
-```json
-{
-  "decisions": [
-    {"question": "...", "answer": "...", "impact": "high | medium"}
-  ],
-  "constraints": ["identified constraints"],
-  "assumptions": ["confirmed assumptions"],
-  "risks": ["identified risks"],
-  "refined_goal": "refined, unambiguous goal statement"
-}
-```
-
-## Workflow
-
-### Phase 1: Context Acquisition
-
-**Orchestrated mode** (called with context):
-- Parse the input contract
-- Proceed directly to Phase 2
-
-**Standalone mode** (called by user):
-1. Ask the user: "What are you trying to accomplish?"
-2. If in a project directory, launch `context-collector` as sub-agent to gather codebase context
-3. Wait for context, then proceed to Phase 2
-
-### Phase 2: Uncertainty Analysis
-
-Analyze goal + context to identify "uncertainty zones" — areas where:
-- Multiple valid approaches exist
-- Requirements are ambiguous or contradictory
-- Technical constraints are unclear
-- Scope boundaries are undefined
-- Dependencies or impacts are unknown
-
-Each uncertainty zone becomes a potential question. Skip questions where the answer is already clear from context or known_facts.
-
-Determine question count dynamically:
-- Simple task with good context → 2-3 questions
-- Complex task with sparse context → 5-7 questions
-- Stop when remaining uncertainty is low enough to proceed confidently
-
-### Phase 3: Interactive Interview
-
-Ask questions **one at a time**, each with answer options where possible:
-
-```
-❓ Question 1/~N: [Topic — e.g., "Authentication approach"]
-
-[Brief context why this matters for the task]
-
-  A) Option one (brief explanation)
-  B) Option two (brief explanation)
-  C) Option three
-  D) Need more context — tell me more
-
-> answer with letter or free text
-```
-
-**Adaptation rules:**
-- If user picks an option → record decision, move to next question
-- If user answers in free text → extract the decision, confirm understanding
-- If user picks "Need more context" (D) → provide deeper explanation or trigger a mini `/brainstorm --quick` on this specific point, then re-ask
-- If user says "skip" or "don't care" → record as assumption with medium confidence, move on
-- Adjust remaining questions based on answers (some questions become irrelevant after certain decisions)
-
-### Phase 4: Synthesis
-
-After all questions are answered:
-
-1. Compile the output contract:
-   - **decisions**: all Q&A pairs with impact level
-   - **constraints**: technical and business constraints identified
-   - **assumptions**: things assumed true but not explicitly confirmed
-   - **risks**: potential issues surfaced during interview
-   - **refined_goal**: clear, unambiguous restatement of the goal
-
-2. Present summary to user:
-```markdown
-## Interview Summary
-
-### Goal (refined)
-[Clear statement]
-
-### Key Decisions
-1. [Decision] — impact: high
-2. [Decision] — impact: medium
-
-### Constraints
-- [Constraint]
-
-### Assumptions (please verify)
-- [Assumption]
-
-### Risks
-- [Risk]
-```
-
-3. Ask: "Does this look right? Anything to correct before we proceed?"
-
-### Phase 5: Handoff
-
-Return the output contract to the calling skill, or if standalone — ask what the user wants to do next:
-- "Start implementing? I can run `/feature-dev`"
-- "Create a PRD? I can run `/prd-creator`"
-- "Need more brainstorming? Try `/brainstorm`"
-
-## Question Design Principles
-
-Good interview questions are:
-- **Specific**: "Should auth use JWT or session cookies?" not "How should auth work?"
-- **Impactful**: the answer meaningfully changes the implementation
-- **Non-obvious**: don't ask things derivable from the codebase
-- **Ordered by dependency**: ask foundational questions first (they may make later questions unnecessary)
-
-Provide answer options when:
-- There are 2-4 clear alternatives
-- The user might not know all options available
-- You want to speed up the interview
-
-Skip options when:
-- The question requires a free-text answer (e.g., "What's the deadline?")
-- The space of answers is too large
-
-## Integration with Other Skills
-
-```
-job-orchestrator → context-collector → interview → plan → execute
-feature-dev → interview (Phase 1) → design → implement
-prd-creator → interview → requirements document
-```
-
-The interview skill is designed to be composable — any skill that needs user input before proceeding can call it.
-
-## Rules
-
-- NEVER ask more than 7 questions (keep it focused)
-- NEVER ask questions whose answers are already in the provided context
-- ALWAYS provide answer options when 2-4 clear alternatives exist
-- ALWAYS adapt subsequent questions based on previous answers
-- If the user seems impatient or says "just do it" — stop interviewing, document remaining unknowns as assumptions, and proceed
-- One question at a time — never dump all questions at once

package/src/gdskills/bundled/skills/planning/interviewer/SKILL.codex.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?