@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/skills/orchestration/task-implementer/orchestrator-prompt.md

@@ -0,0 +1,206 @@
+# Task Implementer — Orchestrator Prompt
+
+> **Purpose:** Template used by `wave-executor` (dispatched by `job-orchestrator`) to dispatch `task-implementer` as a sub-agent.
+> The wave-executor fills in the placeholders below and sends the result as a Task prompt.
+> The task-implementer executes SKILL.md autonomously, writes the full JSON result to a file, and returns a compact STATUS response.
+
+## Data Flow
+
+```
+[job-orchestrator] → dispatches wave-executor per wave (not task-implementer directly)
+                                    ↓
+[wave-executor]    → extracts tasks → fills template → Task(task-implementer) × N (parallel)
+                                                                  ↓
+[task-implementer] → executes SKILL.md → writes JSON to .metaproject/jobs/<job-name>/results/<task_id>.json
+                                                                  ↓
+[Result]           → compact STATUS: DONE response (no inline JSON)
+                                    ↓
+[wave-executor]    → collects STATUS responses → returns compact WAVE_DONE summary
+                                    ↓
+[job-orchestrator] → receives one-line wave summary per wave
+```
+
+## Step 1: Extract Task Parameters
+
+From the issue-analyzer JSON output, extract one task object:
+
+```
+TASK:
+  task_id              → from tasks[i].task_id
+  task_name            → from tasks[i].task_name
+  task_type            → from tasks[i].task_type
+  complexity           → from tasks[i].complexity
+  dependencies         → from tasks[i].dependencies (already satisfied — dispatch in dependency_order)
+  description          → from tasks[i].description
+  target_files         → from tasks[i].target_files
+  acceptance_criteria  → from tasks[i].acceptance_criteria
+  context              → from tasks[i].context
+  existing_tests       → from tasks[i].existing_tests
+  existing_stories     → from tasks[i].existing_stories
+  module_patterns      → from tasks[i].module_patterns
+
+WORKSPACE:
+  codebase_path        → absolute path to project repo (worktree path)
+  branch               → feature branch name (already checked out in worktree)
+  issue_number         → GitHub issue number
+  issue_title          → GitHub issue title
+
+JOB_CONTEXT (optional):
+  job_name             → job folder name
+  context_path         → <JOBS_ROOT>/<job-name>/ai/context.md
+```
+
+## Step 2: Validate
+
+```
+ASSERT task_id is not empty         → otherwise ABORT: "Missing task_id"
+ASSERT task_type in valid types     → otherwise ABORT: "Invalid task_type"
+ASSERT target_files is not empty    → otherwise ABORT: "No target files"
+ASSERT codebase_path exists         → otherwise ABORT: "Codebase path not found"
+```
+
+## Step 3: Build Sub-Agent Prompt (regular task)
+
+```
+You are running the task-implementer skill in AUTONOMOUS MODE.
+DO NOT ask the user any questions. Execute the full workflow end-to-end.
+
+Load the skill: task-implementer (from skills/task-implementer/SKILL.md)
+
+═══════════════════════════════════════════════
+  TASK
+═══════════════════════════════════════════════
+
+{
+  "task_id": "<TASK_ID>",
+  "task_name": "<TASK_NAME>",
+  "task_type": "<TASK_TYPE>",
+  "complexity": "<COMPLEXITY>",
+  "dependencies": [<DEPENDENCY_LIST>],
+  "description": "<DESCRIPTION>",
+  "target_files": [<TARGET_FILES_LIST>],
+  "acceptance_criteria": [<ACCEPTANCE_CRITERIA_LIST>],
+  "context": "<CONTEXT>",
+  "existing_tests": [<EXISTING_TESTS_LIST>],
+  "existing_stories": [<EXISTING_STORIES_LIST>],
+  "module_patterns": "<MODULE_PATTERNS>"
+}
+
+═══════════════════════════════════════════════
+  WORKSPACE
+═══════════════════════════════════════════════
+
+CODEBASE_PATH: <CODEBASE_PATH>
+BRANCH:        <BRANCH>
+ISSUE_NUMBER:  <ISSUE_NUMBER>
+ISSUE_TITLE:   <ISSUE_TITLE>
+
+<!-- If job context available: -->
+JOB_NAME:     <JOB_NAME>
+CONTEXT_PATH: <JOBS_ROOT>/<JOB_NAME>/ai/context.md
+
+═══════════════════════════════════════════════
+  AUTOMATION SETTINGS
+═══════════════════════════════════════════════
+
+1. CONFIRMATION: SKIP. Proceed immediately.
+2. AUTO COMMIT: true
+3. VERIFY LINT: true
+4. VERIFY TYPES: true
+5. VERIFY TESTS: true
+6. MAX SELF-FIX ATTEMPTS: 3
+
+═══════════════════════════════════════════════
+  EXECUTION INSTRUCTIONS
+═══════════════════════════════════════════════
+
+1. Load task-implementer SKILL.md
+2. Execute all 6 phases: RECEIVE → RESEARCH → PLAN → IMPLEMENT → VERIFY → REPORT
+3. Phase 6: Write full JSON result to <JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json
+4. Return a compact STATUS response as your FINAL MESSAGE — NO inline JSON:
+
+   STATUS: DONE
+   ## Completed
+   - <what was done>
+   ## Files changed
+   - <file> — <change>
+   ## Verification
+   - lint: pass / type-check: pass / tests: N passed
+   Result file: <JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json
+
+DO NOT ask questions. DO NOT stop for user input. DO NOT include the JSON block in your response. Run to completion.
+```
+
+## Step 4: Build Sub-Agent Prompt (fix task)
+
+For fix tasks dispatched from the review loop:
+
+```
+You are running the task-implementer skill in FIX MODE (AUTONOMOUS).
+DO NOT ask the user any questions. Execute the full workflow end-to-end.
+
+Load the skill: task-implementer (from skills/task-implementer/SKILL.md)
+
+═══════════════════════════════════════════════
+  FIX TASK
+═══════════════════════════════════════════════
+
+{
+  "task_id": "fix-<ITERATION>",
+  "task_name": "Fix review findings — iteration <ITERATION>",
+  "task_type": "fix",
+  "complexity": "medium",
+  "dependencies": [],
+  "description": "Fix review findings from iteration <ITERATION>",
+  "target_files": [<FILES_WITH_FINDINGS>],
+  "acceptance_criteria": ["All CRITICAL and WARNING findings resolved"],
+  "context": "",
+  "existing_tests": [],
+  "existing_stories": [],
+  "module_patterns": ""
+}
+
+FIX_CONTEXT:
+{
+  "review_feedback": <REVIEW_FINDINGS_JSON>,
+  "original_task_ids": [<ORIGINAL_TASK_IDS>],
+  "iteration": <ITERATION_NUMBER>
+}
+
+WORKSPACE: (same as above)
+
+AUTOMATION SETTINGS: (same as above)
+
+EXECUTION: Run to completion, return JSON result.
+```
+
+---
+
+## Example Task Tool Call
+
+```javascript
+Task({
+  description: "Implement task-1: <TASK_NAME>",
+  subagent_type: "general",
+  prompt: "<generated prompt from template above>"
+})
+```
+
+---
+
+## Parsing the Result (wave-executor)
+
+After receiving the sub-agent STATUS response, the wave-executor must:
+
+1. Read the STATUS line: `DONE` | `DONE_WITH_CONCERNS` | `BLOCKED`
+2. Extract compact summary from the response:
+   - Files changed section
+   - Verification results
+   - Commits (from "Completed" bullets or result file)
+3. **Read the result file** only when needed (DONE_WITH_CONCERNS or BLOCKED):
+   - Path: `<JOBS_ROOT>/<JOB_NAME>/results/<task_id>.json`
+   - Fields: task_id, status, files_modified, files_created, commits, lint_result, type_check_result, test_result, acceptance_criteria_met
+4. Decision based on STATUS:
+   - `DONE` → continue, collect commit hashes from response
+   - `DONE_WITH_CONCERNS` → read result file, log concerns, continue
+   - `BLOCKED` → STOP wave, report to orchestrator with reason

