kh-sdlc-workflow — Open Questions

RETIRED (S491): Open-questions ratification surface for kh-sdlc-workflow.md, which was itself archived W4b (superseded by the no-planner Intent workflow, DR-089). Archived with its parent per owner ruling. Retained for historical context only.

Provenance

Inputs:
- T1 → docs/plans/phase-0-investigation/kh-sdlc-workflow-feedback-structured.md (48 Qs raised)
- T2 → docs/reference/skill-interaction-matrix.md (empirical answers + 10 net-new gaps; moved + stripped to reference doc in S49 ID-6 — narrative analysis and gap list retained in git history at the old path docs/plans/phase-0-investigation/skill-interaction-matrix.md)
- T3 → docs/reference/taskmaster-schema-reference.md (TM schema reality + 3 hand-decomp discrepancies)
- T4 → docs/plans/phase-0-investigation/session-driver-cmux-divergence.md (cmux fork-state + 1 latent bug)
- Original feedback (preserved): docs/plans/phase-0-investigation/kh-sdlc-workflow-feedback.md
This doc: the single ratification surface. Liam works through this; once each Q has a decision, kh-sdlc-workflow.md is re-authored against those decisions.

How to read

Status — one of:
- ANSWERED — empirical research (T2/T3/T4) produced a defensible default; Liam can override or rubber-stamp.
- OPEN — Liam decision required; no empirical default available.
- BLOCKED-LIAM — needs Liam input to unblock.
- BLOCKED-EXTERNAL — needs external precondition (updated specs, new skill, etc.).
Severity — BLOCKER (workflow can’t be finalised without this) / HIGH (workflow degrades materially if punted) / MEDIUM (sensible default exists) / LOW (nice-to-have, defer).
Recommended next action — concrete next step for Liam (or pre-condition that unblocks it).

Decision priority (recommended order for ratification)

Section 2 BLOCKERs first — terminology, role set, lifecycle phase ordering, dispatch entry pattern. Nothing else can land until these are decided.
Section 1 ANSWERED items — rubber-stamp or override; quick.
Section 3 NEW gaps — decide which to fill, defer, or accept as-is.
Section 4 BLOCKED items — re-anchor in S49 once preconditions clear.

Section 1 — ANSWERED by empirical research

A1. Implementation-family skills (T2 §A)

Resolves: Q-EXEC-SKILLS-1, Q-ORCH-SKILLS-3, Q-PLANNER-SKILLS-2

Empirical finding (T2 §A, skill-interaction-matrix:75-79): the four skills are NOT peers — they compose at four altitudes:

Altitude	Skill	Invoked by
Project (per-feature)	`spec-driven-implementation`	Orchestrator (decides if specs needed)
Feature (per-WP)	`implement-specs`	Executor (entry point for spec-aware work)
Slice (per-file-cluster)	`incremental-implementation`	Executor (internally per slice)
Behaviour (per-function)	`test-driven-development`	Executor (internally per behaviour)

Default to ratify:

Orchestrator owns spec-driven-implementation at session start when AUTHOR mode (F3-3) detected.
Executor’s entry skill per implementation subtask = implement-specs. It internally calls planning-and-task-breakdown if large, then incremental-implementation per slice, then test-driven-development per behaviour.
implement-specs is NOT redundant in task-driven model — it’s the spec-anchoring composer.
test-driven-development showing up in Planner’s Spec-authoring phase (F4-3) is reinterpretable as “TDD-shaped spec writing” (test cases enumerated in PRODUCT.md Behavior invariants — which write-product-spec:72-95 already mandates).

Status: ANSWERED. Severity: HIGH. Next action: Liam rubber-stamps or overrides.

A2. Spec-authoring chain (T2 §B)

Resolves: Q-ORCH-SKILLS-3 (cross-reference with A1)

Empirical finding (T2 §B, spec-driven-implementation:80-124): spec-driven-implementation explicitly composes write-product-spec → write-tech-spec → implement-specs sequentially. Each handoff is an explicit skill invocation (no auto-firing). Sub-skills are independently invocable.

Default to ratify:

Planner subtasks {N.2} (PRODUCT.md) and {N.3} (TECH.md) per F3-4 invoke write-product-spec and write-tech-spec directly — NOT via spec-driven-implementation.
spec-driven-implementation itself fires only when Orchestrator confirms AUTHOR mode at session start AND specs don’t yet exist. From then on, the chain is decomposed into the subtask sequence and individual sub-skills are called per subtask.

