log-analysis

Q: How do I install log-analysis?

Run npx skills add https://github.com/akillness/jeo-skills --skill log-analysis in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/log-analysis/ (personal) or .claude/skills/log-analysis/ (project).

by akillnessDevOps & Cloud

Route runtime-log requests into one evidence packet before diagnosing anything. Use when the user shares app/server/container/browser/CI/JSON log output and wants the first actionable blocker, repeated signature, likely blast radius, or safest next read-only checks. Choose one packet: app-runtime, container-runtime, browser-plus-api, ci-cascade, structured-json, or security-signal. Triggers on: check the logs, which line matters, real error, first blocker, noisy stack trace, retry storm, browser 401/500, pod logs, worker crash, CI abort, webhook failure. Route engine-specific Unity/Unreal logs to game-build-log-triage, observability design to monitoring-observability, and remediation/debug hypotheses to debugging.

Installs: 384
Last 24h: —
Trending rank: —
Security: Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/akillness/jeo-skills --skill log-analysis

01
Install
Run the command in your project. The CLI asks which agents to install for.
02
Describe the task
Ask your agent for something this skill covers. It loads log-analysis automatically when relevant.
03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Log Analysis

When to use this skill

The main job is read-only log triage, not code changes or monitoring design.
The user wants the first actionable blocker, not a paraphrase of every line.
The evidence is application, API, worker, proxy, container, pod, browser, CI, or JSON logs.
The user needs the repeated signature or blast radius summarized after the first failure is isolated.
The prompt is really "which lines matter / what is the real error / where does the cascade start?" even if the user never says "triage".

Do not use this skill as the main workflow when:

The logs are Unity / Unreal build, cook, package, editor, or player logs → use game-build-log-triage.
The real job is instrumentation, dashboards, alerting, ingestion, retention, or observability coverage → use monitoring-observability.
The likely blocker is already known and the user now needs reproduction, hypotheses, or fixes → use debugging.
The main job is repeated anomaly/rule hunting across logs or telemetry families rather than first-failure triage → use pattern-detection.

Core idea

log-analysis should act like a packet router, not a giant troubleshooting encyclopedia.

Normalize the request into one primary log packet.
Narrow the evidence slice before interpreting it.
Isolate the earliest actionable failure.
Group repeated fallout into a pattern / blast radius note.
Route out as soon as the work becomes debugging, observability design, anomaly hunting, or engine-specialist triage.

Read these support docs before choosing the packet:

references/intake-packets-and-route-outs.md
references/triage-playbook.md
references/source-boundaries.md

Instructions

Step 1: Normalize the request

Convert the prompt into this intake shape first:

log_analysis_packet:
  primary_packet: app-runtime | container-runtime | browser-plus-api | ci-cascade | structured-json | security-signal
  source_shape: app | proxy | worker | browser | ci | container | pod | json | mixed | unknown
  environment: local | ci | staging | production | browser | container | pod | unknown
  failure_goal: first-blocker | cascade-start | repeated-signature | blast-radius | suspicious-access | unknown
  anchor: timestamp | request-id | trace-id | job-build-id | browser-route | none | unknown
  route_after: stay-here | debugging | monitoring-observability | pattern-detection | game-build-log-triage

Choose one primary packet for the run. If two seem plausible, pick the cheaper packet that reduces uncertainty fastest.

Step 2: Choose the packet

Packet	Use when	Best fits	Typical anchors
`app-runtime`	The key evidence is app/API/worker/proxy text logs	crashes, stack traces, request failures, queue poison messages	earliest fatal/error line, route, service, request ID
`container-runtime`	The evidence comes from `docker logs`, `kubectl logs`, pod output, or deploy-window restarts	container crashes, env/config mismatch, dependency connectivity, restart loops	pod/container name, deploy window, host, request ID
`browser-plus-api`	Browser console/network symptoms need server-side confirmation	401/403/500 flows, failed fetch, CORS/auth mismatch, SSR/client divergence	route, request ID, timestamp, browser/network trace
`ci-cascade`	CI output contains many secondary failures after one blocker	install/import/test/build cascades, missing dependency/config, runner mismatch	job name, step name, stage, earliest stack trace/import error
`structured-json`	The logs are JSON or field-rich event records	grouped error families, request/trace correlation, worker/event triage	level, service, request ID, trace ID, tenant, event name
`security-signal`	Access/error logs suggest suspicious probing or auth/permission anomalies	repeated 401/403/404 probes, token misuse, rate-limit storms	IP/user/session, route family, status code, time window

Packet rules:

Prefer app-runtime for plain text stack traces and server logs.
Prefer container-runtime when restart timing, pod identity, or env/deploy context matters.
Prefer browser-plus-api when frontend symptoms are not sufficient on their own.
Prefer ci-cascade when the visible failure may be generic abort noise.
Prefer structured-json when fields make grouping and correlation cheaper than free-text scanning.
Prefer security-signal only when suspicious access/auth behavior is the main job; otherwise keep security-looking noise inside the packet that owns the first blocker.

Step 3: Narrow the slice before reading everything

Apply at least one narrowing move before interpreting the logs:

limit by time window
limit by request / trace / job / build / session / tenant identifier
separate fatal/actionable lines from retries and fallout
separate one noisy source from many affected sources
separate browser symptom lines from server-side blocker lines
in CI, locate the earliest failing step before summarizing the full transcript

Useful heuristics by packet:

app-runtime → exception / fatal / failed / timeout / refusal first
container-runtime → restart window + dependency/connectivity/env mismatch first
browser-plus-api → backend auth/config/runtime evidence before generic client symptoms
ci-cascade → earliest import/config/build/test failure before abort/footer lines
structured-json → group by message family, exception class, request ID, or service before reading raw rows
security-signal → distinguish broad probing from one broken client before escalating

Step 4: Isolate the first actionable failure

Use this order:

Hard stop — crash, panic, uncaught exception, process exit, build failure
Dependency / environment blocker — missing config, secret, DNS, file, service, auth, or connection
Request / runtime failure — 500, timeout, rejected promise, queue poison message, parser failure
Fallout — retries, secondary warnings, repeated health-check failures, broad abort text

Do not report 20 repeated downstream lines as 20 different causes.

Step 5: Correlate and classify

If the evidence spans more than one source, correlate instead of concatenating.

Primary classification buckets:

missing-config-or-secret
dependency-or-connection
auth-or-permission
request-or-runtime-error
data-shape-or-validation
resource-or-capacity
browser-network-mismatch
ci-build-test-failure
security-or-suspicious-pattern
unknown-needs-more-context

Correlation anchors to prefer:

timestamp window
request / trace / correlation ID
job/build ID or CI step
service / worker / pod / container name
route, browser action, or API endpoint
user / tenant / session identifier when safe to mention

Step 6: Return a triage brief

Default response shape:

# Log Triage

## Source
- Packet: app-runtime | container-runtime | browser-plus-api | ci-cascade | structured-json | security-signal
- Environment: local | CI | staging | production | browser | container | pod
- Confidence: high | medium | low

## First actionable failure
- Line or excerpt: `...`
- Why it matters: ...
- Why later lines look secondary: ...

## Pattern / blast radius
- Repeated signature: ...
- Scope: one request | repeated requests | one worker | one deploy window | one environment | broad

## Classification
- Primary bucket: ...
- Secondary bucket: ...

## Likely root cause
- 1-3 sentence explanation grounded in the evidence

## Next read-only checks
1. ...
2. ...
3. ...

## Route-out
- stay in `log-analysis` | `debugging` | `monitoring-observability` | `pattern-detection` | `game-build-log-triage`

Step 7: Route out aggressively

Switch when the next job is no longer first-failure log triage:

Reproduction, hypotheses, code/config fixes → debugging
Dashboards, alerts, ingestion, telemetry coverage, retention → monitoring-observability
Repeated signature hunting across many windows or datasets → pattern-detection
Unity / Unreal build/editor/package logs → game-build-log-triage

If the excerpt is too short or starts mid-cascade:

mark confidence low
ask for the earliest error cluster or 20-80 lines around the first blocker
ask for one anchor only if needed: time window, request ID, job/build, pod/container, or browser route
do not pretend certainty from a truncated excerpt

Examples

Example 1: Container dependency failure

Prompt:

kubectl logs shows Error: connect ECONNREFUSED redis:6379 and then dozens of job retry failed lines.

Good response shape:

choose container-runtime
identify the Redis connection failure as the first actionable blocker
group later retry lines as fallout
route next to debugging or monitoring-observability only after the blocker is isolated

Example 2: Browser + API mismatch

Prompt:

Browser console says Failed to fetch, the network tab shows 401 on /api/session, and the server log says JWT audience invalid.

Good response shape:

choose browser-plus-api
identify backend auth validation as the actionable blocker
treat browser failure as a symptom, not the cause
route next to debugging once the config/code suspect is clear

Example 3: CI cascade

Prompt:

CI ends with test suite aborted, but earlier there is ModuleNotFoundError: No module named 'dotenv'.

Good response shape:

choose ci-cascade
isolate the earliest import failure
treat the abort/footer text as fallout
route next to debugging after the failing dependency path is known

Example 4: Automation/webhook JSON logs

Prompt:

These JSON webhook logs show repeated status=429 retries after one invalid API key response. What actually matters?

Good response shape:

choose structured-json or security-signal depending on whether auth abuse or one bad credential is the primary job
isolate the first credential/auth failure
summarize retry volume separately
route repeated pattern hunting to pattern-detection only if the user wants broader anomaly work

Best practices

Choose the smallest packet that can answer the question.
Lead with the earliest blocker, not the loudest line.
Group repeated fallout into one signature or blast-radius summary.
Correlate browser/network/app evidence instead of summarizing each source independently.
Keep all suggested checks read-only inside this skill.
Treat engine-specific logs as a hard specialist boundary.
Route out as soon as the work becomes debugging, observability design, or anomaly hunting.

References

references/intake-packets-and-route-outs.md
references/triage-playbook.md
references/source-boundaries.md

FAQ

What does the log-analysis skill do?

