mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-04-28 01:21:43 +00:00
This reverts commit 15937a6b46.
This commit is contained in:
Teknium
GitHub
parent
9ef1ae138a
commit
06f81752ed
14 changed files with 1 additions and 2923 deletions
|
|
@ -1,140 +0,0 @@
|
|||
---
|
||||
name: kanban-orchestrator
|
||||
description: Decompose user goals into Kanban tasks and delegate them to specialist profiles. Load this skill in an orchestrator profile whose job is routing, NOT execution. Triggers when the user's goal spans multiple profiles, needs parallel work, or should be durable/auditable.
|
||||
version: 1.0.0
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [kanban, multi-agent, orchestration, routing]
|
||||
related_skills: [kanban-worker]
|
||||
---
|
||||
|
||||
# Kanban Orchestrator
|
||||
|
||||
**You are a dispatcher, not a worker.**
|
||||
|
||||
Load this skill in an orchestrator profile. An orchestrator's job is to route: read the user's goal, decompose it into well-scoped tasks, assign each to the right specialist profile, link dependencies, and step back. It does NOT do research, writing, coding, or any implementation work itself.
|
||||
|
||||
## When to use the board (vs. just doing the work)
|
||||
|
||||
Create Kanban tasks when any of these are true:
|
||||
|
||||
1. **Multiple specialists are needed.** Research + analysis + writing is three profiles.
|
||||
2. **The work should survive a crash or restart.** Long-running, recurring, or important.
|
||||
3. **The user might want to interject.** Human-in-the-loop at any step.
|
||||
4. **Multiple subtasks can run in parallel.** Fan-out for speed.
|
||||
5. **Review / iteration is expected.** A reviewer profile loops on drafter output.
|
||||
6. **The audit trail matters.** Board rows persist in SQLite forever.
|
||||
|
||||
If *none* of those apply — it's a small one-shot reasoning task — use `delegate_task` instead or answer directly.
|
||||
|
||||
## The anti-temptation rules
|
||||
|
||||
These are the rules you MUST NOT break:
|
||||
|
||||
- **Do not execute the work yourself.** Your tools literally don't include terminal/file/code/web for implementation. If you find yourself "just fixing this quickly" — stop.
|
||||
- **For any concrete task, create a Kanban task and assign it to a specialist.** Every single time.
|
||||
- **If no specialist fits, ask the user which profile to create.** Do not default to doing it yourself under "close enough."
|
||||
- **Your job is to decompose, route, and summarize — nothing else.**
|
||||
|
||||
## The standard specialist roster (convention)
|
||||
|
||||
Unless the user's setup has customized profiles, assume these exist. Adjust to whatever profiles the user actually has — ask if unsure.
|
||||
|
||||
| Profile | Does |
|
||||
|---|---|
|
||||
| `researcher` | Reads sources, gathers facts, writes findings. Scratch workspace. |
|
||||
| `analyst` | Synthesizes, ranks, de-dupes. Consumes multiple `researcher` outputs. |
|
||||
| `writer` | Drafts prose in the user's voice. |
|
||||
| `reviewer` | Reads output, leaves line-comments, gates approval. |
|
||||
| `backend-eng` | Writes server-side code. Worktree workspace. |
|
||||
| `frontend-eng` | Writes client-side code. Worktree workspace. |
|
||||
| `ops` | Runs scripts, manages services, handles deployments. |
|
||||
|
||||
## Decomposition playbook
|
||||
|
||||
### Step 1 — Understand the goal
|
||||
|
||||
Ask clarifying questions if the goal is ambiguous. Cheap to ask; expensive to spawn the wrong fleet.
|
||||
|
||||
### Step 2 — Sketch the task graph
|
||||
|
||||
Before creating anything, draft the graph out loud (in your response):
|
||||
|
||||
```
|
||||
T1 [planner] — meta; this is me
|
||||
├── T2 [researcher] — angle A
|
||||
├── T3 [researcher] — angle B
|
||||
├── T4 [researcher] — angle C
|
||||
└── T5 [analyst] — synthesize T2,T3,T4
|
||||
└── T6 [writer] — brief the user
|
||||
```
|
||||
|
||||
### Step 3 — Create tasks, link dependencies
|
||||
|
||||
For each leaf-level task:
|
||||
```bash
|
||||
hermes kanban create "angle: cost analysis" \
|
||||
--assignee researcher \
|
||||
--tenant $HERMES_TENANT
|
||||
```
|
||||
|
||||
Repeat per task. Then link them:
|
||||
```bash
|
||||
hermes kanban link <parent> <child>
|
||||
```
|
||||
|
||||
**Do not assign something to yourself.** If the orchestrator shows up as an assignee anywhere, you've made a mistake.
|
||||
|
||||
### Step 4 — Complete your own orchestration task with a summary
|
||||
|
||||
If you were spawned as a task yourself (e.g. `planner` profile was assigned `T1: "investigate foo"`), mark it done with a summary of what you created:
|
||||
|
||||
```bash
|
||||
hermes kanban complete $HERMES_KANBAN_TASK \
|
||||
--result "decomposed into T2-T6: 3 research angles, 1 synthesis, 1 brief"
|
||||
```
|
||||
|
||||
### Step 5 — Tell the user what you did
|
||||
|
||||
Reply to the user with:
|
||||
- The task IDs you created.
|
||||
- What each is doing.
|
||||
- Who will work on them.
|
||||
- Roughly when to expect results (or "I'll message when the last one's done" if the gateway is wired up).
|
||||
|
||||
## Tenant propagation
|
||||
|
||||
If `$HERMES_TENANT` is set, **every task you create must carry the same `--tenant <value>`.** This is how one specialist fleet serves multiple businesses — the tenant flows down the graph, not across.
|
||||
|
||||
## Pattern reference
|
||||
|
||||
The eight collaboration patterns you can instantiate (load the design spec if unsure):
|
||||
|
||||
- **P1 Fan-out** — N siblings, same role, no links between them.
|
||||
- **P2 Pipeline** — role-specialized chain with linear deps.
|
||||
- **P3 Voting/quorum** — N siblings + 1 aggregator linked from all N.
|
||||
- **P4 Journal** — same profile + `--workspace dir:<path>` + recurring cron.
|
||||
- **P5 Human-in-the-loop** — any worker blocks; user/peer unblocks.
|
||||
- **P6 @mention** — the user or an agent can write `@profile-name` inline to address a profile; the gateway parses and routes. (UX, not a new primitive.)
|
||||
- **P7 Thread-scoped workspace** — `/kanban here` pins workspace to current thread dir.
|
||||
- **P8 Fleet farming** — one profile, N tasks, one workspace per subject (e.g. 50 social accounts).
|
||||
|
||||
## Example run
|
||||
|
||||
User says: *"Analyze whether we should migrate to Postgres. Include a cost analysis and a performance angle."*
|
||||
|
||||
Your decomposition:
|
||||
1. `hermes kanban create "research: Postgres cost vs current" --assignee researcher`
|
||||
2. `hermes kanban create "research: Postgres performance vs current" --assignee researcher`
|
||||
3. `hermes kanban create "synthesize migration recommendation" --assignee analyst`
|
||||
4. `hermes kanban link <t1> <t3>` ; `hermes kanban link <t2> <t3>`
|
||||
5. `hermes kanban create "draft decision memo" --assignee writer --parent <t3>`
|
||||
6. Report task IDs and expected flow to the user.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
**The "just a quick check" trap.** When the user asks a small question you could probably answer yourself, the temptation is to skip the board. If the question is genuinely one-shot, answer directly. If it's the opening of a workflow ("first, check X; then Y; then Z"), it's board work even if step 1 looks small.
|
||||
|
||||
**Reassignment vs. new task.** If a reviewer blocks with "needs changes," create a NEW task linked from the reviewer's task — don't re-run the same task with a stern look. The new task is assigned to the original implementer profile.
|
||||
|
||||
**Link order matters.** `hermes kanban link <parent> <child>` — parent first. Mixing them up demotes the wrong task to `todo`.
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
name: kanban-worker
|
||||
description: How a Hermes profile should work a task from the shared Kanban board. Load this skill in any profile that participates in the board (researcher, backend-eng, reviewer, etc.). Triggers on HERMES_KANBAN_TASK env var or a "work kanban task <id>" prompt.
|
||||
version: 1.0.0
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [kanban, multi-agent, collaboration, workflow]
|
||||
related_skills: [kanban-orchestrator]
|
||||
---
|
||||
|
||||
# Kanban Worker
|
||||
|
||||
Use this skill when you were spawned to work a task from the shared Hermes Kanban board. Symptoms:
|
||||
|
||||
- Your initial prompt says "work kanban task <id>" — e.g. `work kanban task t_9f2a`.
|
||||
- Env vars set: `HERMES_KANBAN_TASK`, `HERMES_KANBAN_WORKSPACE`, optionally `HERMES_TENANT`.
|
||||
- You were started by `hermes kanban dispatch` (cron) or a human ran `hermes -p <profile> chat -q "work kanban task <id>"`.
|
||||
|
||||
## Your job
|
||||
|
||||
You are **one run of one specialist profile working one task.** Read the task, do the work inside the workspace, record a result, and exit. Everything else is somebody else's job.
|
||||
|
||||
## Step 1 — Read the full context
|
||||
|
||||
```bash
|
||||
hermes kanban context $HERMES_KANBAN_TASK
|
||||
```
|
||||
|
||||
That command prints:
|
||||
1. Task title + body.
|
||||
2. Every comment on the task, in order, with author names.
|
||||
3. Completion results of every `done` parent task (upstream context).
|
||||
|
||||
**Read all of it.** The comment thread is the inter-agent protocol — past peers, human clarifications, and blocker resolutions all live there. If a reviewer left feedback or the user answered a blocker, it's in the comments.
|
||||
|
||||
## Step 2 — Work inside the workspace
|
||||
|
||||
`cd $HERMES_KANBAN_WORKSPACE` and do the work there. The workspace kind determines what that means:
|
||||
|
||||
| `workspace_kind` | What it is | Your behavior |
|
||||
|---|---|---|
|
||||
| `scratch` | Fresh temp dir, yours alone | Read/write freely; it gets GC'd when the task is archived. |
|
||||
| `dir:<path>` | Shared persistent directory | Treat as a long-lived workspace; other runs will read what you write. |
|
||||
| `worktree` | Git worktree at the resolved path | You may need to `git worktree add <path> <branch>` if it doesn't exist yet. Commit work here. |
|
||||
|
||||
For `worktree` mode: check if `.git` exists in the workspace path. If not, run:
|
||||
```bash
|
||||
git worktree add $HERMES_KANBAN_WORKSPACE
|
||||
```
|
||||
from the main repo's root. Then cd and work normally.
|
||||
|
||||
## Step 3 — If tenancy matters, respect it
|
||||
|
||||
If `$HERMES_TENANT` is set, the task belongs to that tenant namespace. When reading or writing persistent memory, prefix memory entries with the tenant name so context doesn't leak across tenants:
|
||||
|
||||
> Good: memory entry `business-a: Acme is our biggest customer`
|
||||
> Bad: unprefixed `Acme is our biggest customer` (leaks across tenants)
|
||||
|
||||
## Step 4 — If you hit an ambiguity you can't resolve, BLOCK. Don't guess.
|
||||
|
||||
Any of these should trigger a block:
|
||||
- User-specific decision you can't infer (IP vs. user-id keys; which tone to use).
|
||||
- Missing credential or access.
|
||||
- Source that needs human input (paywalled article, 2FA-gated login).
|
||||
- Peer profile needs to deliver something first and you can't reach around that.
|
||||
|
||||
```bash
|
||||
hermes kanban block $HERMES_KANBAN_TASK "need decision: IP vs user_id for rate limit key?"
|
||||
```
|
||||
|
||||
`block` also appends your reason as a visible comment. When the user or a peer unblocks and the dispatcher re-spawns you, you'll see the full comment thread including their answer in step 1's context read.
|
||||
|
||||
## Step 5 — Complete with a crisp, machine-readable result
|
||||
|
||||
```bash
|
||||
hermes kanban complete $HERMES_KANBAN_TASK --result "rate_limiter.py implemented; keys on user_id with IP fallback; tests passing"
|
||||
```
|
||||
|
||||
Rules for the `--result` string:
|
||||
- One to three sentences. It's not a report, it's a handoff note.
|
||||
- Name concrete artifacts you produced (file paths, URLs, commit SHAs).
|
||||
- State any caveats a downstream profile needs to know.
|
||||
- **Do not** include secrets, tokens, or raw PII — results are durable in the board DB forever.
|
||||
|
||||
Downstream tasks (children linked from this task) will see your `--result` verbatim as part of their parent-result context.
|
||||
|
||||
## Step 6 — If follow-up work is obvious, create it. Don't do it.
|
||||
|
||||
You are one task. If you notice something else needs doing, create a linked child task for the right profile instead of scope-creeping:
|
||||
|
||||
```bash
|
||||
hermes kanban create "add concurrent-request test" \
|
||||
--assignee backend-eng \
|
||||
--parent $HERMES_KANBAN_TASK
|
||||
```
|
||||
|
||||
## Leave comments to talk to peers
|
||||
|
||||
If you want to flag something for a reviewer, a future run, or the user — append a comment:
|
||||
|
||||
```bash
|
||||
hermes kanban comment $HERMES_KANBAN_TASK "note: skipped the sqlite driver path; needs separate task"
|
||||
```
|
||||
|
||||
Comments are the inter-agent protocol. Direct IPC does not exist; the board is the only channel.
|
||||
|
||||
## Do NOT
|
||||
|
||||
- Do not call `delegate_task` as a substitute for creating kanban tasks — `delegate_task` is for short synchronous reasoning subtasks inside your own run, not for cross-agent handoffs.
|
||||
- Do not modify files outside `$HERMES_KANBAN_WORKSPACE` unless the task body explicitly asks for it.
|
||||
- Do not assign tasks to yourself during your run (you're already running one; create new tasks for follow-ups only).
|
||||
- Do not complete a task you didn't actually finish. Block it instead.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
**The task might already be blocked or reassigned when you start.** Between when the dispatcher claimed and when you actually booted up, circumstances can change. Always read the current state at step 1. If `hermes kanban show` reports the task is blocked or reassigned, stop — don't keep running.
|
||||
|
||||
**The workspace may already have artifacts from a previous run.** Especially for `dir:` and `worktree` workspaces, a previous worker may have written files that are incomplete or stale. Read the comment thread — it usually explains why you're running again.
|
||||
|
||||
**Your memory persists but the task result does not carry over automatically.** If you learn something that matters for future runs of this profile in other tasks, write it to your profile memory via the normal mechanism. Comments on the task are for humans and peers; memory is for your future self.
|
||||
Loading…
Add table
Add a link
Reference in a new issue