# Context Pack > Pack, share, and load context using Epismo context packs. Trigger on: 'pack this', 'new pack', 'get ', 'read ', 'load my context', 'what context do I have', 'restore session', 'save this context', 'share with my team', 'pack this up', 'hand this off', 'publish this guide', 'organize my packs', 'suggest a change to a pack', 'review suggestions', 'resolve a suggestion', or any intent to… - **Type:** Skill - **Install:** `agentstack add skill-epismoai-skills-context-pack` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [epismoai](https://agentstack.voostack.com/s/epismoai) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [epismoai](https://github.com/epismoai) - **Source:** https://github.com/epismoai/skills/tree/main/skills/context-pack - **Website:** https://epismo.ai/hub ## Install ```sh agentstack add skill-epismoai-skills-context-pack ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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](../epismo-basics/SKILL.md). > For sending and resolving improvement suggestions, see [Suggestions](../epismo-basics/references/suggestions.md). > **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](#pack) | | `new` | new pack, start fresh, hand off a task, share project status | [NEW](#new) | | `publish []` | publish this, make this public, publish a guide, share with community | [PUBLISH](#publish) | | `get ` | get this ID, load this ID, restore from ID, read alias, open alias | [GET](#get) | | `find ` | what context do I have, load my context, search | [FIND](#find) | | `update []` | edit this pack, update my last pack | [UPDATE](#update) | | `organize` | reorganize blocks, split this, clean up | [ORGANIZE](#organize) | | `suggest` | suggest a change, propose an edit, review suggestions, resolve a suggestion | [SUGGEST](#suggest) | | — | unclear intent | Ask once | ## Operations | Operation | CLI | | -------------------- | --------------------------------------------------------------------------- | | `search pack` | `epismo pack search --type context [--query ] [--filter '{...}']` | | `get pack` | `epismo pack get [--full] [--block-id ]` | | `create pack` | `epismo pack create --input ''` | | `update pack` | `epismo pack update --input ''` | | `delete pack` | `epismo pack delete ` | | `like pack` | `epismo pack like --liked` | | `upsert alias` | `epismo alias upsert @ --id ` | | `get alias` | `epismo alias get @` | | `list aliases` | `epismo alias list --type context` | | `delete alias` | `epismo alias delete @` | | `create suggestion` | `epismo suggestion create --title --content ` | | `get suggestion` | `epismo suggestion get [--include-snapshot]` | | `list suggestions` | `epismo suggestion list [--owner] [--reference ] [--status ]` | | `update suggestion` | `epismo suggestion update --title --content ` | | `resolve suggestion` | `epismo suggestion resolve --status ` | CLI forms shown; on MCP, derive the tool name mechanically (`pack get` → `epismo_pack_get`). See [surface conventions](../epismo-basics/SKILL.md#surface-conventions). `` is any pack reference — an ID, `@alias`, share URL, or hub URL — resolved server-side. See [Pack References](../epismo-basics/SKILL.md#pack-references-resolving-share-urls). --- ## 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: `, `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](#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": "", "content": "", "blocks": [ { "op": "update", "id": "", "title": "", "content": "" }, { "op": "add", "title": "", "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 block ``` --- ## 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](./templates/content.md). ### 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](#publish) to go public. `create pack`: ```json { "title": "", "content": "", "type": "context", "visibility": "private", "blocks": [ { "title": "", "content": "" }, { "title": "", "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` | Scope / share | | --------------- | ------------ | ------------------------------------------------ | | Just me | `"private"` | `scope: { type: "personal" }` | | My team | `"private"` | `scope: { type: "projects", ids: ["pj_xxx"] }` | | Specific people | `"private"` | any `scope` + `sharedWith: { userIds / emails }` | ``` context block ``` --- ## 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 1. `get pack` — fetch the pack. Run the [Public Review Gate](./references/visibility.md#public-review-gate). Flag issues before proceeding. 2. Confirm with user: **"Publish '{title}' (`{id}`) as public under category `{category}`?"** 3. `update pack`: ```json { "id": "", "visibility": "public", "category": "" } ``` ### Create new public Write for an external reader using the public guide template in [Content Templates](./templates/content.md). Content must be self-contained and pass the [Public Review Gate](./references/visibility.md#public-review-gate). Choose category carefully — it determines how people find this pack. See [Category Reference](./references/visibility.md#category-reference). Confirm with user, then `create pack`: ```json { "title": "", "content": "", "type": "context", "visibility": "public", "category": "" } ``` Return ID, title, and share URL. A share URL can be passed straight back to `pack get` as a `reference`; see [Epismo Basics — Pack References](../epismo-basics/SKILL.md#pack-references-resolving-share-urls). ``` context share https://epismo.ai/hub/contexts/ ``` --- ## 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](#get) | Explicit retrieval | | `find ...`, `search ...`, `what context do I have`, `show my packs` | [FIND](#find) | Explicit discovery | | Bare UUID | [GET](#get) | IDs are unambiguous | | Short ambiguous phrase | [GET](#get) | Try alias first, then search if it misses | | Obvious search query, question, or long descriptive phrase | [FIND](#find) | Discovery intent is clearer than alias intent | ### Resolve the input 1. UUID → `get pack `. 2. `@`, `@/`, or one compact token like `weekly-handoff` → `get pack @`; if it misses, run [FIND](#find) with the same text. 3. Short phrase like `auth refactor handoff` → try `get pack @` first; if it misses, run [FIND](#find). 4. Question, explicit search wording, or long descriptive text → [FIND](#find) first. 5. `get/read/open/use ` 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 private and public scopes for the same topic, then compare results before fetching full content: 1. `type: context`, `query: `, `filter: { visibility: ["private"] }` 2. `type: context`, `query: `, `filter: { visibility: ["public"] }` 3. `type: context`, `query: `, `filter: { like: "liked" }` Present the title list; if the match is clear, `get pack` immediately. For filter keys and search recipes, see [Search & Discovery](./references/search.md). --- ## 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 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 1. `search pack` — `type: context`, `query: `, `filter: { visibility: ["private"] }` 2. **One clear match** → fetch and update without asking. 3. **Multiple candidates** → show titles and IDs, ask the user to pick. 4. **No match** → fall back to [NEW](#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. --- ## SUGGEST **Goal:** propose an improvement to a context pack you don't own, or review and resolve suggestions on a pack you do own. Suggestions are text-first — they never edit the pack directly. Full lifecycle, listing modes, and the CLI/MCP surface are in [Suggestions](../epismo-basics/references/suggestions.md). Decide direction first: | Intent | Action | | --------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Propose a change to someone else's pack | `create suggestion` with the pack reference, a short t … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [epismoai](https://github.com/epismoai) - **Source:** [epismoai/skills](https://github.com/epismoai/skills) - **License:** MIT - **Homepage:** https://epismo.ai/hub Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-epismoai-skills-context-pack - Seller: https://agentstack.voostack.com/s/epismoai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.