Workflow Orchestration Assessment Feedback

Superseded by: docs/plans/phase-0-investigation/kh-sdlc-workflow.md (S47, 2026-05-15). Liam’s S45 feedback on the assessment. Decisions reached here are reflected in the canonical SDLC workflow doc; read that first.

Workflow Assessment Feedback

Workflow Roles

• We can check when we initiate a project in Taskmaster, but previously I’ve used it where it’s both come with three out of the box agent files and separately in an updated version where these weren’t included.
  • The previous agent files are available here, and we should review and determine whether we should look to adapt and utilise the executor and checker roles as a baseline structure: /Users/liamj/Documents/development/propel-pathways-39761/.claude/agents
• Whether we adopt these or not, we should also determine whether we look to utilise the context-engineering-collection and prompt-engineering-patterns + Agent Development for our Workflow Auditor, Workflow Evaluator agent roles, and/or our session-driver-cmux workflow orchestrator.
• Also, see OQ Responses section at the bottom of this document for more info on session-driver-cmux, as we DO have the full config available for the original session-driver-tmux, from Superpowers plugin.

Meta-skill and Additional Skills

• Is the suggestion to use frontend-ui-engineering, context-engineering, debugging-and-error-recovery, shipping-and-launch, browser-testing-with-devtools, security-and-hardening, and performance-optimization with the current suggested skills for each SDLC phase or in place of them? The assessment notes “They are explicit prereqs in using-agent-skills lifecycle sequence — omitting any of them creates a gap in the workflow”, but we have non-using-agent-skills workflow skills listed as part of our intended workflow, so we need to determine our exact approach here, to prevent duplication or ambiguity, ensuring the orchestrator has clear structure and direction. I’ve provided more related information on this below, in the SDLC Skill Workflow section.
  • Once we’ve established our workflow, we’ll be able to determine how using-agent-skills is utilised e.g., is it the structure for our orchestrator’s skill-router meta-skill, but adapted to include our workflow skills, or will we need an entirely new skill-router meta-skill.
  • We will also need to include taskmaster-related context in the meta-skill, unless this gets covered by the main session-driver-cmux skill. Until we migrate to Linear, taskmaster will be used for task-management/tracking. See below section Taskmaster Next Steps for more information on how it may be utilised/integrated, as this will also have implications on our workflow approach.

Was GitBook - Now Astro/Starlight

• Having reviewed the assessment and then doing some investigation into Warp’s approach, I actually think it would make more sense if we pivot to using Astro and Starlight rather than GitBook. This will be much better suited to our needs (Open source Markdown storage and sync, rather than GitBook’s DB approach and related costs), and I imagine probably means less changes in relation to the documentation skills which we should adopt from Warp.

