| 🚧 Feature Request | 🐛 Bug Report |
Konductor is an open-source package of skills, standard operating procedures (SOPs) and workflows that automate the software development cycle.
Fuse-Konductor is an evolution of Konductor with two main differences:
- Fuse-Konductor turns Konductor's elements into a reusable library of modules, aimed at users who tweak the pre-packaged workflows and assemble their own.
- Fuse-Konductor replaces Konductor's suite of specialist agent personas and orchestration rules with a workflow engine operated by your harness's default agent.
Fuse-Konductor is a set of agent skills, plus a block of "always-on" instructions installed in your AGENTS.md (global or project-specific).
The workflow engine, fuse-flow, ships as TypeScript code that runs on bun and keeps its state in local Markdown files on your machine.
Your agent runs fuse-flow for you: it tells the agent which step comes next and which guide to follow.
By default, AI coding sessions improvise their process. They go from a prompt straight to code, and the requirements, design decisions and review criteria stay in the chat, where the next session cannot see them. Spec-driven development writes them down first and checks each one before the next step builds on it. Any workflow of this kind, whether it is Konductor's, Fuse-Konductor's or one you build yourself, gives you artifacts you can review and code you can check against what was agreed. A new session picks up where the last one stopped.
Konductor, the original project from AWS Solutions, gives the session such a written process: guides that say how to write requirements, design a system, review a design, split features, write specs, implement, review code, plan tests and document, each with its own checker, and workflows that produce these artifacts in order with human or agentic quality gates. Fuse-Konductor keeps these guides and turns them into modules, so you can adapt the pre-packaged workflows to the way your team works or assemble your own.
You get this by installing one package. No servers to run and no infrastructure to provision: the skills, guides and workflows are files that your existing coding agent reads directly.
Clone the fuse branch and start an agent session in the clone, with any supported harness:
git clone -b fuse https://github.com/aws-solutions/konductor.git fuse-konductor
cd fuse-konductor
claude # or codex, opencode, kiro-cli, ...Then say "Start the tutorial", or just say hello. Nothing is installed until you agree to it.
The tutorial explains what installing changes and how to undo it, checks which harnesses you have and which of your existing skills or instructions might conflict, and runs the installation with you.
It then coaches you hands-on: choosing a workflow for a task, working on one of your own projects, building a small greenfield demo project, or shaping a workflow to the way you work.
Once Fuse-Konductor is installed, you can return to the tutorial from any project with "Start the fuse tutorial" or the command /fuse-tutorial.
You need git and Bun; install.sh refuses to install without Bun.
From your clone, run install.sh, either into one project or for yourself across all projects:
# Either install into one project:
./install.sh --project /path/to/your/project
# Or install for yourself across all projects:
./install.sh --global ~/.claude/CLAUDE.mdINSTALL.md covers every supported harness, updating, uninstalling and custom forks.
Prompt your agent with "Use fuse-feature-development to build <...>", giving an initial description of your feature. This can be a few words or several paragraphs. The agent will take it from there, guiding you through the workflow and eliciting the details you haven't provided yet.
The workflow definitions in fuse/flow/workflows/ are the entry points for multi-phase work.
Pick one by naming it to your agent, or let the agent pick the best fit for the work at hand.
If none of the pre-packaged workflows matches your needs, start an agent session in your Fuse-Konductor clone and ask the agent to modify a workflow or build your own; it uses the fuse-flow-builder skill for this.
Optionally, you can use Komposer, a React app served from your machine, to visualize and modify workflows yourself. Its README explains how to build and start it.
| Workflow | Steps |
|---|---|
fuse/fuse-feature-development.yml |
One feature in an existing codebase: intake, design, implementation and code review. Agent review of the spec and of the whole change comes before the owner approves the spec and lands the work. Where the project shows signs of a pull request or similar review process, the owner can approve the work for it instead, and the workflow hands off to fuse-pull-request. |
fuse/fuse-pull-request.yml |
A change through the project's pull request or code review process, the way the project runs it: open the request, answer each round of reviewer feedback with fixes that pass an agent review first, and finish once the change is merged. It can also be started on its own for an existing change or pull request. Feature branches, a fixed branch per worktree and commits on the integration branch all work; the house rules decide. |
fuse/fuse-dependency-migration.yml |
A complex migration or refactoring that must leave the system behaving the same: catalogue the checks that prove it, add the missing ones, record a baseline, migrate in increments that keep the checks green and compare the result against the baseline in a report the owner reviews before landing. |
fuse/fuse-system-development.yml |
A new system, or a new module that needs its own architecture: intake, requirements, optional prototypes, a system design with a principal engineer review rehearsal by an agent, and a build order, with agent review before each owner decision. Each feature in the build order is then built with fuse-feature-development. |
fuse/fuse-rapid-prototyping.yml |
A new product idea explored before it is designed: a short interview on the owner's intent, then many small build-and-feedback iterations on a runnable prototype with no code review loop, ending in a product brief of what to build that fuse-system-development can take up. |
konductor/_k-full-sdlc.yml |
Konductor's full chain: elicitation, codebase analysis, requirements, design, design review, feature splitting, specs, implementation, code review, testing, documentation and a final summary, with owner gates between phases. |
konductor/_k-phase-chain.yml |
Konductor's lighter chain: requirements, design, feature splitting, specs, implementation, code review and QA, with no owner gates. |
konductor/*-sop.yml |
Konductor's SOPs as workflows, one per SOP: design doc creation and review, principal engineer design review, Kiro specs, planning and verification, codebase analysis, search and context gathering, code review, adversarial pull request review, pre-review critique, cleanup, test coverage review, end-to-end test generation and light UI testing. |
examples/custom-example-*.yml |
Examples of project-specific workflows at different sizes. |
examples/superpowers/superpowers.yml |
Spec-driven development after obra/superpowers: design, plan, branch and baseline, test-first implementation with a whole-branch review and the owner's choice of integration. Needs no Superpowers skills installed. |
For a single task, ask the session to use a skill directly; see Skills and guides.
You can edit these workflows or add your own. fuse-flow looks up a workflow by name in three places, and the first match wins: the project's .konductor/workflows/, then your own ~/.konductor/workflows/, then fuse/flow/workflows/ in your clone. Komposer reads and writes all three.
A workflow for one project goes in that project's .konductor/workflows/, where everyone who works on the project gets it. A workflow you want in all your projects goes in ~/.konductor/workflows/.
Inside your clone, personal workflows that you do not want to share can also go in fuse/flow/workflows/personal/, which is gitignored. To share workflows with a group but not with everybody, keep them in a separate repository and add a symlink to it named fuse/flow/workflows/team, which is gitignored too. fuse/flow/README.md gives the full lookup rules.
Skills are modular knowledge packages that a session loads automatically when the agent thinks that a task needs them.
Their structure is defined by the agent skills standard, which all mainstream coding agents support.
While the implementation of skill activation can differ from harness to harness,
keep in mind that activation is based on each skill's name and description frontmatter, and is generally left to the agent's judgment rather than enforced.
Instructions that Konductor wants to pass to an agent deterministically (e.g. how to write a system-design.md document) are therefore not built as skills, but as plain .md files that the workflow engine instructs the agent to use at a certain step in the workflow. We call these instruction files "guides" rather than skills. Guides have no frontmatter that gets loaded into every agent session, which keeps your agent's context clean.
The skills live in skills/, one folder per skill. The guides live in the artifact library, as fuse/flow/library/artifacts/<artifact>/guide.md, next to the artifact's template and review guide; fuse/flow/README.md describes the library and how a project or a user overrides an entry.
See CONTRIBUTING.md for how to report bugs, request features and submit pull requests. See CODE_OF_CONDUCT.md for community standards.
See SECURITY.md for how to report a security vulnerability.
Licensed under the Apache License, Version 2.0 — see LICENSE.txt. Third-party attribution is in NOTICE.txt.
Fuse-Konductor collects no data. The installer sends nothing over the network. fuse-flow downloads its two dependencies, zod and yaml, from the npm registry when they are missing from fuse/flow/node_modules in your clone, normally only the first time it runs; otherwise it sends nothing. Offline, that run fails and names the install command to run.
Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.