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/talayash/spring-fleet/debugging-runtime-logsnpx skills add talayash/spring-fleet --skill debugging-runtime-logsgit clone --depth 1 https://github.com/talayash/spring-fleetWhat 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 | $0.00052 | $0.00701 |
| Opus 5 | $0.00026 | $0.00351 |
| Sonnet 5 | $0.00010 | $0.00140 |
| Haiku 4.5 | $0.00005 | $0.00070 |
Grade A, and why
debugging-runtime-logs 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 yesterday.
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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging Runtime Logs Across a Service Fleet
When something breaks in a multi-service dev run, the symptom usually appears in one service while the cause lives in another. This skill correlates logs across the whole fleet and ties the failure back to code.
Prerequisites
- A
spring-fleet.config.jsonexists (else run/fleet-init). - Services write to the configured
logDir(see thespring-fleet-logging-setupskill if logs are scattered or console-only).
Procedure
-
Get a correlation handle. Best case: an OTel
trace_id(32-char hex) from the user's APM dashboard or atraceparentheader, or a legacysessionId/X-Request-Idfrom a failed request. Otherwise, start from the error message/stack the user pasted — extract a key from a nearby log line, preferringtrace_idoversessionId. -
Dispatch the
log-correlatoragent with the config path and the trace value (or error snippet). It runsscripts/correlate_logs.pyand returns one chronological cross-service timeline plus a failure-origin analysis.Run directly if you prefer:
python "${CLAUDE_PLUGIN_ROOT}/scripts/correlate_logs.py" \ --config ./spring-fleet.config.json --value <traceValue> -
Read the timeline as a story. Follow the request hop by hop. The first ERROR/exception in time order is the likely origin; everything after it is usually propagation. Watch the time gaps — a long gap before an error often means a timeout.
-
Map the origin to code. Take the failing service + class from the log and open the source. For a cross-service cause, dispatch the
fleet-exploreragent (or use thetracing-across-servicesskill) to confirm the call path. -
Report. State: what the user did, the cross-service timeline, the failure origin (service +
file:line), how it surfaced upstream, and a ROOT-CAUSE HYPOTHESIS block — what the fault is, where in code to fix it, why the timeline supports that, your confidence, and a concrete suggested fix (snippet or behavior). Always include alternatives the evidence does not rule out. Call out any service with no log file — a missing log can hide the real cause.
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.
- yesterday First seen · 60 lines · 52 tokens per session scan A cff3297cec6d
debugging-runtime-logs is a skill published in the GitHub repository talayash/spring-fleet (2 stars, last pushed 2mo ago), licensed MIT. It adds 52 tokens to every session and 701 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-31.
Other skills, from other repositories
tika-eval-compare
Compare extracts from two Tika builds over a corpus to detect regressions in content, encoding, exceptions, and embedded-document handling. Use for "compare before/after extracts", "eval this change against the corpus".
run-tests
Run project tests using Maven (mvn). Use when the user asks to run tests.
file-forensics
Examine what a file claims about itself and what it actually contains — powered by Apache Tika. True content-based type detection (extensions lie), provenance claims (authors, dates, creating application), revision and tamper signals (PDF incremental updates, tracked changes, hidden slides, zip integrity), hidden and…
ideogram-ultra
Build Ideogram 4 (Ideogram Ultra) txt2img and img2img workflows with the local open-weights model, dual conditional/unconditional models with DualModelGuider, Qwen3-VL text encoder, and structured JSON ("compositional deconstruction") prompts for strong text rendering and layout control.
mcp-chat-summary
Chat moderator that summarizes ongoing conversations. Use when invoked through the Atmosphere MCP server's chat-summary tool.
model-compatibility
Model family compatibility matrix covering loaders, resolutions, samplers, CFG, VAE, ControlNet, and LoRA compatibility for SD 1.5, SDXL, Flux, SD3, and video models.