How do I install log-analysis?

Run npx skills add https://github.com/akillness/jeo-skills --skill log-analysis in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/log-analysis/ (personal) or .claude/skills/log-analysis/ (project).

Which AI agents can use log-analysis?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is log-analysis safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains log-analysis?

It is published by akillness in akillness/jeo-skills. It has 384 recorded installs.

More from akillness/jeo-skills

View all →

rtk

akillness/jeo-skills

Install, initialize, verify, and troubleshoot RTK (Rust Token Killer) for AI coding agents. Use when you need to reduce shell-command token output, confirm that the correct rtk binary is installed, choose between Homebrew, install.sh, or Cargo installation, wire rtk init for Claude Code, Codex, Gemini CLI, Cursor, Copilot, Windsurf, Cline, or OpenCode, or use compact wrappers such as rtk git status, rtk read, rtk grep, rtk test, rtk lint, and rtk gain. Triggers on: rtk, rust token killer, token saver cli, rtk init, rtk gain, codex rtk, gemini rtk, opencode rtk, claude hook token reduction.

Backend & APIs672 installs

graphify

akillness/jeo-skills

Drive Graphify from its CLI to build, refresh, query, export, and serve a durable code/corpus knowledge graph. Use when the user wants .graphify/GRAPHREPORT.md, graph.json, graph.html, graphify update/summary/query/path/explain/tree, change-aware review context, git-hook or watch-based refresh, a stdio MCP graph server, or an install into jeo, jeopi, gjc, opencode, Claude, Codex, or Gemini. Also covers the honest structural fallback when native extraction is empty or misleading. Route simple locate/reference work to codebase-search, narrative knowledge-base work to llm-wiki, and project-memory handoff to opencontext. Triggers on: graphify, graphify update, graphify query, knowledge graph CLI, GRAPHREPORT.md, graph.json, codebase graph, graph refresh, graphify install, graphify serve, review context, affected flows.

Code Quality & Workflow662 installs

data-analysis

akillness/jeo-skills

Analyze datasets to extract insights, identify patterns, and generate reports.

598 installs

code-refactoring

akillness/jeo-skills

Turn a cleanup packet into one behavior-preserving refactor brief. Use when simplifying a messy function/component/service, freezing behavior before touching fragile legacy code, splitting a cleanup-heavy diff into reviewable slices, or planning a repeated migration / codemod without changing intended behavior. Route diagnosis to debugging, review judgment to code-review, validation-program design to testing-strategies, bottleneck-led tuning to performance-optimization, and pure symbol inventory to codebase-search.

Code Quality & Workflow546 installs

technical-writing

akillness/jeo-skills

Write internal technical documentation for engineers and operators: technical specs, architecture docs, ADRs, runbooks, migration plans, and developer-facing implementation guides. Use when the main job is capturing a technical decision, system boundary, operating procedure, or rollout path for builders and maintainers. Triggers on: tech spec, design doc, architecture doc, ADR, runbook, migration guide, implementation guide, rollout doc, operational guide, and internal technical writing. End-user onboarding guides, tutorials, FAQs, and help-center flows belong here too. Route API portals to api-documentation, release notes to changelog-maintenance, decks to presentation-builder, and GTM messaging to marketing-automation.

Docs & Writing544 installs

web-accessibility

akillness/jeo-skills

Routing-first skill for web accessibility remediation and verification. Use when the main job is classifying which accessibility surface is failing — semantics, keyboard/focus, labels/announcements, visual perception/reflow, media alternatives, or routed-app navigation feedback — and turning vague audit, WCAG, axe/Lighthouse, or "make this accessible" requests into one concrete remediation packet. Broad UI critique for hierarchy, polish, and launch readiness belongs here too. Route component API architecture and system governance to design-system, and responsive layout strategy to responsive-design.

Frontend & Design531 installs

Popular devops & cloud skills

View category →

microsoft-foundry

microsoft/azure-skills

Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure

OfficialDevOps & Cloud579.1K installs

azure-diagnostics

microsoft/azure-skills

Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.

OfficialDevOps & Cloud569.8K installs

azure-prepare

microsoft/azure-skills

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

OfficialDevOps & Cloud569K installs

azure-ai

microsoft/azure-skills

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.

OfficialDevOps & Cloud568.8K installs

azure-deploy

microsoft/azure-skills

Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.

OfficialDevOps & Cloud568.6K installs

azure-validate

microsoft/azure-skills

Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.

OfficialDevOps & Cloud568K installs

log-analysis

Install

Install

Describe the task

Review the result

SKILL.md

Log Analysis

When to use this skill

Core idea

Instructions

Step 1: Normalize the request

Step 2: Choose the packet

Step 3: Narrow the slice before reading everything

Step 4: Isolate the first actionable failure

Step 5: Correlate and classify

Step 6: Return a triage brief

Step 7: Route out aggressively

Examples

Example 1: Container dependency failure

Example 2: Browser + API mismatch

Example 3: CI cascade

Example 4: Automation/webhook JSON logs

Best practices

References

FAQ

More from akillness/jeo-skills

Popular devops & cloud skills