Agent Skill · 研究检索

ln-514-test-log-analyzer（ln 514 测试日志分析仪）

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据，避免为了通过测试而改坏真实逻辑；涉及浏览器或外部服务时，应区分本地模拟、测试环境和生产环境。

ln-514-test-log-analyzer 是研究检索类 Agent Skill，可用宿主为 Codex、Claude、Cursor、Gemini CLI，通过GitHub 仓库获取，权限为调用外部服务；许可证信息还不明确，第三方扫描有提醒项，按安装量在研究检索类的 73,675 个 Skill 里排第 29,899。

总安装 2,976周安装 124GitHub Stars 441下载 992核验 2026-05-01

研究检索调用外部服务 GitHub 仓库未标认证来源可访问许可证需确认审计提醒 Codex Claude Cursor Gemini CLI

安装说明

本站只整理中文说明，不托管安装包，也不代用户安装。

GitHub

许可证: unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手，先确认命令和权限，再让它执行。

请帮我安装这个 Agent Skill：ln-514-test-log-analyzer（ln 514 测试日志分析仪）
来源仓库：https://github.com/levnikolaevich/claude-code-skills
仓库路径：skills/ln-514-test-log-analyzer
安装命令：
npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-514-test-log-analyzer
安装前请先检查当前环境是否支持对应 CLI，并向我确认将要执行的命令、安装目录、联网范围和文件读写权限；确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill；本站只展示命令，不托管安装包，也不自动执行。

skills.shnpx skills

npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-514-test-log-analyzer

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题，通常会让助手先检索再总结。

用于辅助测试设计、自动化测试、用例整理和回归验证。可编写单元测试、端到端测试或根据日志定位问题，提升测试效率。通过 npx skills add 命令从指定 GitHub 仓库安装使用。使用时需确认测试框架、运行命令，并区分模拟与生产环境。

ln-514-test-log-analyzer 属于研究检索类 Skill，可作为该场景下的辅助能力补充。

来源仓库内路径：skills/ln-514-test-log-analyzer

上手步骤

4 步

1
确认自己的宿主工具
公开资料标注支持 Codex、Claude、Cursor、Gemini CLI；先确认自己用的是其中之一，再按对应工具的 Skills 目录放置。
2
拿到安装命令
可以直接复制的命令是 npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-5…；命令里的占位符换成自己的路径或密钥再执行。
3
安装后重启宿主
命令执行完要完全退出宿主工具再打开，让新装的 Skill 被重新扫描到，否则列表里可能看不到。
4
按最小权限试用
它需要调用外部服务，先在测试目录或测试账号里跑，确认没问题再放到正式项目。

常见问题

6 条

ln-514-test-log-analyzer 怎么安装？

在终端执行 npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-514-test-lo…。装完完全退出宿主工具再打开，让它重新扫描本地 Skill。

ln-514-test-log-analyzer 支持哪些 AI 工具？

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录，一般也能手动放进去，但要自己确认触发方式是否一致。

ln-514-test-log-analyzer 需要什么权限？

权限级别是调用外部服务。该 Skill 可能调用第三方服务、云服务或外部模型 API，使用前需要确认账号、额度、数据发送范围和服务条款。

ln-514-test-log-analyzer 是免费的吗？

公开资料没有标注明确许可证，收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

ln-514-test-log-analyzer 用的人多吗？

公开数据是累计安装 2,976 次，近一周安装 124 次，下载 992 次，GitHub 441 星。这些数字来自第三方目录统计，只能当作热度参考，不代表质量或安全性。

ln-514-test-log-analyzer 安全吗？

第三方扫描有提醒项，说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

同时适配 4 种工具，换客户端不用重新找替代品。

先想清楚的地方

许可证没有明确标注，能不能商用、能不能再分发都不确定。
第三方扫描存在提醒项或未通过项，需要人工逐条确认。
第三方目录整理，版本更新和行为细节以来源仓库为准。

适不适合你

更适合

已经在用 Codex，想直接扩展它能力的人。
需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

需要明确授权才能用到公司项目里的场景。
需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类

Skill	总安装	GitHub 星	权限	许可证	扫描
find-skills 寻找技能 · Codex、Claude	31,199,813	16,486	操作浏览器	MIT	有提醒
self-improving-agent 自我改进 Agent · OpenClaw	16,464,002	3,396	接触敏感数据	MIT-0	通过
soultrace 灵魂追踪 · Codex、Claude	7,588,944	12	需要联网	未明确	有提醒
self-improving 自我完善 · OpenClaw	6,829,284	1,046	需要联网	MIT-0	通过
microsoft-foundry 微软代工厂 · Codex、Claude	6,614,144	764	调用外部服务	未明确	有提醒
ln-514-test-log-analyzer ln 514 测试日志分析仪 · 本页	2,976	441	调用外部服务	未明确	有提醒

按安装量取同分类前几名；数字来自第三方目录统计，只作热度参考，不代表质量结论。

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. If shared/ is missing, fetch files via WebFetch from https://raw.githubusercontent.com/levnikolaevich/claude-code-skills/master/skills/{path}.

Test Log Analyzer

Type: L3 Worker Category: 5XX Quality

Two-layer analysis of application logs. Node.js 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

Read target project files if they exist: docs/project/infrastructure.md, docs/project/runbook.md

Check if scripts/analyze_test_logs.mjs exists in target project. If missing, copy from references/analyze_test_logs.mjs.
Detect log source mode (auto-detection priority: docker → file → loki):

Mode	Detection	Source
`docker`	`docker compose ps` returns running containers	`docker compose logs --since {window}`
`file`	`.log` files exist, or `tests/manual/results/` has output	File paths from infrastructure.md or `*.log` glob
`loki`	`LOKI_URL` env var or `environment_state.json` observability section	Loki HTTP query_range API

