@mrciphersmith/keryx 0.2.71 → 0.2.73

package/src/gdskills/bundled/skills/orchestration/feature-analyzer/orchestrator-prompt.md

@@ -308,7 +308,7 @@ FOCUS AREA:
 ```javascript
 Task({
   description: "Feature analysis: pipeline-variables",
-  subagent_type: "general",
+  subagent_type: "general-purpose",
   prompt: "<сгенерированный промпт выше>"
 })
 ```

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.codex.md

@@ -1,6 +1,6 @@
 ---
 name: feature-dev
-description: "7-phase feature development workflow: requirements → design → implement → test → review → fix → PR. Full cycle from idea or GitHub issue to merge-ready PR. Confirms requirements and design with user before autonomous execution."
+description: "Use when taking a feature from idea or GitHub issue all the way to a merge-ready PR in one guided workflow."
 triggers:
   - "/feature-dev"
   - "Develop feature"
@@ -9,12 +9,18 @@ triggers:
   - "Feature from scratch"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "2.0.0"
   category: "workflow"
   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 interactive feature development sessions only.
+Proceed directly with your assigned task.
+</SUBAGENT-STOP>
+
 # Feature Development (7-Phase)
 
 End-to-end feature development workflow from idea to merge-ready PR.
@@ -25,66 +31,104 @@ End-to-end feature development workflow from idea to merge-ready PR.
 - `/feature-dev #<issue>` — start from a GitHub issue
 - `/feature-dev --resume` — resume interrupted feature-dev (checks for existing worktree/branch)
 
-## 7-Phase Architecture
+## 8-Phase Architecture
+
+> **Rules always loaded:** `tdd-workflow.mdc`, `implementation-doc-mandate.mdc`, `error-handling.mdc`
+> **Sub-agents used:** `tests-creator` (before implement), `code-verifier` (after implement)
+
+### Phase 1: REQUIREMENTS + SPEC
 
-### Phase 1: REQUIREMENTS
 1. Parse input (description or GitHub issue via `gh issue view`)
 2. Clarify ambiguities — ask the user up to 3 questions max
-3. Produce a brief spec:
+3. Produce the **Implementation Spec** (per `implementation-doc-mandate.mdc`):
    - **What**: feature description in 2-3 sentences
    - **Why**: user value / business reason
    - **Scope**: what's in, what's explicitly out
    - **Acceptance criteria**: testable bullet points
-4. **Get user confirmation before proceeding**
+   - **Approach**: which files will change, key design decisions
+   - **Test strategy**: framework, which scenarios will be covered
+4. **Save spec** to `.feature-spec.md` in project root (add to .gitignore if not already)
+5. **Get user confirmation before proceeding**
 
 ### Phase 2: DESIGN
+
 1. Research the codebase:
    - Find related modules via search tools
    - Read neighboring implementations for patterns
-   - Check existing tests for testing conventions
+   - **Detect test framework** (package.json, existing test files) — needed for tests-creator
 2. Produce implementation plan:
    - Files to create/modify (with brief description of changes)
    - Dependencies or packages needed
    - Data model changes if any
    - Estimated complexity: S / M / L
-3. **Get user confirmation on the plan**
+3. Load relevant rules from `.metaproject/rules/core/` based on what will be built:
+   - Always: `tdd-workflow.mdc`, `error-handling.mdc`, `solid-principles.mdc`
+   - API/service code: `api-contracts.mdc`, `clean-architecture.mdc`
+   - Database: `database-patterns.mdc`
+   - Async: `async-patterns.mdc`
+   - Security-sensitive: `security-baseline.mdc`
+4. **Get user confirmation on the plan**
 
 ### Phase 3: PREPARE