• Does this still use .github/actions/docubot/action.yml + prompt.txt (envsubst-templated) + .github/workflows/*.yml (workflow_dispatch / on-comment trigger), or have Warp adapted their approach since moving from GitBook?

• Would our update-docs skill not become obsolete once we pivot to Astra/Starlight and our workflow is in place? Why wouldn’t we use warp’s approach here? - review-docs-pr, update-changelog, sync-error-docs, missing_docs, check_for_broken_links, docs-seo-audit ALL look very valuable, and we should adopt - across the many projects that you and I have worked on, documentation drift and identifying where valuable project context lives both from a product functionality perspective and from a codebase and database perspective, and so migrating to using Astro/Starlight will hopefully look to resolve many of the issues which we’ve previously faced.

• As part of the upcoming implementation work on the main track, it’s been identified that something we have been missing for the KH product, sorry, platform is an ontology pipeline. The main track has now created the underlying layer structure for the ontology pipeline and began documenting this. And in addition, has created a technical spec for setting up the pipeline, utilising CocoIndex and then an auto sync workflow to what will now be Astro Starlight. This is an implementation task that you and I will pick up on the production readiness track as part of the workflow setup, as it will also help us gain an understanding of what’s required for utilising Astro and Starlight across the wider project.

SDLC Skill Workflow

• Aside from the below questions, the wider work here is to be able to pull everything together to establish what our development workflow will be. As noted in the Meta-skill and Additional Skills section, there are some skills which haven’t yet been included (but the skills are accessible if we decide to integrate them).
  • In terms of whether we retain spec-driven-development, alongside the 4 other spec-related skills, we need to understand if/how/when it would become part of the dev workflow. The assessment notes “Orchestrator skill: decides if specs are warranted, chains write-product → write-tech → implement-specs.” - is it then that the orchestrator invokes spec-driven-development, which then chains to spec-driven-implementation, and so on? Is there any crossover, or unneccessary abstraction?
  • Should write-product-spec and write-tech-spec be listed under Planning phase if planning-and-task-breakdown decomposes them? Similarly, if spec-driven-development is retained, should it, and spec-driven-implementation also therefore be part of the Planning phase?
  • How would the individual context-engineering skill be integrated into the workflow? Is it just for the orchestrator, if tasks and sub-tasks are already sized correctly for a subagent to execute?
  • Do incremental-implementation and test-driven-development (using-agent-skills provenance) work with write-product-spec and write-tech-spec (Warp-ported)?
    • Also, how does incremental-implementation fit within the workflow, taking account of the above points related to spec-related skills - is there crossover between incremental-implementation and implement-specs?
  • Where does test-driven-development fit in the workflow, considering both (i) the point at which specs/plans are created, and (ii) how we’ll be utilising taskmaster for task-management/tracking e.g., in taskmaster top-level tasks are normall split into sub-tasks, via a prompt - we’ll need to ensure that when tasks are split, they adopt TDD, for tasks which require it.
  • We should rewrite fix-errors to be KH-generic.
  • For warp-integration-test - ignoring that the current skill is Warp-specific, does the skill cover anything which we don’t already have covered in our intended workflow?
  • Agreed, agent-browser and chrome-cdp over webapp-testing.
  • Agreed on retaining pr-review-toolkit (and utilising /ultrareview), and commit-commands, and dropping create-pr and review-pr - we’ll need to ensure other skill files reflect this if create-pr and review-pr are mentioned in them.
    • What about git-workflow-and-versioning and resolve-merge-conflicts?
    • Also, both github-actions-templates and ci-cd-and-automation exist under ~.agents/skills/

OQ Responses

• 1. The roles can be deferred after MVP, but keep in mind that may only be a couple of days away at the most.
• 2. We’ll need to understand what approach we take here, given the pivot to Astro/Starlight, which we’ll cover along with item 3, as part of the Astro/Starlight investigation and setup.
• 3. Provisionally docs/specs/ but TBD per item 2.
• 4. The config that our session-driver-cmux is based on can be found here: /Users/liamj/.claude/plugins/cache/superpowers-marketplace/claude-session-driver (skill/hooks/tests) - we should review, adapt and adopt.
• 5. If cocoindex & GitNexus are confirmed as the approach we should adopt, I’ll remove Graphify, to prevent confusion and de-clutter.
• 6. Agreed, plus potentially others, dependent on findings from the investigations that will spawn from this feedback document.
• 7. Can cocoindex-code (+cocoindex + supabase) be used to create our own AST data-flow tooling? Or is ts-morph + LSP the only route here (discounting sourcegraph)?

Additional Feedback/Questions

• Where our workflow requires any new skills or updates to skills, we should ensure we use create-skill and update-skill.

• In terms of the caveman skill (and plugin) - cocoindex-code suggests 60-70% token savings - is caveman then still required on top of this?

• The assessment notes that gitnexus is an MCP server, not a skill, but the skill files are available at .claude/skills/gitnexus/ (on main repo)

• Plannotator will predominantly be used by me, when interacting and iterating on documentation with the orchestrator.

• I’ll remove the GitBook skill, and identify if there are equivalent skills for Astro/Starlight.

• I’ve updated the original KH workflow orchestration file with any of the deduplication actions that have already been agreed based on the above feedback and assessment findings.

Next Steps

• Along with reviewing the above feedback, OQ responses, and additional feedback/question items, what should our next steps be from here? Should we covering the remaining investigation and research items in the next session, and then look to expand and update the suggested sequence at the bottom of the assessment file, but perhaps to a separate new file?

• Our the goal is, of course, to be able to have our workflow set up and then be able to utilise it for the main repo work which we’ll be looking to kick off very soon as they’re currently at the stage of preparing to split out the intended architecture for the platform into separate specific architecture documents, integrating all of the feedback and findings from the main investigation work, and then looking to proceed with remaining planning design and then on to implementation.

• One key area that we haven’t yet covered is how we will look to integrate taskmaster - it may make sense to have a dedicated work package in the next session for reviewing the Taskmaster repo and then identifying what will be required for us to be able to utilise the setup, integrating our workflow orchestration. For example, Taskmaster recommends having a PRD which then gets split out, analysed and converted to tasks and subtasks. We need to determine how we will integrate that with KH. So for example, we’ll have a main project plan for the upcoming work. Is it that that gets converted to a PRD and then extracted? Or would another approach be to have a project per feature or functionality that we’re going to be working on, with each having its own PRD for Taskmaster. Taskmaster also has an automated TDD approach and likely other functionality that may be beneficial, and we should investigate what they have currently and how this will work for us.