Repo Context Ledger logo

Repo Context Ledger

Community
gviiisen
repo-context-ledger

Record every behavior-changing feature addition, fix, and adjustment as durable, evidence-based repository knowledge, then use that ledger to continue accurately across AI windows, tools, Git collaboration, and pull requests. Use the deterministic runtime to route bounded context, isolate private drafts, publish verified change records, refresh stable feature knowledge, and keep native Codex, Claude, Cursor, Copilot, Grok, and other Agent entry points aligned without asking the user to run bookkeeping commands.

Overview

Publishergviiisen
Repositoryrepo-context-ledger
Skill namerepo-context-ledger
Stars
104
Forks
0
Bundled files
12
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 12 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by gviiisen on GitHub. Read the source before you install it.

Installation

Install the Repo Context Ledger AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/gviiisen/repo-context-ledger/tree/main/skills/repo-context-ledger
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/gviiisen/repo-context-ledger.git /tmp/repo-context-ledger
mkdir -p .claude/skills
cp -r /tmp/repo-context-ledger/skills/repo-context-ledger .claude/skills/repo-context-ledger
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Repo Context Ledger in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Repo Context Ledger on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Repo Context Ledger is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Repo Context Ledger

Turn behavior-changing feature work into durable, code-verified repository knowledge. Git-tracked Packs, specs, and completed Changes form the feature change ledger; cross-window and cross-Agent continuation are capabilities built on that shared source. Private vendor Memory is never read or synchronized.

First decide what is new — without a Ledger call

Judge new facts/effects from the current request, loaded conversation, known task and inspected code, not similar wording. Do this mentally: no classifier command, extra document, or automatic Git/Markdown rescan.

  • Routine question/recheck/operation with sufficient context: answer or execute the authorized request normally, without a new Ledger lifecycle. Do not skip a requested recheck or infer permission to repeat side effects.
  • Same known unfinished task: keep its session/epoch and background; add only new changes, findings, decisions and checks. Same-window "continue" does not require resume or a new session.
  • Similar work with new behavior/inputs/paths: reuse the method, not a previous pass. Keep a suitable unfinished task; after publication create a new change record and reference relevant history. Independent deliverables stay separate.
  • Missing identity/background: query only what is missing. Paused tasks and actual handovers need resume; lifecycle writes still validate ownership/epoch. Resolve stale state rather than guessing.

Proceed when scope/identity are clear, without announcing a classification checklist. Reuse results only while relevant code, inputs, environment and acceptance phase remain valid. Changed conditions and time-sensitive safety checks need fresh verification; never relabel an old pass as new. Investigate uncertain code boundaries.

Runtime

Resolve this Skill directory. Its runtime is scripts/ledger.py. After initialization use the repository entry:

text
python .context-ledger/ledger.py <command>

Use python3 when needed. --repo is optional; discovery walks upward to the nearest .context-ledger/config.json and stops at nested Git boundaries.

