@mrciphersmith/keryx 0.2.72 → 0.2.74

package/src/gdskills/bundled/skills/orchestration/code-verifier/SKILL.zed.md

@@ -1,29 +1,353 @@
 ---
 name: code-verifier
-description: "Full quality gate: lint, type-check, tests, circular imports. Mandatory post-implementation step in job-orchestrator. Use when: verifying code after implementation, running quality gate before review."
+model_tier: light
+description: "Use when running a full quality gate after implementation — lint, type-check, tests, and import validation. Mandatory step in job-orchestrator after task-implementer and after fix iterations. Use standalone when you need a structured verification report."
 triggers:
   - "Run verification"
   - "Quality gate"
+  - "Check code quality"
   - "Run lint and tests"
   - "Verify implementation"
+  - "Run checks"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "verification"
+  agent_worthy: true
   compatible_harnesses: "cursor,codex,zed,opencode"
 license: "MIT"
 ---
 
 # Code Verifier
 
-lint → type-check → tests → circular-import gate.
+## Purpose
 
-**Pipeline:** task-implementer → **code-verifier** → review
+Runs the full quality gate for a project: lint, type-check, tests, and import validation. Provides a structured, parseable result that the orchestrator uses to decide whether to proceed or trigger a fix loop.
 
-## Steps
-1. Detect tooling
-2. Run all checks (never abort early)
-3. Classify: CRITICAL/HIGH = FAIL, LOW = PASS_WITH_WARNINGS
-4. Emit VERIFICATION_RESULT
+**Distinct from `task-implementer` Phase 5:** task-implementer does inline self-verification during implementation. `code-verifier` is an independent gate that runs after all tasks in a wave are complete — giving a clean, consolidated view of the whole diff, not per-task.
 
