Daidala is a Hermes-native AI workshop that moves skill-backed work through interchangeable workflow packs and one explicit human approval gate—without introducing a second orchestration server.
Your daily driver for crafted, human-approved work.
Daidala (pronounced DYE-dah-lah) is an Ancient Greek name for skillfully crafted or fashioned works. The word belongs to the tradition of Daedalus, the legendary maker, and the wondrous craft associated with Hephaestus.
The name fits a Hermes-native AI workshop built around disciplined craft rather than unconstrained automation. Daidala brings specialist agents and skills into an ordered process: a goal is defined, planned, approved by a human, implemented in isolation, verified, reviewed, and delivered with evidence. Skills provide the craft, workflow constraints shape the work, and Hermes supplies the agent runtime.
Plain Hermes Kanban already owns cards, dependencies, profiles, retries, comments, and worker runs. Daidala adds pack-defined workflow policy around that runtime:
- Workflow packs map exact skills onto
define,plan,implement,verify,review, anddeliver. - Provenance pins external skill sources, revisions, names, and complete directory digests.
- Approval integrity binds human authorization to the SHA-256 digest of one complete plan revision.
- Git safety rejects a dirty target and performs implementation in one Daidala-owned detached worktree.
- Evidence retains definitions, plans, immutable diffs, changed paths, verification output, and review artifacts.
- Conservative delivery reports a reviewed diff with
committed: falseandpushed: false. - Pack neutrality keeps pack-specific skill mappings in YAML rather than branching the Python engine.
Daidala loads in-process as a Hermes plugin. It creates linked cards on an existing Hermes Kanban board, assigns every executable stage to an explicit Hermes profile, and lets the gateway's existing Kanban dispatcher run ready cards. Daidala's SQLite data is only a policy and artifact ledger; Hermes Kanban remains lifecycle truth.
Daidala adds no MCP server, HTTP daemon, dashboard server, scheduler, model
client, or nested hermes chat process. Its optional /daidala extension runs
inside the existing Hermes dashboard; normal Kanban CLI, /kanban, and gateway
operations remain available for progress and recovery.
flowchart LR
S["explicit Daidala start"] --> D["define"]
D --> P["plan"]
P --> G["approval card<br>blocked"]
G -->|"human approves exact plan digest"| I["implement"]
I --> V["verify"]
V --> R["review"]
R --> DL["deliver<br>no commit or push"]
H["Hermes Kanban<br>status, dispatch, retries"] --> D
H --> P
H --> I
H --> V
H --> R
H --> DL
W["Daidala policy ledger<br>digests and evidence"] -.-> G
Prerequisites:
- Hermes Agent v0.18.2, the only verified host version;
- Daidala installed and enabled in the profile that owns the workflow;
- an existing named Kanban board;
- the selected pack's exact skills installed in every assigned worker profile;
- the Hermes gateway running so its Kanban dispatcher can claim ready cards;
- a clean local Git target repository.
hermes plugins install forgegod/daidala --enable
hermes daidala doctor --pack aidlc
hermes kanban boards create project-board --name "Project board"
hermes gateway runRun the gateway in a separate terminal on WSL. Then start explicitly with one profile for every stage:
hermes daidala start /absolute/path/to/repo "Implement the requested change" \
--board project-board \
--default-profile default \
--pack aidlc \
--workflow-id first-workflowThe command validates policy inputs and creates define → plan; it does not
start another scheduler. Observe the board with hermes kanban --board project-board watch, the dashboard, or /kanban. After the plan card records a
plan artifact, approve that exact digest:
hermes daidala approve first-workflow <64-character-plan-digest>A generic hermes kanban unblock is not approval. Successful Daidala approval
completes the gate and creates implement → verify → review → deliver in one
persistent worktree. Use hermes daidala status first-workflow for combined
policy facts and live card status; use normal Kanban comments, reassignment, and
unblock for worker recovery.
See Getting started for the complete walkthrough, including pack setup, optional stage-specific profiles, recovery, and delivery.
A workflow starts only through an explicit Daidala start action: the verified
operator CLI above or an agent calling daidala_start. Cron is not required
and is not part of Daidala's runtime. It may send a future prompt that asks an
agent to perform the same explicit start, but Daidala owns no cron job, daemon,
or polling loop.
The global Hermes kanban.orchestrator_profile limitation tracked in
NousResearch/hermes-agent#34977
does not route Daidala stages. Daidala selects the board explicitly, assigns
every executable card to an explicit profile, and creates the graph directly
instead of asking Hermes goal decomposition to choose an orchestrator profile.
- Supported host: Hermes Agent v0.18.2 on one local/single-host installation.
- Supported entry points: native
hermes daidala, standalone diagnostics, agent-facing plugin tools, and the optional Hermes dashboard extension. - Packs: Addyosmani
agent-skillsand the bundled AI-DLC v1.0.1 adapter. - Unattended runtime: the existing Hermes gateway Kanban dispatcher only.
- Delivery never commits, pushes, deploys, or publishes without separate authorization.
- Daidala does not copy secrets into artifacts and does not read or write the Hermes Kanban database.
Start with the documentation index. Runtime claims and
compatibility evidence are recorded in the
Hermes integration guide; development commands
and repository verification live in AGENTS.md.
Release maintainers run both compatibility probes in scripts/; the release
workflow enforces them for version tags and explicit manual dispatches.
python -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/lefthook install
.venv/bin/pytest
.venv/bin/ruff check .MIT