package/src/gdskills/bundled/skills/orchestration/task-implementer/output-contract.schema.json

@@ -0,0 +1,51 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://keryx.local/schemas/task-implementer/output-contract.schema.json",
+  "title": "Task Implementer Output Contract",
+  "description": "JSON result returned by task-implementer after executing a task. Replaces the previous Gherkin format.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["task_id", "task_name", "task_type", "status"],
+  "properties": {
+    "task_id": { "type": "string", "pattern": "^task-[0-9]+$" },
+    "task_name": { "type": "string" },
+    "task_type": {
+      "type": "string",
+      "enum": ["ui_component", "store_logic", "service_api", "refactoring", "fix", "mixed"]
+    },
+    "status": {
+      "type": "string",
+      "enum": ["success", "partial", "failed"],
+      "description": "success: all criteria met, all verifications pass; partial: some criteria met or verification failures; failed: critical blockers"
+    },
+    "description": { "type": "string", "description": "What was implemented" },
+    "files_modified": { "type": "array", "items": { "type": "string" } },
+    "files_created": { "type": "array", "items": { "type": "string" } },
+    "files_deleted": { "type": "array", "items": { "type": "string" } },
+    "commits": { "type": "array", "items": { "type": "string" } },
+    "lint_result": {
+      "type": "string",
+      "description": "pass OR 'N errors: <details>'"
+    },
+    "type_check_result": {
+      "type": "string",
+      "description": "pass OR 'N errors: <details>'"
+    },
+    "test_result": {
+      "type": "string",
+      "description": "pass OR 'N passed, M failed: <details>' OR 'skipped'"
+    },
+    "story_result": {
+      "type": "string",
+      "description": "pass OR 'build error: <details>' OR 'not applicable'"
+    },
+    "acceptance_criteria_met": {
+      "type": "string",
+      "description": "all OR 'partial: <list of unmet criteria>' OR none"
+    },
+    "notes": {
+      "type": "string",
+      "description": "Warnings, blockers, or additional context"
+    }
+  }
+}

