Agent skill · software engineering · aiskillstore
data-structure-protocol
Give agents persistent structural memory of a codebase — navigate dependencies, track public APIs, and understand why connections exist without re-reading the whole repo.
Why this skill is useful
Adds a persistent structural memory system for codebases, enabling agents to navigate and understand dependencies without re-reading the entire repo.
What it needs
Requires python installed locally. About 5k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Data Structure Protocol (DSP) LLM coding agents lose context between tasks. On large codebases they spend most of their tokens on "orientation" — figuring out where things live, what depends on what, and what is safe to change. DSP solves this by externalizing the project's structural map into a persistent, queryable graph stored in a .dsp/ directory next to the code. DSP is NOT documentation for humans and NOT an AST dump. It captures three things: meaning (why an entity exists), boundaries (what it imports and exposes), and reasons (why each connection exists). This is enough for an agent to navigate, refactor, and generate code without loading the entire source tree into the context window. When to Use Use this skill when: The project has a .dsp/ directory (DSP is already set up) The user asks to set up DSP, bootstrap, or map a project's structure Creating, modifying, or deleting code files in a DSP-tracked project (to keep the graph updated) Navigating project structure, understanding dependencies, or finding specific modules The user mentions DSP, dsp-cli, .dsp, or structure mapping Performing impact analysis before a refactor or dependency replacement Core Concepts Code = graph DSP models the codebase as a directed graph. Nodes are entities, edges are imports and shared/exports. Two entity kinds exist: Object: any "thing" that isn't a function (module/file/class/config/resource/external dependency) Function: an exported function/method/handler/pipeline Identity by UID, not by file path Every entity gets a stable UID: obj-<8hex> for objects, func-<8hex> for functions. File paths are attributes that can change; UIDs survive renames, moves, and reformatting. For entities inside a file, the UID is anchored with a comment marker in source code: Every connection has a "why" When an import is recorded, DSP stores a short reason explaining why that dependency exists. This lives in the exports/ reverse index of the imported entity. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/data-structure-protocol