@mrciphersmith/keryx 0.2.9

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

@@ -0,0 +1,99 @@
+---
+name: interviewer
+description: "Critical requirements interviewer that gathers precise context before complex tasks. Asks one focused question at a time (with A/B/C options where applicable). Skips questions already answered by provided context. Can be called by other skills as a sub-agent or directly by the user. Outputs structured context for the calling skill."
+triggers:
+  - "Interview me"
+  - "Ask me questions"
+  - "Clarify requirements"
+  - "Gather requirements"
+  - "What do you need to know"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "meta"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode,claude"
+---
+
+# 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/interviewer/SKILL.cursor.md

@@ -0,0 +1,99 @@
+---
+name: interviewer
+description: "Critical requirements interviewer that gathers precise context before complex tasks. Asks one focused question at a time (with A/B/C options where applicable). Skips questions already answered by provided context. Can be called by other skills as a sub-agent or directly by the user. Outputs structured context for the calling skill."
+triggers:
+  - "Interview me"
+  - "Ask me questions"
+  - "Clarify requirements"
+  - "Gather requirements"
+  - "What do you need to know"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "meta"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode,claude"
+---
+
+# 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/interviewer/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: interviewer
+description: "Use when requirements are ambiguous and precise clarification is needed before proceeding with a complex task."
+triggers:
+  - "Interview me"
+  - "Ask me questions"
+  - "Clarify requirements"
+  - "Gather requirements"
+  - "What do you need to know"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "meta"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode,claude"
+---
+
+<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/patterns-researcher/SKILL.codex.md

@@ -0,0 +1,33 @@
+---
+name: gproject-patterns-researcher
+description: "Researches per-technology best practices and defines architecture patterns that become binding PRD constraints. Use when: dispatched by gproject-orchestrator Phase 3."
+triggers:
+  - "gproject-patterns-researcher: research patterns"
+  - "Dispatched by gproject-orchestrator Phase 3"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+
+# gproject-patterns-researcher
+
+## Purpose
+
+After stack is chosen, research and define the specific patterns, conventions,
+and architectural decisions for each technology. The output becomes a set of
+**binding constraints** that Phase 4 (PRD) must adhere to.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Every pattern MUST reference a source (official docs, community consensus, or established practice) |
+| 2 | Patterns MUST be compatible with chosen project level — no enterprise patterns for MVP |
+| 3 | Architecture decisions MUST list alternatives considered |
+| 4 | NEVER copy-paste generic "best practices" — every recommendation must be contextualized to THIS project |
+| 5 | Output MUST be structured as checkable constraints, not prose advice |
+| 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |

package/src/gdskills/bundled/skills/planning/patterns-researcher/SKILL.cursor.md

@@ -0,0 +1,33 @@
+---
+name: gproject-patterns-researcher
+description: "Researches per-technology best practices and defines architecture patterns that become binding PRD constraints. Use when: dispatched by gproject-orchestrator Phase 3."
+triggers:
+  - "gproject-patterns-researcher: research patterns"
+  - "Dispatched by gproject-orchestrator Phase 3"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+
+# gproject-patterns-researcher
+
+## Purpose
+
+After stack is chosen, research and define the specific patterns, conventions,
+and architectural decisions for each technology. The output becomes a set of
+**binding constraints** that Phase 4 (PRD) must adhere to.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Every pattern MUST reference a source (official docs, community consensus, or established practice) |
+| 2 | Patterns MUST be compatible with chosen project level — no enterprise patterns for MVP |
+| 3 | Architecture decisions MUST list alternatives considered |
+| 4 | NEVER copy-paste generic "best practices" — every recommendation must be contextualized to THIS project |
+| 5 | Output MUST be structured as checkable constraints, not prose advice |
+| 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |

