Kanban tutorial
Kanban tutorial
Start with meaning, then move to detail.
This lesson explains Kanban tutorial as part of getting started with Hermes correctly. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect Setup, The board at a glance, Flat view, then verify failure modes and version compatibility.
No prior experience is required; follow the steps on a safe test setup first.
A clear outcome before you read.
- Understand Kanban tutorial without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
What does the source say, and in what order?
- 01Setup
Start here to understand the core idea or structure.
- 02The board at a glance
Read this after the foundation, then connect it to the previous step.
- 03Flat view
Read this after the foundation, then connect it to the previous step.
- 04Story 1 — Solo dev shipping a feature
Read this after the foundation, then connect it to the previous step.
- 05Story 2 — Fleet farming
Read this after the foundation, then connect it to the previous step.
- 06Story 3 — Role pipeline with retry
Read this after the foundation, then connect it to the previous step.
- 07Story 4 — Circuit breaker and crash recovery
Read this after the foundation, then connect it to the previous step.
- 08Circuit breaker — permanent-looking failure
Read this after the foundation, then connect it to the previous step.
- 09Crash recovery — worker dies mid-flight
Read this after the foundation, then connect it to the previous step.
- 10Structured handoff — why summary and metadata matter
Finish here to verify the result and special cases.
Copy only after you understand the effect.
hermes kanban init # optional; first `hermes kanban <anything>` auto-inits
hermes dashboard # opens http://127.0.0.1:9119 in your browser
# click Kanban in the left navSCHEMA=$(hermes kanban create "Design auth schema" \
--assignee backend-dev --tenant auth-project --priority 2 \
--body "Design the user/session/token schema for the auth module." \
--json | jq -r .id)
API=$(hermes kanban create "Implement auth API endpoints" \
--assignee backend-dev --tenant auth-project --priority 2 \
--parent $SCHEMA \
--body "POST /register, POST /login, POST /refresh, POST /logout." \
--json | jq -r .id)
hermes kanban create "Write auth integration tests" \
--assignee qa-dev --tenant auth-project --priority 2 \
--parent $API \
--b`kanban_show` defaults `task_id` to `$HERMES_KANBAN_TASK`, so the worker doesn't need to know its own id. `kanban_complete` writes the summary + metadata onto the current `task_runs` row, closes that run, and transitions the task to `done` — all in one atomic hop through `kanban_db`.
When `SCHEMA` hits `done`, the dependency engine promotes `API` to `ready` automatically. The API worker, when it picks up, will call `kanban_show()` and see `SCHEMA`'s summary and metadata attached to the parent handoff — so it knows the schema decisions without re-reading a long design doc.
Click the completedRead the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.