Missing Error Handling

Code handles only the happy path — external calls, I/O, and parsing have no failure handling and crash on anything unexpected.

Security Scan

This is an instruction-only guidance skill about missing error handling; it requests no credentials, installs, or system access and its contents match its name and description.

Purpose & Capability

Name, description, and the SKILL.md all describe the same thing: guidance on handling failures. The skill declares no binaries, env vars, or install steps that would be unexpected for a documentation-only guidance skill.

Instruction Scope

The SKILL.md contains developer guidance and checklists (timeouts for network calls, catching specific exceptions, logging, etc.). It does not instruct the agent to read files, access environment variables, call external endpoints, or run commands, so it stays within the stated purpose.

Install Mechanism

There is no install spec and no code files. Being instruction-only means nothing is written to disk or executed by the install process—this is the lowest-risk install profile.

Credentials

The skill declares no required env vars, credentials, or config paths. The guidance does not reference any secrets or unrelated services.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent presence or special privileges; being instruction-only it cannot modify other skills or system settings.

Assessment

This skill is essentially a short checklist and best-practices note about error handling — it poses minimal risk because it contains no code, no install steps, and asks for no credentials. You can safely read and use its advice, but remember it is only guidance: it won't automatically fix your code or enforce checks. If you expect an automated tool, look for a skill that provides linters or runtime wrappers; otherwise incorporate the suggested checks into your codebase and CI. Confidence is high because the skill is internally consistent and contains no surprising requirements.

Every external interaction is a source of failure: network, disk, subprocess, parsing, third-party API. If the code assumes they always succeed, a production run will hit the first unexpected condition and crash unhelpfully.

Symptoms

• HTTP calls without status-code checks and without timeout.
• File I/O with no handling for missing files, permission denied, or partial reads.
• Subprocess calls that ignore non-zero exit codes.
• JSON.parse / yaml.load with no handling of malformed input.
• Broad except: / catch (e) {} that swallows everything without logging.

What to do

• For each external call, list the failure modes explicitly: timeout, non-2xx status, missing resource, malformed payload, permissions. Handle each with specific recovery or a loud failure.
• Add a timeout to every network call. No exceptions.
• When catching, catch the specific exception types you can actually recover from. Let unknown errors propagate with context.
• When swallowing is unavoidable, log the full error with context — at minimum, the operation that failed and the arguments.
• Distinguish "user-visible error" (explain, ask them to retry or adjust) from "internal error" (log with stack, fail fast). Don't leak internal errors to users.