Skill Interaction Matrix — KH SDLC Workflow Reference
Skill Interaction Matrix — KH SDLC Workflow Reference
Section titled “Skill Interaction Matrix — KH SDLC Workflow Reference”RETIRED (S491): Phase-0 (S48/S49) skill-composition analysis of the pre-Intent SDLC skill set — many referenced skills/agents are since retired or relocated, and the Planner/Executor/Checker role model it maps no longer exists. Retained for historical context only.
Status: Reference (was Phase 0 investigation artefact, S48).
Last updated: 2026-06-30 (S49 ID-6 — stripped narrative analysis,
updated per S48 ratifications captured in s49-open-resolutions.md; S432 —
decision-register cross-ref added: triage-finding Branch E + DR-intent wiring).
Per-skill catalogue used by the SDLC workflow to map skills to roles
(Workflow Orchestrator skill, Task Planner, Task Executor, Task Checker,
Workflow Curator). Citations use <skill>:<lineno> to point at the lines that
justify each claim. Rows tagged (planned) are skills authorised but not
yet authored (see kh-sdlc-workflow.md and s49-open-resolutions.md).
Planning / Design family
Section titled “Planning / Design family”| Skill | Source path | Trigger | Input | Process (top-level steps) | Output | Natural handoff | Overlap with | Role fit |
|---|---|---|---|---|---|---|---|---|
| context-engineering | ~/.agents/skills/context-engineering/SKILL.md (also .claude/skills/context-engineering/SKILL.md) | Starting new session, agent output quality degrading, switching tasks, configuring rules files (context-engineering:3) | Rules files, specs, source files, error output, prior conversation (context-engineering:22-36) | (1) Build a 5-level context hierarchy; (2) load rules file + relevant source + error output selectively; (3) surface ambiguity rather than guess; (4) emit “inline plan” before acting (context-engineering:38-251) | Loaded context bundle + optional confusion notes + lightweight inline plan (context-engineering:240-249) | Any downstream implementation skill | start-session (loads similar context); planning-and-task-breakdown (inline-plan pattern overlaps with Step-5 task drafting) | Workflow Orchestrator (set-up phase) — used at wave start; not invoked by Executor mid-task |
| planning-and-task-breakdown | ~/.agents/skills/planning-and-task-breakdown/SKILL.md | Have a spec, need to break into tasks; task feels too large; parallel work possible (planning-and-task-breakdown:3) | Spec / clear requirements + codebase context (planning-and-task-breakdown:14-21) | (1) Enter Plan Mode (read-only); (2) identify dependency graph; (3) slice vertically; (4) write tasks with acceptance criteria + verification; (5) order + checkpoint (planning-and-task-breakdown:24-123) | Plan document (markdown) with phased tasks, dependencies, verification steps, checkpoints (planning-and-task-breakdown:144-185) | implement-subtask (planned) for the Executor pickup | write-tech-spec partially (both decompose work); spec-driven-implementation Step 4 delegates here | Task Planner — decomposes ratified specs into implementation subtasks {N.5+} |
Spec-authoring family
Section titled “Spec-authoring family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| write-product-spec | .claude/skills/write-product-spec/SKILL.md | Write a product spec, PRD, desired-behaviour doc; significant user-facing feature (write-product-spec:3) | Feature summary, target users, key behaviours, Figma link if any (write-product-spec:38-50) | (1) Decide directory id; (2) gather context via AskUserQuestion; (3) draft Summary + Behavior + optional sections; (4) enumerate edge cases exhaustively (write-product-spec:38-115) | docs/specs/<id>/PRODUCT.md with numbered, testable Behavior invariants | write-tech-spec | Subtask {N.2} in the spec-authoring chain (per A2 ratification) | Task Planner |
| write-tech-spec | .claude/skills/write-tech-spec/SKILL.md | Tech spec / implementation plan / architecture doc tied to a product spec (write-tech-spec:3) | Sibling PRODUCT.md + codebase research (write-tech-spec:29-47) | (1) Research current code (cites files with line refs); (2) write Context + Proposed changes + Testing & validation; (3) reference PRODUCT.md Behavior invariants by number (write-tech-spec:50-67) | docs/specs/<id>/TECH.md with Context, Proposed changes, Testing & validation, optional E2E/Diagram/Risks/Parallelisation/Follow-ups | Conditional {N.4} PLAN.md or directly planning-and-task-breakdown | Subtask {N.3} in the spec-authoring chain | Task Planner |
| spec-driven-implementation | .claude/skills/spec-driven-implementation/SKILL.md | Triggers new-task creation; substantial feature with PRODUCT+TECH specs required (spec-driven-implementation:4-8); rewritten in ID-4 to emit {N.1} RESEARCH.md → {N.2} PRODUCT.md → {N.3} TECH.md → conditional {N.4} PLAN.md subtask chain per A2 ratification | Feature idea + sizing/risk judgement | Per S49 ID-4 rewrite: create TM-shaped Task with the {N.1}-{N.4} spec-authoring subtask chain; do NOT compose implement-specs (Executor reads the subtask chain post-ratification) | A TM-shaped Task ready for ratification, with subtasks for each spec artefact | After ratification, Planner adds implementation subtasks {N.5+} | Old behaviour composed write-product-spec → write-tech-spec → implement-specs; new behaviour stops at task creation | Task Planner (entry point for new feature work) |
Implementation family
Section titled “Implementation family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| implement-subtask (planned, S49 ID-4) | .claude/skills/implement-subtask/SKILL.md (TBA) | Execute ONE pre-decomposed subtask brief from a TM-shaped Task | Subtask record (TM shape — id, title, description, details, testStrategy, dependencies) + spec slice referenced in details | Read spec slice; implement against the brief; invoke test-driven-development and incremental-implementation as required; commit via commit-commands; set status pending→in-progress only; append <info added on …> journal block to details | Implementation commit on the worker branch; subtask record updated with journal annotation | Task Checker (standard variant) consumes the commit for verification | Old implement-specs was the closest predecessor — implement-subtask is the single-subtask scope adaptation (per A1 ratification) | Task Executor — single-subtask entry point |
| incremental-implementation | ~/.agents/skills/incremental-implementation/SKILL.md | Any multi-file change; building from a task breakdown; refactoring; tempted to write >100 lines before testing (incremental-implementation:3, 13-18) | A planned subtask | (1) Implement smallest complete piece; (2) test; (3) verify; (4) commit; (5) move to next slice (incremental-implementation:22-43) | A sequence of small, individually-tested, individually-revertable commits on a single branch (incremental-implementation:175-181) | code-review-and-quality (Checker) | test-driven-development (stricter inner loop); implement-subtask invokes explicitly when needed | Task Executor — execution discipline |
| implement-specs | .claude/skills/implement-specs/SKILL.md | After PRODUCT.md + TECH.md approved AND the next step is building (implement-specs:4-7) | Approved PRODUCT.md + TECH.md | (1) Read approved specs; (2) offer optional PROJECT_LOG/DECISIONS aids; (3) break work into steps (uses planning-and-task-breakdown if large), then test-driven-development + incremental-implementation; (4) update specs as implementation evolves; (5) verify with vitest/pytest/playwright/MCP eval (implement-specs:43-129) | Implementation PR with code + tests + updated specs | code-review-and-quality | Preserved unchanged for genuine whole-spec single-Executor cases; the new SDLC default is implement-subtask (per A1) | Executor (legacy whole-spec entry — kept available but not the SDLC default) |
| test-driven-development | ~/.agents/skills/test-driven-development/SKILL.md | Implementing any logic, fixing any bug, changing any behaviour (test-driven-development:3) | Behaviour to implement / bug report | RED → GREEN → REFACTOR; Prove-It Pattern for bugs (test-driven-development:25-128) | Source + tests with red-then-green discipline | code-review-and-quality (Checker) | incremental-implementation (stricter inner loop) | Task Executor — execution discipline at the function/behaviour level |
Quality / review family
Section titled “Quality / review family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| code-review-and-quality | ~/.agents/skills/code-review-and-quality/SKILL.md | Before merging any change; reviewing code written by self/agent/human; assess across multiple dimensions (code-review-and-quality:3) | A change / PR / branch ready for merge | Five-axis review (Correctness, Readability, Architecture, Security, Performance); categorise findings (Critical/Nit/Optional/FYI) | Categorised review comments + approve/request-changes verdict + checklist (code-review-and-quality:269-313) | Author addresses findings, then re-review; on quality-review variant, can invoke security-and-hardening / performance-optimization / type-design-analyzer based on findings (per B5) | simplify overlaps on auto-fix axis | Task Checker (standard and quality-review variants per B5) |
| resolve-merge-conflicts | .claude/skills/resolve-merge-conflicts/SKILL.md | A merge, rebase, cherry-pick, or stash pop stops on conflicts; git status shows unmerged paths; files contain conflict markers (resolve-merge-conflicts:3) | Conflicted working tree | Extract conflict context via Python helper; resolve one file at a time via git checkout --ours/--theirs or direct edit; revalidate (resolve-merge-conflicts:8-48) | Resolved working tree + staged files | Workflow Orchestrator continues the wave merge | None | Workflow Orchestrator (invoked during wave-merge gate) |
Domain-knowledge family
Section titled “Domain-knowledge family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| supabase-postgres-best-practices | .claude/skills/supabase-postgres-best-practices/SKILL.md | Writing / reviewing / optimising Postgres queries, schemas, or DB configs (supabase-postgres-best-practices:3) | Query / schema / config being authored | Reference 8 categories of rules (Query performance, Connection mgmt, Security & RLS, Schema design, Concurrency, Data access, Monitoring, Advanced) — pure reference skill, no procedural workflow | Inline guidance applied by the calling skill — no standalone artefact | Whichever Executor / Checker called it | None — pure domain reference | Task Executor (consultative) or Task Checker (security/perf axis) |
| playwright-best-practices | .claude/skills/playwright-best-practices/SKILL.md | Writing / debugging / maintaining Playwright tests in TypeScript (playwright-best-practices:3) | E2E/component test being authored or failing | Activity-based reference guide; decision tree picks the right references/*.md from ~30 | Inline test code + references followed — no standalone artefact | Whichever Executor / Checker called it | test-driven-development (Playwright is one test tier) | Task Executor (consultative) when writing E2E |
| diagnose-ci-failures | .claude/skills/diagnose-ci-failures/SKILL.md | Check CI status / pull CI issues / triage test failures / investigate PR build failures (diagnose-ci-failures:3) | PR / branch with red CI | GitHub-CLI driven log extraction; generate a plan to fix | Diagnostic report + fix plan | Task Executor consumes the fix plan | fix-errors for the actual fix step | Task Executor (CI diagnostic), Workflow Orchestrator (wave-merge gate) |
Skill / agent tooling family
Section titled “Skill / agent tooling family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| create-skill | .claude/skills/create-skill/SKILL.md | Create a skill from scratch / edit / optimise / run evals / benchmark / optimise description (create-skill:3-5) | Skill intent / draft / existing skill (create-skill:46-62) | (1) Capture intent; (2) interview / research; (3) write SKILL.md; (4) write test cases under evals/; (5) run with-skill + baseline subagents; (6) grade & aggregate; (7) launch eval-viewer; (8) iterate; (9) optional description-optimisation via run_loop; (10) optional packaging | New / updated SKILL.md with frontmatter + body + (optionally) evals/, scripts/, references/, assets/; benchmark.json; eval-viewer HTML report | None — terminal skill | update-skill (smaller-scope; no eval loop) | Skill Author (Workflow Orchestrator-side meta-skill) |
| update-skill | .claude/skills/update-skill/SKILL.md | Generating / editing / refining SKILL.md files (update-skill:3) | Existing SKILL.md or intent for a new one | (1) Quick-start template; (2) frontmatter requirements; (3) structure best practices; (4) “split when >200 lines” rule; (5) optional skills-ref validate | Updated SKILL.md (no eval loop) | None — terminal | create-skill (lightweight subset of) | Skill Author — lightweight edits |
| agent-development | .claude/skills/agent-development/SKILL.md | Create / add an agent / write a subagent; frontmatter / examples / tools / colours / autonomous-agent questions (agent-development:3) | Intent for an agent | (1) File structure spec; (2) frontmatter spec; (3) system prompt design template; (4) two creation methods; (5) validation rules; (6) test triggering | Agent .md file under agents/ with frontmatter + system prompt body | None — terminal | None directly — different artefact type (agents vs skills) | Agent Author — meta-skill |
Workflow infrastructure family
Section titled “Workflow infrastructure family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| workflow-orchestration (shipped S51 ID-6) | .claude/skills/workflow-orchestration/SKILL.md | Session entry pattern (ii) per B1 — main session = Claude + Liam acting as Orchestrator | Session task list (Tasks + Subtasks in TM shape) | Phase routing per §3 of kh-sdlc-workflow.md; wave structure; dispatch brief composition; sequential merge cadence; finding routing per binary in-scope-ness rule (B10); promotion gates (subtask→task→PR) per N3 | Dispatch decisions, wave-merge commits, finding-router outputs | dispatching-parallel-agents and session-driver-cmux for actual dispatch; triage-finding for out-of-scope findings | Old workflow-orchestrator.md agent (deleted S51 ID-6, commit e989e36c) | Workflow Orchestrator — core loop skill |
| session-driver-cmux | .claude/skills/session-driver-cmux/SKILL.md | Orchestrator fans out work to one or more independent Claude Code sessions; trigger phrases “spawn worker”, “fan out”, “dispatch sub-Claude”, “session-driver”, “orchestrator-of-orchestrators” (session-driver-cmux:3) | Worker name(s) + prompts + worktree base + optional branch (session-driver-cmux post-S49 ID-5: --worker-mode flag dropped) | (1) launch-worker.sh (cmux workspace + worktree + claude session + safety gate); (2) converse.sh (send prompt, wait for stop, return response); (3) wait-for-fleet.sh (any/all coordination); (4) stop-worker.sh (verify clean tree, remove worktree) (session-driver-cmux:74-159) | Worker session IDs + JSONL events at .claude/cmux-events/<id>/events.jsonl + worktrees at .claude/worktrees/<name>/ | Worker output collected via direct JSONL polling or upstream read-turn.sh; merge or cherry-pick sequentially | dispatching-parallel-agents (concrete primitive for that pattern); using-git-worktrees on worktree-creation axis | Workflow Orchestrator — dispatch primitive |
| dispatching-parallel-agents | .claude/skills/dispatching-parallel-agents/SKILL.md (also ~/.agents/skills/dispatching-parallel-agents/SKILL.md) | 2+ independent tasks that can be worked on without shared state or sequential dependencies (dispatching-parallel-agents:3) | List of independent problem domains + per-domain context | (1) Identify independent domains; (2) create focused agent tasks; (3) dispatch in parallel via Task(); (4) review and integrate (dispatching-parallel-agents:46-81) | N agent results, integrated into a single branch after sequential review | code-review-and-quality (integrate-and-verify); merge sequentially | session-driver-cmux (concrete implementation); using-git-worktrees (worktree-isolation half) | Workflow Orchestrator — high-level pattern |
| using-git-worktrees | .claude/skills/using-git-worktrees/SKILL.md | Starting feature work that needs isolation from current workspace or before executing implementation plans (using-git-worktrees:3) | Branch name + project root | (1) Detect existing worktree dir (priority .worktrees > worktrees); (2) git check-ignore; (3) git worktree add; (4) auto-detect project setup; (5) run baseline tests; (6) report location | Worktree directory with branch + dependencies installed + baseline tests green | Implementation skill takes over inside the worktree | session-driver-cmux (creates worktrees as side effect; harmonised in S49 ID-5 to add the same git check-ignore safety gate) | Workflow Orchestrator — workspace setup primitive |
| commit-commands | .claude/skills/commit-commands/... (or plugin) — supplies commit-commands:commit, commit-commands:commit-push-pr, commit-commands:clean_gone | Executor needs to commit subtask work per B9 (Executor uses commit-commands, NOT git-workflow-and-versioning) | Staged changes + commit message intent | Per individual command — typically: stage, draft message, commit, optionally push + open PR | New commit (or commit + push + PR) | Task Checker | git-workflow-and-versioning is the Orchestrator-side equivalent (per B9 split) | Task Executor (subtask commit) |
| git-workflow-and-versioning | Plugin-loaded (see available-skills inventory). Structures git workflow practices — commits, branching, conflict resolution, parallel-stream organisation | Making any code change; committing, branching, resolving conflicts, organising work across parallel streams | Current branch state + intended change | Branching strategy, commit hygiene, parallel-stream organisation | Coherent git history | Wave merge invokes resolve-merge-conflicts on conflict | commit-commands is the per-subtask Executor variant (per B9 split) | Workflow Orchestrator (wave-merge cadence, cross-track promotion) |
Curator / triage family
Section titled “Curator / triage family”| Skill | Source path | Trigger | Input | Process | Output | Handoff | Overlap | Role fit |
|---|---|---|---|---|---|---|---|---|
| triage-finding | .claude/skills/triage-finding/SKILL.md | Decide whether a finding is subtask / roadmap / backlog / no-action; triggered by workflow-curator agent when Orchestrator routes a finding for triage (triage-finding:3-9) | Finding packet (source, source_context, description, evidence, source_recommendation, task_context) | (1) Check roadmap/backlog for existing coverage; (2) walk decision tree (Branch A subtask / B roadmap / C backlog / E decision-register / D no-action); (3) output structured decision YAML | YAML decision packet with decision, justification, branch-specific fields | update-roadmap-backlog for roadmap/backlog decisions; back to Orchestrator for subtask / no-action / decision-register (the DR-intent is written on main by the Orchestrator / handoff) | None — pure decision skill | Workflow Curator (decision half) |
| update-ledgers | .claude/skills/update-ledgers/SKILL.md | Promote a triaged finding into backlog (or task-list); invoked by workflow-curator agent after triage-finding. | Triage decision payload + provenance (source_task_id, source_commit_sha, session_counter) | All writes route through bun scripts/ledger-cli.ts — see update-ledgers/SKILL.md for the current CLI-based Create/Update/Delete/Promote flow | Updated product-backlog.json (or task-list.json via Promote); mirrors regenerate server-side | Back to Curator (who reports to Orchestrator) — never commits itself | None — pure write skill paired 1:1 with triage-finding | Workflow Curator (write half) |
Decision register cross-ref. The decision register
(reference/decision-register.md, DR-NNN) is a read-at-start store of settled
cross-cutting rulings — not a skill, but several skills now interact with it: the
spec-authoring trio (write-product-spec / write-tech-spec /
planning-and-task-breakdown) and task-planner consult it before authoring and emit
DR-intents; workflow-orchestration surfaces in-force DRs in briefs and writes
DR-NNN entries on main; triage-finding / workflow-curator add decision-register
as a 5th finding disposition. Workers never write the register in-branch — they return
DR-intents the Orchestrator writes (mirrors the ledger-write invariant).
Role-to-skill summary (quick reference)
Section titled “Role-to-skill summary (quick reference)”| Role | Form | Primary skills |
|---|---|---|
| Workflow Orchestrator | SKILL (workflow-orchestration) | context-engineering, git-workflow-and-versioning, resolve-merge-conflicts, dispatching-parallel-agents, session-driver-cmux, using-git-worktrees, triage-finding (route findings), diagnose-ci-failures (wave-merge gate) |
| Task Planner | Agent (task-planner.md). Opus thinking: 'max' | Core: write-product-spec, write-tech-spec, planning-and-task-breakdown, documentation-and-adrs. Task-specific: claude-api, supabase-postgres-best-practices, playwright-best-practices, astro, etc. |
| Task Executor | Agent (task-executor.md) | implement-subtask, test-driven-development, incremental-implementation, commit-commands, diagnose-ci-failures, supabase-postgres-best-practices / playwright-best-practices consultative |
| Task Checker | Agent (task-checker.md). Variants: standard, quality-review | code-review-and-quality. Conditional in quality-review variant: security-and-hardening, performance-optimization, type-design-analyzer |
| Workflow Curator | Agent (workflow-curator.md) | triage-finding, update-ledgers |
End of reference. Source artefacts (Phase 0 investigation, S48): see
docs/plans/phase-0-investigation/skill-interaction-matrix.md git history,
which retains the original narrative analysis and gap-list pre-strip.