Opencontext

OpenContext

Use this skill when the real question is "what project-memory packet should the next agent load, search, or leave behind?"

The job is not to dump the whole oc CLI. The job is to: 1. classify the memory need honestly, 2. choose one primary packet, 3. load the minimum useful context, 4. search old decisions only when needed, 5. store reusable conclusions after meaningful work, 6. route wiki / graph / vault / repo-packer requests away immediately.

Read references/intake-packets-and-route-outs.md before handling an unfamiliar memory request. Read references/memory-layer-decision-guide.md when the first question is which memory layer should own the job. Read references/load-search-store-playbook.md when the task is active project-memory operation. Read references/trust-precedence-and-freshness.md when multiple memory artifacts disagree or branch freshness is unclear. Read references/setup-and-integration.md when the real task is installing or wiring OpenContext.

When to use this skill

• The next agent should not start cold and needs a compact project-memory packet first
• Repo or project decisions, pitfalls, acceptance notes, or constraints should be searchable across sessions
• A team needs a durable cross-agent handoff that points to the right docs instead of pasting giant transcripts
• The work needs manifests or stable links that say what to read now
• OpenContext itself needs setup, repo initialization, or integration guidance
• The user is choosing between OpenContext, a wiki, a graph layer, a vault, or a repo-packer workflow

When not to use this skill

• The main task is building a long-lived markdown knowledge base or research wiki → use llm-wiki
• The main task is mapping code/docs/media structure, generating `GRAPH_REPORT.md`, or tracing relationships → use graphify
• The main task is organizing human-authored notes or vault workflows → use the relevant note/vault skill
• The main task is flattening a repo into a single prompt/digest for one-shot model context → use the repo-packer tool or skill that owns that flow
• The main task is repo automation, scripts, hooks, or recurring commands → use workflow-automation

Instructions

Step 1: Start from the packet already in hand

Use references/intake-packets-and-route-outs.md.

Normalize the request into one of these packet shapes:

• memory-layer-choice-packet — the user is deciding between OpenContext, wiki, graph, vault, or repo-packer layers
• load-context-packet — the next agent needs the smallest truthful read-first context before work starts
• search-context-packet — the current task needs prior decisions, constraints, pitfalls, or acceptance notes
• store-conclusions-packet — meaningful work finished and reusable outcomes should be saved
• setup-integration-packet — OpenContext itself needs install/init/integration guidance
• repo-packer-route-out-packet — the request is really about one-shot repo-to-prompt packing, not ongoing project memory

Capture the minimum useful frame:

Packet: load-context-packet
Project scope: active repo
Goal: prepare the next coding agent
Current pain: repeated background + cold starts
Artifact preference: manifest + stable links

Rule: start with the packet the user already has. Do not force every request through a full memory-taxonomy lecture.

Step 2: Choose one primary mode

Pick exactly one primary mode for the run:

• memory-layer-choice
• load-context
• search-context
• store-conclusions
• setup-integration
• route-out

Optional: name one secondary mode, but do not flatten load/search/store/setup into one giant answer.

Step 3: Decide whether OpenContext should own the job at all

Use this quick ownership test:

• OpenContext owns it when the dominant need is active project/repo memory for agents: small read-first packets, searchable decisions, handoff notes, manifests, stable links
• `llm-wiki` owns it when the dominant need is long-lived synthesized markdown knowledge
• `graphify` owns it when the dominant need is structure graphs, relationship tracing, or graph artifacts
• Vault / note tools own it when the dominant workflow is human-authored notes and editorial control
• Repo packers own it when the real request is “turn this repo into one prompt/digest right now”

If OpenContext is not the right owner, route out immediately instead of describing it as the universal memory layer.

Step 4: Load before you create

If OpenContext already exists, orient first:

oc folder ls --all
oc doc ls <folder>
oc search "<topic>" --mode keyword --format json
oc context manifest <folder> --limit 10

Look for:

• the folder that already owns the project/topic memory
• existing decision logs, pitfalls, acceptance notes, or handoff docs
• the smallest useful set of files the next agent should read first
• the most trustworthy source if several notes overlap

Run one fast trust check before you load or search further:

