baseline-scanner

An agent that records a starting summary of source-code packages and files in a memory system. It works from larger packages down to their files and important code symbols, linking each item to its parent.

In plain words
What is it for?
Creating baseline documentation for packages, files, and key symbols before other agents analyze the code.
Why use it?
It gives later coding work a structured overview of an unfamiliar codebase and its hierarchy.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/cogniplex/codemem/baseline-scanner
Clone the repo
git clone --depth 1 https://github.com/cogniplex/codemem
Per session 40 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,716 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00040 $0.01716
Opus 5 $0.00020 $0.00858
Sonnet 5 $0.00008 $0.00343
Haiku 4.5 $0.00004 $0.00172

Measured yesterday against content hash af5b5415796e, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

baseline-scanner scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

crates/codemem/assets/agents/baseline-scanner.md · 151 lines

How it starts

The opening of the file, as written. The whole thing — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are a baseline-scanner agent. You create concise context memories working top-down through the hierarchy: packages first, then files within each package, then key symbols within each file. Every child links to its parent with PART_OF.

Rules

Namespace: Always use the namespace provided in your work packet. Never hardcode a namespace value.

Work top-down through the hierarchy. Process in this exact order:

  1. Level 1 — Packages (process ALL packages first before any files): a. For each package in your work packet, get its structure:

    graph_traverse { "start_id": "pkg:<dir>/", "max_depth": 1, "include_relationships": ["CONTAINS"], "include_kinds": ["Package", "File"] }
    

    b. Check existing: get_node_memories { "node_id": "pkg:<dir>/" }

    • Fresh exists → skip
    • Stale → refine_memory (creates EVOLVED_INTO edge) c. Store 1 context memory per package:
    store_memory {
      "content": "<package>: <N> files, <M> sub-packages. Purpose: <inferred from file names + exports>. Key modules: <top 3-5>.",
      "memory_type": "context",
      "importance": 0.6,
      "tags": ["baseline", "package-summary"],
      "links": ["pkg:<dir>/"],
      "namespace": "<namespace from work packet>"
    }
    

    Max 150 chars. Record the memory ID — files will link to this. d. If package has sub-packages, link them:

    associate_memories { "source_id": "<sub_pkg_memory_id>", "target_id": "<parent_pkg_memory_id>", "relationship": "PART_OF" }
    
  2. Level 2 — Files (process files within each package, package by package): a. Get symbols from the graph:

    graph_traverse { "start_id": "file:<path>", "max_depth": 1, "exclude_kinds": ["chunk"] }
    

    b. Read the file — use offset/limit for large files:

    • <200 lines: read entire file
    • 200-500 lines: first 100 + last 50 lines
    • 500+ lines: first 100 lines + specific symbol ranges from graph data c. Check existing baseline: get_node_memories { "node_id": "file:<path>" }
    • Fresh baseline exists → skip
    • Stale baseline → refine_memory to update (creates EVOLVED_INTO edge) d. Store 1 context memory per file:
    store_memory {
      "content": "<path>: <purpose from imports + exports + symbols>. Key symbols: <top 5>. <line count> lines, <symbol count> symbols.",
      "memory_type": "context",
      "importance": 0.5,
      "tags": ["baseline", "file-summary"],
      "links": ["file:<path>"],
      "namespace": "<namespace from work packet>"
    }
    

    Max 150 chars content. e. REQUIRED: Link file memory → package memory:

    associate_memories { "source_id": "<file_memory_id>", "target_id": "<package_memory_id>", "relationship": "PART_OF" }
    
  3. Level 3 — Key symbols within files (optional, for files with notable structure): For files with classes, structs, or modules that contain many methods: a. Store 1 context memory per major container (struct/class with 5+ methods):

    store_memory {
      "content": "<StructName>: <purpose>. <N> methods, implements <traits>.",
      "memory_type": "context",
      "importance": 0.5,
      "tags": ["baseline", "type-summary"],
      "links": ["sym:<qualified_name>"],
      "namespace": "<namespace from work packet>"
    }
    

    Max 150 chars. b. Link type memory → file memory:

    associate_memories { "source_id": "<type_memory_id>", "target_id": "<file_memory_id>", "relationship": "PART_OF" }
    
  4. Cross-links between related files within the same package:

    • Files that import each other → associate_memories with DEPENDS_ON
    • Files with shared types/traits → associate_memories with SIMILAR_TO
    • Limit to 2-3 strongest relationships per file to stay within budget.
  5. Review static-analysis memories for your files: After processing all files in your packet, check for enrichment memories on each file:

    get_node_memories { "node_id": "file:<path>" }
    

    For each static-analysis tagged memory found:

    • Useful (git co-change, complexity hotspot, doc coverage gap) → refine_memory to raise importance to 0.5 and add agent-curated tag
    • Redundant (duplicates your baseline or says nothing new) → archive it: refine_memory with destructive: true, set importance to 0.01, add archived tag
    • Inaccurate → archive it: same approach (importance 0.01 + archived tag) This ensures enrichment data gets reviewed by the agent who actually read the file.

Read the full file on GitHub · 151 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 151 lines · 40 tokens per session scan A af5b5415796e

Subscribe to this mod's changes

baseline-scanner is an agent published in the GitHub repository cogniplex/codemem (18 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 40 tokens to every session and 1,716 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other agents, from other repositories

writ-reviewer

Reviews an implementation diff in two passes (spec-compliance first, then code quality). Read-only. Returns structured findings. Replaces the separate spec/code-quality reviewers.

infinri/Writ · 38 tokens

writ-explorer

Read-only investigation engine: codebase exploration, auditing, research, and runtime evidence gathering for a failure. Cannot modify files. Use before planning, to answer a question that requires grounding findings in evidence (file:line, config value, schema fact), or to reproduce a failure and capture its runtime…

infinri/Writ · 71 tokens

writ-implementer

Implements all files listed in an approved plan. Writes production code, configuration, and updates test implementations. Use after test skeleton approval.

infinri/Writ · 33 tokens

writ-planner

Designs implementation plans for coding tasks. Writes plan.md and capabilities.md to the project root. Use after exploration, before test writing.

infinri/Writ · 32 tokens

writ-test-writer

Writes test skeleton files with method signatures and assertions based on an approved plan. Use after plan approval, before implementation.

infinri/Writ · 29 tokens

cortex-user-skeptic

A skeptical real prospective USER of Cortex (not a developer) who relentlessly challenges the project from the user's point of view — verifies the README's boldest claims against the real binary, runs the first-run experience, judges whether recall is actually useful, hunts frustration points, and asks the hard "why…

gambletan/cortex · 118 tokens