-1. Create a feature branch: `git checkout -b feat/<name>`
-2. If large feature, consider `git worktree add` for isolation
-3. Install any new dependencies
-
-### Phase 4: IMPLEMENT
-1. Implement changes file by file, following the plan
-2. Follow existing code patterns discovered in Phase 2
-3. After each logical chunk, run available checks:
-   - Lint: `npm run lint` or equivalent
-   - Type-check: `npx tsc --noEmit` or equivalent
-   - Fix issues immediately before moving on
-
-### Phase 5: TEST
-1. Write tests matching the project's testing patterns
-2. Unit tests for new functions/modules
-3. Integration tests for API/data flow changes
-4. Run full test suite
-5. Fix failing tests (max 3 attempts per test)
-
-### Phase 6: REVIEW (Self)
-1. Launch `code-review` skill on own changes (if available)
+
+1. Create a feature branch: `wt switch -c feat/<name>`
+2. Install any new dependencies
+
+### Phase 4: TESTS-CREATOR (TDD — RED phase)
+
+**Run before writing any implementation code.**
+
+1. For each group of acceptance criteria, invoke `tests-creator`:
+   - Input: acceptance criteria from Phase 1 spec + target files from Phase 2 plan
+   - tests-creator detects framework and generates failing test stubs
+   - tests-creator commits the stubs and verifies RED state
+2. Confirm test stubs are in place and failing before proceeding to Phase 5
+
+### Phase 5: IMPLEMENT (TDD — GREEN phase)
+
+1. Implement changes file by file, following the plan from Phase 2
+2. Goal: make the failing tests from Phase 4 GREEN
+3. Follow existing code patterns and loaded rules
+4. After each file group, run quick inline check: `npx tsc --noEmit` (type errors only)
+5. Commit with conventional message after each logical chunk
+
+### Phase 6: VERIFY (code-verifier gate)
+
+Run `code-verifier` on the full diff:
+
+```
+Invoke: skills/orchestration/code-verifier/SKILL.md
+Input:  codebase_path=<project_root>, scope=changed, base_branch=<base>
+```
+
+- `gate: PASS` → proceed to Phase 7
+- `gate: FAIL` → fix findings, re-run code-verifier (max 2 cycles)
+- Still FAIL after 2 cycles → report blocker to user, stop
+
+### Phase 7: REVIEW (Self)
+
+1. Launch the `review-orchestrator` skill on own changes
 2. Or run a focused self-review:
    - `git diff main...HEAD` — review the full diff
    - Check for: TODOs left behind, console.logs, hardcoded values
-   - Verify all acceptance criteria from Phase 1
+   - Verify all acceptance criteria from Phase 1 spec
 3. Fix any findings (max 2 review-fix cycles)
+4. Re-run `code-verifier` after any fixes
+
+### Phase 8: DELIVER + CHANGE REPORT
 
-### Phase 7: DELIVER
-1. Final checks: lint + type-check + tests all pass
-2. Commit with conventional message: `feat(<scope>): <description>`
-3. Push branch
-4. Create PR:
+1. Push branch
+2. Create PR:
    - Link to issue if applicable
-   - Include acceptance criteria as checklist
-   - Add test plan
+   - Include acceptance criteria checklist
+   - Add test plan and code-verifier results
+3. **Produce Change Report** (per `implementation-doc-mandate.mdc`):
+   - Files created/modified with descriptions
+   - Test count and results
+   - code-verifier gate result
+   - Acceptance criteria checklist (checked off)
+   - Commits list
+4. Print Change Report to user
 5. Report PR URL to user
 
 ## Status Updates
@@ -97,9 +141,25 @@ At each phase transition, report progress:
 
 ## Rules
 
-- ALWAYS get user confirmation after Phase 1 (requirements) and Phase 2 (design)
-- Phases 4-6 are autonomous — no user interaction needed
+- ALWAYS get user confirmation after Phase 1 (requirements + spec) and Phase 2 (design)
+- Phases 4-7 are autonomous — no user interaction needed
 - If stuck for >3 attempts on any step, report the blocker and ask user