-Full spec: `.metaproject/skills/gdskills/orchestration/code-verifier/SKILL.md`
+**Input:** Codebase path + worktree path + scope (changed files or full project)
+**Output:** `VERIFICATION_RESULT` structured report — gate status (pass/fail), per-check results, actionable findings
+
+## When to Use
+
+- Dispatched by `job-orchestrator` after each task-implementer wave (mandatory)
+- Dispatched by `job-orchestrator` after each fix iteration
+- Run standalone: "verify my code", "run quality gate", "/code-verifier"
+- Any time you need a reproducible, structured view of project health
+
+## Architecture: 4 Phases
+
+```
+Phase 1: DETECT   →  Auto-detect stack, tooling, commands
+Phase 2: RUN      →  Execute lint → type-check → tests → import-check
+Phase 3: ANALYZE  →  Parse outputs, classify findings by severity
+Phase 4: REPORT   →  Emit VERIFICATION_RESULT
+```
+
+---
+
+## Workflow
+
+```
+Code Verifier Progress:
+- [ ] Phase 1: Detect stack and tooling
+- [ ] Phase 2: Run verification checks
+- [ ] Phase 3: Analyze and classify findings
+- [ ] Phase 4: Report results
+```
+
+---
+
+### Phase 1: DETECT
+
+Auto-detect the project stack and available verification tools.
+
+**1.1 Package manager and runner:**
+
+```bash
+cd <codebase_path>
+
+if   [ -f bun.lockb ];         then PM=bun;    RUNNER="bun run"
+elif [ -f pnpm-lock.yaml ];    then PM=pnpm;   RUNNER="pnpm run"
+elif [ -f yarn.lock ];         then PM=yarn;   RUNNER="yarn"
+elif [ -f package-lock.json ]; then PM=npm;    RUNNER="npm run"
+elif [ -f pyproject.toml ] || [ -f requirements.txt ]; then PM=python; RUNNER=""
+elif [ -f go.mod ];            then PM=go;     RUNNER=""
+else PM=unknown; RUNNER=""
+fi
+```
+
+**1.2 Detect available check commands:**
+
+| Check | How to detect | Command |
+|---|---|---|
+| Lint | `package.json` has `"lint"` script | `$RUNNER lint` |
+| Lint (auto) | `eslint.config.*` or `.eslintrc*` present | `npx eslint . --max-warnings 0` |
+| Biome | `biome.json` present | `npx biome check .` |
+| Type-check | `package.json` has `"type-check"` or `"typecheck"` script | `$RUNNER type-check` |
+| Type-check (auto) | `tsconfig.json` present | `npx tsc --noEmit` |
+| Tests | `package.json` has `"test"` script | `$RUNNER test --run` (vitest) or `$RUNNER test` |
+| pytest | `pytest` in `pyproject.toml` or `requirements.txt` | `pytest --tb=short -q` |
+| Go tests | `go.mod` present | `go test ./...` |
+| Circular imports | `madge` in devDependencies | `npx madge --circular src/` |
+
+**1.3 Determine scope:**
+
+```
+IF scope = "changed" (default when dispatched by orchestrator):
+  FILES = git diff --name-only <base_branch>...HEAD
+  Run tests only for files related to changed code
+  Run lint only on changed files: npx eslint <changed_files>
+  Run type-check on full project (tsc doesn't support file-level scope)
+
+IF scope = "full":
+  Run all checks on full project
+```
+
+**Output of Phase 1:**
+```
+TOOLING:
+  pm: bun | pnpm | yarn | npm | python | go | unknown
+  runner: "bun run" | ...
+  checks_available: [lint, type-check, tests, circular-imports]
+  checks_skipped: [<reason>]
+  scope: changed | full
+  changed_files: [<paths>]
+```
+
+---
+
+### Phase 2: RUN
+
+Execute each available check in order. Capture full output.
+
+**Execution order:** lint → type-check → tests → import-check
+
+**Do NOT abort early** — run all checks even if one fails. The orchestrator needs the complete picture.
+
+**2.1 Lint:**
+```bash
+# Changed files only (faster, more actionable)
+npx eslint <changed_files> --format=json --max-warnings 0
+# OR if lint script exists:
+$RUNNER lint
+```
+
+Capture:
+- Exit code (0 = pass, non-zero = fail)
+- Number of errors and warnings
+- Per-file error list (file path, line, column, rule, message)
+
+**2.2 Type-check:**
+```bash
+npx tsc --noEmit 2>&1
+# OR:
+$RUNNER type-check
+```
+
+Capture:
+- Exit code
+- Number of errors
+- Per-error: file, line, column, message, TS error code
+
+**2.3 Tests:**
+```bash
+$RUNNER test --run 2>&1        # vitest
+# OR: npx jest --ci 2>&1
+# OR: pytest --tb=short -q 2>&1
+# OR: go test ./... 2>&1
+```
+
+Capture:
+- Exit code
+- Tests passed / failed / skipped counts
+- Per-failure: test name, file, error message, stack (first 5 lines)
+
+**2.4 Circular import check (if madge available):**
+```bash
+npx madge --circular --extensions ts,tsx src/ 2>&1
+```
+
+Capture:
+- Exit code
+- List of circular chains (if any)
+
+---
+
+### Phase 3: ANALYZE
+
+Parse raw outputs into structured findings. Classify by severity.
+
+**3.1 Severity classification:**
+
+| Finding | Severity |
+|---|---|
+| Type error | CRITICAL |
+| Test failure | CRITICAL |
+| ESLint error (not warning) | HIGH |
+| Circular import | HIGH |
+| ESLint warning | LOW |
+| Skipped test | INFO |
+
+**3.2 Gate decision:**
+
+```
+GATE = PASS
+IF any CRITICAL findings  → GATE = FAIL (blocks proceed)
+IF any HIGH findings      → GATE = FAIL (blocks proceed)
+IF only LOW/INFO findings → GATE = PASS_WITH_WARNINGS
+```
+
+**3.3 Actionable finding format:**
+
+Each finding must include enough context for `task-implementer` (fix mode) to resolve it without re-reading the full output:
+
+```
+{
+  severity: CRITICAL | HIGH | LOW | INFO,
+  check: lint | type-check | test | circular-import,
+  file: <path>,
+  line: <N> | null,
+  column: <N> | null,
+  rule: <ESLint rule or TS error code> | null,
+  message: <error text>,
+  suggestion: <optional fix hint>
+}
+```
+
+---
+
+### Phase 4: REPORT
+
+Emit the structured `VERIFICATION_RESULT` as the final message.
+
+```
+VERIFICATION_RESULT:
+  gate: PASS | PASS_WITH_WARNINGS | FAIL
+  scope: changed | full
+  
+  checks:
+    lint:
+      status: pass | fail | skipped
+      errors: <N>
+      warnings: <N>
+      command_used: "<command>"
+    
+    type_check:
+      status: pass | fail | skipped
+      errors: <N>
+      command_used: "<command>"
+    
+    tests:
+      status: pass | fail | skipped
+      passed: <N>
+      failed: <N>
+      skipped: <N>
+      command_used: "<command>"
+    
+    circular_imports:
+      status: pass | fail | skipped
+      cycles: <N>
+  
+  findings:
+    - severity: CRITICAL
+      check: type-check
+      file: src/services/UserService.ts
+      line: 42
+      rule: TS2345
+      message: "Argument of type 'string' is not assignable to parameter of type 'number'"
+    - severity: HIGH
+      check: lint
+      file: src/components/Form.tsx
+      line: 18
+      rule: "no-unused-vars"
+      message: "'value' is defined but never used"
+  
+  summary: "<1-2 sentence human-readable summary>"
+```
+
+**STATUS reporting:**
+
+```
+STATUS: DONE          — gate PASS or PASS_WITH_WARNINGS, report follows
+STATUS: DONE_WITH_CONCERNS — PASS_WITH_WARNINGS with notable warnings
+STATUS: BLOCKED       — could not run checks (missing tooling, wrong directory)
+```
+
+> If `gate: FAIL` → STATUS is still `DONE` (the gate result, not the skill's execution). The orchestrator reads `gate: FAIL` and decides to trigger fix.
+
+---
+
+## Integration with job-orchestrator
+
+The orchestrator dispatches `code-verifier` at two points:
+
+**After task-implementer wave (pre-review gate):**
+```
+code-verifier:
+  codebase_path: <worktree_path>
+  scope: changed
+  base_branch: <base_branch from JOB_STATE>
+→ If gate: FAIL → dispatch fix tasks → re-run code-verifier
+→ If gate: PASS → proceed to review
+```
+
+**After fix iterations (post-fix gate):**
+```
+code-verifier:
+  codebase_path: <worktree_path>
+  scope: changed
+→ If gate still FAIL after 2 iterations → report as BLOCKED, skip to report
+→ If gate: PASS → proceed to report
+```
+
+**The orchestrator's internal "checks" step (2.8) is replaced by `code-verifier` dispatch.**
+
+---
+
+## Standalone Usage
+
+```bash
+# Run on current directory, changed files only
+/code-verifier
+
+# Run on specific project
+/code-verifier --path /path/to/project
+
+# Full project scan (not just changed files)
+/code-verifier --scope full
+```
+
+---
+
+## Automation Settings
+
+| Setting | Default | Options | Description |
+|---------|---------|---------|-------------|
+| `scope` | `changed` | `changed` / `full` | Limit checks to changed files or run full project |
+| `fail_on_warnings` | `false` | true/false | Treat ESLint warnings as gate failures |
+| `include_circular` | `true` | true/false | Run circular import detection if madge available |
+| `max_findings_reported` | `20` | 1-100 | Cap findings in report to avoid overflow |
+
+---
+
+## Error Handling
+
+| Error | Action |
+|---|---|
+| Check command not found | Mark check as `skipped`, continue others |
+| Wrong working directory | ABORT with `STATUS: BLOCKED` and directory hint |
+| Command times out (>120s) | Mark check as `skipped (timeout)`, continue |
+| Zero checks available | `STATUS: BLOCKED` — cannot verify without any tooling |
+| Circular import tool missing | Skip silently (not installed in all projects) |
+
+---
+
+## Rules of Engagement
+
+1. **Run ALL checks** — never abort after first failure. The orchestrator needs the full picture.
+2. **Do NOT modify files** — this is read-only verification.
+3. **Scope to changed files** by default — full scans are slow and produce noise.
+4. **Be specific** in findings — include file, line, rule, message. Vague "lint failed" is not actionable.
+5. Return `VERIFICATION_RESULT` as the **final message** to the orchestrator.

package/src/gdskills/bundled/skills/orchestration/context-collector/SKILL.codex.md

@@ -1,6 +1,6 @@
 ---
 name: context-collector
-description: "Collects, summarizes, and maintains a unified context document for a job. Gathers relevant local documentation (docs/, jobs/, rules), identifies libraries/patterns/references, fetches external documentation via web, extracts best practices, and produces a single context document that all sub-agents can reference during the job lifecycle. Can be invoked by job-orchestrator or directly by user."
+description: "Use when a job needs a unified context document — gathering docs, libraries, and references for sub-agents before execution."
 triggers:
   - "Collect context"
   - "Build context"
@@ -11,12 +11,19 @@ triggers:
   - "Research context"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.1.0"
   category: "context"
+  agent_worthy: true
   compatible_harnesses: "cursor,codex,zed,opencode"
 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>
+
 # Context Collector
 
 ## Purpose
@@ -163,9 +170,15 @@ Scan local sources for relevant context. Be selective — only include what is d
    |------------|---------------|
    | React components | code-style-patterns.mdc, frontend-assistant.mdc, storybook-guidelines.mdc |
    | MobX stores | code-style-patterns.mdc, mobx-store-template.mdc |
-   | API / DTOs | nestjs-dto.mdc, code-style-patterns.mdc |
-   | Testing | playwright-testing.mdc, storybook-guidelines.mdc |
+   | API / DTOs | nestjs-dto.mdc, code-style-patterns.mdc, api-contracts.mdc |
+   | Testing | playwright-testing.mdc, storybook-guidelines.mdc, tdd-workflow.mdc |
    | General code | code-style-patterns.mdc, frontend-assistant.mdc |
+   | TDD / test-first | tdd-workflow.mdc |
+   | Architecture / layers | clean-architecture.mdc, solid-principles.mdc |
+   | Error handling | error-handling.mdc |
+   | Database / ORM | database-patterns.mdc |
+   | Security | security-baseline.mdc |
+   | Async code | async-patterns.mdc |
    
 2. Read each applicable rule
 3. Extract: specific conventions, required patterns, prohibited practices
@@ -189,6 +202,61 @@ Scan local sources for relevant context. Be selective — only include what is d
    - Key patterns to follow for consistency
 ```
 
+### 2.5 Test Framework Detection (`PROJECT_DIR`)
+
+Always detect the test framework — `tests-creator` and `task-implementer` both need this.
+
+```
+1. Read package.json:
+   - Check "dependencies" and "devDependencies" for:
+     vitest, jest, @jest/*, mocha, jasmine, bun:test, pytest, go test
+   
+2. Check for config files:
+   - vitest.config.ts / vitest.config.js
+   - jest.config.ts / jest.config.js
+   - .mocharc.* / mocha.opts
+
+3. Read 2-3 existing test files (*.test.ts, *.spec.ts, test_*.py):
+   - Import style (global vs explicit import)
+   - Describe/it/test nesting depth
+   - Assertion style (expect().toBe vs assert.equal)
+   - Mock library (vi.fn / jest.fn / sinon)
+   - Fixture patterns (factories, builders, inline data)
+   - Test file location convention (co-located vs __tests__/)
+
+4. Summarize as "Test Framework Context":
+   framework: <vitest|jest|bun:test|mocha|pytest>
+   import_style: esm | cjs | global
+   file_pattern: "*.test.ts" | "*.spec.ts"
+   file_location: co-located | __tests__ | tests/
+   mock_library: vi | jest | sinon
+   run_command: "bun test" | "npx vitest run" | "npm test"
+   example_test_file: <path to a representative test>
+```
+
+### 2.6 Greptile Codebase Context (when available)
+
+Greptile indexes the full repository and stores codebase-level context. If Greptile MCP is available in the session, query it as an additional local source — it can surface cross-file patterns that a manual scan would miss.
+
+```
+1. Try fetching stored custom context:
+   mcp__greptile__get_custom_context({})
+   or
+   mcp__greptile__search_custom_context({ query: "<task_description>" })
+
+2. If Greptile context is returned:
+   - Extract: documented patterns, known exceptions, team conventions
+   - Note: "Source: Greptile codebase index"
+
+3. Check for relevant past review comments (signals about recurring issues):
+   mcp__greptile__search_greptile_comments({ query: "<focus_area>", limit: 5 })
+   - Extract recurring findings → add to "Known Issues / Watch Areas" section
+
+4. If Greptile MCP is not available or returns empty: skip silently, proceed normally.
+```
+
+Greptile context is additive — it supplements local context, never replaces it.
+
 **Output of Phase 2:**
 ```
 LOCAL_CONTEXT:
@@ -196,6 +264,8 @@ LOCAL_CONTEXT:
   related_jobs:      [{job_name, relevance, key_findings}]
   applicable_rules:  [{rule, key_conventions: [string]}]
   codebase_patterns: [{area, patterns: [string], example_files: [path]}]
+  test_framework:    {framework, import_style, file_pattern, file_location, mock_library, run_command, example_test_file}
+  greptile_context:  {available: bool, patterns: [string], known_issues: [string]}
 ```
 
 ---
@@ -445,6 +515,24 @@ If no JOB_NAME is provided:
 - Write context to `<DOCS_ROOT>/context/<descriptive-slug>.md`
 - Include full metadata block
 
+## Reporting Results
+
+Every final response to the orchestrator MUST begin with the status line:
+
+```
+STATUS: DONE
+
+## Context collected
+[summary of what was gathered]
+
+## CONTEXT_RESULT
+[the full result block]
+```
+
+Use `STATUS: DONE_WITH_CONCERNS` if context is partial. Use `STATUS: BLOCKED` if access fails.
+
+**IRON LAW: THE FIRST LINE OF YOUR FINAL RESPONSE IS ALWAYS "STATUS: <STATUS>". THE CONTEXT_RESULT BLOCK FOLLOWS AFTER.**
+
 ### 5.3 Return Result
 
 ```

package/src/gdskills/bundled/skills/orchestration/context-collector/SKILL.cursor.md

@@ -1,6 +1,6 @@
 ---
 name: context-collector
-description: "Collects, summarizes, and maintains a unified context document for a job. Gathers relevant local documentation (docs/, jobs/, rules), identifies libraries/patterns/references, fetches external documentation via web, extracts best practices, and produces a single context document that all sub-agents can reference during the job lifecycle. Can be invoked by job-orchestrator or directly by user."
+description: "Use when a job needs a unified context document — gathering docs, libraries, and references for sub-agents before execution."
 triggers:
   - "Collect context"
   - "Build context"
@@ -11,12 +11,19 @@ triggers:
   - "Research context"
 metadata:
   author: "MrCipherSmith"
-  version: "1.0.0"
+  version: "1.1.0"
   category: "context"
+  agent_worthy: true
   compatible_harnesses: "cursor,codex,zed,opencode"
 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>
+
 # Context Collector
 
 ## Purpose
@@ -163,9 +170,15 @@ Scan local sources for relevant context. Be selective — only include what is d
    |------------|---------------|
    | React components | code-style-patterns.mdc, frontend-assistant.mdc, storybook-guidelines.mdc |
    | MobX stores | code-style-patterns.mdc, mobx-store-template.mdc |
-   | API / DTOs | nestjs-dto.mdc, code-style-patterns.mdc |
-   | Testing | playwright-testing.mdc, storybook-guidelines.mdc |
+   | API / DTOs | nestjs-dto.mdc, code-style-patterns.mdc, api-contracts.mdc |
+   | Testing | playwright-testing.mdc, storybook-guidelines.mdc, tdd-workflow.mdc |
    | General code | code-style-patterns.mdc, frontend-assistant.mdc |
+   | TDD / test-first | tdd-workflow.mdc |
+   | Architecture / layers | clean-architecture.mdc, solid-principles.mdc |
+   | Error handling | error-handling.mdc |
+   | Database / ORM | database-patterns.mdc |
+   | Security | security-baseline.mdc |
+   | Async code | async-patterns.mdc |
    
 2. Read each applicable rule
 3. Extract: specific conventions, required patterns, prohibited practices
@@ -189,6 +202,61 @@ Scan local sources for relevant context. Be selective — only include what is d
    - Key patterns to follow for consistency
 ```
 
+### 2.5 Test Framework Detection (`PROJECT_DIR`)
+
+Always detect the test framework — `tests-creator` and `task-implementer` both need this.
+
+```
+1. Read package.json:
+   - Check "dependencies" and "devDependencies" for:
+     vitest, jest, @jest/*, mocha, jasmine, bun:test, pytest, go test
+   
+2. Check for config files:
+   - vitest.config.ts / vitest.config.js
+   - jest.config.ts / jest.config.js
+   - .mocharc.* / mocha.opts
+
+3. Read 2-3 existing test files (*.test.ts, *.spec.ts, test_*.py):
+   - Import style (global vs explicit import)
+   - Describe/it/test nesting depth
+   - Assertion style (expect().toBe vs assert.equal)
+   - Mock library (vi.fn / jest.fn / sinon)
+   - Fixture patterns (factories, builders, inline data)
+   - Test file location convention (co-located vs __tests__/)
+
+4. Summarize as "Test Framework Context":
+   framework: <vitest|jest|bun:test|mocha|pytest>
+   import_style: esm | cjs | global
+   file_pattern: "*.test.ts" | "*.spec.ts"
+   file_location: co-located | __tests__ | tests/
+   mock_library: vi | jest | sinon
+   run_command: "bun test" | "npx vitest run" | "npm test"
+   example_test_file: <path to a representative test>
+```
+
+### 2.6 Greptile Codebase Context (when available)
+
+Greptile indexes the full repository and stores codebase-level context. If Greptile MCP is available in the session, query it as an additional local source — it can surface cross-file patterns that a manual scan would miss.
+
+```
+1. Try fetching stored custom context:
+   mcp__greptile__get_custom_context({})
+   or
+   mcp__greptile__search_custom_context({ query: "<task_description>" })
+
+2. If Greptile context is returned:
+   - Extract: documented patterns, known exceptions, team conventions
+   - Note: "Source: Greptile codebase index"
+
+3. Check for relevant past review comments (signals about recurring issues):
+   mcp__greptile__search_greptile_comments({ query: "<focus_area>", limit: 5 })
+   - Extract recurring findings → add to "Known Issues / Watch Areas" section
+
+4. If Greptile MCP is not available or returns empty: skip silently, proceed normally.
+```
+
+Greptile context is additive — it supplements local context, never replaces it.
+
 **Output of Phase 2:**
 ```
 LOCAL_CONTEXT:
@@ -196,6 +264,8 @@ LOCAL_CONTEXT:
   related_jobs:      [{job_name, relevance, key_findings}]
   applicable_rules:  [{rule, key_conventions: [string]}]
   codebase_patterns: [{area, patterns: [string], example_files: [path]}]
+  test_framework:    {framework, import_style, file_pattern, file_location, mock_library, run_command, example_test_file}
+  greptile_context:  {available: bool, patterns: [string], known_issues: [string]}
 ```
 
 ---
@@ -445,6 +515,24 @@ If no JOB_NAME is provided:
 - Write context to `<DOCS_ROOT>/context/<descriptive-slug>.md`
 - Include full metadata block
 
+## Reporting Results
+
+Every final response to the orchestrator MUST begin with the status line:
+
+```
+STATUS: DONE
+
+## Context collected
+[summary of what was gathered]
+
+## CONTEXT_RESULT
+[the full result block]
+```
+
+Use `STATUS: DONE_WITH_CONCERNS` if context is partial. Use `STATUS: BLOCKED` if access fails.
+
+**IRON LAW: THE FIRST LINE OF YOUR FINAL RESPONSE IS ALWAYS "STATUS: <STATUS>". THE CONTEXT_RESULT BLOCK FOLLOWS AFTER.**
+
 ### 5.3 Return Result
 
 ```