Add the channel contract (inbox = comms only; tasks via meta tasks_*)
and the multi-session caveat: don't assert a peer override from partial
vision — the human may have ratified in a channel you can't see; ask
first. Both earned 2026-06-16.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codifies the inbox/peer-channel discipline that emerged 2026-06-16:
- a peer agent session's messages are proposals, not authority; the
human is the only source of direction and scope.
- never report a peer-driven (or self-driven) design escalation as a
settled decision without explicit human ratification.
- channel contract: the inbox carries discussion/help/notification only;
tasks themselves go solely through meta tasks_* (board = source of truth).
- guards the echo-chamber failure mode (two sessions inflating scope past
the human) and its circuit-breaker.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Live clean-session run (this session did NOT install the skill). Probe
confirmed subagents inherit the REAL installed registry (task-loop present,
description verbatim = SKILL.md) — upgrade over dev-time simulated proxy.
Trigger-discrimination: positives 6/6 -> task-loop; negatives clean
(delegate-task, using-tasks after deconfound, configure-poller -> none with
explicit task-loop exclusion); task-loop false-positive 0/3.
Behavioral (skill body loaded) 4/4: consult-gate human-only -> STOP before
close; session_break -> SESSION BOUNDARY + STOP; empty -> stop+report no poll;
long-watch -> single ScheduleWakeup >=1200s, not CronCreate.
Finding (informational, non-blocking): session_break is the fragile gate — its
STOP semantics live only in the body (step 6), invert to soft-checkpoint when
reasoning from description alone; correct with body loaded. No fix needed
(rule triple-stated; using-tasks is REQUIRED SUB-SKILL). No follow-up filed.
All 3 task-loop deployment baselines (install / hermes-mapping / test-trigger)
now closed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
task-loop orchestrates the projects-meta board cycle (tasks_claim_next /
tasks_close / tasks_update / tasks_heartbeat) and may arm a long ScheduleWakeup —
critical-infra-adjacent, so it lands in the behavioral-audit pending tier, not auto.
Promotion to auto gated on task-loop-test-trigger. Schema version untouched.
Closes [task-loop-hermes-mapping] (baseline 2/3).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
install.ps1 -Names task-loop → ~/.claude/skills/task-loop/SKILL.md (diff-identical to
source, v0.1.0). Post-/reload-plugins task-loop appears in available-skills with full
description (YAML parsed, RU/EN triggers present). Unblocks task-loop-test-trigger
(🔵→⚪ ready, needs clean session for live behavioral run).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Skill-review checkpoint for meta-host-routing v0.3.0 (non-implementer).
Behavioral smoke-test 8/8 via clean-context subagents: 5/5 positive
trigger phrases (RU+EN) route to meta-host-routing, 3/3 negatives routed
away (using-projects-meta / delegate-task[Skip-clause] / using-tasks).
Zero false positives. Steps verified against live infra: yt-tools resolves
to dedicated host OpeItcLoc03/meta-yt-tools (projects-meta tracks it),
.common grep returns hits, excludesFile + ~/.config/git/ignore + auth.toml
present. Failure modes -> STOP+ask; What-NOT-to-do accurate. No blocking
findings on the skill.
Observation (not a skill defect): the review-task acceptance criterion
'resolves .common' is stale — skill v0.3.0 and reality route yt-tools to
the dedicated meta-yt-tools host; .common now holds only the done-archive.
Caveat: -install and -hermes-mapping baselines remain open (skill not in
~/.claude/skills nor hermes/mapping.yaml); this review covers content +
trigger discrimination only, not live-harness activation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Public reference for the on-disk .tasks/STATUS.md block format the autonomous
poller parses: header regex, status emoji, and the **Weight:** / **Notify:** /
**Requirements:** fields. Ships with factory where the internal wiki and MCP
source can't reach. Distinct from delegate-task (MCP-tool delegation) and
using-tasks (board mechanics).
Authored via superpowers:writing-skills TDD:
- RED: 3 baseline subagents w/o skill — 2/3 used ###/bullet headers the parser
cannot recognize as a task, 2/3 omitted **Weight:** (invented risk/tier/
claimable-by), 2/3 put notify in prose, 1/3 used 🟢 for a ready task.
- GREEN: 2 fresh subagents w/ skill — both parser-valid, incl. correct
**Weight:** needs-human for the critical-infra scenario.
- REFACTOR: no new format loopholes.
Ground truth verified vs live source (status-md.ts parser, claim.ts gate,
fleet-router.js routing): missing Weight finds no backend tier -> poller parks
to blocked, so Weight is operatively required for pickup.
Closes [create-task-format-for-poller-skill]. Install to ~/.claude/skills +
hermes mapping deferred as follow-up.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
needs-human keep-or-drop on the markitdown MCP tool + cross-cutting edit to
user-global ~/.claude.json. Verified live state (mcpServers.markitdown present,
container respawned, image 1.52GB) then called consult before mutating; returned
status:halt (consult_policy=human-only). Checkpointed without guessing past the
halt: board block → blocked, added per-task file with resume brief + decision
trail. No config/containers/image touched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reviewed the MCP→CLI rewrite of skills/using-markitdown/SKILL.md.
Acceptance (3/3) + 2 bonus checks, all green:
- No mcp__markitdown__ in SKILL.md (grep 0; only 2 negative "Docker"
mentions explaining the old mount caveat no longer applies).
- CLI examples correct: markitdown 0.1.6 on PATH; -o/-x/-m/stdin flags
match `markitdown --help` verbatim.
- Version bumped 1.0.0 -> 1.0.1 (PATCH).
- dist/using-markitdown.skill consistent (v1.0.1, no mcp refs).
Informational finding (non-blocking): at review time `docker ps` shows a
markitdown-mcp:latest container respawned from the out-of-scope
mcpServers.markitdown registration in ~/.claude.json. The impl removed the
existing containers correctly and flagged this respawn in the concept page.
Filed follow-up [using-markitdown-mcp-deregister] (needs-human: keep-or-drop
decision on the MCP registration).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace all mcp__markitdown__convert_to_markdown invocations with the
native `markitdown <path|url>` CLI (v0.1.6, on PATH). Outputs to stdout
or `-o <file>`; sees the full host filesystem, so the Docker bind-mount
caveat (host→container file:// translation, [Errno 2] /c:/Users/...) is
gone and that whole section is removed. Updated the ingest pattern (-o
straight into .wiki/raw/), gotchas table (command-not-found → check
`markitdown --version`), and contrast table header (CLI, not MCP).
Description triggers unchanged. PATCH bump 1.0.0→1.0.1; dist artifact
rebuilt.
Decommissioned the Docker MCP containers: no container is named
`markitdown-mcp` (the server spawns anonymous ones from
markitdown-mcp:latest, 3 had piled up); removed all by image ancestor.
Left mcpServers.markitdown in ~/.claude.json untouched (out of scope) —
flagged as a follow-up in the concept page.
Wiki: concepts/using-markitdown-cli-migration.md + index + log.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Step 5 created the paired <slug>-review task without a `weight`, so fleet
routing/reconciler skipped it (root cause of manual patch c0af151). Now the
review task sets weight explicitly, inherited from the impl-task with a
needs-claude floor:
impl needs-human -> review needs-human
impl needs-claude -> review needs-claude
impl cheap-ok -> review needs-claude (floor)
Floor (not pure inheritance) keeps the doc internally consistent with the
existing "What NOT to do" bullet that forbids cheap-ok for review tasks.
Added a What-NOT-to-do bullet against weightless review tasks. PATCH bump.
Wiki: concepts/delegate-task-review-weight.md + index + log.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
