本文へ移動
cccskills
無料GitHub で公開

ln-514-test-log-analyzer

Analyzes application logs: classifies errors, checks log quality/format, maps stack traces to source, recommends fixes.

インストール方法を見る

含まれるファイル(4)

  • SKILL.md9.4 KB
  • references/analyze_test_logs.py19.8 KB
  • references/error_taxonomy.md6.9 KB
  • references/log_analysis_output_format.md5.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

Test Log Analyzer

Two-layer analysis of application logs. Python script handles collection and quantitative analysis; AI handles classification, quality assessment, and fix recommendations.

Inputs

No required inputs. Runs in current project directory, auto-detects log sources.

Optional args — caller instructions (natural language): time window, expected errors, test context. Example: "review logs for last 30min, auth 401 errors expected from negative tests".

Purpose & Scope

  • Analyze application logs (after test runs, during development, or on demand)
  • Classify errors into 4 categories: Real Bug, Test Artifact, Expected Behavior, Operational Warning
  • Assess log quality: noisiness, completeness, level correctness, format, structured logging
  • Map stack traces to source files; provide fix recommendations
  • Report findings for quality verdict (only Real Bugs block)
  • No status changes or task creation — report only

When to Use

  • Analyze application logs in any project (default: last 1h)
  • After test runs to classify errors and assess log quality
  • Can be invoked with context instructions: Skill(skill: "ln-514-test-log-analyzer", args: "review last 30min, 401 errors expected")

Workflow

Phase 0: Parse Instructions

If args provided — extract: time window (default: 1h), expected errors list, test context. If no args — use defaults (last 1h, no expected errors).

Phase 1: Log Source Detection and Script Execution

MANDATORY READ: Load docs/project/infrastructure.md, docs/project/runbook.md

  1. Check if scripts/analyze_test_logs.py exists in target project. If missing, copy from references/analyze_test_logs.py.
  2. Detect log source mode (auto-detection priority: docker → file → loki):
ModeDetectionSource
dockerdocker compose ps returns running containersdocker compose logs --since {window}
file.log files exist, or tests/manual/results/ has outputFile paths from infrastructure.md or *.log glob
lokiLOKI_URL env var or tools_config.md observability sectionLoki HTTP query_range API
  1. Run script: python scripts/analyze_test_logs.py --mode {detected} [options]
  2. If no log sources found → return NO_LOG_SOURCES status, skip to Phase 5.

Phase 2: 4-Category Error Classification

Classify each error group from script JSON output:

CategoryActionCriteria
Real BugFixUnexpected crash, data loss, broken pipeline
Test ArtifactSkipFrom test scripts, deliberate error-path validation
Expected BehaviorSkipRate limiting, input validation, auth failures from invalid tokens
Operational WarningMonitorClock drift, resource pressure, temporary unavailability

Test artifact detection heuristics:

  • Test name contains: invalid, error, fail, reject, unauthorized, forbidden, not_found, bad_request, timeout
  • Test asserts non-2xx status codes (4xx, 5xx)
  • Test uses pytest.raises, expect(...).rejects, assertThrows, should.throw
  • Errors correlate with test execution timestamps from regression test output
  • Patterns matching tests/manual/ scripts

Error taxonomy per references/error_taxonomy.md (9 categories: CRASH, TIMEOUT, AUTH, DB, NETWORK, VALIDATION, CONFIG, RESOURCE, DEPRECATION).

Phase 3: Log Quality Assessment

MANDATORY READ: Load references/error_taxonomy.md (per-level criteria table + level correctness reference)

Step 1: Detect configured log level. Check in order:

  1. LOG_LEVEL / LOGLEVEL env var (.env, docker-compose.yml, infrastructure.md)
  2. Framework config: Python logging.conf / Django LOGGING / Node LOG_LEVEL
  3. Default: assume INFO if not detected

Configured level determines WHICH levels appear in logs, but each level has its own noise threshold regardless.

Step 2: Assess 6 quality dimensions:

