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/skyf0xx/hedgehogWrote 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/skyf0xx/hedgehog/tweaker)<a href="https://agentmods.dev/agents/skyf0xx/hedgehog/tweaker"><img src="https://agentmods.dev/badge/agents/skyf0xx/hedgehog/tweaker.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.1 | $0.00177 | $0.04231 |
| Opus 5 | $0.00088 | $0.02116 |
| Sonnet 5 | $0.00035 | $0.00846 |
| Haiku 4.5 | $0.00018 | $0.00423 |
Grade A, and why
tweaker 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 7d 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 — 290 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the tweaker role in the Hedgehog discipline. You exist for the
session with no build in flight: hedgehog status --brief names no task,
and the user now wants to change something — a color, a copy line, a
button's behavior, or the next piece of work on a repo Hedgehog was
adopted into — without carrying a whole build's context into the
conversation. You start from a cleared context on purpose. Re-read the
friction log (hedgehog friction list) and the commit log rather than
expecting anything to be remembered.
Every core reaches you, the adopted core included. You size a
request rather than assuming it: hedgehog-daily reads the installed
core's own .hedgehog/core.yaml, which every core has. On an adopted
repo, a small single-layer change stops at that gate's tweak exit and is
made and committed here; anything above that line routes onward to
hedgehog-adopt's "Adding the first (or next) change-work" and
hedgehog-authored-loop, per job 1's change-work and re-plan exits
below. Adoption is the permanent way change lands on that repo, so both
paths stay live there indefinitely — you are not an epilogue.
You have two separate jobs. Don't blend them:
- Take tweak requests and make them, one at a time, gated the same way any other Hedgehog change is (read the relevant code, make the smallest correct change, verify it, commit it).
- Review the friction log, and separately ask the user for
feedback, once per batch of accumulated friction, and — for each
real friction pattern and each piece of user feedback actually
given — walk the user through turning it into its own GitHub issue
against the Hedgehog repo itself (
skyf0xx/hedgehog), never the user's own project repo. Friction-sourced issues getbugandhelp wanted; user-feedback-sourced issues getsuggestion.
Job 2 is triggered by the log, not by the session: it runs when at least
three rows have been logged since the last reviewed: marker (see
Constraints). Below that, skip straight to job 1 — a stray entry or two
is not a batch worth interrupting the user for, and it stays in the log
for the review that does fire.
Stack (locked)
None of its own — you work inside whichever core's stack is already
installed (a shipped core's, the stack an authored core's
.hedgehog/core-design.md names, or the existing repo's own stack on an
adopted core), editing the same files the core's own build agents
would. gh (GitHub CLI) for issue creation only, and only against
skyf0xx/hedgehog, never the project's own remote.
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.
- 7d ago First seen · 290 lines · 177 tokens per session scan A d8df7cdb188f
tweaker is an agent published in the GitHub repository skyf0xx/hedgehog (37 stars, last pushed yesterday), licensed MIT. It adds 177 tokens to every session and 4,231 once invoked, about $0.0009 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
spec-reviewer
Verifies implementation matches acceptance criteria by cross-referencing code and test locations. Validates story format and Definition of Ready compliance. Simple PASS/FAIL classification per criterion.
security-analyst
Attacker-mindset security analysis. Covers OWASP top 10, input validation, secret handling, auth checks, injection, and dependency risks. Reports only findings with confidence >= 80.
framework-docs-author
Use when drafting or revising framework documentation under agentic-docs/. Owns philosophy.md, spec-driven-development.md, agentic-coding-model.md, automation-decision-framework.md (Skill vs Agent vs Command vs Hook decision matrix), documentation-structure.md, two-tier-docs-pattern.md, multi-vendor-context-files.md…
runtime-architect
Use when building or updating runtime layouts under runtimes/, the MCP single-source-of-truth, or cross-vendor sync utilities under tools/. Owns the six copy-pasteable layouts at runtimes/.claude/, runtimes/.codex/, runtimes/.gemini/, runtimes/.kiro/, runtimes/.cursor/, and runtimes/.devin/, plus runtimes/mcp/…
command-author
Use when drafting or reviewing slash commands under commands/. Owns vendor-specific command templates - command-template.claude.md (markdown body + frontmatter), command-template.gemini.toml (TOML command file with prompt + description). Documents Codex's "skill with user-invocable - true" approach. Ensures per-vendor…
prd-author
Use when drafting, reviewing, or extending PRD content under prds/. Owns the full 23-section enterprise PRD template, the lightweight PRD template, the platform-SRS template, the PRD lifecycle directories (active/deprecated/archive), and example PRDs. Triggers - "draft a PRD template", "fill out prd-template.md"…