Status: ANSWERED. Severity: MEDIUM. Next action: Liam confirm.

A3. Quality-review ordering (T2 §C)

Resolves: Q-CHECKER-ORDER-1, partial Q-EXEC-SKILLS-4, partial Q-SELF-REVIEW-1

Empirical finding (T2 §C, code-review-and-quality:14-19 + simplify inventory description):

code-review-and-quality positions itself as a per-CHANGE pre-merge gate, NOT per-subtask. Five axes (Correctness, Readability, Architecture, Security, Performance). Categorises findings as Critical / Nit / Optional / FYI.
simplify (no local SKILL.md — built-in slash command per inventory) reads as a pre-Checker Executor auto-fix on a diff.

Default to ratify (pattern C from F-X4 with refinement):

Per-subtask: no quality-review skill fires. Checker variant fires only for spec/standards compliance.
Per-task (after all implementation subtasks complete): Executor invokes simplify (auto-fix cheap reuse/quality/efficiency wins). Then Checker invokes code-review-and-quality (five-axis pre-merge gate).
Any Critical/Important findings from code-review-and-quality → Orchestrator dispatches fix-Executor → re-Checker (loop until PASS).

Status: ANSWERED. Severity: HIGH. Next action: Liam confirm pattern C-refined, OR substitute pattern A/B/D.

New Q raised: Q-SIMPLIFY-1 — simplify has no inspectable SKILL.md (built-in). KH cannot inspect/customise. Three options:

Treat simplify as opaque; trust the inventory description.
Author a project-local simplify SKILL.md that overrides + makes behaviour inspectable.
Replace with a domain-equivalent skill (e.g. an Anthropic code-simplifier agent if available).

A4. Worktree / parallel-dispatch composition (T2 §D)

Resolves: Q-AMALGAMATE-1, Q-AMALGAMATE-2

Empirical finding (T2 §D): three skills are LAYERED, not redundant:

dispatching-parallel-agents = abstract pattern (identify domains → focused tasks → parallel → integrate).
using-git-worktrees = workspace-isolation primitive (with git check-ignore + baseline-test safety contract).
session-driver-cmux = one concrete dispatch implementation (cmux + claude sessions + per-worker worktree + JSONL events).

session-driver-cmux creates worktrees but does NOT call using-git-worktrees’s safety contract (no ignore-check, no baseline-test gate).

Default to ratify:

DO NOT amalgamate. Each layer is independently useful (single-worker worktree for Executor doesn’t need cmux fleet).
DO harmonise: session-driver-cmux launch-worker.sh should adopt the same worktree-creation contract as using-git-worktrees (ignore-check + baseline-test). Tracked as a new subtask under the broader session-driver-cmux cleanup work (combined with T4’s identified latent bug).

Status: ANSWERED. Severity: MEDIUM. Next action: Liam confirm. If yes, schedule the harmonisation subtask.

A5. session-driver-cmux re-sync vs hard-fork (T4 recommendation)

Resolves: Q-AMALGAMATE-2 (downstream), FX-8

Empirical finding (T4 verdict): option (a) hard-fork recommended. Upstream (~/.claude/plugins/cache/superpowers-marketplace/claude-session-driver/1.0.1/) is .orphaned_at marked (2026-02-22). 4 of 7 KH commits are cmux-property bug fixes (S46 Phase B): tmux→cmux transport, raw-mode TUI Enter handling, title drift, log-path encoding. KH-only additives: per-worker git worktree, dirty-status safety gate, --worker-mode flag.

Latent bug surfaced (T4): local SKILL.md references upstream read-events.sh and controller approve-tool.sh that hard-code /tmp/claude-workers/ and silently miss KH-located events. 30-min cleanup pass would close.

Default to ratify:

Hard-fork. Stop tracking upstream.
File latent bug as new subtask under session-driver-cmux cleanup.
(Optional courtesy) upstream the log-path encoding bug fix (e1591f21) as a PR — likely latent upstream too.

Status: ANSWERED. Severity: MEDIUM. Next action: Liam confirm; if yes, schedule cleanup subtask.

A6. TM Subtask dependencies are sibling-only (T3 §STEP 3 + discrepancy 3)

Resolves: partial Q-SPEC-SUBTASKS-1, partial Q-SUBTASK-KIND-1

Empirical finding (T3, example-tm-tasks.json): Subtask.dependencies is sibling-only — integer ids referencing other subtasks of the SAME parent. Cross-Task dependencies live at the Task level (Task.dependencies[]).

Implications for KH workflow:

