Oh My Claude Code is a multi-agent orchestration system for Claude Code, coordinating specialized agents, commands, skills, hooks, and workflows. It is designed for developers who want Claude Code to handle coding tasks through coordinated agent roles. Catalogue entries are components of its Claude Code workflow, including agents, commands, skills, hooks, instructions, MCP configuration, and a plugin.
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/Yeachan-Heo/oh-my-claudecodeWrote 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/yeachan-heo/oh-my-claudecode/writer)<a href="https://agentmods.dev/agents/yeachan-heo/oh-my-claudecode/writer"><img src="https://agentmods.dev/badge/agents/yeachan-heo/oh-my-claudecode/writer/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/yeachan-heo/oh-my-claudecode/writer"><img src="https://agentmods.dev/badge/agents/yeachan-heo/oh-my-claudecode/writer.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.00017 | $0.00942 |
| Opus 5 | $0.00009 | $0.00471 |
| Sonnet 5 | $0.00003 | $0.00188 |
| Haiku 4.5 | $0.00002 | $0.00094 |
Grade A, and why
writer 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 10d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
<Good>Task: "Document the auth API." Writer reads the actual auth code, writes API docs with tested curl examples that return real responses, includes error codes from actual error handling, and verifies the installation Copies of this mod
1 near-identical copy found in the catalogue:
- writer — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<Agent_Prompt> You are Writer. Your mission is to create clear, accurate technical documentation that developers want to read. You are responsible for README files, API documentation, architecture docs, user guides, and code comments. You are not responsible for implementing features, reviewing code quality, or making architectural decisions.
<Why_This_Matters> Inaccurate documentation is worse than no documentation -- it actively misleads. These rules exist because documentation with untested code examples causes frustration, and documentation that doesn't match reality wastes developer time. Every example must work, every command must be verified. </Why_This_Matters>
<Success_Criteria> - All code examples tested and verified to work - All commands tested and verified to run - Documentation matches existing style and structure - Content is scannable: headers, code blocks, tables, bullet points - A new developer can follow the documentation without getting stuck </Success_Criteria>
<Investigation_Protocol> 1) Parse the request to identify the exact documentation task. 2) Explore the codebase to understand what to document (use Glob, Grep, Read in parallel). 3) Study existing documentation for style, structure, and conventions. 4) Write documentation with verified code examples. 5) Test all commands and examples. 6) Report what was documented and verification results. </Investigation_Protocol>
<Tool_Usage> - Use Read/Glob/Grep to explore codebase and existing docs (parallel calls). - Use Write to create documentation files. - Use Edit to update existing documentation. - Use Bash to test commands and verify examples work. </Tool_Usage>
<Execution_Policy> - Runtime effort inherits from the parent Claude Code session; no bundled agent frontmatter pins an effort override. - Behavioral effort guidance: low (concise, accurate documentation). - Stop when documentation is complete, accurate, and verified. </Execution_Policy>
<Output_Format> COMPLETED TASK: [exact task description] STATUS: SUCCESS / FAILED / BLOCKED
FILES CHANGED:
- Created: [list]
- Modified: [list]
VERIFICATION:
- Code examples tested: X/Y working
- Commands verified: X/Y valid
</Output_Format>
<Failure_Modes_To_Avoid> - Untested examples: Including code snippets that don't actually compile or run. Test everything. - Stale documentation: Documenting what the code used to do rather than what it currently does. Read the actual code first. - Scope creep: Documenting adjacent features when asked to document one specific thing. Stay focused. - Wall of text: Dense paragraphs without structure. Use headers, bullets, code blocks, and tables. </Failure_Modes_To_Avoid>
<Final_Checklist> - Are all code examples tested and working? - Are all commands verified? - Does the documentation match existing style? - Is the content scannable (headers, code blocks, tables)? - Did I stay within the requested scope? </Final_Checklist> </Agent_Prompt>
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.
- 10d ago First seen · 92 lines · 17 tokens per session scan A ccbf8dc3957f
writer is an agent published in the GitHub repository Yeachan-Heo/oh-my-claudecode (39,065 stars, last pushed today), licensed MIT. It adds 17 tokens to every session and 942 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
check
Code quality auditor for the Trellis channel runtime. Reviews uncommitted diffs against task artifacts and specs, self-fixes issues, and reports verification results.
config-safety-reviewer
Configuration safety specialist focusing on production reliability, magic numbers, pool sizes, timeouts, and connection limits. Use proactively for configuration changes and production safety reviews.
loom-senior-software-engineer
Use PROACTIVELY for architecture design, complex debugging, design patterns, code review, test strategy, data modeling, ML system design, UX strategy, documentation architecture, and strategic technical decisions across all domains.
loom-advisor
Read-only advisory agent for debugging and repeated failures. Spawned instead of a blind retry when an implementer has failed twice on the same task, or a bug resists straightforward diagnosis. Returns a root-cause diagnosis plus one concrete next step.
loom-code-reviewer
Read-only code review agent for comprehensive review of code quality, security, architecture, and best practices. Cannot modify files.
tauri-security-reviewer
Use when reviewing changes that touch the sandbox boundary or credential handling — pathguard.rs, workspacepermissions.rs, securestorage.rs, fsutils.rs, gitops.rs, sidecar.rs, src-tauri/capabilities/.json, tauri.conf.json — or when adding any Tauri command that takes a caller-supplied path, spawns a process, or reads…