package/src/gdskills/bundled/skills/orchestration/task-implementer/task-request.template.md

@@ -0,0 +1,111 @@
+# Task Implementer — Task Request
+
+<!--
+  ШАБЛОН ЗАПРОСА НА ИМПЛЕМЕНТАЦИЮ ЗАДАЧИ
+  =======================================
+  Заполняется оркестратором ПЕРЕД запуском task-implementer.
+  Все обязательные поля (*) должны быть заполнены.
+  
+  Валидация: input-contract.schema.json
+  Использование: orchestrator-prompt.md читает этот файл и формирует промпт для субагента.
+-->
+
+## Task *
+
+| Field | Value |
+|-------|-------|
+| Task ID * | `task-1` |
+| Task Name * | `Add validation to pipeline step form` |
+| Task Type * | `ui_component` |
+| Complexity | `medium` |
+| Dependencies | `none` |
+
+## Description *
+
+<!-- Полное описание задачи из Scenario issue-analyzer -->
+
+Add client-side validation to the pipeline step configuration form. Validate required fields (name, type) before allowing save. Show inline error messages using Ant Design Form validation.
+
+## Target Files *
+
+| Path | Action |
+|------|--------|
+| `src/pipelines/components/StepForm.tsx` | `modify` |
+| `src/pipelines/components/StepForm.test.tsx` | `create` |
+| `src/pipelines/components/StepForm.stories.tsx` | `create` |
+
+## Acceptance Criteria *
+
+- Required fields show validation errors when empty on submit
+- Form cannot be submitted with invalid data
+- Error messages disappear when field is corrected
+- Validation follows existing form patterns in the project
+
+## Context
+
+<!-- Контекст кода: типы, сигнатуры, паттерны -->
+
+```typescript
+// Existing type from src/pipelines/types.ts
+interface StepConfig {
+  name: string;
+  type: StepType;
+  params: Record<string, unknown>;
+}
+```
+
+## Existing Tests
+
+| Path |
+|------|
+| `none` |
+
+## Existing Stories
+
+| Path |
+|------|
+| `none` |
+
+## Module Patterns
+
+<!-- Как написан похожий код в этом модуле -->
+
+Components in `src/pipelines/components/` use `observer()` wrapping, props interfaces named `<Component>Props`, Ant Design `Form` with `useForm` hook. Validation uses `rules` prop on `Form.Item`.
+
+## Workspace *
+
+| Field | Value |
+|-------|-------|
+| Codebase Path * | `/Users/dev/<PROJECT>` |
+| Branch * | `feature/4141-add-pipeline-validation` |
+| Issue Number * | `4141` |
+| Issue Title | `Add validation to pipeline step form` |
+
+## Fix Context (only for fix tasks)
+
+<!-- Заполняется только если task_type = "fix" и задача пришла из review loop -->
+
+| Field | Value |
+|-------|-------|
+| Original Task ID | |
+| Iteration | |
+
+### Review Feedback
+
+<!-- Structured findings from reviewers -->
+
+| File | Line | Severity | Message | Reviewer |
+|------|------|----------|---------|----------|
+| | | | | |
+
+## Automation Settings *
+
+| Setting | Value | Description |
+|---------|-------|-------------|
+| skip_confirmation * | `true` | Must be true for autonomous mode |
+| auto_commit | `true` | Commit changes after implementation |
+| verify_lint | `true` | Run ESLint |
+| verify_types | `true` | Run type-check |
+| verify_tests | `true` | Run tests |
+| verify_stories | `false` | Build storybook |
+| max_self_fix_attempts | `3` | Max self-fix attempts |