-- NEVER skip Phase 5 (testing) even if user says "skip tests"
-- NEVER commit broken code (lint/type-check must pass)
-- Keep commits atomic: one commit per logical change, not one giant commit
+- NEVER skip Phase 4 (tests-creator) even if user says "skip tests" — this is TDD, not optional testing
+- NEVER skip Phase 6 (code-verifier) — it is the quality gate, not a suggestion
+- NEVER commit broken code (code-verifier gate must pass before PR)
+- Keep commits atomic: one commit per logical chunk, not one giant commit
+- ALWAYS produce the Change Report in Phase 8 — even if the PR was not created
+
+## Red Flags — Stop and re-read this skill if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "Requirements are clear enough, I'll skip the design phase" | Skipping design means discovering mismatches after code is written, not before |
+| "The user already approved this approach verbally, no need to document" | Undocumented approval is invisible to reviewers and future agents; it doesn't exist |
+| "Tests can be written after — implementation first to check if the approach works" | Writing tests after implementation makes you test what you built, not what was required |
+| "This phase isn't needed for such a straightforward feature" | Every skipped phase is a deferred bug report |
+| "I understand the requirements, confirmation is just a formality" | The confirmation step exists to catch the gap between what you understood and what was meant |
+
+**IRON LAW 1: NEVER START IMPLEMENTING BEFORE THE SPEC IS WRITTEN AND CONFIRMED.**
+**IRON LAW 2: NEVER WRITE IMPLEMENTATION CODE BEFORE TESTS-CREATOR HAS GENERATED FAILING STUBS.**
+**IRON LAW 3: NEVER DELIVER WITHOUT A PASSING CODE-VERIFIER GATE AND A CHANGE REPORT.**

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.cursor.md

@@ -1,6 +1,6 @@
 ---
 name: feature-dev
-description: "7-phase feature development workflow: requirements → design → implement → test → review → fix → PR. Full cycle from idea or GitHub issue to merge-ready PR. Confirms requirements and design with user before autonomous execution."
+description: "Use when taking a feature from idea or GitHub issue all the way to a merge-ready PR in one guided workflow."
 triggers:
   - "/feature-dev"
   - "Develop feature"
@@ -9,12 +9,18 @@ triggers:
   - "Feature from scratch"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "2.0.0"
   category: "workflow"
   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 interactive feature development sessions only.
+Proceed directly with your assigned task.
+</SUBAGENT-STOP>
+
 # Feature Development (7-Phase)
 
 End-to-end feature development workflow from idea to merge-ready PR.
@@ -25,66 +31,104 @@ End-to-end feature development workflow from idea to merge-ready PR.
 - `/feature-dev #<issue>` — start from a GitHub issue
 - `/feature-dev --resume` — resume interrupted feature-dev (checks for existing worktree/branch)
 
-## 7-Phase Architecture
+## 8-Phase Architecture
+
+> **Rules always loaded:** `tdd-workflow.mdc`, `implementation-doc-mandate.mdc`, `error-handling.mdc`
+> **Sub-agents used:** `tests-creator` (before implement), `code-verifier` (after implement)
+
+### Phase 1: REQUIREMENTS + SPEC
 
-### Phase 1: REQUIREMENTS
 1. Parse input (description or GitHub issue via `gh issue view`)
 2. Clarify ambiguities — ask the user up to 3 questions max
-3. Produce a brief spec:
+3. Produce the **Implementation Spec** (per `implementation-doc-mandate.mdc`):
    - **What**: feature description in 2-3 sentences
    - **Why**: user value / business reason
    - **Scope**: what's in, what's explicitly out
    - **Acceptance criteria**: testable bullet points
-4. **Get user confirmation before proceeding**
+   - **Approach**: which files will change, key design decisions
+   - **Test strategy**: framework, which scenarios will be covered
+4. **Save spec** to `.feature-spec.md` in project root (add to .gitignore if not already)
+5. **Get user confirmation before proceeding**
 
 ### Phase 2: DESIGN
+
 1. Research the codebase:
    - Find related modules via search tools
    - Read neighboring implementations for patterns
-   - Check existing tests for testing conventions
+   - **Detect test framework** (package.json, existing test files) — needed for tests-creator
 2. Produce implementation plan:
    - Files to create/modify (with brief description of changes)
    - Dependencies or packages needed
    - Data model changes if any
    - Estimated complexity: S / M / L
