kh-sdlc-workflow Feedback — Structured

kh-sdlc-workflow Feedback — Structured

Provenance

• Original (preserved verbatim): docs/plans/phase-0-investigation/kh-sdlc-workflow-feedback.md (Liam, S48)
• This doc: auto-decomposed from the original by S48 synthesis (Task 1). The original is the source of truth; if this doc disagrees with the original, the original wins.
• Purpose: turn Liam’s freeform notes into atomic, addressable entries so each piece of feedback can be tracked, debated, and ratified independently. Each entry maps back to original line numbers for verification.
• Audience: the orchestrator (and Liam) when ratifying the next iteration of kh-sdlc-workflow.md.

How to read this

1. Every entry has a stable ID (F<section>-<N> for section-tied; FX-<N> for cross-cutting).
2. Categories (one per entry):
   • DECISION — Liam has settled on this direction; reflect in the workflow doc.
   • CLARIFICATION — Liam is correcting a wrong understanding in the S47 canonical doc; reflect by editing the relevant section.
   • QUESTION — open Q that needs an answer before a DECISION can be made; feeds into _archive/kh-sdlc-workflow-open-questions.md (T5; archived S491).
   • CONTRADICTION — internal tension in the feedback itself; needs Liam to resolve.
3. Affects column lists the kh-sdlc-workflow.md section(s) that need editing once the entry is ratified.
4. Open Qs raised is the breadcrumb that feeds T5.

---

Section-by-section feedback

§2 Roles (kh-sdlc-workflow.md lines 47–75)

F2-1 — [DECISION] Roles table is DRAFT pending feedback review

“DRAFT - to be updated after next workflow review.” Source: feedback:8

• Affects: §2 roles table.
• Synthesised intent: the table in the feedback doc is a placeholder. The real role set will be derived from the rest of the feedback once ratified.
• Open Qs raised: none directly; downstream entries determine the final role set.

F2-2 — [DECISION] Add a “Task Planner” role distinct from Orchestrator

“Task Planner | opus-4-7 (max) | .claude/agents/task-planner.md (required) | To be updated after feedback review” Source: feedback:14

• Affects: §2 roles table; §4 per-phase skill routing (Planner gets ownership of Research/Design, Spec-authoring, Task Breakdown phases per F4-3); §3 Lifecycle (phases 3.2 + 3.3 likely shift from Orchestrator to Planner).
• Synthesised intent: the S47 canonical merges planning into Orchestrator. Liam wants planning extracted into a dedicated role (own context window, own model tier, own skills) so the Orchestrator stays a pure dispatch + gate coordinator.
• Open Qs raised:
  • Q-PLANNER-1: Does the Planner run in its own cmux terminal, or is it an Agent-tool dispatch from the Orchestrator?
  • Q-PLANNER-2: Does the Planner persist across waves (multi-task session) or is it spun up per-spec / per-task-breakdown?

F2-3 — [DECISION] Rename Executor → Task Executor, Checker → Task Checker

“Task Executor | sonnet-4-6 | .claude/agents/task-executor.md (rename)” “Task Checker | sonnet-4-6 | .claude/agents/task-checker.md (rename)” Source: feedback:15-16

• Affects: .claude/agents/workflow-executor.md → task-executor.md; .claude/agents/workflow-checker.md → task-checker.md; every reference to these names in kh-sdlc-workflow.md and dependent skills; settings.json agent-discovery patterns.
• Synthesised intent: consistent task-driven naming. Aligns with the §3 lifecycle shift (F3-1).
• Open Qs raised:
  • Q-RENAME-1: Is workflow-orchestrator.md also renamed (e.g. task-orchestrator.md) or does it keep the workflow- prefix because it operates at the session/wave level above any single task? (Liam’s feedback table keeps “Workflow Orchestrator” and “Workflow Curator” with the workflow- prefix — implies workflow-level scope is retained for those two roles.)

F2-4 — [CLARIFICATION] Orchestrator NEVER directly fixes findings

“Orchestrator wouldn’t directly fix findings. Based on feedback from the Checker (and/or other agents), they would either deploy a new Executor to fix the issues directly, or deploy the Curator who would assess the findings to determine the approach required - add new subtask(s), impact to current task’s remaining subtasks/parallel implementation work/next task(s), update product backlog, escalate for decision on backlog versus roadmap/wider decision.” Source: feedback:21

• Affects: kh-sdlc-workflow.md §2 “Verification gates are not optional” paragraph (currently says “The Orchestrator fixes ALL findings (FAIL and NOTE alike) before merging.” which is technically correct but ambiguous on the mechanism); §3.6 Curate phase; workflow-orchestrator.md agent file.
• Synthesised intent: Two distinct response paths after Checker feedback:
  1. Direct-fix Executor — for in-scope findings (the fix is part of the same task / acceptance criteria).
  2. Curator triage — for ambiguous or out-of-scope findings; Curator decides on subtask vs roadmap/backlog promotion vs no-action, plus assesses ripple impact on remaining subtasks, parallel implementation work, next tasks.
