Source profileQuality 62/100

sonichi/sutando/skills/context-reconstruct/SKILL.md

context-reconstruct

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.

Source repository stars
359
Declared platforms
0
Static risk flags
0
Last source update
2026-07-28
Source checked
2026-07-28

Decision brief

What it does—and where it fits

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.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/sonichi/sutando --skill "skills/context-reconstruct"
    Safe inspection promptEditorial

    Inspect the Agent Skill "context-reconstruct" from https://github.com/sonichi/sutando/blob/6a8f0fccd32e5aa620a3572c8885544f144bb6fe/skills/context-reconstruct/SKILL.md at commit 6a8f0fccd32e5aa620a3572c8885544f144bb6fe. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      The one rule

      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.

      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.
    2. 02

      What to read — judgment, fit to the moment (not a checklist to run blindly)

      Read the current-track record FIRST — /state/current-track.md (this skill owns it; see "Maintain" below). 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 — th…

      The live thread — the channel(s) the owner is actually active on: python3 src/discord-read.py (Discord), telegram task [Replying to…] quotes (Telegram has no history fetch). Go as deep as the thread needs with --until —…Open decisions — per-host pending-questions.md.Recent judgment/decisions — latest relay/relay-.md.
    3. 03

      Maintain the current-track record (the skill owns it)

      The skill both uses and maintains state/current-track.md — the owner doesn't dictate its content and the agent doesn't invent it from memory; it's derived from the reconstruction:

      Create it if absent (first run): write the current main-track goal + active sub-task + key open decisions, derived from what the durable record (thread / buildlog / pending-questions / relevant project memory) actually…Update it when the track moves — after a reconstruction reveals the goal/sub-task/decisions changed (owner redirected, a thing shipped, a decision resolved), rewrite it. Keep it short (a pinned summary, not a log).Next reconstruction reads it first → "what's the main track" is never a guess again.
    4. 04

      Then

      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.

      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.
    5. 05

      When to reconstruct

      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 confi…

      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 co…

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score62/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars359SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    sonichi/sutando
    Skill path
    skills/context-reconstruct/SKILL.md
    Commit
    6a8f0fccd32e5aa620a3572c8885544f144bb6fe
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    context-reconstruct

    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.

    The one rule

    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.

    What to read — judgment, fit to the moment (not a checklist to run blindly)

    Read the current-track record FIRST<workspace>/state/current-track.md (this skill owns it; see "Maintain" below). 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):

    • The live thread — the channel(s) the owner is actually active on: python3 src/discord-read.py <channel_id> (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.
    • Open decisions — per-host pending-questions.md.
    • Recent judgment/decisions — latest relay/relay-*.md.
    • What's built / nextbuild_log.md tail.
    • Deep history (older than the channel can cheaply reach) — the session transcript JSONL.

    Effective > exhaustive: read enough to make this message/decision stand on its own, then stop.

    Maintain the current-track record (the skill owns it)

    The skill both uses and maintains state/current-track.md — the owner doesn't dictate its content and the agent doesn't invent it from memory; it's derived from the reconstruction:

    • Create it if absent (first run): write the current main-track goal + active sub-task + key open decisions, derived from what the durable record (thread / build_log / pending-questions / relevant project memory) actually shows.
    • Update it when the track moves — after a reconstruction reveals the goal/sub-task/decisions changed (owner redirected, a thing shipped, a decision resolved), rewrite it. Keep it short (a pinned summary, not a log).
    • Next reconstruction reads it first → "what's the main track" is never a guess again.

    Then

    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 to reconstruct

    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).

    Practice log (improve this skill here)

    • 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.