package/src/gdskills/bundled/skills/planning/autodoc-analyst/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: autodoc-analyst
+description: >
+  Phase 2 subagent for autodoc-orchestrator. Deep-dives into a single module
+  to extract purpose, structure, public API surface, patterns, and key dependencies.
+  Use when: dispatched by autodoc-orchestrator Phase 2 (one instance per module).
+  NOT for: direct user invocation.
+version: 1.0.0
+---
+
+# autodoc-analyst
+
+## Purpose
+
+Produce a complete semantic understanding of one module that the architect
+and writers can use without re-reading the source code.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Analyze ONE module per invocation — do not cross module boundaries |
+| 2 | Read actual source files — understanding must come from code, not assumptions |
+| 3 | Prioritize: public interfaces > internal implementation > tests |
+| 4 | Document what the code DOES, not how it does it internally |
+| 5 | Extract concrete examples from code (real function names, real endpoints) |
+
+---
+
+## Input Contract
+
+```yaml
+module:
+  slug: "<module slug>"
+  path: "<absolute module path>"
+  type: "backend | frontend | shared | ..."
+  language: "<lang>"
+  framework: "<framework>"
+  entry_points: ["<file>"]
+project_map: ".metaproject/jobs/<job>/artifacts/project-map.md"
+JOB_DIR: "<job directory>"
+CONFIG: "<from state.json.config>"
+```
+
+## Output Contract
+
+```yaml
+status: "DONE" | "DONE_WITH_CONCERNS" | "NEEDS_CONTEXT"
+summary: "<3-5 sentences: what the module does, its main components, key patterns>"
+concerns: ["<concern>"]
+artifact_path: ".metaproject/jobs/<job>/artifacts/analysis/<slug>.md"
+```
+
+---
+
+## Workflow
+
+### Step 1: Entry Point Analysis
+
+Read the entry point file(s) listed in project-map. Understand:
+- What is bootstrapped / initialized?
+- What are the top-level exports?
+- What dependencies are injected or imported?
+
+### Step 2: Module Structure Mapping
+
+Read directory structure 2-3 levels deep. Identify organizational pattern:
+
+| Pattern | Indicators |
+|---------|-----------|
+| Feature-based | `src/features/`, `src/modules/` with self-contained subdirs |
+| Layer-based | `controllers/`, `services/`, `repositories/` at top level |
+| DDD | `domain/`, `application/`, `infrastructure/`, `presentation/` |
+| Component-based (frontend) | `components/`, `pages/`, `hooks/`, `stores/` |
+
+### Step 3: Public API Surface Extraction
+
+For **backend modules**:
+- Find controller/router files → extract endpoints (method, path, description)
+- Find DTO/schema files → extract request/response shapes
+- Find exported service methods → extract public operations
+
+For **frontend modules**:
+- Find page/route components → extract routes
+- Find exported components → extract component library
+- Find custom hooks → extract hook API
+- Find store/state definitions → extract state shape
+
+For **shared/lib modules**:
+- Find index.ts exports → extract public API
+- Find type definitions → extract key types and interfaces
+
+### Step 4: Pattern Detection
+
+Identify patterns actually used in the code:
+
+| Pattern | What to look for |
+|---------|----------------|
+| Dependency Injection | `@Injectable`, `@Module`, constructor params, containers |
+| Repository pattern | `Repository`, `findById`, `save`, `delete` methods |
+| CQRS | `Command`, `Query`, `Handler`, `Bus` classes |
+| Event-driven | `EventEmitter`, `@OnEvent`, message queue clients |
+| React Query / SWR | `useQuery`, `useMutation` hook patterns |
+| MobX | `@observable`, `@action`, `makeAutoObservable` |
+| Redux | `createSlice`, `createAsyncThunk`, `useSelector` |
+
+### Step 5: Dependencies & Integrations
+
+From imports and config files, identify:
+- External services (databases, queues, caches, auth providers)
+- Internal cross-module dependencies
+- Third-party libraries central to the module's function
+
+### Step 6: Write Analysis Artifact
+
+```markdown
+# Module Analysis: <Module Name>
+
+## Purpose
+<1-2 paragraphs: what this module does, what problem it solves>
+
+## Architecture Pattern
+<pattern name + brief explanation>
+
+## Structure
+<annotated directory tree, 2-3 levels>
+
+## Public API
+
+### Endpoints (backend) / Routes (frontend)
+| Method | Path | Description |
+|--------|------|-------------|
+
+### Key Exports / Components / Services
+| Name | Type | Purpose |
+|------|------|---------|
+
+### Data Models / DTOs
+| Model | Fields (key ones) | Used in |
+|-------|------------------|---------|
+
+## Key Patterns Used
+<list with brief explanation of each>
+
+## External Dependencies
+| Dependency | Purpose |
+|-----------|---------|
+
+## Internal Dependencies
+<which other modules this module depends on>
+
+## Configuration
+<env vars, config files, feature flags used>
+
+## Error Handling
+<how errors are handled and propagated>
+
+## Testing
+<test coverage summary, test patterns used>
+
+## Notes & Observations
+<unusual patterns, technical debt, important constraints>
+```

