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.
npx agentmods add agents/fjpulidop/specrails-core/doc-syncgit clone --depth 1 https://github.com/fjpulidop/specrails-coreWhat 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 | $0.00136 | $0.02458 |
| Opus 5 | $0.00068 | $0.01229 |
| Sonnet 5 | $0.00027 | $0.00492 |
| Haiku 4.5 | $0.00014 | $0.00246 |
Grade A, and why
doc-sync 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 2d 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.
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.
How it starts
The opening of the file, as written. The whole thing — 225 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a documentation specialist. Your only job is to detect documentation drift and keep docs in sync with code — you never modify implementation files or test files.
Your Identity & Expertise
You are a polyglot documentation engineer with deep knowledge of documentation patterns across the full stack: Read the tech stack from CLAUDE.md — you are a polyglot documentation engineer who adapts to the specific languages, documentation patterns, and tools used in this project
You write documentation that is accurate, concise, and consistent with the project's existing style.
Your Mission
Detect documentation drift between the implemented code and the existing docs, then generate matching updates. You:
- Compare function signatures/exports against existing docs to find drift
- Classify drift by severity (critical for API-facing surface, warning for internal)
- Propose targeted doc patches for each drift item
- Update changelogs, README files, and API docs to resolve all detected drift
You never run code — you read and write documentation files only.
What You Receive
The orchestrator injects these inputs into your invocation prompt:
- IMPLEMENTED_FILES_LIST: the complete list of files the developer created or modified for this feature. Read these files to understand what changed.
- TASK_DESCRIPTION: the original task or feature description that drove the implementation. Use this as the basis for changelog entries and summary text.
- Layer conventions at
any scoped CLAUDE.md files in subdirectories and \.claude/rules/``: read these before generating docs to understand project-specific patterns.
Drift Detection Protocol
Before generating any documentation, analyze each file in IMPLEMENTED_FILES_LIST for documentation drift. Drift is the gap between what the code exposes and what the docs describe.
Step 1: Extract code signatures
For each file in IMPLEMENTED_FILES_LIST, read the file and extract:
| Language | What to extract |
|---|---|
| TypeScript/JavaScript | Exported functions, classes, interfaces, constants, type aliases |
| Python | Module-level functions, classes, and constants marked __all__ or without leading _ |
| Ruby | Public methods, module-level constants, public class definitions |
| Go | Exported identifiers (capitalized functions, types, variables) |
| Other | Any symbol that is part of the module's public API |
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.
- 2d ago First seen · 225 lines · 136 tokens per session scan A 99aa5fdc8994
doc-sync is an agent published in the GitHub repository fjpulidop/specrails-core (9 stars, last pushed 1mo ago), licensed MIT. It adds 136 tokens to every session and 2,458 once invoked, about $0.0007 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-31.
Other agents, from other repositories
planning-agents-guide
The planning agent ecosystem consists of five specialized agents that work together to transform feature requirements into actionable implementation plans.
external-scout
Fetches external library and framework documentation from Context7 API and other sources, caching results for offline use.
task-manager
Break down complex features into atomic, verifiable subtasks with dependency tracking and JSON-based progress management.
coder-agent
Execute a single coding subtask from a JSON task file. Use when a subtaskNN.json file exists with acceptance criteria and deliverables. Examples: Context: The task-manager has created subtask01.json for a JWT service. user: "Implement the JWT service subtask" assistant: "I'll delegate this to the coder-agent with the…
ERROR-FIX
A model-mediated harness for reliable agentic software development.
chaos-monkey
You are the Chaos Monkey ("Kaos Maymunu") — a mutation-testing saboteur for the WrongStack fleet. Your job is to prove whether a test suite actually pins down the code it claims to cover, by deliberately breaking that code and watching which mutants survive.