Context Pack

Store and retrieve context through Epismo context packs — so knowledge survives tool switches, session ends, and team handoffs.

The unit of organization is a block inside a pack. The goal is one well-structured pack per topic, grown over time by adding and refining blocks — not many small packs.

For Epismo connection setup, CLI/MCP surface conventions, scope model, share URL resolution, and error handling, see Epismo Basics.

Surface selection: CLI and MCP connect to the same Epismo service. Use CLI if available; fall back to MCP if not. Never use both in the same session.

Commands

Command	Natural language triggers	→
`pack`	pack this, save this, summarize session	PACK
`new`	new pack, start fresh, hand off a task, share project status	NEW
`publish [<id>]`	publish this, make this public, publish a guide, share with community	PUBLISH
`get <id\|alias>`	get this ID, load this ID, restore from ID, read alias, open alias	GET
`find <query>`	what context do I have, load my context, search	FIND
`update [<id\|alias>]`	edit this pack, update my last pack	UPDATE
`organize`	reorganize blocks, split this, clean up	ORGANIZE
—	unclear intent	Ask once

Operations (context packs)

Operation	CLI	MCP
`search pack`	`epismo pack search --type context [--query <keywords>] [--filter '{...}']`	`epismo_pack_search`
`get pack`	`epismo pack get --id <id> [--full] [--block-id <id>]` <br> `epismo pack get --alias <alias>`	`epismo_pack_get`
`create pack`	`epismo pack create --input '<json>'`	`epismo_pack_create`
`update pack`	`epismo pack update --id <id> --input '<json>'`	`epismo_pack_update`
`delete pack`	`epismo pack delete --id <id>`	`epismo_pack_delete`
`like pack`	`epismo pack like --id <id> --liked`	`epismo_pack_like`
`upsert alias`	`epismo alias upsert --type context --id <id> --alias <name>`	—
`get alias`	`epismo alias get --alias <name>`	—
`list aliases`	`epismo alias list --type context`	—
`delete alias`	`epismo alias delete --alias <name>`	—

PACK

Goal: save current context as a block inside the right pack. Find an existing pack and add or refine a block; create a new pack only when nothing relevant exists.

Step 1 — Find the right pack

Infer 2–4 topic keywords from the current session. Search private packs (titles only — one fast call).

search pack

—

type: context

query: <inferred topic>

filter: { visibility: ["private"] }

Result	Action
One clear match	Fetch it → add or update a block → upsert
Multiple candidates	Show titles and IDs → ask user to pick
No match	Proceed as NEW

Step 2 — Identify the right block

get pack

— fetch the pack and read its existing blocks. Decide:

Update an existing block — if the new content belongs to a block that already exists (e.g., decisions, next steps), integrate it there. Rewrite the block so it reads as a coherent whole, not as an append.
Add a new block — if the new content is a distinct topic not covered by any existing block.

The pack should read well from scratch at any point. Do not leave stale or contradicted information in place.

Step 3 — Update and return

update pack

json

{
  "id": "<existing-id>",
  "content": "<top-level summary or intro — does not include block content>",
  "blocks": [
    { "op": "update", "id": "<existing-block-id>", "title": "<block-title>", "content": "<updated block content>" },
    { "op": "add", "title": "<new-block-title>", "content": "<new block content>" }
  ]
}

Omitted fields are left unchanged. Omitting
```
"blocks"
```
means no block changes.
```
"op": "update"
```
updates an existing block by ID.
```
"op": "add"
```
adds a new block.
```
"op": "remove"
```
deletes a block by ID (only
```
"id"
```
needed).
```
"content"
```
at the top level is a brief intro or summary. Block content lives in
```
"blocks[]"
```
, not in the top-level
```
"content"
```
.

context  <context-id>  <context-title>
block    <block-id>    <block-title>

NEW

Goal: create a fresh pack with an initial block structure. Use when no relevant pack exists, or when the content is clearly a separate topic.

Step 1 — Design the block structure

Before writing, decide how the content divides into blocks. Each block should be focused enough to update independently and broad enough to stay relevant over time.

Design for selective fetch. Because blocks can be loaded individually with

--block-id

, a well-split pack lets future sessions load only what they need without pulling the whole pack. Aim for blocks where any one block answers a distinct question on its own.

Use case	Starting blocks
Session / tool handoff	Context, Decisions, Next Steps
Source summary (YouTube, blog, paper)	Source, Summary, Key Takeaways, Reuse Notes
Project memory / working context	Purpose, Constraints, Decisions, References
Prompt or instruction pack	When To Use This, Inputs, Instructions, Output Expectations
Project status	Summary, Progress, Blockers
Team rules or plan	Purpose, Rules, Plan
Task handoff	Current State, What Remains, Context for Recipient

Good block boundaries: topic changes, audience changes, or update frequency changes (e.g., "Decisions" is stable; "Next Steps" changes every session — keep them separate).

For templates, see Content Templates.

Step 2 — Write

Content rules:

Each block is self-contained — no "see above" references
Prefer scannable structure: bullets, short paragraphs, and small tables only when they help
Include IDs, URLs, and precise names so the reader can act without searching
Title: infer from session topic. Do not ask unless genuinely ambiguous.

Step 3 — Publish

Default

private

. Use PUBLISH to go public.

create pack

json

{
  "title": "<title>",
  "content": "<top-level summary or intro>",
  "type": "context",
  "visibility": "private",
  "blocks": [
    { "title": "<block-title>", "content": "<block content>" },
    { "title": "<block-title>", "content": "<block content>" }
  ]
}

Blocks are passed as a separate
```
"blocks[]"
```
array — not embedded in the top-level
```
"content"
```
string.
```
"content"
```
at the top level is a brief intro only. All substantive content belongs in blocks.

