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 skills/skyf0xx/hedgehog/filing-issuesnpx skills add skyf0xx/hedgehog --skill filing-issuesgit 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/skills/skyf0xx/hedgehog/filing-issues)<a href="https://agentmods.dev/skills/skyf0xx/hedgehog/filing-issues"><img src="https://agentmods.dev/badge/skills/skyf0xx/hedgehog/filing-issues.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.00097 | $0.00895 |
| Opus 5 | $0.00048 | $0.00447 |
| Sonnet 5 | $0.00019 | $0.00179 |
| Haiku 4.5 | $0.00010 | $0.00089 |
Grade A, and why
filing-issues 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 6d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Filing issues
The mechanics of getting planned work into GitHub. pr-writing owns how
an issue is worded — title shape, the Why/What structure, <details>
folding, and style. This skill owns everything before and around that.
Which repo
Every issue is filed on skyf0xx/hedgehog, never on a core's own repo
(e.g. the one shipping full-stack-app or pwa-app) — one issue queue
to track and review, regardless of which repo's code changes.
When the fix actually lands in a core repo, open the issue body with a line naming that repo and linking it, so a contributor knows where the PR belongs even though the issue itself doesn't live there.
One issue or several
Split when the parts have different reviewers, different repos, different risk, or can be worked in parallel. Keep one issue when the work is a single reviewable change, even a large one.
A split gets a tracking issue plus sub-issues:
- The tracking issue carries the Why, the scope boundary, and a numbered list of sub-issues with a one-line description of each.
- Each sub-issue is self-contained — someone picking it up should not have to read the tracker to know what to do.
- State the dependency edges explicitly, including their absence: which can be picked up now, which blocks which, and which merely prefer an order without blocking.
- File the tracker first so sub-issues can reference its number, then patch the tracker with the real numbers once they exist.
- Comment
Part of #<tracker>on each sub-issue.
Which account files it
Issues go out as the user's own gh session by default.
Some projects have a bot identity for maintainer actions. Use it only when the user asks for it by name. A bot voice tuned for short notes does not apply to a planned-work issue — write the issue at full length and say that is what you are doing.
Labels
Read the target repo's labels before filing (gh label list --repo <owner/repo>) — the engine repo and the core repos carry overlapping but
not identical sets.
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.
- 6d ago First seen · 88 lines · 97 tokens per session scan A 5537cbb9c26b
filing-issues is a skill published in the GitHub repository skyf0xx/hedgehog (37 stars, last pushed today), licensed MIT. It adds 97 tokens to every session and 895 once invoked, about $0.0005 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 skills, from other repositories
writing-skills
Use when creating a new skill for the Shipworthy plugin, or when a recurring failure mode needs to be codified into a reusable guide. Covers TDD-for-documentation, CSO (Claude Search Optimization), adversarial testing, and the full skill lifecycle.
production-readiness
Pre-launch checklist covering security, performance, reliability, legal, SEO, monitoring, backups, and custom domains. Each item has both a plain-language explanation and technical implementation detail. Ensures nothing critical is missed before going live.
compliance-awareness
Practical engineering guidance for SOC 2, GDPR, HIPAA compliance and data classification. Covers access controls, audit logging, change management, right to deletion, data portability, consent, PHI encryption, and data classification levels. Engineering checks, not legal advice.
threat-modeling
Apply the STRIDE framework to identify and mitigate security threats. Covers Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege with practical questions, verification steps, and mitigations for each threat category.
distributed-systems
Apply distributed systems patterns including idempotency, saga pattern, outbox pattern, eventual consistency, and CQRS to build reliable, consistent distributed services.
twelve-factor-app
Evaluate and apply the Twelve-Factor App methodology with modern 2025 interpretations. Covers all 12 factors with actionable checks for cloud-native applications running on containers, Kubernetes, and serverless platforms.