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).
中文简介正在准备中。当前显示原文说明。
Analyzes application logs: classifies errors, checks log quality/format, maps stack traces to source, recommends fixes.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
Two-layer analysis of application logs. Python script handles collection and quantitative analysis; AI handles classification, quality assessment, and fix recommendations.
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".
Skill(skill: "ln-514-test-log-analyzer", args: "review last 30min, 401 errors expected")If args provided — extract: time window (default: 1h), expected errors list, test context.
If no args — use defaults (last 1h, no expected errors).
MANDATORY READ: Load docs/project/infrastructure.md, docs/project/runbook.md
scripts/analyze_test_logs.py exists in target project. If missing, copy from references/analyze_test_logs.py.| 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 tools_config.md observability section | Loki HTTP query_range API |
python scripts/analyze_test_logs.py --mode {detected} [options]NO_LOG_SOURCES status, skip to Phase 5.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:
invalid, error, fail, reject, unauthorized, forbidden, not_found, bad_request, timeoutpytest.raises, expect(...).rejects, assertThrows, should.throwtests/manual/ scriptsError taxonomy per references/error_taxonomy.md (9 categories: CRASH, TIMEOUT, AUTH, DB, NETWORK, VALIDATION, CONFIG, RESOURCE, DEPRECATION).
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)logging.conf / Django LOGGING / Node LOG_LEVELINFO if not detectedConfigured 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.
For each Real Bug:
Prioritize using Sentry-inspired dimensions:
MANDATORY READ: Load references/log_analysis_output_format.md
Output report to chat with header ## Test Log Analysis. Include:
<!-- LOG-ANALYSIS-DATA ... --> for programmatic consumptionMANDATORY READ: Load shared/references/meta_analysis_protocol.md
Skill type: execution-worker. Run after all phases complete.
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.
NO_LOG_SOURCES.scripts/ (or already exists)references/error_taxonomy.mdreferences/log_analysis_output_format.mdreferences/analyze_test_logs.pyVersion: 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).
中文简介正在准备中。当前显示原文说明。
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`.
中文简介正在准备中。当前显示原文说明。
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`.
中文简介正在准备中。当前显示原文说明。
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'.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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`.
中文简介正在准备中。当前显示原文说明。