package/src/gdskills/bundled/skills/planning/autodoc-architect/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: autodoc-architect
+description: >
+  Phase 3 subagent for autodoc-orchestrator. Synthesizes all module analyses
+  into a system-level architecture description: layers, data flows, integration
+  points, and cross-cutting concerns.
+  Use when: dispatched by autodoc-orchestrator Phase 3.
+  NOT for: direct user invocation.
+version: 1.0.0
+---
+
+# autodoc-architect
+
+## Purpose
+
+Derive the overall system architecture from individual module analyses.
+Produce a unified architecture document that captures how the modules
+fit together — something no single module analyst can see alone.
+
+## Iron Laws
+
+| # | Law |
+|---|-----|
+| 1 | Read ALL module analysis artifacts — no module may be ignored |
+| 2 | Derive architecture from evidence in the analyses — no assumptions |
+| 3 | Map ALL cross-module interactions found in the analyses |
+| 4 | Identify the system's architectural style (what it IS, not what it should be) |
+
+---
+
+## Input Contract
+
+```yaml
+project_map: ".metaproject/jobs/<job>/artifacts/project-map.md"
+module_analyses: ".metaproject/jobs/<job>/artifacts/analysis/*.md"  # read all
+JOB_DIR: "<job directory>"
+```
+
+## Output Contract
+
+```yaml
+status: "DONE" | "DONE_WITH_CONCERNS"
+summary: "<3-5 sentences: architectural style, key patterns, integration topology>"
+concerns: ["<concern if any>"]
+artifact_path: ".metaproject/jobs/<job>/artifacts/architecture.md"
+```
+
+---
+
+## Workflow
+
+### Step 1: Read All Artifacts
+
+Read `project-map.md` and every `analysis/*.md` file. Build mental model of:
+- How many modules exist and what each does
+- What each module exposes to others
+- What each module depends on
+
+### Step 2: Identify Architectural Style
+
+From the evidence across all modules, determine the dominant architectural style:
+
+| Style | Indicators |
+|-------|-----------|
+| Monolith | Single deployable, shared DB, shared process |
+| Modular monolith | Single deployable, feature-separated modules, isolated data |
+| Microservices | Multiple deployables, service discovery, message bus |
+| BFF (Backend for Frontend) | Dedicated API layer per client type |
+| Layered (N-tier) | Strict Presentation → Business → Data layers |
+| Event-driven | Async messaging, event sourcing, CQRS |
+| Hexagonal / Clean | Ports+adapters, domain-centric, dependency inversion |
+
+### Step 3: Map System Topology
+
+Draw the integration map:
+- Which modules communicate with which
+- What protocol (HTTP, gRPC, message queue, shared DB, direct import)
+- Direction of dependency (A → B means A depends on B)
+
+### Step 4: Identify Cross-Cutting Concerns
+
+From evidence across all module analyses:
+- **Authentication**: where it's enforced, what mechanism
+- **Authorization**: RBAC, ABAC, policy-based
+- **Logging**: centralized or per-module, log aggregation
+- **Error handling**: global handlers, error propagation patterns
+- **Caching**: what's cached, where, eviction strategy
+- **Configuration**: how config is injected (env, config service, remote)
+- **Observability**: metrics, tracing, health checks
+
+### Step 5: Data Flow Mapping
+
+Trace the main user journeys through the system:
+- Request ingress (API gateway, load balancer, CDN)
+- Processing path (which modules touch the request)
+- Data persistence (which databases/caches are involved)
+- Response path
+
+### Step 6: Write Architecture Artifact
+
+```markdown
+# System Architecture: <Project Name>
+
+## Architectural Style
+<name + 1-paragraph description of why this style is evident in the codebase>
+
+## System Overview
+
+### Components
+| Component | Type | Technology | Responsibility |
+|-----------|------|-----------|---------------|
+
+### Integration Map
+<textual description of connections>
+Module A → Module B (HTTP/REST)
+Module B → Module C (async, RabbitMQ)
+Module B → PostgreSQL (Prisma ORM)
+
+## Layer Breakdown
+
+### <Layer Name>
+<what lives here, what it's responsible for, what it depends on>
+
+## Cross-Cutting Concerns
+
+### Authentication & Authorization
+<mechanism, enforcement points>
+
+### Error Handling
+<strategy, propagation, user-facing errors>
+
+### Logging & Observability
+<approach, tools, what's instrumented>
+
+### Configuration
+<how config reaches services>
+
+### Caching
+<what, where, how>
+
+## Data Flow
+
+### Main Request Path
+1. <step>
+2. <step>
+...
+
+### Key Data Stores
+| Store | Type | Used By | Data |
+|-------|------|---------|------|
+
+## Deployment Architecture
+<what deploys where, containerization, orchestration>
+
+## Key Architectural Decisions
+| Decision | Choice | Evidence from Code |
+|----------|--------|--------------------|
+
+## Technical Observations
+<technical debt, inconsistencies between modules, areas of improvement>
+```