F3-4’s spec-authoring sequence {N.1} Research → {N.2} Product spec → {N.3} Tech spec → {N.4} Task breakdown → {N.5+} Implementation IS structurally compatible with TM (all siblings of Task N).
BUT if a follow-up implementation Task N+1 depends on Task N being PASSED, that dep lives at the Task level, not the Subtask level.
KH cannot express “Task M, Subtask 3 depends on Task N, Subtask 7” — must promote to Task-level dep or restructure.

Status: ANSWERED. Severity: HIGH (informs every Planner decomposition decision). Next action: Liam acknowledge constraint; consider whether KH plans should ever attempt cross-Task subtask deps (recommend NO).

A7. TM Subtask 25-soft-ceiling (T3 quantitative aggregates)

Resolves: partial Q-SPEC-SUBTASKS-1, partial F3-1 task-driven shift sizing

Empirical finding (T3, example-tm-tasks.json — 7 Tasks / 151 Subtasks): mean 21.6 subtasks per Task. 25 is a soft ceiling. Zero sub-subtask depth (flat 2-level hierarchy).

Implications:

The 2h Executor cap (CLAUDE.md “Agent Work Limits”) aligns nicely — if 25 subtasks × ~5–10 min each = ~2–4h, then 25-subtask Tasks are at the Executor-cap edge.
KH should adopt the SAME flat 2-level model. Don’t try to express sub-subtasks. If a Task needs more, split into sibling Tasks with Task-level deps.

Status: ANSWERED. Severity: MEDIUM. Next action: Liam confirm flat-2-level adoption.

A8. TM `details` field is the executor dispatch brief carrier (T3 discrepancy 1)

Resolves: partial Q-DISPATCH-1, partial F3-5

Empirical finding (T3, discrepancy 1): TM Subtask.details carries ~80% of the usable executor instruction (acceptance criteria, file paths, edge cases). KH hand-decomp omitted this field entirely.

Default to ratify:

KH adopts TM details and testStrategy as canonical dispatch-brief fields per subtask. The Orchestrator’s per-subtask dispatch brief is essentially {title, description, details, testStrategy, dependencies} pulled from TM.
Planner’s {N.4} Task Breakdown subtask is RESPONSIBLE for populating details + testStrategy per Subtask at decomposition time. Without this, the Executor dispatch brief degrades to a stub.

Status: ANSWERED. Severity: HIGH. Next action: Liam confirm; update F4-3 Planner skill mapping to require Planner emits filled details + testStrategy per subtask.

A9. TM id-type inconsistency (T3 — Task `id` = `"153"` string, Subtask `id` = `1` integer)

Resolves: new — surfaced by T3 (not in T1)

Empirical finding (T3): Task id is stringified integer ("153"); Subtask id is bare integer (1). Mixed types in same export. parentId: "undefined" literal string on every Subtask (vestigial).

KH options:

Mirror TM exactly (accept the mixed types).
Standardise to ONE type at KH side (then convert at TM-import time).
Use compound ids ("153.1" for subtasks — what KH was already doing in handoff prompts).

Status: ANSWERED (empirical reality known). Severity: LOW (operational hygiene). Next action: Liam pick standardisation strategy.

A10. TM Subtask status enum has wider value set than Task (T3)

Resolves: new

Empirical finding (T3): Subtask-level status adds pending and deferred that don’t appear at Task level. <info added on YYYY-MM-DDTHH:MM:SS.sssZ> blocks are append-only journal entries from mcp__task-master-ai__update_subtask.

Implications:

KH workflow needs the deferred subtask status if it adopts TM’s pattern of pausing/parking work.
The journal entry pattern is useful — KH’s continuation prompt “Completed work” could be auto-derived from these.

Status: ANSWERED. Severity: LOW. Next action: Liam acknowledge.

Section 2 — OPEN (Liam decision required; BLOCKERs first)

B1. Session entry pattern (FX-1)

Source Q-IDs: Q-ENTRY-1, Q-ENTRY-2

Decision needed: pick option (i) or (ii) from FX-1.

(i) Main session → /start-session → /session-driver-cmux → DEPLOY workflow-orchestrator agent in own cmux terminal. Main session monitors + intervenes.
(ii) Main session IS the orchestrator. /start-session → workflow-orchestration skill (no agent) → session-driver-cmux skill → amalgamated dispatch+worktrees skill → Executor+Checker workflow.

Status: OPEN. Severity: BLOCKER (drives every downstream lifecycle decision). Next action: Liam picks.