• precedence: prefer canonical repo docs and current decision logs over stale summaries
• provenance: say whether a note came from a human-maintained doc, a current handoff, a previous agent summary, or an inferred heuristic
• freshness: check whether branch, release, migration, or incident state may have invalidated the note

Default rule: update existing memory docs before creating a parallel doc with the same purpose.

Step 5: Run the load → search → store loop

Use references/load-search-store-playbook.md.

A. load-context

Use when the next agent needs the smallest truthful startup packet.

Typical outputs:

• one manifest command or read-first packet
• one folder recommendation
• one short list of docs to read first
• one trust note naming the highest-confidence source and any stale-risk warning

Questions to answer:

• Which folder is the project-memory home?
• Which 3–10 docs should be read first?
• Which constraints or pitfalls already exist?
• Which source currently wins if docs disagree?
• Does branch or release state make any saved note risky?

B. search-context

Use when current work would otherwise rely on guesswork.

Typical search targets:

• prior decisions
• acceptance criteria
• environment quirks
• architecture constraints
• release notes or incident learnings

Default: try keyword search and manifests first. Do not jump straight to embeddings/index builds unless the corpus and failure mode justify it.

C. store-conclusions

Use after meaningful work, not after every tiny edit.

Good document shapes:

• decision-log.md
• pitfalls.md
• acceptance-criteria.md
• release-notes.md
• handoff-YYYY-MM-DD.md

A useful stored note usually contains:

• what changed
• why that choice was made
• what to verify next
• the smallest evidence links/citations needed later
• which source won if artifacts conflicted, plus any branch/freshness warning for the next session

Step 6: Handle setup and integration cleanly

Use references/setup-and-integration.md.

Core commands worth surfacing:

npm install -g @aicontextlab/cli
# or
npx @aicontextlab/cli <command>

cd your-project
oc init
oc folder ls --all
oc doc create <folder> <doc>.md -d "Description"
oc search "query" --mode keyword --format json
oc context manifest <folder> --limit 10
oc doc link <doc_path>

Escalate to embeddings/indexing only when keyword search and manifests are not enough and the indexing cost is justified.

Step 7: Route out honestly

Typical route-outs:

• `llm-wiki` — narrative synthesis, entity/concept pages, index/log/schema discipline
• `graphify` — graph artifacts, structural repo/corpus mapping, relationship tracing
• Vault/note skills — human-first note organization and editing
• Repo packers (Repomix / Gitingest / Code2Prompt-style workflows) — one-shot repo-to-prompt context packing
• `workflow-automation` — recurring scripts, repo hooks, and automation that are not really about memory ownership

If the user says “package this repo for one model prompt,” that is not an opencontext job. If they say “make sure the next agent knows what to load, what we already decided, and what to store after the task,” that is.

Step 8: Return one concise project-memory brief

Preferred format:

# Project Memory Brief

## Packet
- Packet:
- Primary mode:
- Project horizon:
- Why OpenContext owns this (or route-out):

## Do now
1. ...
2. ...
3. ...

## Read / search / store targets
- Folder:
- Docs to read first:
- Search terms:
- Note to update or create:

## Trust check
- Highest-confidence source:
- Provenance:
- Freshness / branch warning:

## Route-outs
- ...

Short, deterministic packets beat giant CLI encyclopedias.

Output format

Always return a project-memory brief, memory-layer choice memo, or OpenContext setup note.

Required qualities:

• identify the packet already in hand
• choose one primary mode
• explain whether OpenContext owns the job or should route out
• keep the answer focused on the smallest truthful manifest/search/store packet
• state the highest-confidence source when overlapping notes exist
• mention freshness / branch risk when it could invalidate saved memory
• mention embeddings/index builds only as an escalation path
• name the next owner when another memory or tooling layer is a better fit

Examples

Example 1: Load project memory before coding

Input

We keep losing repo background between agent sessions. I need the next coding agent to load the right docs before touching this repo.

Output sketch

• Packet: load-context-packet
• Primary mode: load-context
• OpenContext owns the job because the need is an active repo-memory startup packet
• Action: identify folder, generate manifest, list the 3–10 docs to read first, and leave a handoff note after the task

