メニュー
Re-anchor on the durable record (current-track, live owner thread, pending-questions, relay, build_log) before acting on anything that depends on earlier context. Read, do not recall.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/sonichi/sutando --skill context-reconstructコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Infer stable semantic workstreams for ungrouped Sutando task history and apply the validated assignments to the durable workstream sidecar. Use for internal task-workstream-grouping maintenance tasks, initial history backfills, and later batches of tasks that need cross-channel or cross-device workstream organization.
Start Sutando's autonomous proactive loop. Monitors tasks, runs health checks, and builds missing capabilities on a recurring schedule.
Make conversational phone calls and join Zoom meetings via Twilio + Gemini. Multi-turn AI conversations on the phone on behalf of the user.
SKILL.md を表示中
| name | context-reconstruct |
| description | Re-anchor on the durable record (current-track, live owner thread, pending-questions, relay, build_log) before acting on anything that depends on earlier context. Read, do not recall. |
Goal: never act on lost/eroded memory of the ongoing work. The agent can be interrupted, compacted, or run dozens of interleaved cron passes and still pick up exactly where the thread left off — without the owner re-reminding it.
Why a skill, not a script: a hardcoded bundler (fixed N reads, one channel, fixed depth) is rigid — and easy to skip (narrate "re-anchor" then assert from memory anyway). The fix isn't a rigid script; it's flexible judgment + practice. This file is living — improve it whenever a reconstruction misses.
Before interpreting or acting on anything that depends on earlier context, READ the durable record. Don't recall — read. A "re-anchor" you claim but don't actually read is the failure.
Read the current-track record FIRST — <workspace>/hosts/<hostname>/current-track.md (this skill owns it; see "Maintain" below).
Resolve <hostname> with bash scripts/sutando-config.sh host-label, the same way pending-questions.md does. Legacy fallback: if that file is absent but <workspace>/state/current-track.md exists, read the legacy path and migrate it to the per-host path on the next write — the flat path was shared across hosts and is being retired (#2567).
It's the fast anchor: the current main-track goal, the active sub-task, and the live open decisions. This is what's missing when "continue your main track" gets guessed — the goal must be a pinned record, not inferred from luck.
Then, as the situation needs (pick what's relevant; skip what isn't):
python3 src/discord-read.py <channel_id> --serving <task channel_id> when serving a task (the contextNotFrom gate runs before the fetch), or --operator on autonomous passes with no serving context (Discord), telegram task [Replying to…] quotes (Telegram has no history fetch). Go as deep as the thread needs with --until <id|iso> — not a fixed message count. If unsure which channel is live, check the most recent task's channel_id / state/last-owner-activity.json.pending-questions.md.relay/relay-*.md.build_log.md tail.Effective > exhaustive: read enough to make this message/decision stand on its own, then stop.
The skill both uses and maintains <workspace>/hosts/<hostname>/current-track.md (NOT the legacy flat state/current-track.md — writing there again re-creates the cross-host delivery of one host's anchor onto another at the same local path; see the 2026-08-03 practice-log entry below, which retracts the "clobber"/data-loss framing this line used to carry) — the owner doesn't dictate its content and the agent doesn't invent it from memory; it's derived from the reconstruction:
Compare what you read against what you think is true. Where they differ, trust the record. If the current track is a still-open owner thread, continue THAT.
When the thing in front of you isn't self-contained — terse ("y", "no", "?", a pronoun), a reply, refers to something not stated, or you're resuming after a gap/compaction. Keyed on the message/situation, not on felt confidence (felt confidence is what fails — the agent is confidently wrong).
v0: created after a hardcoded reanchor.sh was rejected for being rigid + skippable. Open problem: making "actually read" reliable (it's a habit, not a one-liner). Iterate as misses happen.
invocation test PASSED: wired into proactive-loop step 0.7 as an actual Skill-tool invocation (not a "see X" reference — references don't load). Verified: invoking loads this body, then following it (read the live thread) confirms the current track. Invocation is the reliable-load half; doing the read is still the habit half.
added current-track ownership: the skill now READS state/current-track.md first and MAINTAINS it (derive from the record, don't dictate/invent). Seeded the file from the durable record. Closes the "reconstructs context but not the persistent goal" gap.
frontmatter is what makes it invocable. This file originally shipped without YAML frontmatter while most sibling skills carry name:/description:. A skill that isn't discoverable can't be invoked, and step 0.7 then no-ops silently — no error, no warning, indistinguishable from having run. Whenever this skill is changed, the check that matters is an actual Skill-tool invocation, not the file's presence on disk.
2026-08-03 PATH MOVED: the anchor now lives at <workspace>/hosts/<hostname>/current-track.md, not the flat state/current-track.md. The flat path was added to the shipped carrier set by #2534 and is shared across hosts, so two cores write the same vault path and a peer's anchor is delivered into your working copy. hosts/<label>/ is already carried by hosts/*/, so the per-host path needs no carrier entry and cannot collide — structurally impossible rather than correctly configured (#2568, merged 2026-08-03T12:44:58Z; refinement credit: Sutando-Mini).
⚠ CORRECTED 2026-08-04 — this entry previously said "after a live data loss" and claimed a peer "overwrote this host's 1056-line anchor … three writes, all destructive". THAT IS FALSE, and Chi corrected it. The vault uses per-host branches (host/<host>/<wsid>): a host only ever merges a peer INTO its own branch and never writes to the peer's. Checked afterwards — both branches were byte-identical, and this host's index referenced 263 memory files against the discarded copy's 262, a strict superset with nothing missing. Sutando-Pro independently confirmed it from the file's own two-commit history. The correction is written into src/health-check.py (see the UNSAFE_TO_READD comment, ~line 1396), which is the authority.
The guidance is unchanged — do not re-add the flat path — but the reason is cross-host CONTENT DELIVERY on a shared path, NOT data loss. Keeping the wrong reason here mattered: this file is loaded on every proactive-loop pass via step 0.7, so it re-taught a claim the owner had already retracted, and on 2026-08-04 I repeated "destroyed a 1056-line anchor" back to Chi from it. A retraction has to reach the file that gets read, not only the file that learned it.
Note the 2026-06-25 entry above is left as written — it was true then.
2026-08-13 — the first entry here that is NOT "I did not read." I read, and the reader returned a plausible partial result. Every entry above assumes the agent is the unreliable part, and the fix is always go read the durable record. This one is about the record's reader being unreliable, and it defeats the whole step silently.
A history read returned only messages from a recent cutoff onward — at every limit up to 1000 — while a local archive held months of earlier traffic from the same source. Probed with known ids from before the cutoff: 0 returned, with a positive control confirming the id field was populated on every message it did return, so the zero was absence rather than an empty field.
The property to carry: an agent cannot distinguish a plausible partial result from a complete one. A windowed read and a genuinely short thread are the same object from inside. So step 0.7's "reconstruct the live thread" can report success while returning almost nothing, and felt compliance is exactly as unreliable here as felt confidence is everywhere else in this file.
What to do instead. When a reconstruction returns fewer items than the situation implies, treat the shortfall as unexplained until something outside that reader accounts for it. Three cheap discriminating probes, in order:
returned == requested, it is not a truncation signal at all.Probe 3 is where the second mistake lives. An outside record is not automatically trustworthy:
>= the event time, and its tail is brutal. Calibrated over
2678 files carrying both a declared timestamp and an mtime: median lag +1s, maximum lag
8.1 days. An excellent proxy almost always and catastrophically wrong occasionally — the worst
possible shape, because a small sample lands in the well-behaved majority and reads as
confirmation. Quote a max, never a rate: measured across three populations the tail frequency
spans two orders of magnitude (0.1% / 5.5% / 20%), so the rate is a property of the corpus, not of
the archive. Name the corpus and the filter with any such number.And "two independent methods" must mean methods with different FAILURE MODES, not two invocations. Two calls that share a cutoff, a corpus, or a path convention can agree perfectly while omitting the same thing. Independence is semantic, and the only way to establish it is to have seen the two disagree on a case where you know the answer.