Publish Sign in

Data Structure Protocol

Build and navigate DSP (Data Structure Protocol) — graph-based long-term structural memory of codebases for LLM agents, storing entities…

You say
Buy it · $89 Read it before you buy $89 Written by k-kolomeitsev · unverified publisher
Context cost
30.6k tokensestimated from the bundle, loaded when it triggers
Bundle
6 files · 122.2 kB1 script among them — read before you run
Licence
Apache-2.0paid listing
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Build and navigate DSP (Data Structure Protocol) — graph-based long-term structural memory of codebases for LLM agents. Stores entities (modules, functions), their dependencies (imports), public API (shared/exports), and reasons for every connection. Use when: (1) project has a .dsp/ directory, (2) user asks to set up DSP or bootstrap project structure, (3) creating/modifying/deleting code files in a DSP-tracked project, (4) navigating project structure, understanding dependencies, or finding modules, (5) user mentions DSP, dsp-cli, .dsp, or structure mapping.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

memoryknowledge-graphcodebaseprotocol
Filed under

Memory & Knowledge

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md12.4 kB · 183 lines
--- name: data-structure-protocol description: >- Build and navigate DSP (Data Structure Protocol) — graph-based long-term structural memory of codebases for LLM agents. Stores entities (modules, functions), their dependencies (imports), public API (shared/exports), and reasons for every connection. Use when: (1) project has a .dsp/ directory, (2) user asks to set up DSP or bootstrap project structure, (3) creating/modifying/deleting code files in a DSP-tracked project, (4) navigating project structure, understanding dependencies, or finding modules, (5) user mentions DSP, dsp-cli, .dsp, or structure mapping. ---
11# Data Structure Protocol (DSP)
12
13DSP builds a dependency graph of project entities in a .dsp/ directory. Each entity (module, function, external dependency) gets a UID, description, import list, and export index. The graph answers: what exists, why it exists, what depends on what, and who uses what.
14
15**DSP is NOT documentation for humans or AST dump.** It captures _meaning_ (purpose), _boundaries_ (imports/exports), and _reasons for connections_ (why).
16
17## Agent Prompt
18
19Embed this context when working on a DSP-tracked project:
20
21> **This project uses DSP (Data Structure Protocol).**
22> The .dsp/ directory is the entity graph of this project: modules, functions, dependencies, public API. It is your long-term memory of the code structure.
23>
24> **Core rules:**
25>
26> 1. **Before changing code** — find affected entities via dsp-cli search, find-by-source, or read-toc. Read their description and imports to understand context.
27> 2. **When creating a file/module** — call dsp-cli create-object. For each exported function — create-function (with --owner). Register exports via create-shared.
28> 3. **When adding an import** — call dsp-cli add-import with a brief why. For external dependencies — first create-object --kind external if the entity doesn't exist yet.
29> 4. **When removing import / export / file** — call remove-import, remove-shared, remove-entity respectively. Cascade cleanup is automatic.
30> 5. **When renaming/moving a file** — call move-entity. UID does not change.
31> 6. **Don't touch DSP** if only internal implementation changed without affecting purpose or dependencies.
32> 7. **TOC membership** — new entities land in every TOC whose root scope covers their path (or pass --toc explicitly, repeatable). Reshape membership with add-to-toc / move-to-toc.
33> 8. **Bootstrap** — if .dsp/ is empty: discover roots (--new-root --scope), split files into per-TOC batches balanced by volume, then three waves over the batches in parallel — index all files, then all exports, then all imports. Each file is read exactly once (in Wave 1); later waves reuse that read.
34>
35> **Key commands:**
36> ```
37> dsp-cli init
38> dsp-cli create-object <source> <purpose> [--kind external] [--uid UID] [--toc TOC ...] [--new-root [--scope DIR]]
39> dsp-cli create-function <source> <purpose> [--owner UID] [--uid UID] [--toc TOC ...]
40> dsp-cli create-shared <exporter_uid> <shared_uid> [<shared_uid> ...]
41> dsp-cli add-import <importer_uid> <imported_uid> <why> [--exporter UID]
42> dsp-cli add-to-toc <uid> [<uid> ...] --toc TOC [--toc TOC ...]
43> dsp-cli move-to-toc <uid> [<uid> ...] --from TOC --to TOC
44> dsp-cli remove-import <importer_uid> <imported_uid> [--exporter UID]
45> dsp-cli remove-shared <exporter_uid> <shared_uid>
46> dsp-cli remove-entity <uid>
47> dsp-cli move-entity <uid> <new_source>
48> dsp-cli update-description <uid> [--source S] [--purpose P] [--kind K] [--scope DIR]
49> dsp-cli get-entity <uid>
50> dsp-cli get-children <uid> [--depth N]
51> dsp-cli get-parents <uid> [--depth N]
52> dsp-cli search <query>
53> dsp-cli find-by-source <path>
54> dsp-cli read-toc [--toc ROOT_UID]
55> dsp-cli get-stats
56> ```
57>
58> TOC is a root UID or the literal default (the plain .dsp/TOC file).
59
60## Using the CLI
61
62The script is at scripts/dsp-cli.py relative to this skill directory.
63
64```
65python <skill-path>/scripts/dsp-cli.py [--root <project-root>] <command> [args]
66```
67
68--root defaults to current working directory. All paths in arguments are repo-relative.
69
70## Core Concepts
71
72- **Code = graph.** Nodes are Objects and Functions. Edges are imports and shared/exports.
73- **Identity by UID, not file path.** Path is an attribute; renames/moves don't change UID.
74- **"Shared" creates an entity.** If something becomes public (exported), it gets its own UID.
75- **Import tracks both "from where" and "what".** One code import may create two DSP links: to the module and to the specific shared entity.
76- **Full import coverage.** Every imported file/asset must be an Object in .dsp — code, images, styles, configs, everything.
77- **why lives next to the imported entity** in its exports/ directory (reverse index).
78- **Start from roots.** Each root entrypoint has its own TOC file. A root may declare a scope (directory subtree); new entities are auto-assigned to every TOC whose root scope covers their path.
79- **External deps — record only.** kind: external, no deep dive into node_modules/site-packages/etc. But exports index works — shows who imports it.
80- **Persistent reverse-index cache.** .dsp/.cache/ holds the reverse adjacency (imported → importers), one file per imported entity. It makes reverse and traversal commands (get-recipients, get-parents, get-path, and get-entity's "exported to") fast on large graphs without re-scanning. Local and forward commands (get-children, get-shared, read-toc, find-by-source, search) read live files and never touch it. Mutating commands keep it up to date incrementally (only the affected entries), so it stays correct as you build the graph.
81 - **Auto-build.** If the cache is missing, the next reverse/traversal command — or the next reverse-affecting mutation — builds it automatically. No manual step is needed in normal use.
82 - **It is committed with the graph** (not git-ignored): a plain git checkout/pull moves the cache together with .dsp/. Caveat: a merge/rebase that touches .dsp/ can merge .cache/ files incorrectly or leave conflicts — the cache is not self-validating (it tracks only a sentinel, not content), so run rebuild-cache afterwards to be safe.
83 - **rebuild-cache.** Run python <skill-path>/scripts/dsp-cli.py rebuild-cache if .dsp/ was changed **outside** this CLI — hand-edited files, or a merge/rebase that touched .dsp/. Agents that follow the protocol mutate .dsp/ solely through dsp-cli, so during normal work this is rarely needed.
84
85## UID Format
86
87- Objects: obj-<8 hex> (e.g., obj-a1b2c3d4)
88- Functions: func-<8 hex> (e.g., func-7f3a9c12)
89
90UID marker in source code — comment @dsp <uid> before declaration:
91
92```js
93// @dsp func-7f3a9c12
94export function calculateTotal(items) { ... }
95```
96
97```python
98# @dsp obj-e5f6g7h8
99class UserService:
100```
101
102## Workflows
103
104### Setting Up DSP (bootstrap in 3 waves)
105
106Core economy rule: **each file is read exactly once, by exactly one subagent** — all three waves run on top of that single read. Batches run in parallel; the only sync point is the barrier before Wave 3.
107
1081. Run dsp-cli init to create .dsp/ directory.
1092. **Phase 0 — roots**: identify entrypoint(s) and their directory scopes, create each with create-object <path> <purpose> --new-root --scope <dir> (. = whole repo). Scopes make TOC assignment automatic for everything that follows.
1103. **Inventory & batching**: list all project files with sizes (e.g. git ls-files | xargs wc -c; skip vendored code, build output, lock files). Group by TOC, split each group into batches of roughly equal volume — one batch per subagent, dispatched in parallel.
1114. **Wave 1 — all files**: each subagent reads each file of its batch **once** (capturing purpose, entities, exports, imports with usage sites) and registers it: create-object + create-function --owner for significant inner entities, @dsp markers in source.
1125. **Wave 2 — all exports**: same subagent, no re-reading — create-shared per file (batch-local, no waiting on other batches).
1136. **Barrier**: when ALL batches finish Waves 1–2, subagents report their externals; the orchestrator dedupes and registers each once (create-object --kind external + add-to-toc for other roots using it).
1147. **Wave 3 — all imports**: same subagent, still no re-reading — add-import with usage-based why (dead imports were already filtered at the Wave 1 read); targets resolve via find-by-source.
1158. Verify: get-stats, get-orphans, detect-cycles; every inventory file resolves via find-by-source. Details: [bootstrap.md](references/bootstrap.md).
116
117Re-indexing a project whose code already has @dsp markers: pass the old UIDs via --uid at every create step — the graph is rebuilt with stable identity.
118
119### Creating Entities (when writing new code)
120
1211. Create module: dsp-cli create-object <path> <purpose> — it lands in every TOC whose root scope covers the path (override with --toc <TOC>, repeatable)
1222. Create functions: dsp-cli create-function <path>#<symbol> <purpose> --owner <module-uid>
1233. Register exports: dsp-cli create-shared <module-uid> <func-uid> [<func-uid> ...] — shared entries are UIDs of existing entities, never export names
1244. Register imports: dsp-cli add-import <this-uid> <imported-uid> <why> [--exporter <module-uid>] — all UIDs must already exist
1255. External deps: dsp-cli create-object <package-name> <purpose> --kind external
126
127### Navigating the Graph (when reading/understanding code)
128
129- **Find entity by file**: dsp-cli find-by-source <path>
130- **Search by keyword**: dsp-cli search <query>
131- **Read TOC**: dsp-cli read-toc → get all UIDs, then get-entity for details
132- **Dependency tree down**: dsp-cli get-children <uid> --depth N
133- **Dependency tree up**: dsp-cli get-parents <uid> --depth N
134- **Impact analysis**: dsp-cli get-recipients <uid> — who depends on this entity
135- **Path between entities**: dsp-cli get-path <from> <to>
136
137### Updating (when modifying code)
138
139- Purpose changed: dsp-cli update-description <uid> --purpose <new>
140- File moved: dsp-cli move-entity <uid> <new-path>
141- Import reason changed: dsp-cli update-import-why <importer> <imported> <new-why>
142- Root's zone changed: dsp-cli update-description <root-uid> --scope <dir>
143
144### Managing TOC membership
145
146- Add existing entities to more TOCs: dsp-cli add-to-toc <uid> [<uid> ...] --toc <TOC> (idempotent; e.g. an external used by a second root)
147- Transfer entities between TOCs (single or batch): dsp-cli move-to-toc <uid> [<uid> ...] --from <TOC> --to <TOC> — all-or-nothing; a root cannot leave its own TOC
148- <TOC> is a root UID or default
149
150### Deleting (when removing code)
151
152- Import removed: dsp-cli remove-import <importer> <imported> [--exporter UID]
153- Export removed: dsp-cli remove-shared <exporter> <shared>
154- File/module deleted: dsp-cli remove-entity <uid> (cascading cleanup)
155
156### Diagnostics
157
158- dsp-cli detect-cycles [--toc ROOT_UID] — circular dependencies (--toc scopes to one TOC root's entities)
159- dsp-cli get-orphans [--toc ROOT_UID] — unused entities (--toc scopes to one TOC root's entities)
160- dsp-cli get-stats [--toc ROOT_UID] — project graph overview (--toc scopes to one TOC root's entities)
161
162## When to Update DSP
163
164| Code Change | DSP Action |
165|---|---|
166| New file/module | create-object + create-function + create-shared + add-import |
167| New import added | add-import (+ create-object --kind external if new external dep) |
168| Import removed | remove-import |
169| Export added | create-shared (+ create-function if new function) |
170| Export removed | remove-shared |
171| File renamed/moved | move-entity |
172| File deleted | remove-entity |
173| Purpose changed | update-description |
174| Module moved to another subproject/root | move-to-toc (+ move-entity if the path changed) |
175| Entity now used by another root | add-to-toc |
176| Internal-only change | **No DSP update needed** |
177
178## References
179
180- **[Storage format](references/storage-format.md)** — .dsp/ directory structure, file formats, TOC
181- **[Bootstrap procedure](references/bootstrap.md)** — initial project markup (3-wave algorithm)
182- **[Operations reference](references/operations.md)** — detailed semantics of all operations with import examples
183
In the file
SKILL.md1,760 words
Files6
LicenceApache-2.0
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈160
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
30,390
on trigger
The instruction body and 5 supporting files, read only when the skill fires.
15.3%
of a 200k window
Ten skills this size would take about 153% of the window before you open a file.
050k100k150k200k context window

30.6k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Heavy. Teams tend to install this one per project rather than globally, and load it only when the job comes up.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

6 files, 122.2 kB on disk. Mostly text — the instructions the model reads — with 1 script in it that your client would run only if the instructions tell it to.

  • SKILL.md12.4 kB
  • dsp-tool-config.json15.2 kB
  • references/bootstrap.md11.6 kB
  • references/operations.md13.3 kB
  • references/storage-format.md6.5 kB
  • scripts/dsp-cli.py63.2 kB
What is not in it

A skill installs nothing and depends on nothing: it is a folder your client reads. This one carries 1 script beside the text, so the bundle is 6 files you can review in full before installing. The Apache-2.0 licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$89 once
Data Structure Protocol · Apache-2.0 · k-kolomeitsev
one-time
Price$89 once
LicenceApache-2.0 — the author’s, unchanged by this purchase
Paid throughStripe, once, on the card you add at the checkout
Keeps workingfor good — the files are yours once they are on disk
Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are Apache-2.0, set by the author and unchanged by buying it here.

Sign in to buyCreate an account

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
Price$89
Referencek-kolomeitsev/data-structure-protocol

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

KK
k-kolomeitsev

Publishes on mcprush.

0 servers listed1 skill listednot claimed
Profile
Publisher
Servers0