Example 2: Memory-layer choice

Input

Should we use OpenContext, a wiki, Obsidian, or a graph tool for this product work?

Output sketch

• Packet: memory-layer-choice-packet
• Primary mode: memory-layer-choice
• Distinguish project-memory vs wiki vs graph vs human-vault roles
• Keep OpenContext only for active project/repo memory and handoff packets

Example 3: Search old decisions during work

Input

Before we change this release flow, search whether we already recorded deployment constraints or rollback notes.

Output sketch

• Packet: search-context-packet
• Primary mode: search-context
• Search existing decision logs / release notes first
• Prefer keyword search + manifest before any indexing escalation

Example 4: One-shot repo packing is the real task

Input

Turn this repo into a single prompt I can paste into a model right now.

Output sketch

• Packet: repo-packer-route-out-packet
• Primary mode: route-out
• Route to Repomix / Gitingest / Code2Prompt-style workflow instead of pretending OpenContext is the right tool

Example 5: Conflicting memory artifacts on a release branch

Input

README.md says one deploy step, CLAUDE.md says another, and we just switched to a release branch. What should the next agent trust?

Output sketch

• Packet: load-context-packet or search-context-packet
• Name the highest-confidence source instead of flattening both notes together
• Explain provenance and note that branch/release state may invalidate the older instruction
• Store a compact handoff note describing which source won and what still needs verification

Best practices

1. Pick OpenContext because the workflow needs active project/repo memory, not because the word “memory” appeared. 2. Prefer updating existing docs over creating duplicates. 3. Load the minimum useful context first; manifests beat giant indiscriminate reads. 4. State which source currently wins when memory artifacts overlap, and why. 5. Treat branch/release/incident state as a freshness check, not background trivia. 6. Store decisions after meaningful work so the next session starts with less ambiguity. 7. Keep document shapes predictable (decision-log, pitfalls, handoff, acceptance-criteria, release-notes). 8. Treat embeddings/index builds as an escalation, not the default. 9. Route wiki, graph, vault, and repo-packer requests out early instead of flattening them into one skill.

References

• Intake Packets and Route-outs
• Memory Layer Decision Guide
• Load/Search/Store Playbook
• Trust, Precedence, and Freshness
• Setup and Integration Notes
• OpenContext README
• OpenContext usage docs
• Karpathy LLM Wiki gist
• Graphify README

Intake Packets and Route-outs

Start from the project-memory packet already in hand. Do not turn every request into a giant memory taxonomy or CLI command dump.

memory-layer-choice-packet

Use when the user is deciding whether the job belongs in OpenContext, a wiki, a graph layer, a vault, or a repo-packer workflow.

Capture:

• the dominant need: active project memory, narrative knowledge base, structure graph, human-authored notes, or one-shot repo packing
• project horizon: current project, multi-project, or evergreen knowledge
• who consumes the artifact: one agent, many agents, or humans first

Good outcome:

• one explicit owner (opencontext, llm-wiki, graphify, a vault skill, or a repo packer)
• one sentence explaining why the neighboring lanes do not own this request

Route out when:

• the real job is long-form wiki maintenance → llm-wiki
• the real job is graph structure mapping → graphify
• the real job is human note/vault organization → vault skill
• the real job is one-shot repo prompt packing → Repomix / Gitingest / Code2Prompt-style workflow

load-context-packet

Use when the next agent should not start cold and needs the smallest truthful read-first packet.

Capture:

• current project or folder scope
• what the next agent is about to do
• the strongest current pain: repeated background, missing constraints, unclear read order
• preferred artifact: manifest, stable links, short read-first list, or mixed

Good outcome:

• one folder to start from
• one manifest command or equivalent read-first packet
• one list of 3–10 docs to read first

Route out when:

• the task is actually flattening a repo into one prompt → repo packer
• the task is really repo structure design, not memory loading → file-organization

search-context-packet

Use when the current task needs prior decisions, constraints, acceptance notes, incidents, or pitfalls.

Capture:

• the exact topic or decision you need to recover
• whether the target is likely a decision log, pitfall note, acceptance criteria, release note, or handoff
• whether keyword search has already been tried