Who needs it	`visibility`	Access target
Just me	`"private"`	omit `targets`
My team	`"private"`	`targets.projectIds=["pj_xxx"]`

context  <context-id>  <context-title>
block    <block-id>    <block-title>

PUBLISH

Goal: make a pack publicly discoverable. Always requires explicit user confirmation before writing.

Two paths:

Situation	Path
Existing private pack worth sharing	Promote — change visibility to `public`
New content written for a broad audience	Create new public pack

Promote: private → public

```
get pack
```
— fetch the pack. Run the Public Review Gate. Flag issues before proceeding.
Confirm with user: "Publish '{title}' (
{id}
) as public under category
{category}
?"
```
update pack
```
:

json

{
  "id": "<id>",
  "visibility": "public",
  "category": "<category>"
}

Create new public

Write for an external reader using the public guide template in Content Templates. Content must be self-contained and pass the Public Review Gate.

Choose category carefully — it determines how people find this pack. See Category Reference.

Confirm with user, then

create pack

json

{
  "title": "<title>",
  "content": "<content>",
  "type": "context",
  "visibility": "public",
  "category": "<category>"
}

Return ID, title, and share URL. For share URL resolution, see Epismo Basics — Resolving Share URLs.

context  <context-id>  <context-title>
share    https://epismo.ai/hub/contexts/<id>

GET

Goal: fetch a pack by ID, alias, or explicit read/open target.

Route intent before resolving

Prefer alias-first unless the input is obviously a search query.

Input pattern	Route	Why
`get ...` , `use ...` , `load ...` , `open ...` , `read ...` , `restore ...`	GET	Explicit retrieval
`find ...` , `search ...` , `what context do I have` , `show my packs`	FIND	Explicit discovery
Bare UUID	GET	IDs are unambiguous
Short ambiguous phrase	GET	Try alias first, then search if it misses
Obvious search query, question, or long descriptive phrase	FIND	Discovery intent is clearer than alias intent

Resolve the input

UUID →
```
get pack --id
```
.
```
@handle/name
```
or one compact token like
```
weekly-handoff
```
→
```
get pack --alias
```
; if it misses, run FIND with the same text.
Short phrase like
```
auth refactor handoff
```
→ try
```
get pack --alias
```
first; if it misses, run FIND.
Question, explicit search wording, or long descriptive text → FIND first.
```
get/read/open/use <target>
```
always counts as retrieval intent.

get pack

— by

id

, or by

alias

. Default returns outline only; pass

--full

for all blocks, or

--block-id

to load a single block.

Read the most relevant block first. Continue from there without re-reading history.

FIND

Goal: discover the right pack when the ID is not known.

search pack

— scan titles only (no full content). Use this for natural-language discovery requests and multi-keyword topic phrases. Search in this order:

type: context

query: <topic>

filter: { visibility: ["private"] }

type: context

query: <topic>

filter: { like: "liked" }

type: context

query: <topic>

filter: { visibility: ["public"] }

Present the title list; if the match is clear,

get pack

immediately.

For filter keys and search recipes, see Search & Discovery.

UPDATE

Goal: edit an existing pack directly.

ID or alias known

Always fetch before writing.

get pack

→ inspect current blocks →

update pack

with

id

and block operations using

op

fields.

For

update <alias> based on this conversation

merge new context into the right existing blocks
rewrite blocks coherently instead of appending raw notes
add a new block only for a distinct new topic

ID unknown

search pack

—

type: context

query: <inferred topic>

filter: { visibility: ["private"] }

One clear match → fetch and update without asking.
Multiple candidates → show titles and IDs, ask the user to pick.
No match → fall back to NEW.

"Last pack" shortcut: search private context packs and take the first result from the default recent-first outline.

ORGANIZE

Goal: improve the block structure of an existing pack.

The most common need is not managing many packs — it's making the blocks inside one pack cleaner and more useful.

Actions

Situation	Action
A block has grown too large or covers multiple topics	Split — divide into two focused blocks, rewrite each
Two blocks overlap or one has become redundant	Merge — combine into one coherent block, remove the other
A block is no longer relevant	Remove — delete the block from the pack
The whole pack is no longer needed	Delete — delete the pack (needs approval)

All changes are applied via

update pack

using

op

fields. Use

"op": "add"

for new blocks,

"op": "update"

for existing ones,

"op": "remove"

to delete a block by ID.

delete pack

requires explicit user approval.

Write Safety

Default private —
```
pack
```
,
```
new
```
, and
```
update
```
always write private. Use PUBLISH to go public.
No silent writes — if scope is unclear, ask once before writing.
Approval required — public publication, deletion, and overwriting another owner's pack require explicit user confirmation before writing.

For the full approval matrix, see Visibility & Sharing — Approval Boundary.

Operation Output

After every operation, return in this order:

Context and block — always return both ID and title at each level that was affected
What changed — one sentence
Next action — single most useful next step (omit if none)

context  <context-id>  <context-title>
block    <block-id>    <block-title>    # when a specific block was created or updated

Skip analysis and evidence unless the user asked for it.

Source of Truth

Repository:

https://github.com/epismoai/skills

context-pack

NPX Install

Tags

SKILL.md Content

Context Pack

Commands

Operations (context packs)

PACK

Step 1 — Find the right pack

Step 2 — Identify the right block

Step 3 — Update and return

NEW

Step 1 — Design the block structure

Step 2 — Write

Step 3 — Publish

PUBLISH

Promote: private → public

Create new public

GET

Route intent before resolving

Resolve the input

FIND

UPDATE

ID or alias known

ID unknown

ORGANIZE

Actions

Write Safety

Operation Output

Source of Truth