In runtime.mode: global, that entry is a small forwarder to the Codex Skill under CODEX_HOME/skills (or the user's .codex/skills); configuration and records remain repository-local. If the entry is absent, invoke this installed Skill's runtime with explicit --repo <project>. Never initialize or copy an old runtime just to execute a command. See global-runtime.md only for runtime installation/migration.

Plan only when routing is needed

When the decision above leaves task identity or required context unresolved, run:

text
python .context-ledger/ledger.py plan --query "<user request>" --tool <agent>

Follow the returned workflow-plan-v1 mode and next_action:

  • readonly: load bounded context only; never create a session.
  • small-fix: start one short session, edit the known boundary, verify, finish.
  • ordinary-change: route the Pack/spec, start one session, implement, verify, refresh stable knowledge, finish.
  • resume: resume only one uniquely selected accessible session and keep its new epoch.

Automatic classification is guidance, not permission. If requires_confirmation is true, clarify the workflow or select a session; never guess. start --workflow readonly|resume must fail. context returns the same nested Workflow Plan, and resume --query uses the same owned-session route.

Non-negotiable safety

  • Never read, pause, resume, checkpoint, finish, invalidate, or expose another principal's private task unless an explicit unexpired grant permits that exact access.
  • Never message, delegate to, steer, or interrupt another user-owned Agent task unless the user explicitly requests cross-task coordination.
  • The ledger isolates documentation sessions only. It does not lock, copy, merge, or coordinate source-code edits; leave code conflicts to the host Agent and Git.
  • Read only Context Bundle required_reads initially. Never recursively load docs/ai, docs/specs, or docs/changes. This is a starting route, not a cap: expand through every behavior-relevant caller, implementation, configuration, persistence, permission, concurrency, retry, test, and external boundary.
  • Prefer code and executed verification over specs, specs over Packs, and Git-tracked knowledge over private Agent Memory.
  • Do not create a handoff for read-only analysis, questions, or formatting-only work.
  • Do not ask the user to run ledger bookkeeping commands.
  • One bounded logical request gets one session and one completed Change. Archive once, but update the same draft when meaningful facts emerge. Before a context/window switch, and after a changed diagnosis, key decision, or relevant failed approach, preserve the useful explanation while it is fresh. Use private checkpoints for continuation, not a new Change per step; do not combine unrelated requests or independently deliverable work just to reduce record counts.

Change lifecycle

  1. Keep the session ID and epoch from start/resume; use status only when this task's identity or state needs resolving. Pass --session on lifecycle writes; never guess or absorb another task.
  2. Follow an existing accepted plan. Run context/focus only for missing or changed background, not again for every ordinary-work turn. A known code boundary needs no repeated broad routing.
  3. Start once when behavior will change and there is no suitable unfinished task: start --title "<title>" --feature <feature> --workflow <small-fix|ordinary-change> --tool <agent>. Reuse only a genuinely related task; never reopen a completed record to hide a new change.
  4. Implement after verifying the routed boundary in code. Context docs guide where to look; they never justify reading too little code.
  5. Choose acceptance goals before verification. Reads, searches, file/configuration generation, preparation, and authorized deployment use ordinary tools, not a verify wrapper per operation. Run acceptance through verify once when first needed; do not run it bare and repeat it just for a Ledger entry. Group related checks with an existing reviewed project script/preset, preserving step results and failure exit codes. Keep pre-deployment and post-deployment goals separate. Independent checks may run concurrently only without shared mutable resources; use direct argv, not nested shell strings.
  6. Prefer an exact repository preset when configured. If PRESET_TRUST_REQUIRED appears, review it and repeat with its exact printed --trust-digest; never trust without reviewing. Ordinary operations and useful diagnostic observations belong in the same draft as such, not fabricated managed check results. Never replay a deployment, authorization, migration, or trade to obtain missing logging. See verification-presets.md for grouping and the optional tested script example.
  7. A single-session small fix lets finish collect evidence. With parallel sessions or a broad dirty tree, run evidence --path for this task's paths only.
  8. Refresh the related Pack and spec when their facts or dependencies changed. Update only the draft's new differences and correct superseded assumptions; retain useful earlier reasoning rather than rewriting unchanged background. A small-fix form still explains each meaningful change, its file/symbol references, and documentation rationale. Only Updated is generated; share common boundaries and verification rather than repeating them.
  9. Remove unresolved template placeholders and finish once the bounded request is actually complete, not at every intermediate reply: finish --spec <spec>, or --no-spec --reason "<why no stable behavior exists>". Keep a returned continuation epoch on every resumed write.

Read production-workflow.md for large repositories, verification concurrency, PR baselines, coverage gates, and derived-index timing. Read writing-quality.md before editing an evidence-v1 draft.

Small is a known low-risk boundary, not a line count. Independent behavior changes, permissions, persistence, money, concurrency, public contracts, or uncertain impact need ordinary investigation and records. Expand the same draft when scope grows; preserve its notes and evidence, rather than finishing early or starting over. finish --dry-run is optional; do not make it a mandatory extra step or loop through it while still writing. Before finish, reconcile meaningful diff changes against the record; passing structural checks is not proof of complete business explanations.

Initialize or upgrade

Run init --dry-run, review the exact plan, then run the same init only when its scope is correct. Preserve prose outside managed markers and all existing completed history. Confirm adapters check, manifest check, and doctor. See document-model.md for legacy layouts and where facts belong.

Cross-window continuation

Before switching Agents or windows, run checkpoint --summary "<state>" --next "<action>"; use pause only when suspending the task. In the new window run plan --query "continue <keywords>", then its explicit resume action. Resume increments the epoch; it does not create a replacement session.

"Continue" inside the same active window is not a handover. If the task and current epoch are already known, continue directly; resume only for an actual handover, paused task, or state recovery.

If several sessions are close matches, choose an explicit session. If only foreign work overlaps, use committed Pack/spec/Change guidance. Private unfinished state does not travel with clone, pull, or another computer.

Integration and recovery

  • Use doctor first for bounded read-only diagnosis. It never deletes locks or mutates Packs/sessions.
  • At PR/integration time run policy --base <ref> for aggregate delta-based checks. Use audit --history --policy as-recorded --fail-on unresolved only for controlled historical/release audits, never to unblock an unrelated session.
  • After merge, run sync --derived once on the configured default branch. Do not hand-edit generated indexes.
  • Keep unfinished drafts private. Publish only through finish; never persist secrets or machine-specific absolute paths.

Runtime development

Edit src/repo_context_ledger/runtime.py.tmpl and its ordered source fragments, not generated runtimes. Run python scripts/build_runtime.py and python scripts/build_runtime.py --check; .context-ledger/ledger.py and the Skill runtime must remain byte-identical standalone files.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Repo Context Ledger AI skill do?

Record every behavior-changing feature addition, fix, and adjustment as durable, evidence-based repository knowledge, then use that ledger to continue accurately across AI windows, tools, Git collaboration, and pull requests. Use the deterministic runtime to route bounded context, isolate private drafts, publish verified change records, refresh stable feature knowledge, and keep native Codex, Claude, Cursor, Copilot, Grok, and other Agent entry points aligned without asking the user to run bookkeeping commands.

Why use Repo Context Ledger on TypingMind?

Because you install it once and use it with any model. Repo Context Ledger is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Repo Context Ledger in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/gviiisen/repo-context-ledger/tree/main/skills/repo-context-ledger. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Repo Context Ledger?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Repo Context Ledger?

As many as you like. As long as a model supports skills, you can use Repo Context Ledger with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Repo Context Ledger AI skill free?

Yes. It is published on GitHub by gviiisen under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