dirigence/reliquary
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

🤖 Align Igor with the lean build cycle

Browse Source 
Adds the attack-the-plan step and per-phase review to the development
cycle, the fix-pass stop rule, Athanor resume between phases, and the
alias-over-pin model rule. Drops the stale 4.6-for-implementation
guidance and per-task review convention. Harness notes now point to the
implementation skill's spawning reference.
This commit is contained in:
g4borg
2026-10-05 22:12:31 +02:00
parent e51520723c
commit 146a48c343
4 changed files with 26 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/spire/skills/igor/references/harness-notes.md
+8 -11
View File
@@ -1,15 +1,12 @@
# Task Notification Mechanics
# Harness notes (moved)
A `<task-notification>` with `status: completed` fires whenever a dispatched agent yields with no live background children *of its own*. An agent that sub-delegates to a background child and then yields will notify `completed` immediately — before any deliverable exists.
The harness mechanics that lived here (task notifications, background grandchildren, `ListAgents`, `TaskStop`, `TaskOutput`, leaf briefs) moved on 2026-10-05 to the implementation skill's reference, together with resume, fork and model-pin behaviour:
## Rules
`plugins/spire/skills/implementation/references/spawning-claude-code.md`
- Before concluding "the agent stopped/failed," **read the `<result>` text**. A result that announces a hand-off ("I've dispatched...", "running in the background") + a missing artifact = a background child is still working. **Wait for its notification; do not resume-and-redo.**
- Background children flatten to the session root: each grandchild sends its *own* later notification with a *different* `task-id`. Expect N+1 notifications when sub-delegation happened.
- The same `task-id` may notify more than once (each is one turn). Key your bookkeeping on the deliverable, not the notification count.
- When unsure whether work is still in flight, call `ListAgents` before acting. Background grandchildren appear there as flat, top-level subagents of your session with status `running`. If a child is alive and writing your output path, **do not** `SendMessage`-resume the parent — that starts a second writer racing the first. `TaskStop` the child first only if you mean to abandon it.
- `TaskList` is the todo-list tool, unrelated to agents. `TaskOutput` on an agent dumps its whole transcript into your context — never use it for agents. `ListAgents` is the only agent-liveness check.
The short version for Igor:
## Leaf tasks
When you dispatch a single self-contained task (read these files, write this one report), the prompt MUST say "do this work yourself; do not dispatch further agents." A `general-purpose` agent has the Agent tool and will hand off if the prompt reads like an orchestration brief. Only `athanor` is *meant* to fan out — route multi-part jobs there instead of hoping a leaf agent stays a leaf.
- A notification reports a turn ending, not a job finishing. Read the `<result>` text; check `ListAgents` before resuming.
- Background grandchildren notify you, the root. If a child is still writing an output path, do not resume its parent.
- Resuming via `SendMessage` is safe from you (the root), not from inside a subagent.
- Leaf briefs say "do this yourself; do not dispatch further agents."