oncokb-logging-review

Review application logging for correct severity levels, labels, and error-path coverage.

Updated Aug 31, 2026
One-click install
npx skills add https://github.com/oncokb/oncokb-skills --skill oncokb-logging-review-oncokb
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: oncokb-logging-review
Source: https://github.com/oncokb/oncokb-skills/tree/main/skills/oncokb-logging-review
Command: npx skills add https://github.com/oncokb/oncokb-skills --skill oncokb-logging-review-oncokb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent or missing application logging makes production incidents hard to triage, hides silent failures, and floods operators with mislabeled noise. This Skill reviews logging changes so every event has the right severity, a mandatory level label, and full error-path coverage. ## Core Features & Use Cases - Severity Validation: Checks each changed log statement against TRACE/DEBUG/INFO/WARN/ERROR/FATAL semantics and flags over-severe or under-severe usage. - Error Observability Checks: Traces changed error and fatal branches end-to-end to confirm no silent failure paths or swallowed exceptions. - Ignored-Error Enforcement: Requires a contextual WARN log whenever code intentionally ignores or downgrades an error. - Use Case: During a PR review that modifies retry logic and exception handlers, run this Skill to produce a report of blockers (silent error paths, missing labels) and concrete INFO-level milestone suggestions. ## Quick Start Review the logging changes in this pull request and report any severity, labeling, or error-coverage issues.

Frequently Asked Questions about oncokb-logging-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review logging levels in a pull request?▼

Check each changed log statement against severity semantics: TRACE for loop-level detail, DEBUG for developer diagnostics, INFO for business milestones, WARN for recoverable anomalies, ERROR for failed operations, and FATAL for unrecoverable states. Flag any statement whose level does not match its operational impact.

What is the difference between WARN and ERROR log levels?▼

WARN indicates recoverable anomalies such as retries, fallbacks, defaults, or ignored errors where execution continues normally. ERROR indicates a failed operation affecting a request, task, or feature, while the process can still continue elsewhere.

When should I use INFO vs DEBUG logging?▼

Use INFO for expected lifecycle and business milestones like startup, shutdown, job begin/end, and state transitions that explain normal behavior. Use DEBUG for developer diagnostics useful only in non-production or temporary investigation, and avoid INFO for high-frequency low-value events.

Should ignored exceptions always be logged?▼

Yes. When code intentionally ignores, suppresses, or downgrades an error, it should emit a WARN log that includes context and the reason the error is being ignored. Silent exception swallowing hides operational risk and makes incident triage harder.

How do I ensure error paths are observable in logs?▼

Trace every changed error and fatal branch end-to-end to confirm at least one reliable log emission, either directly at the source or through a guaranteed centralized handler, middleware, or worker wrapper. Flag any return-error branch with no observable log trail.