-3. **Get user confirmation on the plan**
+3. Load relevant rules from `.metaproject/rules/core/` based on what will be built:
+   - Always: `tdd-workflow.mdc`, `error-handling.mdc`, `solid-principles.mdc`
+   - API/service code: `api-contracts.mdc`, `clean-architecture.mdc`
+   - Database: `database-patterns.mdc`
+   - Async: `async-patterns.mdc`
+   - Security-sensitive: `security-baseline.mdc`
+4. **Get user confirmation on the plan**
 
 ### Phase 3: PREPARE
-1. Create a feature branch: `git checkout -b feat/<name>`
-2. If large feature, consider `git worktree add` for isolation
-3. Install any new dependencies
-
-### Phase 4: IMPLEMENT
-1. Implement changes file by file, following the plan
-2. Follow existing code patterns discovered in Phase 2
-3. After each logical chunk, run available checks:
-   - Lint: `npm run lint` or equivalent
-   - Type-check: `npx tsc --noEmit` or equivalent
-   - Fix issues immediately before moving on
-
-### Phase 5: TEST
-1. Write tests matching the project's testing patterns
-2. Unit tests for new functions/modules
-3. Integration tests for API/data flow changes
-4. Run full test suite
-5. Fix failing tests (max 3 attempts per test)
-
-### Phase 6: REVIEW (Self)
-1. Launch `code-review` skill on own changes (if available)
+
+1. Create a feature branch: `wt switch -c feat/<name>`
+2. Install any new dependencies
+
+### Phase 4: TESTS-CREATOR (TDD — RED phase)
+
+**Run before writing any implementation code.**
+
+1. For each group of acceptance criteria, invoke `tests-creator`:
+   - Input: acceptance criteria from Phase 1 spec + target files from Phase 2 plan
+   - tests-creator detects framework and generates failing test stubs
+   - tests-creator commits the stubs and verifies RED state
+2. Confirm test stubs are in place and failing before proceeding to Phase 5
+
+### Phase 5: IMPLEMENT (TDD — GREEN phase)
+
+1. Implement changes file by file, following the plan from Phase 2
+2. Goal: make the failing tests from Phase 4 GREEN
+3. Follow existing code patterns and loaded rules
+4. After each file group, run quick inline check: `npx tsc --noEmit` (type errors only)
+5. Commit with conventional message after each logical chunk
+
+### Phase 6: VERIFY (code-verifier gate)
+
+Run `code-verifier` on the full diff:
+
+```
+Invoke: skills/orchestration/code-verifier/SKILL.md
+Input:  codebase_path=<project_root>, scope=changed, base_branch=<base>
+```
+
+- `gate: PASS` → proceed to Phase 7
+- `gate: FAIL` → fix findings, re-run code-verifier (max 2 cycles)
+- Still FAIL after 2 cycles → report blocker to user, stop
+
+### Phase 7: REVIEW (Self)
+
+1. Launch the `review-orchestrator` skill on own changes
 2. Or run a focused self-review:
    - `git diff main...HEAD` — review the full diff
    - Check for: TODOs left behind, console.logs, hardcoded values
-   - Verify all acceptance criteria from Phase 1
+   - Verify all acceptance criteria from Phase 1 spec
 3. Fix any findings (max 2 review-fix cycles)
+4. Re-run `code-verifier` after any fixes
+
+### Phase 8: DELIVER + CHANGE REPORT
 
-### Phase 7: DELIVER
-1. Final checks: lint + type-check + tests all pass
-2. Commit with conventional message: `feat(<scope>): <description>`
-3. Push branch
-4. Create PR:
+1. Push branch
+2. Create PR:
    - Link to issue if applicable
-   - Include acceptance criteria as checklist
-   - Add test plan
+   - Include acceptance criteria checklist
+   - Add test plan and code-verifier results
+3. **Produce Change Report** (per `implementation-doc-mandate.mdc`):
+   - Files created/modified with descriptions
+   - Test count and results
+   - code-verifier gate result
+   - Acceptance criteria checklist (checked off)
+   - Commits list
+4. Print Change Report to user
 5. Report PR URL to user
 
 ## Status Updates