Good outcome:

• one targeted search query or small query set
• one likely folder/document family
• one recommendation about whether manifests are enough or indexing should remain out of scope

Route out when:

• the user is really asking for broad wiki synthesis → llm-wiki
• the user needs structure/relationship tracing instead of note retrieval → graphify

store-conclusions-packet

Use when meaningful work finished and reusable outcomes should survive the next session.

Capture:

• what changed
• why the decision was made
• what still needs verification
• the smallest evidence links or citations to keep

Good outcome:

• one updated existing doc, or one new doc with a predictable shape
• explicit avoidance of transcript dumps when a compact note is enough

Route out when:

• the output should become a durable wiki page rather than active project memory → llm-wiki
• the result is primarily a human note or editorial artifact → vault skill

setup-integration-packet

Use when OpenContext itself needs install, repo initialization, manifests, stable-link usage, or search/index setup.

Capture:

• current environment
• whether OpenContext is installed already
• whether the user needs CLI-only setup, repo init, or integration guidance
• whether keyword search is enough or semantic search/indexing is being considered

Good outcome:

• one bounded install/init sequence
• one list of core commands worth remembering
• one explicit rule for when not to build an index yet

Route out when:

• the main task is runtime automation or hooks instead of memory setup → workflow-automation

repo-packer-route-out-packet

Use when the request is really “package this repo for a model right now” rather than ongoing memory.

Signals:

• one prompt/digest for a single chat/model
• snapshot packaging of a repo
• no need for persistent decisions, handoff notes, or later search

Good outcome:

• route to Repomix / Gitingest / Code2Prompt-style tooling
• explain briefly that this is a snapshot context-loading problem, not a project-memory problem

Quick route-out table

Rule of thumb

A good packet is the smallest artifact set that lets the next agent load, search, or store project context honestly. If the packet cannot answer that need, route to the neighboring layer instead of pretending OpenContext covers everything.

OpenContext Load/Search/Store Playbook

Core operating loop

Load context → do the work → search when unsure → store conclusions

This skill is strongest when the operator treats OpenContext as a lightweight project-memory loop, not as a giant document dump.

1. Load before work

Use a manifest or folder scan to pull in the minimum relevant context.

Typical commands:

oc folder ls --all
oc context manifest <folder> --limit 10
oc search "<topic>" --mode keyword --format json

Questions to answer before doing work:

• Which folder holds the project or topic memory?
• Which 3-10 documents should the next agent read first?
• Are there already decisions or pitfalls recorded?

2. Search during work

Search when a task would otherwise trigger guesswork or re-explanation.

Good search targets:

• prior decisions
• acceptance criteria
• environment quirks
• architectural constraints
• release notes / known incidents

3. Store after meaningful work

Capture outcomes after a meaningful run, not after every tiny edit.

Good document types:

• decision-log.md
• pitfalls.md
• release-notes.md
• acceptance-criteria.md
• handoff-<date>.md

A useful stored note usually contains:

• what changed
• why that choice was made
• what to verify next
• links/citations to evidence

4. Update instead of duplicate

If the relevant document already exists, extend or refresh it instead of creating parallel files with the same purpose.

5. Handoff packet

When work passes to another agent or session, store a compact handoff packet:

• current objective
• constraints / decisions already made
• files or folders to read first
• next checks / open questions

Anti-patterns

• dumping giant raw transcripts without extracting decisions
• storing everything in one mega document
• using OpenContext as a substitute for a real wiki when the need is long-lived synthesis
• rebuilding semantic search indexes without a reason or cost check

OpenContext Memory-Layer Decision Guide

Use this when the user says some version of "remember this project context and help future sessions pick it up quickly".

Pick the right layer

Choose opencontext when you need

• project or repo background loaded before work starts
• searchable decisions, lessons, and follow-up notes
• cross-session continuity for active delivery work
• cross-agent handoff between planning, coding, and testing tools
• stable links or manifests that tell the next agent what to read

Route to llm-wiki when you need

• a long-lived, compounding markdown knowledge base
• narrative synthesis across many sources
• entity/concept/comparison pages
• periodic linting of contradictions, orphan pages, and stale content