Recommendation: Option (ii) as default — simpler operational model for a 1-user project. Promote to (i) only if/when a complexity threshold is crossed. Open Q-ENTRY-2 supports this hybrid: build for (ii) first, treat (i) as escalation path.

B2. Task vs Workpackage terminology rollout (F3-1)

Source Q-IDs: Q-TERM-1, Q-TERM-2

Decision needed:

Q-TERM-1: Is the unit “Task” (terse) or “Task ID {N}” (precise)? Sub-decision: cite as T15 / T15.3, or Task 15 / Task 15.3, or [T15] / [T15.3]?
Q-TERM-2: Out-of-scope items too small for TM — Curator-route-to-subtask, ephemeral TodoList, or third option?

Status: OPEN. Severity: BLOCKER (every doc + agent file + skill file needs the rename concurrently). Next action: Liam picks both.

Recommendation: T15 / T15.3 shorthand (matches existing usage in handoff prompts); Curator-route-to-subtask for out-of-scope (preserves task-driven discipline). TodoList only for transient in-session reasoning, never for promoted work.

B3. Worktree collapse + track migration (F3-2)

Source Q-IDs: Q-WORKTREES-1, Q-WORKTREES-2, Q-COUNTER-1

Decision needed:

Q-WORKTREES-1: Migration plan for 4 current tracks (main, production-readiness, kh-knowledge-platform, ast-dataflow). Each has unmerged work; needs landing strategy.
Q-WORKTREES-2: What replaces per-track primer (docs/tracks/*.md)? Task-level briefing in TM description?
Q-COUNTER-1: Session-counter scheme post-collapse — single counter, TM-task-bound, date-based?

Status: OPEN. Severity: BLOCKER (every continuation prompt, every primer, every agent ref needs updating). Next action: Liam picks all three.

Recommendation:

Q-WORKTREES-1: each track lands its in-flight work via standard merge to main over 1–2 sessions per track; then track branch is archived.
Q-WORKTREES-2: drop per-track primers; promote any persisting context to CLAUDE.md or a per-Task TM description.
Q-COUNTER-1: single global session counter (e.g. kh-s49, kh-s50, …) — drop track prefix.

B4. Planner role scope (F2-2 + F4-3)

Source Q-IDs: Q-PLANNER-1, Q-PLANNER-2, Q-PLANNER-SKILLS-1, Q-PLANNER-SKILLS-3

Decision needed:

Q-PLANNER-1: Planner runs in own cmux terminal or Agent-tool dispatch from Orchestrator?
Q-PLANNER-2: Planner persists across waves OR spun up per-spec / per-task-breakdown?
Q-PLANNER-SKILLS-1: Which of the missing Planner skills are existing-plugin / net-new authorship / deferred? Specifically: ast-dataflow, gitnexus-*, vercel-react-best-practices, web-design-guidelines, interaction-design, mobile-design, ci-cd-and-automation, github-actions-templates, context-engineering-collection, prompt-engineering-patterns, mcp-builder, create-mcp-app, api-and-interface-design, mermaid-diagrams.
Q-PLANNER-SKILLS-3: Install context7 MCP?

Status: OPEN. Severity: BLOCKER (Planner is a new role; can’t author task-planner.md without these). Next action: Liam picks; T2/T3 do not help here.

Recommendation:

Q-PLANNER-1: Agent-tool dispatch (matches B1 option (ii) — Orchestrator-in-main spawns specialist sub-agents). Spec-authoring needs long-form research → opus tier in dedicated context.
Q-PLANNER-2: per-spec / per-task-breakdown (NOT persistent). One Planner instance per {N.2}-{N.4} chain; closes when subtasks ratified.
Q-PLANNER-SKILLS-1: bulk-classify exercise — Liam runs through the list, marks each as [installed-plugin / authorship-WP / defer].

B5. Checker variants design (F3-6 + FX-4)

Source Q-IDs: Q-CHECKER-1, Q-CHECKER-2, Q-CHECKER-3, Q-CHECKER-ORDER-2, Q-CHECKER-ORDER-3, Q-CHECKER-OUT-1, Q-PR-GATE-1, Q-PERF-SEC-2

Decision needed (composite):

Variant enumeration: spec-compliance, code-quality, simplest-approach, test-quality, design-tokens, silent-failure, type-design, performance, security. WHICH map to (a) per-subtask Checker variants, (b) per-task Checker variants, (c) PR-time Auditor gate?
Variant implementation: distinct AGENTS per variant OR one Checker agent with variant-selection input?
Cadence: per-subtask always OR per-task checkpoints OR Orchestrator-routed?
Output format: JSON-shaped finding packets so Orchestrator can route mechanically?
code-simplifier Anthropic agent vs simplify skill — keep both? drop one?
silent-failure-hunter agent → which lifecycle slot? (Likely PR-time, not per-subtask.)

Status: OPEN. Severity: BLOCKER. Next action: Liam picks; A3 + A5 partial defaults exist.

Recommendation (composite default):

Per-subtask = nothing beyond spec-compliance Checker variant.
Per-task = simplify (Executor) → code-quality + design-tokens (Checker code-review-and-quality axes) → optional type-design (if subtask kind = “introduce/refactor types”).
PR-time Auditor (new §3.7 PR phase before §3.8 Close) = silent-failure-hunter + security + performance (last three are conditional on subtask kinds in the wave).
One Checker agent file, variant-selection via dispatch brief field (cheaper to maintain than N agent files).
JSON-shaped Checker output: yes (Q-CHECKER-OUT-1). Schema TBD as small follow-up subtask.
Drop code-simplifier agent — simplify skill (or its replacement per Q-SIMPLIFY-1) covers the slot.

B6. Continuation-prompt mode declaration (F3-3)

Source Q-IDs: Q-MODE-1, Q-MODE-2

Decision needed:

Q-MODE-1: Single session = single mode (CONTINUE / EXTEND / AUTHOR), or can span multiple modes (e.g. wave 1 EXTEND, wave 2 AUTHOR)?
Q-MODE-2: Mode declared in continuation-prompt header OR computed at session-start from TM state?

Status: OPEN. Severity: HIGH. Next action: Liam picks.

Recommendation: allow multi-mode sessions (Q-MODE-1 = yes); declare mode per Task at session-plan time (Q-MODE-2 = computed by Orchestrator after reading TM at session start, surfaced in session plan for ratification).

B7. Spec-authoring sequence parent (F3-4)

Source Q-IDs: Q-SPEC-SUBTASKS-1, Q-SPEC-SUBTASKS-2, Q-SPEC-SUBTASKS-3

Decision needed:

Q-SPEC-SUBTASKS-1: are {N.1}-{N.4} (Research, ProductSpec, TechSpec, Breakdown) in SAME parent as {N.5+} implementation subtasks, OR do they become own top-level Tasks with implementation Task being N+1?
Q-SPEC-SUBTASKS-2: “implementation-ready” decision rule — concrete signals?
Q-SPEC-SUBTASKS-3: who decides “implementation-ready” — Orchestrator alone, with Checker, or escalate to Liam?

Status: OPEN. Severity: HIGH (downstream of B5 + B6). Next action: Liam picks.

Recommendation:

Q-SPEC-SUBTASKS-1: SAME parent Task. Spec authoring is part of the work to ship the feature; should not require a sibling-Task dep. Matches A6 sibling-only TM constraint.
Q-SPEC-SUBTASKS-2: signals = (a) PRODUCT.md has numbered + testable Behavior invariants (write-product-spec:72-95); (b) TECH.md has migration plan + Proposed changes per invariant (write-tech-spec:50-67); (c) all author-flagged Qs resolved; (d) Checker PASSED both specs.
Q-SPEC-SUBTASKS-3: Orchestrator decides after Checker PASS; escalate to Liam only if signals (a)-(d) are partial or if Checker FAIL-loop runs 3+ times (matches workflow-orchestrator.md “Error handling” 3-strikes rule).

B8. Worker variants — bare-mode reinterpretation (FX-7)

Source Q-IDs: Q-BARE-1, Q-BARE-2, Q-BARE-3

Decision needed:

Q-BARE-1: Is Anthropic “bare mode” (code.claude.com/docs/en/headless#start-faster-with-bare-mode) applicable beyond headless?
Q-BARE-2: If not, which context-economy alternative — per-subtask CLAUDE.md trimming, skill auto-discovery filtering, explicit allowedTools overrides via dispatch brief, plugin-disable flags?
Q-BARE-3: Out-of-workflow KH platform use case for streamlined agents — separate Q for later session.

Status: OPEN. Severity: HIGH (the existing workflow-worker-minimal.md is on death row pending this decision; original S48 WP3 minimal-worker tool-gate enforcement is INVALIDATED). Next action: Liam reads bare-mode docs + picks.

Recommendation:

Q-BARE-1: research-then-decide. Bare mode IS headless-specific per the URL fragment; sub-agents probably can’t inherit, but worth confirming. If confirmed inapplicable, drop the term and use generic “context-economy”.
Q-BARE-2: combination of per-dispatch allowedTools + per-dispatch skill list (already supported by Anthropic agent frontmatter) + per-dispatch CLAUDE.md selection (via CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 + project-local override). NOT a separate agent file — economy built into the default Executor.
DELETE .claude/agents/workflow-worker-minimal.md; remove --worker-mode minimal from launch-worker.sh; replace with optional per-dispatch context-economy flags on the standard Executor.

B9. Orchestrator vs Executor commit/branch hygiene (F4-4 Q-EXEC-SKILLS-2)

Source Q-IDs: Q-EXEC-SKILLS-2, Q-RENAME-1 (related)

Decision needed: commit-commands + git-workflow-and-versioning — Executor invokes (each commits its subtask) OR Orchestrator invokes (only Orchestrator does merges)? Probably both for different surfaces — but what’s the actual split?

Status: OPEN. Severity: MEDIUM. Next action: Liam picks.

Recommendation:

Executor: invokes commit-commands per subtask (commit own work to own worktree branch). NOT git-workflow-and-versioning (workflow-level concerns).
Orchestrator: invokes git-workflow-and-versioning (sequential merge orchestration, conflict resolution, branch hygiene). NOT commit-commands per se (defers to Executors).

B10. Finding routing — fix-Executor vs Curator decision rule (F2-4)

Source Q-IDs: Q-FINDINGS-1

Decision needed: decision rule for “Orchestrator picks direct-fix Executor vs Curator triage”. Candidates: severity, in-scope-ness, ambiguity, time-to-fix.

Status: OPEN. Severity: MEDIUM. Next action: Liam picks.

Recommendation: binary on in-scope-ness alone. If finding is within the current task’s acceptance criteria → fix-Executor. If finding mentions out-of-scope file/concern → Curator triage. Severity is the Checker’s verdict input, not the routing input. Ambiguity → Curator (Curator is the routing arbitrator).

B11. Agent rename scope (F2-3)

Source Q-IDs: Q-RENAME-1

Decision needed: is workflow-orchestrator.md also renamed (task-orchestrator.md), or does it keep workflow- prefix because it operates above any single task? Same Q for workflow-curator.md.

Status: OPEN. Severity: MEDIUM. Next action: Liam picks.

Recommendation: keep workflow- prefix on Orchestrator and Curator (session/wave-level scope). Rename only Executor and Checker (per-task scope). Liam’s feedback table at feedback:11-17 already reflects this.

B12. Subtask kind explicit vs implicit in TM (F4-2)

Source Q-IDs: Q-SUBTASK-KIND-1

Decision needed: is “check” subtask explicit in TM (separate subtask {N.3-check} after {N.3-execute}) OR implicit (single subtask flips to “checked” status after execution)?

Status: OPEN. Severity: MEDIUM (informs every Planner decomposition). Next action: Liam picks.

Recommendation: EXPLICIT. Each implementation subtask is followed by its own Checker subtask. Matches F3-4’s spec-authoring example (Executor + Checker iterate as distinct subtasks). Also matches TM’s flat status enum (no “checked” state — it’d need explicit subtask with own status field).

Section 3 — NEW gaps surfaced by T2 (not in original T1 feedback)

N1. `fix-findings` / `fix-checker-output` skill missing (T2 gap)

Decision needed: does KH need a dedicated skill for “Executor re-entry after Checker FAIL/NOTE”, or does Executor reuse implement-specs / incremental-implementation?

Recommendation: reuse implement-specs with a “fix-only” mode flag in the dispatch brief. No new skill.

Status: OPEN. Severity: MEDIUM.

N2. `merge-coordinator` skill missing (T2 gap)

Decision needed: package the sequential cherry-pick / merge / regression-test cycle (currently described in CLAUDE.md “Worktree isolation rules”) as a skill?

Recommendation: YES. Author merge-coordinator SKILL.md as part of Orchestrator’s skill set. Covers cherry-pick ordering, post-merge git status leak detection, full-test-suite gate per merge, knip post-add/remove.

Status: OPEN. Severity: MEDIUM.

N3. `integration-tier-promotion` skill missing (T2 gap)

Decision needed: package the gate-promotion logic (subtask passed → task pass → wave pass → PR pass) as a skill?

Recommendation: defer until the four roles + Checker variants are stable. The promotion logic IS the Orchestrator’s core loop and may be better expressed in workflow-orchestrator.md agent body than as a separate skill.