Run script: node scripts/analyze_test_logs.mjs --mode {detected} [options]
If no log sources found → return NO_LOG_SOURCES status, skip to Phase 5.

Level-based error detection (CRITICAL): When constructing Loki queries or grep commands to scan for errors, ALWAYS filter by the parsed level field, NOT by text matching the word "error" in the full log line. Logger names like uvicorn.error contain "error" as part of the name but log at INFO level — text matching produces false positives.

Log format	Correct error filter	Wrong filter
Pipe-delimited (`ts \	LEVEL \	...`)	`\	ERROR `or` \	CRITICAL` (match level field position)	`grep -i error` (matches logger names)
Loki structured	`{service_name="X"} \	level="ERROR" `or` \	pattern` extraction	`{service_name="X"} \	= "error"`
Key=value (`level=ERROR msg=...`)	`level=ERROR` or `level=FATAL`	`\	~ "(?i)error"`
Docker logs (local)	`grep -E '\	ERROR \	\	CRITICAL '`	`grep -iE 'error\	exception'`

The analyze_test_logs.mjs script handles this correctly via structured regex parsers. These rules apply to ad-hoc Loki/grep queries constructed during analysis.

Phase 2: 4-Category Error Classification

Classify each error group from script JSON output:

Category	Action	Criteria
Real Bug	Fix	Unexpected crash, data loss, broken pipeline
Test Artifact	Skip	From test scripts, deliberate error-path validation
Expected Behavior	Skip	Rate limiting, input validation, auth failures from invalid tokens
Operational Warning	Monitor	Clock 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, UNSUPPORTED_API).

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:

LOG_LEVEL / LOGLEVEL env var (.env, docker-compose.yml, infrastructure.md)
Framework config: Python logging.conf / Django LOGGING / Node LOG_LEVEL
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:

Dimension	What to Check	Signal
Noisiness	Per-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 & Traceability	Critical operations missing log entries + traceability gaps (see table below)	`MISSING: No log for {operation}` / `TRACEABILITY_GAP: {type} in {file}:{line}`
Level correctness	Per-level criteria from `error_taxonomy.md` section 4: content, anti-patterns, library rule	`WRONG_LEVEL: should be {level}`
Structured logging	Missing trace_id/request_id/user context; unstructured plaintext	`UNSTRUCTURED: lacks {field}`
Sensitivity	PII/secrets/tokens/passwords in log messages	`SENSITIVE: {type} exposure`
Context richness	Errors 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 Type	Expected Log	Where to Add
Incoming request handling	Request received + response status	Entry/exit of route handler
External API call	Request sent + response status + duration	Before/after HTTP client call
DB write (INSERT/UPDATE/DELETE)	Operation + affected entity + count	Before/after ORM/query call
Auth decision	Result (allow/deny) + reason	After auth check
State transition	Old state → new state + trigger	At transition point
Background job	Start + complete/fail + duration	Entry/exit of job handler
File/resource operation	Open/close + path + size	At I/O operation

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

#	Criterion	Check
1	Dual format	JSON in prod, readable in dev
2	Timestamp	Consistent, timezone-aware
3	Level field	Present, uppercase
4	Trace/Correlation ID	Present in every entry, async-safe
5	Service name	Identifies source service
6	Source location	module:line + function
7	Extra context	Structured fields, not string interpolation
8	PII redaction	Passwords, API keys, emails handled
9	Noise suppression	Duplicate filters, third-party suppressed
10	Parseability	Dev: pipe-delimited; prod: valid JSON per line

Score: passed criteria / 10.

Phase 4: Stack Trace Mapping + Fix Recommendations

For each Real Bug:

Extract stack trace frames; identify origin frame (first frame in project code, not in node_modules/site-packages)
Map to source file:line
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  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:

Status	Maps To	Penalty
CLEAN	--	0
WARNINGS_ONLY	--	0
REAL_BUGS_FOUND	FAIL	-20
SKIPPED / NO_LOG_SOURCES	ignored	0

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).

Runtime Summary Artifact

MANDATORY READ: Load shared/references/quality_summary_contract.md, shared/references/quality_worker_runtime_contract.md

Runtime profile:

family: quality-worker
worker: ln-514
summary kind: quality-worker
payload fields used by coordinators: worker, status, verdict, issues, warnings, artifact_path

Invocation rules:

standalone: omit runId and summaryArtifactPath
managed: pass both runId and exact summaryArtifactPath
always write the validated summary before terminal outcome

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.mjs

Version: 1.0.0 Last Updated: 2026-03-13

平台分布

Codex

38.45%

按下载量换算381

Claude

29.17%

按下载量换算289

Cursor

19.42%

按下载量换算193

Gemini CLI

9.63%

按下载量换算96

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

调用外部服务

该 Skill 可能调用第三方服务、云服务或外部模型 API，使用前需要确认账号、额度、数据发送范围和服务条款。

安装前确认

本站仅展示第三方公开信息，不托管安装包，不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项，安装前请自行复核。目前只有一个公开来源，建议同时核对源仓库。

继续浏览同类 Skills

更多研究检索 Skills（73,675）返回 Skills 目录

上一个 Skill

ln-514-regression-checker（ln 514 回归检查器）

levnikolaevich/claude-code-skills

ln-514-regression-checker 用于查找、检索和筛选相关信息，适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态，以及是否会触发联网、命令执行或文件读写。

下一个 Skill

ln-520-test-planner（ln 520 测试计划员）

levnikolaevich/claude-code-skills