• Open Qs raised:
  • Q-FINDINGS-1: Decision rule for “Orchestrator picks fix-Executor vs Curator”. Heuristic candidates: severity, in-scope-ness, ambiguity, time-to-fix.

---

§3 Lifecycle (kh-sdlc-workflow.md lines 77–145)

F3-1 — [DECISION] Re-think lifecycle to be task-driven (not WP-driven)

“We need to re-think and re-work the lifecycle to be task-driven. Task’s provide the ‘why’, plus they add observability and traceability.” Source: feedback:25

• Affects: every “WP” reference in kh-sdlc-workflow.md, workflow-orchestrator.md, workflow-executor.md, workflow-checker.md, workflow-curator.md, workflow-worker-minimal.md, all .claude/skills/*/SKILL.md that say “workpackage”, all continuation prompt templates in .claude/skills/handoff/SKILL.md, S48 prompt format itself.
• Synthesised intent: “Task ID {N}” / “subtask {N.N}” replaces “WP{N}” as the universal unit of work. Tasks live in Taskmaster (where possible); ad-hoc in-session requests may be tracked outside TM but should be the exception.
• Open Qs raised:
  • Q-TERM-1: Is the unit “Task” or “Task ID {N}”? (Latter is more verbose but matches TM’s id field convention from F2-1 examples.)
  • Q-TERM-2: How are session-discovered out-of-scope items tracked if they’re too small for a TM entry? (Curator routes to subtask of current task is one path; ephemeral TodoList another.)

F3-2 — [DECISION] Collapse to main + feature branches + isolated worktree agents

“Shift to task-driven will also include collapsing the top-level worktrees to just main, and utilising feature branches + isolated worktree agents. /start-session skill will need to be updated - continuation prompt will be reviewed, but the session’s tasks will be available in taskmaster.” Source: feedback:27 (on §3.1)

• Affects: docs/tracks/*.md (production-readiness, kh-knowledge-platform, ast-dataflow primers); start-session skill (.claude/skills/start-session/SKILL.md); handoff skill (.claude/skills/handoff/SKILL.md); CLAUDE.md “Parallel Tracks” section; the four current long-lived worktrees would close once the work is reconciled.
• Synthesised intent: drop the multi-track parallel-worktree model. Future work uses TM-tracked tasks → feature branches off main → isolation-via-Agent-tool-worktree for the implementation work. Track-local session counters (kh-prod-readiness-sN) likely disappear in favour of a single session counter (or session is bound to TM task id rather than a counter).
• Open Qs raised:
  • Q-WORKTREES-1: Migration plan for the four current tracks (main, production-readiness, kh-knowledge-platform, ast-dataflow). Each has unmerged work — how is it landed?
  • Q-WORKTREES-2: What replaces the per-track primer doc (docs/tracks/*.md)? Task-level briefing in the TM description?
  • Q-COUNTER-1: Session-counter scheme post-collapse. Single counter? Bound to TM task? Date-based?

F3-3 — [DECISION] Continuation prompt informs Orchestrator with 3 modes

“Continuation prompt will inform the Orchestrator on what is required for the session. This will either be continuing with taskmaster task/subtask implementation, or updating taskmaster by adding new subtasks to an in-flight task, or adding a new task(s) and expanding to subtasks.” Source: feedback:28 (on §3.2 + old WP3)

• Affects: handoff SKILL.md (the continuation-prompt template needs an explicit “mode” field); start-session SKILL.md (must classify the mode at session start); workflow-orchestrator.md (mode → dispatch behaviour).
• Synthesised intent: three named session modes:
  1. CONTINUE — execute next subtasks of an in-flight TM task.
  2. EXTEND — add new subtasks to an in-flight TM task (then execute or hand to next session).
  3. AUTHOR — add new task(s) + expand to subtasks (then execute or hand to next session).
• Open Qs raised:
  • Q-MODE-1: Can a single session span multiple modes? (e.g. wave 1 = EXTEND existing task, wave 2 = AUTHOR new task)
  • Q-MODE-2: Where is the mode declared? Continuation prompt header? Computed at session-start from TM state?

F3-4 — [DECISION] Spec-authoring pipeline is a numbered subtask sequence

“{N}.1 - Research/Investigate XYZ … {N}.2 - Write Product spec [Written by Workflow Executor using writing-product-spec and then Orchestrator deploys Workflow Checker - Orchestrator deploys Executor to apply ALL findings or moves to next task] - {N}.3 - Write Technical Spec [same pattern] - [Orchestrator then determines whether ratified product and tech specs are ‘implementation-ready’] … if further decomposition is required, a new ‘{N}.4 - {feature/functionality} task breakdown’ task would be required first … then back to Executor to apply ALL findings. Once ratified, if the plan is determined to be ‘implementation-ready’, it can be added as a new taskmaster task and expanded to subtasks.” Source: feedback:28 (continued)

• Affects: kh-sdlc-workflow.md §3.2 (Spec phase needs explicit subtask decomposition); kh-sdlc-workflow.md §3.3 (Plan phase needs the “implementation-ready” decision rule + conditional {N}.4 task breakdown subtask); planning-and-task-breakdown skill triggering criteria (extends the S47 §7 rules).
• Synthesised intent: new feature work has a deterministic 3–4 subtask sequence before any implementation subtasks are even enumerated:
  • {N}.1 Research/Investigate (domain skills as needed)
  • {N}.2 Product spec (Executor uses write-product-spec → Checker → fix-Executor loop until PASS)
  • {N}.3 Tech spec (same loop with write-tech-spec)
  • {N}.4 (conditional) Task breakdown (Executor uses planning-and-task-breakdown → Checker → fix-Executor)
  • Once {N}.4 ratified (or skipped because specs are atomic enough), the implementation subtasks {N}.5+ are appended to the same parent task.
• Open Qs raised:
  • Q-SPEC-SUBTASKS-1: Are {N}.1-{N}.4 always in the SAME parent task, or do they each become their own top-level Task with the implementation Task being {N+1}?
  • Q-SPEC-SUBTASKS-2: Decision rule for “implementation-ready” — what concrete signals? (PRODUCT.md has unambiguous acceptance criteria? TECH.md has migration plan? All Qs resolved?)
  • Q-SPEC-SUBTASKS-3: Who decides “implementation-ready” — Orchestrator alone, Orchestrator-with-Checker, or escalate to Liam by default?

F3-5 — [CLARIFICATION] Orchestrator §3.4 role is parallel/serial dispatch only

“Orchestrator’s role here is to understand which subtasks can be executed sequential versus parallel. All research/investigate/planning/design work should have been completed by this point, the Orchestrator is focused on dispatching Executor agents to complete ‘implementation-ready’ subtasks - the ‘dispatch brief’ shouldn’t need to vary here, this should ideally be pure execution of a pre-defined sub-task.” Source: feedback:29 (on §3.4)

• Affects: §3.4 Implement; workflow-orchestrator.md “Dispatch brief template”.
• Synthesised intent: by the time §3.4 starts, all variability is in the SUBTASK (skill list, file boundaries, acceptance criteria). The dispatch brief becomes a thin transport layer pulling those fields from the TM record. Orchestrator’s only judgement call is parallel-vs-serial.
• Open Qs raised:
  • Q-DISPATCH-1: Where do the “skills to invoke” come from at dispatch time — TM subtask field? Curated by Planner at §3.3? Orchestrator’s routing matrix?

F3-6 — [CLARIFICATION] Checkers are per-subtask/per-stage, NOT per-wave

“Checkers aren’t ‘per wave’, they are ‘per subtask/per stage’. This could be ‘does the implementation meet the spec and project conventions?’, or ‘Does the implementation meet code quality standards?’ or ‘Is this the most elegant implementation and has the simplest approach been used?’ - this is an audit phase, and the Orchestrator’s role is to then determine if these are quick fixes which new Executors can resolve, or if the Curator assessment workflow is required.” Source: feedback:30 (on §3.5)

• Affects: §3.5 Verify; workflow-checker.md agent file (currently has six audit axes baked into one Checker — needs split into Checker variants per concern); §6.1 Checker verdict.
• Synthesised intent: the single Checker-with-6-axes is wrong shape. Real shape is: per-subtask, the Orchestrator picks the appropriate Checker variant (spec-compliance, code-quality, simplest-approach, etc.) and dispatches it. The verdict + finding-routing pattern (F2-4) is the same; only the Checker’s axis-set changes.
• Open Qs raised:
  • Q-CHECKER-1: Enumeration of Checker variants needed. Candidates from feedback:
    • spec/standards compliance
    • code quality
    • simplest-approach (overlaps with simplify skill)
    • test quality
    • design tokens (UI-only subtasks)
    • silent-failure prevention (overlaps with silent-failure-hunter agent — F-X3)
    • type design (overlaps with type-design-analyzer agent — F-X3)
    • performance (overlaps with potential performance-optimization skill — F-X3)
    • security (overlaps with potential security-and-hardening skill — F-X3)
  • Q-CHECKER-2: Are variants distinct AGENTS, or one Checker agent with a variant-selection input?
  • Q-CHECKER-3: Cadence — per subtask always, or only at task-completion checkpoints? (Connects to F-X2.)

---

§4 Per-phase skill routing (kh-sdlc-workflow.md lines 147–199)

F4-1 — [CLARIFICATION] Baseline Executor + Checker are skill-agnostic

“It looks like the best approach would be using baseline Executor and Checker agents, who’s role is ‘task-execution & verification’ - it’s the research/planning/design/verification/debugging phases where agents require domain or phase-specific skills, rather than the implementation phase, and introducing a task-planner may be a suitable option here.” Source: feedback:34

• Affects: §4 entire matrix; task-executor.md (post-rename per F2-3) — skill list becomes inputs from dispatch brief, not baked in; task-checker.md similarly; introduction of task-planner.md.
• Synthesised intent: Executor and Checker are pure execution shells. Skills are injected via dispatch brief per subtask. Planner (new role per F2-2) owns the skill-heavy upstream phases.
• Open Qs raised:
  • Q-AGENT-CONFIG-1: Mechanism for skill injection. Anthropic agent frontmatter has a skills field (per feedback FX-6) — does that satisfy this? Or does the Orchestrator pass skills as part of the prompt body each dispatch?

F4-2 — [DECISION] Subtasks are either executed OR checked

“Sub-tasks are either executed or checked - skill-agnostic Executors and Checkers complete these actions.” Source: feedback:41

• Affects: §3 lifecycle; the TM subtask schema (need a kind: execute | check field? or is it implicit from skill list?).
• Synthesised intent: binary subtask kind. Implementation, QA pass, doc update = “execute”. Spec-compliance audit, code-quality audit, simplification audit = “check”.
• Open Qs raised:
  • Q-SUBTASK-KIND-1: 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)? The feedback’s spec-authoring example (F3-4) implies separate Executor + Checker loops which suggests EXPLICIT.

F4-3 — [DECISION] Planner phase + skill mapping

[Long enumeration in feedback:43-74 covering Research & Design (current state + target state), Spec-authoring, Task Breakdown sub-phases] Source: feedback:43-74

• Affects: §4 matrix (Planner row + sub-rows per phase); new .claude/agents/task-planner.md agent file.
• Synthesised intent: Planner owns three pre-implementation phases:
  • Research & Design
    • Current state: context-engineering, ccc, ast-dataflow (new), Supabase MCP, cocoindex, gitnexus-impact-analysis, gitnexus-refactoring
    • Target state: context-engineering, context7 MCP, supabase-postgres-best-practices, cocoindex, api-and-interface-design, claude-api, vercel-react-best-practices, web-design-guidelines, interaction-design, mobile-design, ci-cd-and-automation, github-actions-templates, context-engineering-collection, prompt-engineering-patterns, create-skill, update-skill, agent-development, mcp-builder, create-mcp-app, playwright-best-practices, documentation-and-adrs, astro, mermaid-diagrams
  • Spec-authoring: write-product-spec, test-driven-development, write-tech-spec, mermaid-diagrams
  • Task Breakdown: test-driven-development, planning-and-task-breakdown, mermaid-diagrams
• Open Qs raised:
  • Q-PLANNER-SKILLS-1: Many of these skills do not exist in .claude/skills/ yet (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). Which are existing-plugin? Which are net-new authorship? Which are deferred?
  • Q-PLANNER-SKILLS-2: test-driven-development appears in BOTH Spec-authoring AND Task Breakdown phases for the Planner. Original test-driven-development SKILL.md is implementation-oriented — is it being reinterpreted by the Planner as “TDD-shaped spec writing”? (T2 should answer this empirically.)
  • Q-PLANNER-SKILLS-3: context7 MCP not currently installed. Add to project plugins? Or defer?

F4-4 — [DECISION] Executor phase + skill mapping

[Enumeration feedback:75-99 covering Implementation, QA, Testing, Debugging, Documentation Updates, and exceptions for skill-reviewer + agent-creator] Source: feedback:75-99

• Affects: §4 matrix (Executor row + sub-rows per phase); task-executor.md.
• Synthesised intent: Executor sub-phase skill map:
  • Implementation: context-engineering, implement-specs (Q: too broad in task-driven model?), commit-commands, git-workflow-and-versioning (Q: Orchestrator only?), fix-errors (?)
  • QA: code-simplification (likely renamed simplify), code-review-and-quality
  • Testing: browser-testing-with-devtools + agent-browser
  • Debugging: gitnexus-debugging, browser-testing-with-devtools + chrome-cdp, chrome-devtools MCP
  • Documentation Updates: documentation-and-adrs, astro, mermaid-diagrams
  • Exception A: Skill reviews use skill-reviewer agent (not Executor).
  • Exception B: Agent creation uses agent-creator agent (not Executor).
• Open Qs raised:
  • Q-EXEC-SKILLS-1: Is implement-specs redundant in a task-driven model where the subtask already encodes the spec slice? (T2 should answer.)
  • Q-EXEC-SKILLS-2: commit-commands + git-workflow-and-versioning — Executor or Orchestrator? Argument for Executor: each Executor commits its own subtask. Argument for Orchestrator: only the Orchestrator does sequential merges. Probably BOTH need the skills but for different surfaces.
  • Q-EXEC-SKILLS-3: fix-errors skill — does it exist? What does it do? (T2 should answer.)
  • Q-EXEC-SKILLS-4: code-simplification vs simplify — these are the same skill renamed? Confirm against .claude/skills/simplify/SKILL.md.
  • Q-EXEC-SKILLS-5: Several debugging skills (gitnexus-debugging, browser-testing-with-devtools, chrome-devtools MCP) not currently installed locally. Plugin source / install plan?

F4-5 — [DECISION] Justification: no domain skills for pure implementation subtasks

“Why don’t we use domain-specific skills for implementation tasks? This is because once we are at the stage where something is ready to be implemented, we fully understand the code base and implications, we’ve researched the latest technical information and patterns, we’re following best practice, everything has been documented, and so the task/subtask has therefore already been carefully curated and verified, and is ready to be executed.” Source: feedback:98-99

• Affects: §4 matrix narrative; task-executor.md description.
• Synthesised intent: the Planner’s Research+Design phase has already pulled all domain context into the spec(s). The Executor’s job is mechanical translation of spec → code. Domain skills don’t fire at implementation time because they’ve already done their work upstream.
• Open Qs raised:
  • Q-DOMAIN-1: What if mid-implementation an Executor discovers a domain consideration the Planner missed? Escalation path? (Probably loops back to Planner for spec amendment, but should be explicit.)

F4-6 — [CLARIFICATION] Checker is verifier + structured-feedback producer, not do-er

“Checkers also provide structured feedback for the Orchestrator, so that the Orchestrator can make informed decisions on next workflow actions.” Source: feedback:102

• Affects: §4 matrix; task-checker.md output format.
• Synthesised intent: beyond PASS/FAIL/NOTE, the Checker output must be MACHINE-PARSEABLE so the Orchestrator can route findings (fix-Executor vs Curator) without re-reading the Checker’s prose.
• Open Qs raised:
  • Q-CHECKER-OUT-1: JSON-shaped Checker output schema? Per-finding: id, severity, axis, file:line, suggested-route (in-scope-fix / out-of-scope-curate), recommended-fix-skill.

F4-7 — [DECISION] Orchestrator skill mapping

“Orchestrator: Session orchestration - context-engineering, session-driver-cmux, workflow-orchestration, handoff. Phase-specific: Workflow/project context - claude-md-management. When new tasks are required - spec-driven-implementation. Requirements gathering - brainstorming, idea-refine. Deployment - git-workflow-and-versioning, resolve-merge-conflicts, diagnose-ci-failures.” Source: feedback:104-111

• Affects: §4 matrix Orchestrator row; workflow-orchestrator.md skill list.
• Synthesised intent: Orchestrator skill list bifurcates into “always-loaded” (session orchestration) + “phase-specific” (activated as session traverses phases).
• Open Qs raised:
  • Q-ORCH-SKILLS-1: workflow-orchestration is named as a SKILL here but currently doesn’t exist as a skill — it’s an AGENT (workflow-orchestrator.md). Is Liam proposing a separate skill file that the Orchestrator agent invokes? Or is this a renaming/extraction?
  • Q-ORCH-SKILLS-2: brainstorming, idea-refine, resolve-merge-conflicts, diagnose-ci-failures, claude-md-management not all currently in .claude/skills/. Plugin source / install plan?
  • Q-ORCH-SKILLS-3: spec-driven-implementation shows up in Orchestrator skills here (“when new tasks are required”) AND in Planner’s spec-authoring phase (F4-3). Which role actually invokes it? (T2 should answer per its SKILL.md.)

F4-8 — [DECISION] Curator skill mapping

“Curator: Finding triage - triage-finding. Roadmap/backlog promotion - update-roadmap-backlog.” Source: feedback:113-115

• Affects: §4 matrix Curator row.
• Synthesised intent: unchanged from S47.
• Open Qs raised: none.

F4-9 — [DECISION] Evaluator skill mapping (role still deferred)

“Evaluator: Workflow performance improvement - claude-md-management, create-skill, update-skill.” Source: feedback:117-118

• Affects: §10 deferred Evaluator role; future agent file.
• Synthesised intent: when Evaluator is built, these are its skills.
• Open Qs raised: none (role itself is deferred).

F4-10 — [QUESTION] Auditor role TBD

“Auditor: TBD” Source: feedback:120-121

• Affects: §10 deferred Auditor role.
• Synthesised intent: placeholder; will be answered when ~10 orchestrated sessions exist to evaluate against.
• Open Qs raised: none session-blocking.

---

§5 Dispatch primitives (kh-sdlc-workflow.md lines 201–277)

F5-1 — [DECISION] §5 deferred until wider workflow finalised

“These will be adapted after finalising the wider workflow based on this round of feedback.” Source: feedback:125

• Affects: §5 wholesale.
• Synthesised intent: §5 (session-driver-cmux / Agent+isolation / cmux topology) gets re-evaluated after F2/F3/F4 lock in. Likely impacted by F3-2 (worktree collapse), FX-1 (orchestration entry pattern), FX-4 (worker-variant rethink).
• Open Qs raised: all current §5 content is provisional pending wider settlement.

---

Cross-cutting feedback (not tied to a single §)

Session entry pattern

FX-1 — [QUESTION] Two candidate orchestration entry patterns

“(i) Main Session: Invokes /start-session, chains to /session-driver-cmux, deploys workflow-orchestrator agent who begins the Executor + Checker workflow. Main session monitors orchestration agent’s cmux terminal, and communicates with the workflow orchestrator, or intervenes, if there are any issues spotted. (ii) Main Session: Invokes /start-session, chains to workflow-orchestration (skill-version, rather than agent file), chains to /session-driver-cmux skill, chains to amalgamated dispatching-parallel-agents + using-git-worktrees (unless workflow-orchestration covers this), begins the Executor + Checker workflow.” Source: feedback:135-138

• Affects: start-session SKILL.md; workflow-orchestrator.md agent file (or its conversion to a skill); session-driver-cmux SKILL.md; dispatching-parallel-agents + using-git-worktrees skill files (potential amalgamation per FX-2).
• Synthesised intent: undecided. Option (i) treats Orchestrator as a separate cmux-isolated agent (main session monitors); Option (ii) treats Orchestrator as a SKILL the main session itself invokes.
• Trade-off sketch:
  • (i) pros: main session stays clean for human-orchestrator interjection; Orchestrator gets dedicated context window; failure of Orchestrator doesn’t crash the human session.
  • (i) cons: monitoring overhead; doubled cmux + sub-Claude infrastructure for what may be a single-orchestrator-instance project; conversation latency main↔orchestrator.
  • (ii) pros: single context, simpler mental model, no cmux orchestration overhead; faster iteration.
  • (ii) cons: human session IS the orchestrator — if it crashes / runs out of context / autocompacts, the orchestration state is in the same boat; harder for human to intervene mid-task.
• Open Qs raised:
  • Q-ENTRY-1: Pick (i) or (ii) as default for KH workflow.
  • Q-ENTRY-2: If (i), is there a smaller orchestrator running in main that “promotes” to a cmux agent when the work exceeds a complexity threshold?

FX-2 — [QUESTION] Amalgamate dispatching-parallel-agents + using-git-worktrees?

“Does the Orchestrator need dispatching-parallel-agents and/or using-git-worktrees, or would it make sense to create an amalgamated skill, covering the aspects which will be specific to our workflow?” Source: feedback:131

• Affects: .claude/skills/dispatching-parallel-agents/SKILL.md, .claude/skills/using-git-worktrees/SKILL.md. Potential new skill: kh-parallel-worktree-dispatch (or similar).
• Synthesised intent: the two skills are almost always invoked together for KH parallel agent work. Amalgamation would reduce the orchestrator’s skill-routing decision overhead.
• Open Qs raised:
  • Q-AMALGAMATE-1: Are there KH workflows that use ONE without the OTHER? If yes, keep separate. If no, amalgamate.
  • Q-AMALGAMATE-2: If amalgamating, does session-driver-cmux subsume both? (T2 + T4 should answer.)

Code self-review necessity

FX-3 — [QUESTION] Is “Code self-review” phase redundant?

“Is the ‘Code self-review’ phase required, or are we duplicating effort? My thinking here is that by this point: Spec(s) would have been created and verified -> converted to a plan & verified OR added to taskmaster as a task and subtasks -> Executor should already have clear instructions for implementation approach -> Checker is then adversarially reviewing the implementation against the spec -> full verification is about to take place.” Source: feedback:140-141

• Affects: §4 Code self-review row (currently lists code-review-and-quality + simplify invoked by “Executor (before commit) and Checker (during audit)” — that dual invocation is the redundancy under question).
• Synthesised intent: if Checker variants cover code quality + simplification (F3-6 Q-CHECKER-1), the Executor’s pre-commit self-review is duplicative. Remove from Executor; keep only in Checker variants.
• Open Qs raised:
  • Q-SELF-REVIEW-1: Drop Executor self-review entirely, or retain as opt-in for high-risk subtasks?

Checker scope + cadence + agent-vs-skill ordering

FX-4 — [QUESTION] Checker scope split + ordering of simplify / review / Checker

“Currently we have two core Anthropic agents available as a baseline - code-simplifier and code-reviewer. We then also have the code-review-and-quality skill. We need to determine the correct workflow ordering here … Is the Checker therefore purely ‘spec and standards compliance’, and a separate agent or agents cover code review, quality, and simplification? … Or should it be that code simplification takes place first (prior to the checker), followed by code review and quality checks, and then Checker? Or is it that code simplification runs after each sub-task (or main task), but code quality and review only takes place once a full task is complete? I imagine there’s nuance here and certain tasks won’t require code simplification or quality review at all from a code perspective as they won’t have implemented code.” Source: feedback:143-144

• Affects: §3.5 Verify; §6.1 Checker verdict; workflow-checker.md six-axis verdict (may split into N Checker variants); ordering of new Checker subtasks within a parent task.
• Synthesised intent: the current 6-axis Checker is the wrong granularity. Real shape probably is:
  • Per-subtask: simplify + spec/standards compliance (fast, deterministic, narrow).
  • Per-task (or PR-time): code review + quality + type design + silent-failure + security/perf as relevant.
• Open Qs raised:
  • Q-CHECKER-ORDER-1: Pick one of the patterns from the feedback (or design a new one). Candidates:
    • A: Checker (spec+standards) → simplify → code-review (per subtask).
    • B: Simplify → code-review → Checker (per subtask).
    • C: Simplify per-subtask; Checker (spec+standards) per-subtask; code-review + quality at task-completion only.
    • D: Determined per-subtask by Orchestrator routing matrix (no fixed order).
  • Q-CHECKER-ORDER-2: Anthropic’s code-simplifier agent vs simplify skill: keep both? Drop one? (Agent owns the prompt; skill owns the procedure — possibly complementary.)
  • Q-CHECKER-ORDER-3: PR-time vs subtask-time gating. silent-failure-hunter is described as “final check at PR time” — fits as a PR-gate (the “Auditor” role at §10?) not a per-subtask Checker.

FX-5 — [QUESTION] Bring in performance-optimization + security-and-hardening?

“Should performance-optimization and security-and-hardening be brought in, to be used, when a specific subtask or task would benefit from these?” Source: feedback:145

• Affects: §4 matrix (new Checker variants); skill installation list.
• Synthesised intent: conditional Checker variants for subtasks where these axes apply.
• Open Qs raised:
  • Q-PERF-SEC-1: Source for these skills (Anthropic plugin? authorship?).
  • Q-PERF-SEC-2: Trigger heuristic — Orchestrator detects subtask kind and adds these Checker variants automatically? Planner declares them at spec time?

FX-6 — [QUESTION] Integration of type-design-analyzer + silent-failure-hunter

“There are also Anthropic baseline agents available for type-design-analyzer (when introducing or refactoring types) and silent-failure-hunter (as a final check at PR time).” Source: feedback:146

• Affects: §3.5 Verify; §10 deferred roles (possibly new “PR-time Auditor” role).
• Synthesised intent:
  • type-design-analyzer = subtask-time Checker variant when subtask kind = “introduce/refactor types”.
  • silent-failure-hunter = PR-time gate (Auditor / pre-merge), not per-subtask.
• Open Qs raised:
  • Q-PR-GATE-1: Where does PR-time gating live in the lifecycle? §3.5 Verify (per-subtask) is wrong scope. Maybe a new §3.7 PR phase (before §3.7 Close → renumber to §3.8 Close)?

Worker variants (bare mode reinterpretation)

FX-7 — [CLARIFICATION] workflow-worker-minimal concept misunderstood

“I think the workflow-worker-minimal concept has been misunderstood, which will have been my fault for not providing clear enough direction on this. Rather than there being a separate new agent type, my original question and intention was more to do with whether Anthropic had a mode for more streamlined agents - I actually found what I was trying to reference - ‘bare mode’ (https://code.claude.com/docs/en/headless#start-faster-with-bare-mode). For clarity, we don’t need the concept of a workflow-worker-minimal, the intention was just to ensure that we are managing subagent context windows effectively. It may be that ‘bare mode’ isn’t suitable, as it’s for headless, but the concept behind may still be something we can integrate into our workflow, and also potentially into the KH platform, whenever there is a requirement to utilise agents for platform-specific functionality.” Source: feedback:148-149

• Affects: .claude/agents/workflow-worker-minimal.md (likely DELETE); .claude/skills/session-driver-cmux/scripts/launch-worker.sh (--worker-mode minimal flag may be REMOVED or REPURPOSED); §8 Worker variants (collapses to a single Executor profile + a context-management discipline); ORIGINAL S48 WP3 (minimal worker tool-gate enforcement) is INVALIDATED — no separate agent to gate.
• Synthesised intent: the goal was always context-window economy, not a separate agent type. Investigate whether Anthropic “bare mode” (headless-only) has applicable patterns; if not, build context economy into the standard Executor’s dispatch brief (only inject skills + CLAUDE.md sections the subtask needs).
• Open Qs raised:
  • Q-BARE-1: Research “bare mode” applicability. Is it API-only / headless-only / CLI-only? Can sub-agents inherit a “bare-like” config?
  • Q-BARE-2: Alternative context-economy mechanisms: per-subtask CLAUDE.md trimming, skill auto-discovery filtering, explicit allowedTools overrides via dispatch brief, plugin-disable flags.
  • Q-BARE-3: KH platform-side use case (mentioned in passing — agents for platform-specific functionality). Out of workflow scope but worth noting.

session-driver-cmux upstream comparison

FX-8 — [DECISION] Compare local vs upstream driving-claude-code-sessions

“Now may also be a good time to compare the original Superpowers driving-claude-code-sessions skill (~./claude/plugins/cache/superpowers-marketplace/claude-session-driver/1.01/) with our session-driver-cmux skill, from a functionality perspective. It may be that ours deviates, based on the other feedback I’ve provided here, predominantly in terms of interacting with our other skills, and how our sessions will run. If we update our skill we should use /update-skill and also the /cmux skill, to ensure we follow best practice, and are using the latest cmux patterns.” Source: feedback:151-152

• Affects: .claude/skills/session-driver-cmux/SKILL.md; .claude/skills/session-driver-cmux/scripts/*; potentially upstream re-sync vs hard-fork decision (T4 output).
• Synthesised intent: drive the comparison as T4 of this session. Whatever divergence is found, any updates use /update-skill + /cmux to follow best practice.
• Open Qs raised: T4 output will surface any.

Skill + agent evaluation (workflow finalisation follow-up)

FX-9 — [DECISION] Evaluate ALL agent + skill files once workflow finalised

“We need to evaluate ALL agent and skill files once the workflow is finalised. We’ll then use /update-skill and/or /create-skill, and agent-development.” Source: feedback:154-155

• Affects: every file under .claude/skills/ and .claude/agents/.
• Synthesised intent: the workflow doc is upstream of skill+agent file authorship. Don’t edit files yet; queue this work for a post-ratification session.
• Open Qs raised: none session-blocking.

FX-10 — [DECISION] Workflow agents inject same skills via skills field

“For workflow agents who are using the same skills each time they are deployed, we need to ensure we use the skills field to inject skill content. Agents can of course still be deployed with instructions from the Orchestrator to also invoke subtask/task-specific skills.” Source: feedback:156-157

• Affects: all .claude/agents/workflow-*.md and .claude/agents/task-*.md (post-rename) files — add skills frontmatter listing baseline skills.
• Synthesised intent: baseline skills (per-role) injected via frontmatter; ad-hoc per-subtask skills passed via prompt body.
• Open Qs raised:
  • Q-SKILLS-FIELD-1: What’s the precise frontmatter shape? (T2 should pull the agent-development SKILL.md description.)
  • Q-SKILLS-FIELD-2: Does injection via skills field load the SKILL.md body into context at agent start? Or only register the skill as invokable?

---

Section impact summary

kh-sdlc-workflow.md section	# entries affecting	Severity
§2 Roles	4 (F2-1..F2-4)	HIGH — adds Planner role, renames Executor/Checker, clarifies finding-routing
§3 Lifecycle	6 (F3-1..F3-6)	CRITICAL — task-driven shift, worktree collapse, spec-authoring subtask sequence, per-subtask Checker
§4 Per-phase skill routing	10 (F4-1..F4-10)	CRITICAL — new Planner phase, skill mapping per phase per role
§5 Dispatch primitives	1 (F5-1)	DEFERRED — re-evaluate after §2/§3/§4 ratified
§6 Verification & curation gates	1 (FX-4 by impl.)	HIGH — 6-axis Checker → variants
§7 Where Taskmaster fits	0 (untouched by feedback)	LOW
§8 Worker variants	1 (FX-7)	HIGH — concept reframed; agent likely deleted
§10 Future roles & deferred work	2 (F4-9, F4-10, F-X6)	LOW — confirms deferrals

---

Open-question rollup (preview of T5)

The following Q-IDs from above are the explicit open questions surfacing from this synthesis. T5 consolidates them with cross-references and severity ratings:

Q-PLANNER-1, Q-PLANNER-2, Q-RENAME-1, Q-FINDINGS-1, Q-TERM-1, Q-TERM-2, Q-WORKTREES-1, Q-WORKTREES-2, Q-COUNTER-1, Q-MODE-1, Q-MODE-2, Q-SPEC-SUBTASKS-1, Q-SPEC-SUBTASKS-2, Q-SPEC-SUBTASKS-3, Q-DISPATCH-1, Q-CHECKER-1, Q-CHECKER-2, Q-CHECKER-3, Q-AGENT-CONFIG-1, Q-SUBTASK-KIND-1, Q-PLANNER-SKILLS-1, Q-PLANNER-SKILLS-2, Q-PLANNER-SKILLS-3, Q-EXEC-SKILLS-1, Q-EXEC-SKILLS-2, Q-EXEC-SKILLS-3, Q-EXEC-SKILLS-4, Q-EXEC-SKILLS-5, Q-DOMAIN-1, Q-CHECKER-OUT-1, Q-ORCH-SKILLS-1, Q-ORCH-SKILLS-2, Q-ORCH-SKILLS-3, Q-ENTRY-1, Q-ENTRY-2, Q-AMALGAMATE-1, Q-AMALGAMATE-2, Q-SELF-REVIEW-1, Q-CHECKER-ORDER-1, Q-CHECKER-ORDER-2, Q-CHECKER-ORDER-3, Q-PERF-SEC-1, Q-PERF-SEC-2, Q-PR-GATE-1, Q-BARE-1, Q-BARE-2, Q-BARE-3, Q-SKILLS-FIELD-1, Q-SKILLS-FIELD-2.

Total: ~48 open questions.

---

Contradictions (none surfaced)

No internal contradictions flagged in the synthesis. Feedback is largely additive + clarifying. The only tension is between F4-3 (Planner owns spec-driven-implementation in Spec-authoring phase) and F4-7 (Orchestrator owns spec-driven-implementation for “when new tasks are required”) — captured as Q-ORCH-SKILLS-3 for T2 to resolve empirically against the SKILL.md.

---

Next steps

1. T2 (skill empirical interrogation) — resolves Q-PLANNER-SKILLS-2, Q-ORCH-SKILLS-3, Q-EXEC-SKILLS-1, Q-EXEC-SKILLS-3, Q-EXEC-SKILLS-4 via SKILL.md reads.
2. T3 (Taskmaster schema empirical) — informs Q-SUBTASK-KIND-1, Q-TERM-1, Q-SPEC-SUBTASKS-1 via TM JSON shape.
3. T4 (session-driver divergence) — informs Q-AMALGAMATE-2.
4. T5 (open-question synthesis) — consolidates all Q-IDs above plus T2/T3/T4 outputs into a single ratification-ready doc.
5. Post-session: Liam ratifies (decision per Q-ID), kh-sdlc-workflow.md is re-authored, then FX-9 / FX-10 trigger the skill+agent file sweep.

---

End of structured feedback.