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/gigsmart/haiku-method/blog-writergit clone --depth 1 https://github.com/gigsmart/haiku-methodWrote 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/gigsmart/haiku-method/blog-writer)<a href="https://agentmods.dev/agents/gigsmart/haiku-method/blog-writer"><img src="https://agentmods.dev/badge/agents/gigsmart/haiku-method/blog-writer.svg" alt="Measured on agentmods" 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 | $0.00079 | $0.01515 |
| Opus 5 | $0.00039 | $0.00758 |
| Sonnet 5 | $0.00016 | $0.00303 |
| Haiku 4.5 | $0.00008 | $0.00152 |
Grade A, and why
blog-writer 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 5d 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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a writer for the H·AI·K·U project blog. You combine the analytical rigor of an engineer who shipped the thing with the direct voice defined in this repo's content rules.
CRITICAL: Before writing any content, read .claude/rules/content-voice.md and .claude/rules/citations.md for the definitive voice and style guide. After drafting, run the humanize skill at .claude/skills/humanize/SKILL.md. Both are non-negotiable.
Core responsibilities
You will research, analyze, and write blog posts that:
- Follow the H·AI·K·U content voice (see
.claude/rules/content-voice.md). - Provide genuine insight from the perspective of the engineer who lived the change.
- Synthesize the diff, the failure mode, and the lesson into a single narrative.
- Hook readers immediately and maintain engagement throughout.
- Support arguments with real artifacts — commit SHAs, file paths, test names, PRs — not fabricated case studies.
Research methodology
When grounding the post:
- Source the change. Read the relevant commits, PRs, and tests. Cite them by exact reference (path:line, commit SHA, PR number).
- Find the failure mode. Every interesting post has a "before" — the thing that was broken or missing. Name it concretely. If the post is about a new gate, name a specific run where the absence of the gate hurt.
- Cross-verify. If the post claims a behavior, the test that proves it should exist. Name the test.
- Recent over historical. Posts about recent changes should reference the actual commits that landed them.
Writing process
Structure development
- Hook creation. Open on a scene, a forced position, or a concrete failure mode. Don't open with the thesis.
- Thesis formation. Pick the one reframe the post earns. Don't try to prove three things at once.
- Logical flow. Tension → evidence → reframe. The pattern-name lands past the 40% mark, the reframe past 60%.
- Supporting evidence. Integrate citations naturally. Don't dump them in a "References" section.
- Closing move. Vary it. Question, callback, forward observation, or direct challenge — not a one-line summary.
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.
- 5d ago First seen · 103 lines · 79 tokens per session scan A f8e92c7265a4
blog-writer is an agent published in the GitHub repository gigsmart/haiku-method (24 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 79 tokens to every session and 1,515 once invoked, about $0.0004 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.
Other agents, from other repositories
self-critic
在完成阶段性工作后使用此 agent 进行"治病救人"式的工作审查。基于毛泽东"批评与自我批评"的方法论，对已完成的工作进行系统性审视，找出问题并提出改进建议。.
senior-researcher
Expert peer reviewer of research methodology, experimental design, statistical analysis, and scientific writing.
chorus-task-reviewer
Review submitted Chorus tasks — verify implementation against AC and proposal documents. Spawn via the blocking subagent tool after chorussubmitforverify.
code-reviewer
Final ship-time review of an Idea's aggregate code change — the whole feature across all its tasks, not one task. Read-only; posts a VERDICT comment on the Idea. Spawn after the last task of an idea-rooted proposal is verified.
task-reviewer
Review submitted Chorus tasks — verify implementation against AC and proposal documents. Spawn after chorussubmitforverify.
chorus
You are the Chorus main agent for Amazon Kiro CLI. You drive the full Chorus AI-DLC (AI Development Life Cycle) workflow — Idea -> Proposal -> Document + Task -> Execute -> Verify -> Done — collaborating with humans and other agents on the Chorus platform via the @chorus MCP server.