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 commands/jonase47/ccpr/p8-opsgit clone --depth 1 https://github.com/jonase47/ccprWrote 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/commands/jonase47/ccpr/p8-ops)<a href="https://agentmods.dev/commands/jonase47/ccpr/p8-ops"><img src="https://agentmods.dev/badge/commands/jonase47/ccpr/p8-ops.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.00000 | $0.01731 |
| Opus 5 | $0.00000 | $0.00865 |
| Sonnet 5 | $0.00000 | $0.00346 |
| Haiku 4.5 | $0.00000 | $0.00173 |
Grade A, and why
p8-ops 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 2d 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 — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/p8-ops – Production Operations: Analyse Incidents & Monitor Performance
Analyses production errors and performance issues, evaluates incidents, and initiates countermeasures. Called reactively for specific incidents or proactively for regular operational reviews.
Argument: $ARGUMENTS = [Incident/area, e.g. "500 errors since 14:30", "high response times", "weekly review"]
If provided: Analyse the described incident or conduct the review for the specified area. If not provided: Read MONITORING.md and current monitoring data and conduct a general operational review. If any context is missing, ask whether a specific incident exists or a scheduled review should be performed.
0. Work-item adoption guard (ADR-0002 §8)
Run python3 ~/.claude/scripts/workitems.py list.
- Non-empty array → the project uses the structured store. Use the CLI for the follow-up tasks in step 4 below (instead of appending BACKLOG.md prose).
[]and nodocs/workitems/directory → still on prose. Append follow-up tasks to BACKLOG.md as before. Emit one line: "Tip: runliftto adopt the structured work-item store."[]butdocs/workitems/exists → adopted store, just empty right now. Treat as adopted: use the CLI, not the prose fallback.
See Manual/WORKITEMS.md §8 for the full guard rationale and the status-verb mapping.
Execution
1. Read Context
Read the following files (if available):
- MONITORING.md (incident response process, alerting thresholds, escalation paths)
- DEPLOYMENT_LOG.md (most recent deployment – frequently the cause of new incidents)
- ARCHITECTURE.md (system components – for root cause analysis)
- Previous incident reports (if available)
2. Delegation to DevOps Agent (Lead)
Delegate operational analysis to the devops agent:
Analyse the following incident or operational area: $ARGUMENTS Incident response process from MONITORING.md: [Apply process and thresholds]
A. For a Specific Incident
Incident analysis (using the 5-Why principle):
- What exactly happened? (symptom, timeframe, affected users)
- When was it discovered? (alert, user report, proactively)
- What was the immediate cause? (Why 1)
- What was the deeper cause behind it? (Why 2–5)
- Timeline: when did the incident occur, when was it responded to, when resolved?
Immediate measures:
- What was done as a first response?
- Rollback necessary? If so: executed?
- Is the incident resolved or only contained?
B. For a Scheduled Review
Check operational health:
- Uptime for the past period (target vs. actual)
- Average and P99 response times (trend)
- Error rate (trend, notable spikes)
- Resource utilisation (CPU, RAM, disk – is any limit approaching?)
- Planned scaling need: when will current resources no longer be sufficient?
C. Post-Incident Review (PIR) – for severe incidents
- Complete incident timeline
- Root cause (not symptom)
- Impact: how many users affected, for how long?
- What worked well? (detection, response, communication)
- What could have gone better?
- Concrete follow-up actions with ownership and deadline
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.
- 2d ago First seen · 141 lines · 0 tokens per session scan A 77e70b9dd341
p8-ops is a command published in the GitHub repository jonase47/ccpr (1 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,731 tokens. 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-09-03.
Other commands, from other repositories
guard
Manually run the Hydra security and quality scan on specified files or directories.
factory-retro
Find what is repeatedly wasting the factory's time and fix the harness, not the symptom.
debug
Systematic debugging with automated investigation and 4-phase methodology. Default: inline evidence gathering and diagnosis. --deep: spawns systematic-debugger agent for full autonomous debugging. Use for errors, stack traces, test failures, or unexpected behavior.
health
Run documentation health checks (freshness, links, drift, cross-doc consistency).
doctor
Check vault health — broken links, orphans, missing frontmatter, MISSING placeholders — and propose fixes.
think
Single-problem deep reasoning with the deep-think-partner agent. Use for: debugging complex issues, evaluating tradeoffs, validating logic, or thinking through a specific decision. Example: "/think should I use Redis or PostgreSQL for session storage?".