package/src/gdskills/bundled/skills/planning/patterns-researcher/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: gproject-patterns-researcher
+description: >
+  Researches best practices per technology in the chosen stack and defines
+  application architecture patterns. Produces constraints that PRD must follow.
+  Use when: dispatched by gproject-orchestrator Phase 3.
+  NOT for: direct user invocation.
+version: 1.0.0
+---
+
+# gproject-patterns-researcher
+
+## Purpose
+
+After stack is chosen, research and define the specific patterns, conventions,
+and architectural decisions for each technology. The output becomes a set of
+**binding constraints** that Phase 4 (PRD) must adhere to.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Every pattern MUST reference a source (official docs, community consensus, or established practice) |
+| 2 | Patterns MUST be compatible with chosen project level — no enterprise patterns for MVP |
+| 3 | Architecture decisions MUST list alternatives considered |
+| 4 | NEVER copy-paste generic "best practices" — every recommendation must be contextualized to THIS project |
+| 5 | Output MUST be structured as checkable constraints, not prose advice |
+| 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |
+
+---
+
+## Input Contract
+
+```yaml
+task: "Research per-technology patterns and define application architecture"
+input_artifacts:
+  - .metaproject/jobs/<job>/artifacts/stack-decision.md
+  - .metaproject/jobs/<job>/artifacts/problem-statement.md
+decisions_so_far:
+  D_level: "..."
+  D_frontend: "..."
+  D_backend: "..."
+  D_database: "..."
+  D_deploy: "..."
+  # All stack decisions
+```
+
+## Output Contract
+
+```yaml
+status: "DONE" | "NEEDS_CONTEXT"
+summary: "<3-5 sentences: architecture pattern, key per-tech decisions, constraint count>"
+new_decisions:
+  D_arch_pattern: "<e.g., Clean Architecture, Feature-Sliced, MVC>"
+  D_api_style: "<REST | GraphQL | tRPC | gRPC>"
+  D_state_management: "<approach>"
+  D_auth_pattern: "<JWT | session | OAuth flow>"
+  D_testing_strategy: "<unit + integration + e2e split>"
+  D_error_handling: "<pattern>"
+  D_logging_observability: "<approach>"
+artifact_path: ".metaproject/jobs/<job>/artifacts/architecture.md"
+additional_artifacts:
+  - ".metaproject/jobs/<job>/artifacts/tech-bestpractices.md"
+```
+
+---
+
+## Workflow
+
+### Step 1: Define Application Architecture
+
+Based on project level and stack, select architecture pattern:
+
+| Level | Typical Pattern | Why |
+|-------|---------------|-----|
+| MVP | Simple layered (routes → services → DB) | Minimum indirection, fast to build |
+| Pet | Feature-based modules | Good learning structure |
+| Startup | Clean Architecture / Hexagonal | Testable, scalable when team grows |
+| Production | DDD + CQRS where justified | Complex domain needs it |
+
+Document the pattern with:
+- Layer diagram (which layers, what goes where)
+- Dependency direction (who imports whom)
+- Module/feature structure (how to organize code)
+- Cross-cutting concerns (logging, auth, error handling)
+
+### Step 2: Per-Technology Research
+
+For EACH technology in the stack, research and document:
+
+#### Frontend (e.g., Next.js)
+- Project structure pattern (App Router conventions, feature folders)
+- Component patterns (Server vs Client components, composition)
+- State management pattern (chosen approach + why)
+- Data fetching pattern (Server Actions, SWR, React Query)
+- Styling approach (Tailwind, CSS Modules, styled-components)
+- Form handling pattern
+- Error boundary strategy
+- Testing approach (unit: Vitest, e2e: Playwright)
+
+#### Backend (e.g., NestJS)
+- Module structure pattern
+- DTO and validation approach
+- Service layer patterns
+- Repository / data access pattern
+- Error handling (exception filters, typed errors)
+- Authentication and authorization pattern
+- API versioning strategy
+- Testing approach (unit + integration)
+
+#### Database (e.g., PostgreSQL)
+- Schema design approach (normalized vs denormalized for use case)
+- Migration strategy and tooling
+- Indexing guidelines for expected queries
+- Connection pooling approach
+- Backup and recovery (if production level)
+
+#### Infrastructure (e.g., Docker)
+- Container structure (multi-stage builds, compose setup)
+- Environment management (dev/staging/prod)
+- CI/CD pipeline pattern
+- Monitoring and logging stack
+
+### Step 3: Define API Contract Style
+
+Based on project needs:
+- REST: resource-based, OpenAPI spec, versioning scheme
+- GraphQL: schema-first vs code-first, resolver patterns
+- tRPC: shared types, router structure
+- gRPC: proto file organization, service boundaries
+
+### Step 4: Cross-Cutting Patterns
+
+Define patterns that span all layers:
+- **Authentication flow**: complete auth pattern (signup, login, token refresh, logout)
+- **Authorization**: RBAC, ABAC, or simple role checks
+- **Error handling**: typed errors, error codes, user-facing messages
+- **Logging**: structured logging format, log levels, sensitive data masking
+- **Validation**: where validation happens (API layer, domain layer, both)
+- **Testing**: test pyramid ratios for this project level
+
+### Step 5: Write Architecture Doc
+
+Write `artifacts/architecture.md`:
+
+```markdown
+# Architecture: <Project/Task Name>
+
+## Architecture Pattern: <Pattern Name>
+**Rationale**: <why this pattern for this project>
+**Alternative considered**: <pattern and why rejected>
+
+## Layer Diagram
+<describe layers and dependencies>
+
+## Module Structure
+<how code is organized — by feature, by layer, hybrid>
+
+## Component Interaction
+<how layers communicate — direct calls, events, DTOs>
+
+## Cross-Cutting Concerns
+### Authentication: <pattern>
+### Error Handling: <pattern>
+### Logging: <pattern>
+### Validation: <pattern>
+
+## Key Architecture Decisions
+| Decision | Choice | Rationale | Alternative |
+|----------|--------|-----------|-------------|
+| <decision> | <choice> | <why> | <what else> |
+```
+
+### Step 6: Write Best Practices Constraints
+
+Write `artifacts/tech-bestpractices.md` — this is the **constraint document**
+that PRD writer must follow:
+
+```markdown
+# Technical Best Practices & Constraints
+
+## How to Use This Document
+Every requirement in the PRD MUST be compatible with these constraints.
+The consistency-checker (Phase 5) validates PRD against these rules.
+
+## Frontend Constraints (<technology>)
+### MUST
+- [ ] <constraint 1 — e.g., "Use Server Components by default, Client only when needed">
+- [ ] <constraint 2>
+### MUST NOT
+- [ ] <antipattern 1 — e.g., "Do not use getServerSideProps in App Router">
+- [ ] <antipattern 2>
+### SHOULD
+- [ ] <recommendation 1>
+
+## Backend Constraints (<technology>)
+### MUST
+- [ ] ...
+### MUST NOT
+- [ ] ...
+### SHOULD
+- [ ] ...
+
+## Database Constraints (<technology>)
+### MUST
+- [ ] ...
+### MUST NOT
+- [ ] ...
+
+## API Constraints
+### MUST
+- [ ] ...
+
+## Infrastructure Constraints
+### MUST
+- [ ] ...
+
+## Testing Constraints
+### MUST
+- [ ] <e.g., "Every API endpoint must have integration test">
+- [ ] <e.g., "Critical user flows must have e2e tests">
+### Test Pyramid Target
+- Unit: <X>%
+- Integration: <Y>%
+- E2E: <Z>%
+
+## Security Constraints
+### MUST
+- [ ] ...
+### MUST NOT
+- [ ] ...
+```
+
+### Step 7: Return Summary
+
+Compact summary: architecture pattern, number of constraints defined,
+key per-tech decisions, any concerns about pattern compatibility.

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