@@ -97,9 +141,25 @@ At each phase transition, report progress:
 
 ## Rules
 
-- ALWAYS get user confirmation after Phase 1 (requirements) and Phase 2 (design)
-- Phases 4-6 are autonomous — no user interaction needed
+- ALWAYS get user confirmation after Phase 1 (requirements + spec) and Phase 2 (design)
+- Phases 4-7 are autonomous — no user interaction needed
 - If stuck for >3 attempts on any step, report the blocker and ask user
-- NEVER skip Phase 5 (testing) even if user says "skip tests"
-- NEVER commit broken code (lint/type-check must pass)
-- Keep commits atomic: one commit per logical change, not one giant commit
+- NEVER skip Phase 4 (tests-creator) even if user says "skip tests" — this is TDD, not optional testing
+- NEVER skip Phase 6 (code-verifier) — it is the quality gate, not a suggestion
+- NEVER commit broken code (code-verifier gate must pass before PR)
+- Keep commits atomic: one commit per logical chunk, not one giant commit
+- ALWAYS produce the Change Report in Phase 8 — even if the PR was not created
+
+## Red Flags — Stop and re-read this skill if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "Requirements are clear enough, I'll skip the design phase" | Skipping design means discovering mismatches after code is written, not before |
+| "The user already approved this approach verbally, no need to document" | Undocumented approval is invisible to reviewers and future agents; it doesn't exist |
+| "Tests can be written after — implementation first to check if the approach works" | Writing tests after implementation makes you test what you built, not what was required |
+| "This phase isn't needed for such a straightforward feature" | Every skipped phase is a deferred bug report |
+| "I understand the requirements, confirmation is just a formality" | The confirmation step exists to catch the gap between what you understood and what was meant |
+
+**IRON LAW 1: NEVER START IMPLEMENTING BEFORE THE SPEC IS WRITTEN AND CONFIRMED.**
+**IRON LAW 2: NEVER WRITE IMPLEMENTATION CODE BEFORE TESTS-CREATOR HAS GENERATED FAILING STUBS.**
+**IRON LAW 3: NEVER DELIVER WITHOUT A PASSING CODE-VERIFIER GATE AND A CHANGE REPORT.**

package/src/gdskills/bundled/skills/orchestration/feature-dev/SKILL.md

@@ -97,7 +97,7 @@ End-to-end feature development workflow from idea to merge-ready PR.
 Run `code-verifier` on the full diff:
 
 ```
-Invoke: skills/code-verifier/SKILL.md
+Invoke: skills/orchestration/code-verifier/SKILL.md
 Input:  codebase_path=<project_root>, scope=changed, base_branch=<base>
 ```
 
@@ -107,7 +107,7 @@ Input:  codebase_path=<project_root>, scope=changed, base_branch=<base>
 
 ### Phase 7: REVIEW (Self)
 
-1. Launch `code-review` skill on own changes (if available)
+1. Launch the `review-orchestrator` skill on own changes
 2. Or run a focused self-review:
    - `git diff main...HEAD` — review the full diff
    - Check for: TODOs left behind, console.logs, hardcoded values

package/src/gdskills/bundled/skills/orchestration/flow-orchestrator/SKILL.md

@@ -385,8 +385,8 @@ Before accepting implementation:
    the `skill_drift` fields from task-implementer results and the
    `## Skill Learning` block from review-orchestrator. For each flagged
    project-skill, dispatch a subagent — on a cheaper / non-flagship model if one
-   is available (`.metaproject/scripts/detect-models.sh`; see
-   `rules/core/model-selection.mdc`), otherwise the session model — to run
+   is available (`keryx review tier --findings 1 --diff-lines 0` resolves one from runtime
+   provider detection; see `rules/core/model-selection.mdc`), otherwise the session model — to run
    `keryx skills learn --from-review <report> --skill <m>/<s>` and return the
    proposal. Then read the proposal and `skills learn apply` it, or discard it.
    Never apply unread; never put `learn` in a hook.