Route to graphify when you need

• a structural map of code or mixed files
• relationship tracing or graph queries
• GRAPH_REPORT.md, graph.json, or graph-backed architecture discovery

Route to a human-authored vault / note system when you need

• manual note-taking as the primary workflow
• editorial control in Obsidian or a plain markdown vault
• a human-first notebook that an agent may read secondarily

Decision packet

memory_choice:
  primary_need: session-continuity | searchable-decisions | durable-wiki | structure-graph | human-note-vault | unknown
  horizon: current-project | multi-project | evergreen-domain | mixed
  artifact_shape: short-docs | wiki-pages | graph-artifacts | personal-notes | mixed
  consumers: one-agent | many-agents | human-only | mixed

Fast heuristics

• If the question starts with "what should the next agent load before touching this repo?" → opencontext
• If the question starts with "build a persistent knowledge base/wiki" → llm-wiki
• If the question starts with "map the codebase / build a graph / trace relationships" → graphify
• If the question starts with "organize my notes/vault" → note/vault skills

OpenContext Setup and Integration Notes

Install paths

npm install -g @aicontextlab/cli
# or
npx @aicontextlab/cli <command>

Initialize in a repository

cd your-project
oc init

oc init is the right move when the repo should gain OpenContext-aware setup, command surfaces, or MCP config.

Core commands worth remembering

oc folder ls --all
oc doc ls <folder>
oc doc create <folder> <doc>.md -d "Description"
oc search "query" --mode keyword --format json
oc context manifest <folder> --limit 10
oc doc link <doc_path>

Semantic search / embeddings

Only escalate to semantic search when keyword search and manifests are not enough.

Typical setup:

oc config set EMBEDDING_API_KEY "<key>"
oc config set EMBEDDING_API_BASE "https://api.openai.com/v1"
oc config set EMBEDDING_MODEL "text-embedding-3-small"
oc index build

Integration boundary reminders

• OpenContext is compatible with existing agent CLIs; it should complement, not replace, the execution agent.
• Use OpenContext stable links or manifests for handoff.
• Pair OpenContext with llm-wiki when project memory should mature into a long-lived knowledge base.
• Pair OpenContext with graphify when the next question is structural rather than narrative.

Evidence sources

• OpenContext README: https://raw.githubusercontent.com/0xranx/OpenContext/main/README.md
• Karpathy LLM Wiki gist: https://gist.githubusercontent.com/karpathy/442a6bf555914893e9891c11519de94f/raw
• Graphify README: https://raw.githubusercontent.com/safishamsi/graphify/main/README.md

Trust, Precedence, and Freshness

Use this when OpenContext has to answer which memory artifact the next agent should trust instead of just listing every note that exists.

Fast trust order

Prefer this order unless the repo/team has a stronger explicit convention: 1. Canonical repo doc for the current branch — the source of truth if it is clearly maintained for the active workflow. 2. Current handoff / decision / acceptance note tied to the active branch or incident — strongest operational note when the task is in flight. 3. Previous agent summary that cites exact docs, files, or commands — useful if provenance is explicit. 4. Uncited summary or inferred heuristic — lowest confidence; treat as a lead, not a rule.

Provenance labels

When returning or storing a brief, name the origin:

• canonical-doc
• current-handoff
• decision-log
• agent-summary
• inferred-heuristic

If provenance is weak, say so directly.

Freshness checks

Before trusting a saved note, ask:

• Is it for the current branch or a previous branch?
• Did a release, migration, rollback, or incident change the expected workflow?
• Does the note predate the most recent canonical doc update?
• Does it describe an in-flight temporary exception rather than the stable rule?

Conflict resolution packet

When notes disagree, return the smallest honest answer:

• highest-confidence source
• why it wins
• what still needs verification
• whether to update an existing note or store a new handoff

Good storage pattern

A post-task note should capture:

• which source won
• the branch/release scope
• any temporary exception
• the next verification step

Anti-patterns

• flattening conflicting notes into one blended answer
• treating stale branch notes as universal truth
• presenting an agent summary without naming its source or confidence
• storing another duplicate note when the right move is updating the canonical active-memory doc