@mrciphersmith/keryx 0.2.9

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

@@ -0,0 +1,190 @@
+---
+name: gproject-planner
+description: >
+  Generates roadmap, milestones, task breakdown, and dependency graph from PRD.
+  Use when: dispatched by gproject-orchestrator Phase 6.
+  NOT for: direct user invocation.
+version: 1.0.0
+---
+
+# 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 |
+
+---
+
+## Input Contract
+
+```yaml
+task: "Generate roadmap and task breakdown"
+input_artifacts:
+  - .metaproject/jobs/<job>/artifacts/prd.md
+  - .metaproject/jobs/<job>/artifacts/architecture.md
+decisions_so_far:
+  D_level: "..."
+  D_frontend: "..."
+  D_backend: "..."
+  # All relevant decisions
+```
+
+## Output Contract
+
+```yaml
+status: "DONE" | "NEEDS_CONTEXT"
+summary: "<3-5 sentences: milestone count, total tasks, critical path duration>"
+new_decisions:
+  D_milestones: ["<M1 name>", "<M2 name>", ...]
+  D_estimated_duration: "<range>"
+  D_critical_path: "<list of blocking tasks>"
+artifact_path: ".metaproject/jobs/<job>/artifacts/roadmap.md"
+```
+
+---
+
+## Workflow
+
+### Step 1: Decompose User Stories into Tasks
+
+For each user story, break into implementation tasks:
+
+```yaml
+- task_id: "T-001"
+  title: "<specific task>"
+  user_story: "US-001"
+  layer: "frontend | backend | database | infra | testing"
+  type: "setup | feature | integration | test | docs"
+  estimate:
+    optimistic: "<time>"
+    realistic: "<time>"
+    pessimistic: "<time>"
+  depends_on: ["T-000"]  # or [] if no deps
+  acceptance_criteria:
+    - "<from user story, scoped to this task>"
+  files_likely_affected:
+    - "<file path or module>"
+```
+
+### Step 2: Identify Dependencies
+
+Build dependency graph:
+- Infrastructure tasks → before all feature tasks
+- Database schema → before backend → before frontend
+- Auth setup → before any authenticated feature
+- Shared components → before pages that use them
+
+Verify: no cycles in dependency graph.
+
+### Step 3: Group into Milestones
+
+Each milestone:
+- Has a clear deliverable (demo-able, deployable)
+- Contains all P0 stories it covers (no half-done P0 at milestone end)
+- Ends with a verification checkpoint
+
+Typical milestone structure:
+
+**M0: Foundation**
+- Project setup, tooling, CI/CD, dev environment
+- Database schema initial migration
+- Auth skeleton
+- Deploy pipeline to staging
+
+**M1: Core (P0 features)**
+- All P0 user stories
+- Core API endpoints
+- Core UI flows
+- Integration tests for critical paths
+
+**M2: Complete (P1 features)**
+- P1 user stories
+- Polish, edge cases
+- Performance optimization
+- Full test coverage
+
+**M3: Launch-Ready (if production level)**
+- P2 features (selected)
+- Security hardening
+- Monitoring, alerting
+- Documentation
+- Load testing
+
+### Step 4: Estimate Critical Path
+
+Identify the longest dependency chain and estimate total duration.
+Flag tasks that block the most other tasks.
+
+### Step 5: Write Roadmap
+
+Write `artifacts/roadmap.md`:
+
+```markdown
+# Roadmap: <Project/Task Name>
+
+## Overview
+- **Milestones**: <count>
+- **Total tasks**: <count>
+- **Estimated duration**: <optimistic> — <realistic> — <pessimistic>
+- **Critical path**: <list of blocking tasks>
+
+## Milestone 0: Foundation
+**Deliverable**: <what can be demonstrated>
+**Duration estimate**: <range>
+
+### Tasks
+| ID | Title | Layer | Depends On | Estimate | Story |
+|----|-------|-------|-----------|----------|-------|
+| T-001 | <title> | infra | — | <range> | — |
+| T-002 | <title> | database | T-001 | <range> | — |
+
+## Milestone 1: Core
+**Deliverable**: <what can be demonstrated>
+**Duration estimate**: <range>
+
+### Tasks
+| ID | Title | Layer | Depends On | Estimate | Story |
+|----|-------|-------|-----------|----------|-------|
+| T-010 | <title> | backend | T-002 | <range> | US-001 |
+
+## ...
+
+## Dependency Graph (summary)
+<textual description of key dependency chains>
+T-001 → T-002 → T-010 → T-015 (critical path)
+T-001 → T-003 → T-011 (parallel track)
+
+## Risk-Adjusted Timeline
+| Scenario | Duration | Assumptions |
+|----------|---------|-------------|
+| Optimistic | <time> | No blockers, all estimates hold |
+| Realistic | <time> | Normal friction, 1-2 minor blockers |
+| Pessimistic | <time> | Major unknowns surface, rework needed |
+
+## Parallelization Opportunities
+<Which tasks can run simultaneously — useful for team or multi-agent execution>
+
+## Integration with job-orchestrator
+<How to feed this roadmap into job-orchestrator for automated implementation>
+- Each milestone maps to a job-orchestrator run
+- Tasks within a milestone map to issue-analyzer output format
+- Dependency order maps to wave-based execution
+```
+
+### Step 6: Return Summary
+
+Compact summary: milestone count, task count, critical path duration,
+biggest scheduling risk.

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

@@ -0,0 +1,193 @@
+---
+name: prd-creator
+description: "Transforms unstructured user requests into structured, complete, and testable Product Requirements Documents (PRD). Operates in Direct Mode for user interaction and Orchestrated Mode for pipelined multi-agent workflows."
+triggers:
+  - "Create a PRD"
+  - "Formulate requirements"
+  - "Write a product requirements document"
+  - "Draft PRD"
+  - "Analyze requirements"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+# 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: `.metaproject/jobs/<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

@@ -0,0 +1,193 @@
+---
+name: prd-creator
+description: "Transforms unstructured user requests into structured, complete, and testable Product Requirements Documents (PRD). Operates in Direct Mode for user interaction and Orchestrated Mode for pipelined multi-agent workflows."
+triggers:
+  - "Create a PRD"
+  - "Formulate requirements"
+  - "Write a product requirements document"
+  - "Draft PRD"
+  - "Analyze requirements"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "planning"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode"
+---
+
+# 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: `.metaproject/jobs/<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.