@@ -0,0 +1,33 @@
+---
+name: gproject-planner
+description: "Generates roadmap, milestones, task breakdown with dependency graph and effort estimates from approved PRD. Use when: dispatched by gproject-orchestrator Phase 6."
+triggers:
+  - "gproject-planner: generate roadmap"
+  - "Dispatched by gproject-orchestrator Phase 6"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+
+# gproject-planner
+
+## Purpose
+
+Transform approved PRD into an actionable implementation plan with milestones,
+task breakdown, dependency ordering, and effort estimates. Output is ready
+to feed into job-orchestrator or task-implementer.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Every task MUST trace to a user story in PRD |
+| 2 | Dependencies MUST form a DAG — no circular dependencies |
+| 3 | Estimates are ranges (optimistic / realistic / pessimistic), never single numbers |
+| 4 | P0 user stories MUST be in Milestone 1 |
+| 5 | Each milestone MUST be independently deployable / demonstrable |
+| 6 | Infrastructure and setup tasks come before feature tasks |

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

@@ -0,0 +1,33 @@
+---
+name: gproject-planner
+description: "Generates roadmap, milestones, task breakdown with dependency graph and effort estimates from approved PRD. Use when: dispatched by gproject-orchestrator Phase 6."
+triggers:
+  - "gproject-planner: generate roadmap"
+  - "Dispatched by gproject-orchestrator Phase 6"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+
+# gproject-planner
+
+## Purpose
+
+Transform approved PRD into an actionable implementation plan with milestones,
+task breakdown, dependency ordering, and effort estimates. Output is ready
+to feed into job-orchestrator or task-implementer.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Every task MUST trace to a user story in PRD |
+| 2 | Dependencies MUST form a DAG — no circular dependencies |
+| 3 | Estimates are ranges (optimistic / realistic / pessimistic), never single numbers |
+| 4 | P0 user stories MUST be in Milestone 1 |
+| 5 | Each milestone MUST be independently deployable / demonstrable |
+| 6 | Infrastructure and setup tasks come before feature tasks |