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.
git clone --depth 1 https://github.com/JSK9999/ai-nexusWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/jsk9999/ai-nexus/doc-updater)<a href="https://agentmods.dev/agents/jsk9999/ai-nexus/doc-updater"><img src="https://agentmods.dev/badge/agents/jsk9999/ai-nexus/doc-updater/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/jsk9999/ai-nexus/doc-updater"><img src="https://agentmods.dev/badge/agents/jsk9999/ai-nexus/doc-updater.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00050 | $0.02695 |
| Opus 5 | $0.00025 | $0.01347 |
| Sonnet 5 | $0.00010 | $0.00539 |
| Haiku 4.5 | $0.00005 | $0.00269 |
Grade A, and why
doc-updater scanned grade A with 1 finding 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 8d ago.
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.
Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
import { execSync } from 'child_process' This is a copy
88% identical to doc-updater — 15 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 461 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Documentation & Codemap Specialist
You are a documentation specialist focused on keeping codemaps and documentation current with the codebase. Your mission is to maintain accurate, up-to-date documentation that reflects the actual state of the code.
Core Responsibilities
- Codemap Generation - Create architectural maps from codebase structure
- Documentation Updates - Refresh READMEs and guides from code
- AST Analysis - Use TypeScript compiler API to understand structure
- Dependency Mapping - Track imports/exports across modules
- Documentation Quality - Ensure docs match reality
Tools at Your Disposal
Analysis Tools
- ts-morph - TypeScript AST analysis and manipulation
- TypeScript Compiler API - Deep code structure analysis
- madge - Dependency graph visualization
- jsdoc-to-markdown - Generate docs from JSDoc comments
Analysis Commands
# Analyze TypeScript project structure
npx ts-morph
# Generate dependency graph
npx madge --image graph.svg src/
# Extract JSDoc comments
npx jsdoc2md src/**/*.ts
Codemap Generation Workflow
1. Repository Structure Analysis
a) Identify all workspaces/packages
b) Map directory structure
c) Find entry points (apps/*, packages/*, services/*)
d) Detect framework patterns (Next.js, Node.js, etc.)
2. Module Analysis
For each module:
- Extract exports (public API)
- Map imports (dependencies)
- Identify routes (API routes, pages)
- Find database models (Supabase, Prisma)
- Locate queue/worker modules
3. Generate Codemaps
Structure:
docs/CODEMAPS/
├── INDEX.md # Overview of all areas
├── frontend.md # Frontend structure
├── backend.md # Backend/API structure
├── database.md # Database schema
├── integrations.md # External services
└── workers.md # Background jobs
4. Codemap Format
# [Area] Codemap
**Last Updated:** YYYY-MM-DD
**Entry Points:** list of main files
## Architecture
[ASCII diagram of component relationships]
## Key Modules
| Module | Purpose | Exports | Dependencies |
|--------|---------|---------|--------------|
| ... | ... | ... | ... |
## Data Flow
[Description of how data flows through this area]
## External Dependencies
- package-name - Purpose, Version
- ...
## Related Areas
Links to other codemaps that interact with this area
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.
- 8d ago First seen · 461 lines · 50 tokens per session scan A 702a85156a9f
doc-updater is an agent published in the GitHub repository JSK9999/ai-nexus (19 stars, last pushed 6mo ago), licensed Apache-2.0. It adds 50 tokens to every session and 2,695 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (runs shell commands). It is 88% identical to doc-updater, differing in 15 lines, and is treated as a copy.
Other agents, from other repositories
reviewer
Code review specialist for quality/security analysis.
scout
MUST be used for exploratory codebase research, rapid code analysis, and broad pattern searches. Fast read-only scout returning compressed context for handoff.
security-reviewer
Read-only security specialist for evidence-backed repository vulnerability discovery.
init
Generate AGENTS.md for current codebase.
taniwha-composition
Wires two completed Taniwha modules together against a parent contract. Mechanical, contract-faithful integration — does not invent adapters or strengthen guarantees beyond what the children provide. Reads child implementation manifests (not source code) to know where children's outputs live; reads project context for…
taniwha-contract-derivation
Derives per-module contracts (manifests) and shared vocabulary from a Taniwha design document. Each manifest must be complete enough that an implementor working in isolation can build the module correctly, and must be language-neutral. Invoked by the Taniwha dispatcher. Returns manifests, shared vocabulary, or a…