Claude Skill

cdb-scan

Map this codebase into project memory — a code graph of every symbol and how they connect, plus a written profile of stack, layout, conventions and workflows. Re-run any time to refresh both in place. Use when memory is newly installed on an existing project, or when the project

LLM Mart · 0 points · 11 views 32 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download avijit07x-claude-db-skills_cdb-scan-6f2fc33.zip · 2 KB

Install

skills CLI npx skills add https://github.com/Avijit07x/claude-db/tree/main/skills/cdb-scan
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install avijit07x-claude-db@llmmart
Git git clone https://github.com/Avijit07x/claude-db.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole avijit07x/claude-db collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Map this project into memory

Everything else in claude-db's memory is testimony: it records what happened, turn by turn, as it happened. A fresh install knows none of that, and stays useless for weeks while it fills up.

This fills the gap from the one source available on day one — the code itself, in two passes.

Pass 1 — the code graph

Run this first, from the project root:

claude-db scan

It parses every supported source file and stores each symbol and each relationship between them: what calls what, what imports what, what extends what. It is deterministic, costs no tokens, and takes seconds. Report the symbol and edge counts it prints.

Once it has run, find_usages answers structural questions from the graph:

  • mode: "usages" — what references this symbol, with the relation on each line
  • mode: "explain" — that, plus what the symbol itself reaches
  • mode: "path" with target — how two symbols connect

Prefer those over reading files when the question is about structure.

Pass 2 — the written profile

The graph records what the code is. It cannot say why the project is built this way, so the sections below capture that in prose. What you write here is your reading of the codebase, not a record of events, so it is tagged inferred and must never be phrased as history.

Work through the sections below in order. For each one, look at the actual files, then call the remember MCP tool once with the given key.

key is what makes this re-runnable: writing the same key again replaces that note rather than adding a second copy. Use these exact keys, and always pass tags: ["inferred"] and kind: "context".

Before you start, call search for profile in this project. If notes already exist, read them first and update what changed rather than restating it — a second run should be an edit, not a rewrite.

1. profile:stack

Languages, runtime and version floors, frameworks, package manager, database, test runner, build tool. Read the manifest (package.json, pyproject.toml, go.mod, Cargo.toml) and the lockfile rather than guessing. Name versions where a version constrains what can be written.

2. profile:layout

The directory map, one line each, and what lives where. Include the entry points: the binary, the server, the main export. Skip anything generated.

3. profile:conventions

How this codebase is written, taken from the code and not from a style guide: module system, import style, error handling, naming, comment density, how tests are structured. Note where the project deviates from the language default, since that is what someone would otherwise get wrong.

4. profile:workflows

The commands that matter — install, build, test, lint, run, release — and anything non-obvious about running them: a required service, an environment variable, a step that must come first. Take them from the manifest scripts and CI config, not from the README's aspirations.

5. profile:architecture

Only the parts a newcomer could not infer from the layout: the main abstractions and how a request or a command actually flows through them. Two paragraphs at most. If the codebase is small enough that the layout says it all, skip this section rather than padding it.

Rules

  • One remember call per section. Five notes, five stable keys.
  • Write claims, not headings. "Storage is one MemoryStore interface with three adapters, selected by URI scheme" — not "Storage architecture".
  • Say what you verified. If something was not read, leave it out. An inferred profile that is confidently wrong is worse than a short one.
  • Never restate CLAUDE.md. That file is already in the system prompt on every turn. Memory is for what is not.
  • Do not record secrets, credentials or personal data, even if the code contains them.
Files (claude-db)
  • SKILL.md 4.2 KB
    ---
    name: cdb-scan
    description: Map this codebase into project memory — a code graph of every symbol and how they connect, plus a written profile of stack, layout, conventions and workflows. Re-run any time to refresh both in place. Use when memory is newly installed on an existing project, or when the project has changed enough that the stored map is stale.
    ---
    
    # Map this project into memory
    
    Everything else in claude-db's memory is testimony: it records what happened,
    turn by turn, as it happened. A fresh install knows none of that, and stays
    useless for weeks while it fills up.
    
    This fills the gap from the one source available on day one — the code itself,
    in two passes.
    
    ## Pass 1 — the code graph
    
    Run this first, from the project root:
    
    ```bash
    claude-db scan
    ```
    
    It parses every supported source file and stores each symbol and each
    relationship between them: what calls what, what imports what, what extends
    what. It is deterministic, costs no tokens, and takes seconds. Report the
    symbol and edge counts it prints.
    
    Once it has run, `find_usages` answers structural questions from the graph:
    
    - `mode: "usages"` — what references this symbol, with the relation on each line
    - `mode: "explain"` — that, plus what the symbol itself reaches
    - `mode: "path"` with `target` — how two symbols connect
    
    Prefer those over reading files when the question is about structure.
    
    ## Pass 2 — the written profile
    
    The graph records what the code _is_. It cannot say why the project is built
    this way, so the sections below capture that in prose. What you write here is
    **your reading of the codebase, not a record of events**, so it is tagged
    `inferred` and must never be phrased as history.
    
    Work through the sections below in order. For each one, look at the actual
    files, then call the `remember` MCP tool once with the given `key`.
    
    `key` is what makes this re-runnable: writing the same key again replaces that
    note rather than adding a second copy. Use these exact keys, and always pass
    `tags: ["inferred"]` and `kind: "context"`.
    
    Before you start, call `search` for `profile` in this project. If notes already
    exist, read them first and update what changed rather than restating it — a
    second run should be an edit, not a rewrite.
    
    ### 1. `profile:stack`
    
    Languages, runtime and version floors, frameworks, package manager, database,
    test runner, build tool. Read the manifest (`package.json`, `pyproject.toml`,
    `go.mod`, `Cargo.toml`) and the lockfile rather than guessing. Name versions
    where a version constrains what can be written.
    
    ### 2. `profile:layout`
    
    The directory map, one line each, and what lives where. Include the entry
    points: the binary, the server, the main export. Skip anything generated.
    
    ### 3. `profile:conventions`
    
    How this codebase is written, taken from the code and not from a style guide:
    module system, import style, error handling, naming, comment density, how
    tests are structured. Note where the project deviates from the language default,
    since that is what someone would otherwise get wrong.
    
    ### 4. `profile:workflows`
    
    The commands that matter — install, build, test, lint, run, release — and
    anything non-obvious about running them: a required service, an environment
    variable, a step that must come first. Take them from the manifest scripts and
    CI config, not from the README's aspirations.
    
    ### 5. `profile:architecture`
    
    Only the parts a newcomer could not infer from the layout: the main
    abstractions and how a request or a command actually flows through them. Two
    paragraphs at most. If the codebase is small enough that the layout says it
    all, skip this section rather than padding it.
    
    ## Rules
    
    - **One `remember` call per section.** Five notes, five stable keys.
    - **Write claims, not headings.** "Storage is one `MemoryStore` interface with
      three adapters, selected by URI scheme" — not "Storage architecture".
    - **Say what you verified.** If something was not read, leave it out. An
      inferred profile that is confidently wrong is worse than a short one.
    - **Never restate `CLAUDE.md`.** That file is already in the system prompt on
      every turn. Memory is for what is not.
    - **Do not record secrets, credentials or personal data**, even if the code
      contains them.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related