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 skills add EliasOulkadi/shokunin --skill runbook-gengit clone --depth 1 https://github.com/EliasOulkadi/shokuninWrote 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/eliasoulkadi/shokunin/runbook-gen)<a href="https://agentmods.dev/skills/eliasoulkadi/shokunin/runbook-gen"><img src="https://agentmods.dev/badge/skills/eliasoulkadi/shokunin/runbook-gen/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/skills/eliasoulkadi/shokunin/runbook-gen"><img src="https://agentmods.dev/badge/skills/eliasoulkadi/shokunin/runbook-gen.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 234 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00055 | $0.02768 |
| Opus 5 | $0.00028 | $0.01384 |
| Sonnet 5 | $0.00011 | $0.00554 |
| Haiku 4.5 | $0.00006 | $0.00277 |
Grade A, and why
runbook-gen 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 12d 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 — 304 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Runbook Generator
Operation runbooks that on-call engineers can follow under pressure. Based on Google SRE practices, PagerDuty incident response, and post-mortem culture.
Workflow
Follow these steps in order when generating a runbook:
- Discover — Ask the 5 Required Discovery questions (below) to scope the runbook
- Classify — Map the incident to the Severity Matrix; if unclear start at Sev2
- Template — Instantiate the Runbook Template with service-specific commands, time-boxes, and contacts
- War Room — Configure Slack channel, Zoom bridge, shared doc, status page, and customer comms
- Verify — Run through the Production Checklist before marking complete
- Archive — Store the runbook in the team's on-call repo, test in a drill within the quarter
When the ask is a post-mortem (not a runbook), skip steps 3-4 and use the Post-Mortem Template instead.
2. Required Discovery
- Service/System: What is the runbook about? (API, database, cache, queue)
- Incident types: What can go wrong? (down, degraded, slow, data loss)
- Environment: Production, staging, or both?
- Team structure: Primary, secondary, escalation contacts
- Existing monitoring: Alerts, dashboards, runbooks
3. Severity Matrix
| Severity | Definition | Response SLA |
|---|---|---|
| Sev1 | Service down, users impacted | Respond within 15 min |
| Sev2 | Degraded performance, partial impact | Respond within 1 hour |
| Sev3 | Minor issue, no user impact | Next business day |
| Sev4 | Internal tooling, non-critical | Per team schedule |
4. Runbook Template
## Runbook: [Incident Type]
### Detection
How this incident is typically discovered:
- Alert: [Prometheus/Grafana/Datadog alert]
- User symptom: [what users see or report]
- Automated detection: [auto-remediation]
### Initial Response (first 5 min)
1. Acknowledge alert (PagerDuty/Opsgenie). Time: < 2 min
2. Determine severity. Time: < 1 min
3. Assign owner. Create incident channel (#inc-sev1). Time: < 2 min
4. Post initial status:
"Investigating [issue] affecting [scope]. Will update in 15 min."
5. Start diagnosis timer. Time: < 1 min
### Diagnosis (decision tree)
1. Check [primary dashboard]: expected [X], current [Y]
2. Check logs: `kubectl logs -n [ns] -l app=[service] --tail 200`
3. Check database health: `SELECT count(*) FROM pg_stat_activity`
4. Check cache/queue latency: `redis-cli --latency`
5. IF [error in logs] → Runbook A
6. IF [latency > threshold] → Runbook B
7. IF unknown → Escalate
### Resolution Procedures
Each time-boxed with exact commands and verification:
#### Runbook A: [Name] (10 min)
```bash
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.
- 12d ago First seen · 304 lines · 55 tokens per session scan A fee47fbd472d
runbook-gen is a skill published in the GitHub repository EliasOulkadi/shokunin (113 stars, last pushed 1mo ago), licensed MIT. It adds 55 tokens to every session and 2,768 once invoked, about $0.0003 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
python-docs
Create, update, and sync Python project documentation from source code. Use when asked to document a module, generate API references, create architecture diagrams with Mermaid, update docs after code changes, or keep documentation in sync with source. Triggers include "document", "write docs", "update docs", "sync…
code-refactor
Refactor Python code to match this repo's coding standards and style. Use when the user asks to "refactor", "clean up", "fix coding standards", or "apply best practices" to a module, file, or directory in this repo. Applies python-best-practices, pydantic v2, pytorch-lightning, and python-docs conventions as relevant…
quality
PALADIN quality gatekeeper. Two-stage system: Stage 1 checks spec compliance (pass/fail, blocks everything on failure). Stage 2 scores project health 0-100 across 6 tiers. Issues verdict: SHIP IT / SHIP WITH CAUTION / NOT READY / BLOCKED. Evidence Before Claims: every finding must cite the file, line, and what was…
refresh
Use when an existing contextualizer's references may have drifted from current upstream state — typically weekly, or whenever a few days of upstream changes have accumulated — to bring them back into agreement.
distill-habits
Review recent Claude Code conversations, distill the user's stable habits and preferences, persist them into a long-term habit ledger, and maintain a "My Habits" block in the global CLAUDE.md within a character budget. The more you use Claude Code, the more it knows you. Trigger manually with /distill-habits, or on a…
apply
Use when a staged proposal has been reviewed and signed off — REVIEW.md Step 3 ticked reviewed or provisional — and is ready to promote into the live contextualizer.