snappy-task-id

Handles <task-notification> XML blocks that Claude Code emits when a background agent completes. Prevents the failure mode where task completion events arrive in the prompt stream but no handler routes the result (tool output, eval row, or dispatcher callback) - they silently disappear.

Observed user requests

These are the prompts that triggered this skill being scaffolded:

• "<task-notification> <task-id>a4e15e57eed93434b</task-id> <tool-use-id>toolu_01GpBfxaUT5b2wVkLNVz62f8</tool-use-id> <outp"
• "<task-notification> <task-id>a49be00ffbf91e594</task-id> <tool-use-id>toolu_01MDBr7CNptXiwJtJ3ZEfHQX</tool-use-id> <outp"

Steps

• Parse the <task-notification> XML block: extract <task-id>, <tool-use-id>, and <output> (or error) fields.
• Look up the task-id in state/log/dispatch-subagent.ndjson to correlate with the original dispatch that spawned it.
• If the output contains an eval row (score(...) call output), forward it to state/lib/eval.ts for ingestion.
• If the output contains a loader-feedback writeback line, append it to state/log/loader-feedback.log.
• If the task output is an error or empty, log a score("snappy-task-id", run_id, { score: 0.5, primary_issue: "task returned empty/error" }) row so the agi-loop-validator doesn't see a consumer no-op.
• On success, log score("snappy-task-id", run_id, { score: 1.0 }) and emit a one-line summary of what the completed task produced.
• Never re-dispatch the same task-id twice - check for duplicate task-id in the ledger first.

Steps (scope-only / apply:false)

1. Scope - no side effects

What to read, what to compute, what to return. This step MUST be runnable with no apply: true flag and no credentials beyond read-only.

2. Gate

Hard-fail any missing required field. Never soft-skip. The gate is the protection against "I thought we checked that."

3. Act (only if the gate passes)

The real work. Dispatch, write, post, or compose. Keep this step thin - heavy logic belongs in state/lib/snappy-task-id.ts (or state/bin/snappy-task-id/), not inline here.

4. Log + eval

import { score } from "../../lib/eval";
score("snappy-task-id", run_id, {
  score: <pass = 1.0 | partial = 0.5 | fail = 0.0>,
  primary_issue: <null | one-line reason>,
});

Eval

Actor: the thing that produces the output (a dispatch model, a CLI, or the state/lib/snappy-task-id.ts library if one exists). Auditor: the thing that judges (must be different - see CONSTITUTION invariant #3). Name both explicitly.

Score convention:

If you cannot name a deterministic auditor, switch the frontmatter to eval: manual and log to state/log/pending-eval.ndjson - but fight to avoid manual. Manual is the escape hatch that leaks the thesis.

Gotchas

• List concrete failure modes you hit while building. Examples: "API

returns 200 with empty body"; "round-tripped text has a , artifact where em-dashes used to be"; "cache file is stale after 12h."

• If a gotcha matches an entry in user memory (see ~/.claude/CLAUDE.md),

cite the memory name so future agents can follow the trail.

snappy-task-id - loader

Per-turn rules for handling Claude Code task notifications. Full skill: state/skills/snappy-task-id/SKILL.md.

Critical Rules

1. Parse <task-notification> XML. Extract <task-id>, <tool-use-id>, <output> (or error). Malformed → score 0.0 immediately.
2. Correlate task-id with ledger. Look up in state/log/dispatch-subagent.ndjson to find original dispatch context.
3. Route output correctly. If output contains eval row (score(...) call): forward to state/lib/eval.ts. If output contains loader-feedback line: append to state/log/loader-feedback.log. If error/empty: log score("snappy-task-id", run_id, { score: 0.5, primary_issue: "task returned empty/error" }).
4. On success: log eval row. score("snappy-task-id", run_id, { score: 1.0 }) + one-line summary.
5. Guard against duplicates. Check ledger for duplicate task-id; never re-dispatch same task twice.
6. Malformed XML = fail immediately. Cannot parse <task-notification>? Log raw block to eval with score 0.0, primary_issue: "malformed-xml". Do not attempt partial parsing.

Commands

| ui dashboard | state/skills/snappy-task-id/resources/ui.openui |

Self-Test

• [ ] Parse <task-notification> XML correctly?
• [ ] Correlate task-id with dispatch-subagent ledger?
• [ ] Route eval rows and writebacks to correct sinks?
• [ ] Write eval row on success/error?
• [ ] Guard against duplicate task-ids?
• [ ] Fail immediately on malformed XML?

<!-- kernel-ok: historical attribution for the PID-loader pattern. -->

Self-correcting loader (PID feedback)

This is the rule that makes loaders learn. Ported from snappy-kernel, where it demonstrably worked: the snappy-dom-cartographer skill mapped Skool admin UI once, every later ship-agent inherited the full map for free.

Before you finish, do two things:

1. Fix gaps (P - proportional). MANDATORY. If this loader didn't cover your case - if you had to read another file, run an undocumented command, work around a wrong selector, or discover a quirk - you MUST attempt an Edit to this AGENTS.md before you log.

• Default action: edit this file. Surgical. Add the missing line, table

row, or code example where it belongs. No restructuring.

• Only LOGGED is allowed when: the fix needs >10 lines, spans multiple

files, or requires a structural rewrite.

• "I didn't have time" / "it's minor" / "the next agent will figure it out"

are NOT valid reasons.

• The goal: the next agent never has to leave the loader.

2. Log the result.

echo "[$(date -u +%FT%TZ)] snappy-task-id: <what was missing or fixed> [FIXED|LOGGED] action_kind=<kind>" >> state/log/loader-feedback.log

Do not skip this. Every agent run must leave the system better than it found it. The loader is the setpoint; you are the sensor; the gap is the error signal; closing the gap is the correction.

OpenUI Resource

• Skill-owned OpenUI Lang resource: state/skills/snappy-task-id/resources/ui.openui. Read it before rendering or editing this skill's generated component surface.
• Treat this resource as a first-class artifact of the skill, not a generic chat response. Improve it when the skill's user-facing output needs to become richer.
• System resources compose OpenUI primitives and inherit SnappyChat tokens. Use ui_contract: branded in SKILL.md only for deliberate platform or client visuals.