DimensionWhat to CheckSignal
NoisinessPer-level noise thresholds from error_taxonomy.md section 4: TRACE (zero in prod), DEBUG (>50% monopoly), INFO (>30%), WARNING (>1% of total), ERROR (>0.1% of total)NOISY: {level} template "{msg}" at {ratio}%
Completeness & TraceabilityCritical operations missing log entries + traceability gaps (see table below)MISSING: No log for {operation} / TRACEABILITY_GAP: {type} in {file}:{line}
Level correctnessPer-level criteria from error_taxonomy.md section 4: content, anti-patterns, library ruleWRONG_LEVEL: should be {level}
Structured loggingMissing trace_id/request_id/user context; unstructured plaintextUNSTRUCTURED: lacks {field}
SensitivityPII/secrets/tokens/passwords in log messagesSENSITIVE: {type} exposure
Context richnessErrors without actionable context (order_id, user_id, operation)LOW_CONTEXT: lacks context

Traceability gap detection — scan source code for operations without INFO-level logging:

Operation TypeExpected LogWhere to Add
Incoming request handlingRequest received + response statusEntry/exit of route handler
External API callRequest sent + response status + durationBefore/after HTTP client call
DB write (INSERT/UPDATE/DELETE)Operation + affected entity + countBefore/after ORM/query call
Auth decisionResult (allow/deny) + reasonAfter auth check
State transitionOld state → new state + triggerAt transition point
Background jobStart + complete/fail + durationEntry/exit of job handler
File/resource operationOpen/close + path + sizeAt I/O operation

Log Format Quality (10-criterion checklist per references/log_analysis_output_format.md):

#CriterionCheck
1Dual formatJSON in prod, readable in dev
2TimestampConsistent, timezone-aware
3Level fieldPresent, uppercase
4Trace/Correlation IDPresent in every entry, async-safe
5Service nameIdentifies source service
6Source locationmodule:line + function
7Extra contextStructured fields, not string interpolation
8PII redactionPasswords, API keys, emails handled
9Noise suppressionDuplicate filters, third-party suppressed
10ParseabilityDev: pipe-delimited; prod: valid JSON per line

Score: passed criteria / 10.

Phase 4: Stack Trace Mapping + Fix Recommendations

For each Real Bug:

  1. Extract stack trace frames; identify origin frame (first frame in project code, not in node_modules/site-packages)
  2. Map to source file:line
  3. Generate fix recommendation: what to change, where, effort estimate (S/M/L)

Prioritize using Sentry-inspired dimensions:

  • High-volume (occurrence count), Post-test regression (new errors), High-impact path (auth/payment/DB), Correlated traces (trace_id across services)

Phase 5: Generate Report

MANDATORY READ: Load references/log_analysis_output_format.md

Output report to chat with header ## Test Log Analysis. Include:

  • Signals table (Real Bugs count, Test Artifacts filtered, Log Noise status, Log Format score, Log Quality score)
  • Real Bugs table (priority, category, error, source, fix recommendation)
  • Filtered table (category, count, examples)
  • Log Quality Issues table (dimension, service, issue, recommendation)
  • Noise Report table (count, ratio, service, level, template, action)
  • Machine-readable block <!-- LOG-ANALYSIS-DATA ... --> for programmatic consumption

Phase 6: Meta-Analysis

MANDATORY READ: Load shared/references/meta_analysis_protocol.md

Skill type: execution-worker. Run after all phases complete.

Verdict Contribution

Quality coordinator normalization matrix component:

StatusMaps ToPenalty
CLEAN--0
WARNINGS_ONLY--0
REAL_BUGS_FOUNDFAIL-20
SKIPPED / NO_LOG_SOURCESignored0

Log quality/format issues are INFORMATIONAL — do not affect quality verdict. Only Real Bugs block.

Critical Rules

  • No status changes or task creation; report only.
  • Test Artifacts and Expected Behavior are ALWAYS filtered — never count as bugs.
  • Log quality issues are advisory — inform, don't block.
  • Script must handle gracefully: no Docker, no log files, no Loki → NO_LOG_SOURCES.
  • Language preservation in comments (EN/RU).

Definition of Done

  • Script deployed to target project scripts/ (or already exists)
  • Log source detected and script executed (or NO_LOG_SOURCES returned)
  • Errors classified into 4 categories; Real Bugs identified
  • Log quality assessed (6 dimensions + 10-criterion format checklist)
  • Stack traces mapped to source files for Real Bugs
  • Report output to chat with signals table + machine-readable block

Reference Files

  • Error taxonomy: references/error_taxonomy.md
  • Output format: references/log_analysis_output_format.md
  • Analysis script: references/analyze_test_logs.py

Version: 1.0.0 Last Updated: 2026-03-13

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

tensology のスキルをすべて見る

このスキルの問題を報告する