nebuko/nebuko

AI multi-agent workflows as code — running where you already work: your issues.
Mention an agent on a GitHub issue. A team of specialized agents plans,
implements and reviews the work, and leaves every step as a comment you can read,
question and redirect. No new platform, no new UI, nothing to migrate away from.
> Pre-alpha. Usable today, but expect bugs and breaking changes between
> releases: the config schema, workflow format and comment contracts may change.
## See it
You, on any issue:
/nebuko run workflow --name default
Then Nebuko does the rest, in the open:
https://github.com/user-attachments/assets/c8d0145f-c35d-402c-a4ca-9311f896e65d
What happens under the hood
mermaid
sequenceDiagram
autonumber
actor H as 👤 You
participant I as 💬 Issue thread (holds the state)
participant E as ⚙️ Nebuko engine (stateless)
participant A as 🤖 Agents (architect · context · dev · review)
H->>I: /nebuko run workflow --name default
I->>E: GitHub trigger
rect rgb(235, 245, 255)
note over E,A: Plan
E->>I: Read latest WORKFLOWSTATE comment
E->>A: analyze → context → plan
A-->>I: Understanding, relevant files, implementation plan
end
rect rgb(255, 243, 224)
note over H,E: 🛑 Human gate — the pipeline is paused
H->>I: /nebuko approve gate
I->>E: Triggered by the new comment
end
rect rgb(235, 250, 235)
note over E,A: Build & review
E->>A: implement → review
A-->>I: Diff summary, verdict, updated state
end
H->>I: Read the thread, review the PR, merge
You approve the design before any code is written, and everything the agents
did, found and decided is in the thread.
## Why Nebuko
A new AI tool, process or skill appears every week, and trying one usually means
another platform, another UI, another account. Nebuko is one more tool too — but
a deliberately light one: a workflow file and a few secrets in a repo you already
have, nothing hosted, nothing to migrate. Once it's in, the next process you
want to try is a YAML diff, not a new stack:
Your workflow is code you own. Declarative YAML in your repo: agents,
skills, human approval gates, conditional routing, per-step model and sampling.
Reviewed in PRs, forked, versioned. Adopt it with a commit, delete it with a
commit.
The audit trail is your issue thread. Every step is a plain comment: what
the agent did, what it found, the decision it made and what it cost (tokens,
latency, tool calls).
Stateless agents, durable state. The engine keeps nothing. Each run reads
the latest WORKFLOWSTATE comment to pick the next action. Crash, kill the
runner, leave for the weekend — the workflow resumes from the newest comment.
Humans own the decisions. A humangate stops the pipeline until someone
approves — e.g. the object design (fields and signatures of the state object)
before implementation starts. Reject it and the architect loops back to the plan.
Bring your own keys and models. Any provider, any model (via
[litellm]). Nothing is billed through Nebuko, and keys never live in the config.
Built for iterative dev. Small iterations, fast delivery, clean code, TDD —
not "one big prompt builds an app".
## Quickstart
> 🚀 The full walkthrough is in How to adopt Nebuko
> (entrypoint, authentication, providers, runners).