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 kimsanguine/hplan --skill reliabilitygit clone --depth 1 https://github.com/kimsanguine/hplanWrote 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/kimsanguine/hplan/reliability)<a href="https://agentmods.dev/skills/kimsanguine/hplan/reliability"><img src="https://agentmods.dev/badge/skills/kimsanguine/hplan/reliability/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/kimsanguine/hplan/reliability"><img src="https://agentmods.dev/badge/skills/kimsanguine/hplan/reliability.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.00047 | $0.03063 |
| Opus 5.5 | $0.00019 | $0.01225 |
| Sonnet 5.5 | $0.00009 | $0.00613 |
| Haiku 4.5 | $0.00005 | $0.00306 |
Grade A, and why
reliability 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 1mo 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 — 296 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reliability Review
에이전트 신뢰성 체계적 점검 및 개선
Core Goal
- 에이전트의 "최악의 경우" 신뢰성을 정량화 — 평균이 아니라 백분위수(P95, P99)로 신뢰도 평가
- 실패 패턴을 분류하고 각각에 대한 safeguard 설계 — 입력 오류, 모델 오류, 통합 오류 등 유형별 방어책 구축
- 신뢰성 수준(Basic/Standard/High/Critical)을 비즈니스 요구에 맞추기 — 내부 도구는 95%, 고객 대면은 99.9% 같이 차등 목표 설정
Trigger Gate
Use This Skill When
- 에이전트를 프로덕션에 배포하기 전에 신뢰성 평가가 필요할 때
- incident 이후 비슷한 실패를 방지하기 위해 safeguard를 강화할 때
- 에이전트 성능이 불안정하거나 예측 불가능한 패턴을 보일 때
- SLA 보장(예: 99.5% uptime)이 필요한 고객 계약을 체결할 때
Route to Other Skills When
- incident → 실제 장애가 발생한 후 근본 원인 분석과 신뢰성 개선 연결
- 이 스킬의 Pre-mortem 섹션 → 신뢰성 개선 계획의 리스크를 사전 분석할 때 (아래 "사전 위험 분석" 섹션)
- metrics-design --step kpi → 신뢰성을 KPI 대시보드(Success Rate, Error Rate)에 포함
- metrics-design (코호트 분석 섹션) → 신뢰성이 코호트(버전)별로 다르게 나타날 때 (버전 비교)
Boundary Checks
- 기준선 데이터 부족 — 최소 1주일 이상 데이터 필요 (일일 변동성 흡수)
- 실패 분류의 표준화 — 팀마다 "에러"를 다르게 정의하면 신뢰성 측정 불가 → formula 명시
- Safeguard 과도화 — 모든 가능한 실패에 방어책을 세우면 성능 저하 → 영향도 × 발생 확률로 우선순위화
개념
에이전트 신뢰성은 "평균적으로 잘 되는가"가 아니라 "최악의 경우에도 허용 가능한가"로 측정한다. 99%의 성공률은 100번 중 1번 실패를 의미하고, 실패 1번의 비용이 99번의 가치를 초과할 수 있다.
Instructions
You are conducting a reliability review for: $ARGUMENTS
Step 1 — Reliability Baseline
Collect current data:
Total executions (last 30 days): ___
Successful: ___ (___%)
Failed: ___ (___%)
Partially correct: ___ (___%)
Step 2 — Failure Taxonomy
Classify all failures:
| Category | Count | Severity | Example |
|---|---|---|---|
| Input Error | Low-High | Malformed input, missing data | |
| Model Error | Medium | Hallucination, wrong format | |
| Tool Error | Medium | API timeout, rate limit | |
| Logic Error | High | Wrong decision, missed edge case | |
| Output Error | Medium | Correct answer, wrong format |
Step 3 — Failure Pattern Analysis
For each failure category:
Pattern: [description]
Frequency: [how often]
Root Cause: [why it happens]
Impact: [what goes wrong for the user]
Detection: [how we know it failed]
Recovery: [what happens after failure]
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 296 lines · 47 tokens per session scan A 29334a2aecca
reliability is a skill published in the GitHub repository kimsanguine/hplan (3 stars, last pushed 2mo ago), licensed MIT. It adds 47 tokens to every session and 3,063 once invoked, about $0.0002 per session on Opus 5.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-31.
Other skills, from other repositories
issue-analyze
GitHub Issue and PR review thread deep analysis with Codex blind verdict. Use when: analyzing issue root cause, classifying problems, investigation planning, triaging PR review comments for actionability. Not for: fixing bugs (use bug-fix), code exploration (use code-explore). Output: classified analysis + verdict…
debug
Interactive debugging workflow with hypothesis-driven probe loop. Use when: unknown bugs, script errors, silent failures, troubleshooting. Not for: known bugs (use bug-fix), GitHub issue analysis (use issue-analyze), code understanding (use code-explore). Output: debug report with probe journal + root cause + fix.
code-explore
Pure Claude code investigation. Use when: tracing execution paths, understanding architecture, diagnosing issues. Not for: dual-perspective review (use code-investigate), code review (use codex-code-review). Output: analysis report with findings.
code-investigate
Dual-perspective code investigation. Use when: deep code analysis needing both Claude and Codex perspectives. Not for: quick exploration (use code-explore), code review (use codex-code-review). Output: integrated findings from dual analysis.
git-investigate
Git history investigation. Use when: tracking code changes, finding where bugs were introduced, root cause analysis. Not for: code exploration (use code-explore), issue analysis (use issue-analyze). Output: history trace + root cause report.
simplify
Wrap-up refactoring — simplify code, eliminate duplication, preserve behavior.