core-skills
Search Svenska

The loop

The working loop

The order is the contract's order. This page renders it; it does not describe it — a hand-written copy of the loop is a second thing to keep true, and that is how a release list once went seventeen versions stale without anyone noticing.

1 when picking it up 1 once, at set-up 3 before the session 1 you 1 the session 6 after, the same day 2 you 2 weekly and then it begins again 14 steps 3 of them are yours

when picking it up

  1. where it left off

    Reads one folder's current state before any work resumes: loop position and whether the next agenda exists, whether the carry-forward chain is intact, what is carrying and how much of it is unowned, how stale the archives are, what is staged and unsent, and when the record last moved. Read-only - it writes nothing, fetches nothing and caches nothing, because an orientation file that persists can itself go stale and then lie

    $ /ops orient <folder>

    reads the summary, _outbox/<item>/_manifest.md, <venture>/.teamschats/, <venture>/.githubmeta/ → produces a reading of the current state

once, at set-up

  1. the folder's config

    Declares which chat and repositories the work concerns, which post-meeting artifacts the series wants, and where its task ledger lives

    $ edit <project>/.claude/ops-config.yaml, or the folder's _ops.yaml

    produces the config

before the session

  1. the fetchers

    Fetch the chat and repository archives. External CLIs, run on demand or on a schedule - never by a skill

    reads the config → produces <venture>/.teamschats/, <venture>/.githubmeta/

  2. the agenda

    Writes the agenda: what did not land last time, with its session count and age, then what the archives hold that the room has not heard — the script leaves a digest slot, and the agenda is a draft until prepare has read the messages and filled it (CR-101)

    $ /ops prepare (runs build_agenda.py where the loop is wired); /preparation without a config

    reads <venture>/.teamschats/, <venture>/.githubmeta/, the summary's carry-forward section → produces the agenda

  3. the facilitator sheet

    Turning a fact into the right question

    reads the agenda

    You do this one. The agenda carries facts; which question to ask is judgement, not generation

the session

  1. the meeting

    Recorded, so everything asynchronous is invisible to it by construction - which is what the archives exist to answer. The transcript ARRIVES BY SEVERAL ROUTES - a recorder into a knowledge base read over MCP, a file dropped in, or text pasted straight into the session. The loop does not care which; it cares that the source is NAMED in the note, because two recordings of one meeting is the normal case and a note that cannot say which one it came from cannot be corrected against it

    produces a transcript

after, the same day

  1. one pass over the transcript

    The summary, the changelog line, the ledger and insights, the raw source archived to .transcripts/ (CR-085), and whatever the folder declared

    $ /ops process <transcript> (the default); /transcript without a config

    reads a transcript, the config → produces the summary, the ledger and insights, .transcripts/<stem>-raw.md, a staged recap

  2. the summary's carry-forward

    What did not land becomes the top of the next agenda. This is where the loop closes

    $ written into the summary by /ops process; verified by /ops check <folder>

    reads the summary → produces the summary's carry-forward section

  3. the recap

    Offered rather than written: assembled from the narrowest of three inputs it would be confidently incomplete, and invisibly so to a reader with no transcript to check it against

    reads the summary

    You do this one. Whether a session warrants a recap is a judgement about the audience, not about the material

  4. staging and sending

    Staged as a folder with a manifest; a dispatching surface delivers it and records what it did

    $ /outbox list, then /outbox close <folder> once resolved

    reads a staged recap → produces _outbox/<item>/_manifest.md

  5. the dispatching surface

    A dashboard reads _outbox/, previews the staged item and delivers it over the channel its manifest declares - a chat workspace through the messaging client, or an email draft a person presses send on. It writes back status, status-note, channel and contact ONLY, and may create a manifest where a folder has none (CR-115); it never rewrites one, decides what a status means, or archives

    reads _outbox/<item>/_manifest.md → produces the message, delivered

  6. marking it sent

    The manifest's status is the only record that something actually went out

    reads the message, delivered

    You do this one. That click is where the posted message gets read as it actually landed

weekly

  1. the knowledge loop

    Confirmed hypotheses become standing rules; the corpus renders to a wiki

    $ /insights compile, then /insights synthesize

    reads the ledger and insights

  2. the shape checks

    On a folder it finds a broken carry-forward chain and template forks; on the vault it finds closure debt. Both catch the failures that announce nothing

    $ /ops check <folder>, then /ops check

    reads the summary, the ledger and insights

From ecosystem.yaml, contract 41 · core-skills 1.89.4 · read at build 2026-10-08