Ready to supercharge your AI agents?

Install any skill in seconds. Free to start, no credit card required.

Observability · gsd-build | DecimalAI

devopsby gsd-build

Observability

gsd-build/observability

Source gsd-build/gsd-2 ↗License MIT

Add agent-first observability to code — structured logs, health endpoints, failure-state persistence, and explicit failure modes — so the next agent hitting a problem at 3am has the signals it needs to diagnose.

SkillScore86Maintained

Automatic

DevOps & SRE pack

Last verified 9/27/2026

What it changes

Passed 18 of 21 test cases with the skill, and 13 of 21 without it.

Without skill64%

With skill86%

Checks it passed that the model alone missed

Persists failure state when invariant checks fail
Writes operational state to a known status file path
Writes error details to a durable runtime file location

and 3 more in the full report

5 fixed14 passed either way3 still failing0 broke

Pass-rate lift: +23 pp
Tokens: +50%
Agent turns: 0%
Response time: -25%

Model gemini-3.6-flashMeasured 9/27/2026v119 of 22 cases passed with skill · 21 comparable

Tokens, turns and time describe resource use, not a dollar price.

Use this skill

Save it into your project's skills folder. Claude Code picks it up in its next session.

curl -fsSL --create-dirs -o .claude/skills/gsd-build-observability/SKILL.md https://app.decimal.ai/s/gsd-build-observability/SKILL.md

Want it pinned and updatable? pip install "decimalai>=0.15", then decimalai skills add gsd-build-observability, and start Claude Code with claude --plugin-dir "$(git rev-parse --show-toplevel)/.agents"

1 · One-time — install the CLI (docs ↗)

pip install "decimalai>=0.15"

2 · Get the skill — writes .agents/skills/gsd-build-observability/ and pins it in .decimal/skills.lock

decimalai skills add gsd-build-observability

No CLI? Get the same file — curl · raw file

curl -fsSL --create-dirs -o .claude/skills/gsd-build-observability/SKILL.md https://app.decimal.ai/s/gsd-build-observability/SKILL.md

Raw file: /s/gsd-build-observability/SKILL.md ↗ · machine-readable summary at /s/gsd-build-observability.json ↗

Safety checks: 3 of 3 passed

Code scan CleanIntent PassedContent Clean

See it in action

One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.

1 of 5

Prompt

I am instrumenting `src/services/order-processor.ts`. A developer suggested adding `logger.info('Entering processOrder()')` and `logger.info('Exiting processOrder()')` to every function. How should we log execution in this processor?

What was checked, without and with the skill
Checked	Without skill	With skill
Rejects uniform function entry log lines	Passed	Passed
Logs decision points with contextual decision rationale fields	Missed	Passed

case-06 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted

What's inside

The instructions your model reads when the skill loads.

SKILL.md169 linessingle file

This skill is the thinking process for adding it. Not "add logs everywhere" — add the right signals at the right decision points.

Invocation points:

Building auto-mode-style code (loops, dispatch, guards, retries)
Adding a background job, watcher, or scheduled task
Writing a server or long-running process
Refactoring a subsystem that has been hard to debug
Addressing a production bug where "we had no visibility" surfaced

<core_principle> LOG DECISIONS, NOT ACTIVITY. "Entering function X" is noise. "Dispatched unit slice/S02 after guard check passed because status=pending" is signal. Every log line should answer a question a future debugger will ask.

FAIL LOUDLY AND PERSIST THE REASON. Silent try/catch that returns undefined is an anti-pattern. If something fails, the failure state needs to be somewhere a fresh agent can find it — a JSONL, a status file, a health endpoint.

OBSERVABILITY IS NOT FREE. Every log allocation, every metric, every health check costs CPU and disk. Add only what you would actually read. </core_principle>

Step 1: Map the failure modes

Before instrumenting, list what can go wrong:

What inputs could be invalid? External API responses, user-submitted data, filesystem state, env vars.
What external dependencies could fail? Network, DB, child processes, filesystem permissions.
What internal invariants could break? State transitions, lock acquisition, concurrency assumptions.
What silent corruption is possible? Truncated writes, partial transactions, stale caches.

This map tells you where to instrument. Don't instrument uniformly — instrument at the decision points where these failures would manifest.

Step 2: Structured logs at decision points

Track record

Benchmark

18 / 21

test cases passed, vs 13 / 21 without

Adoption

Users: 0
Times used: 0

Safety and source details

SkillSafety

✓ 3 of 3 passed

Code scan15 of 15 checks clean

0 critical · 0 warning · 0 info — scanner v5 — 8/31/2026

View 15 scanner checks

live_secretremote_code_executionreverse_shelldata_exfiltrationssrf_metadataagent_snoopinganti_refusaldestructive_commandsobfuscated_unicodeunicode_homoglyphopaque_blobsuspicious_urltool_overreachtrigger_abuseprompt_injection_phrasing

IntentSafe

LLM judge · does the skill do what it claims

ContentClean

LLM judge · policy & harmful-content review

Source

Imported

gsd-build / gsd-2

src/resources/skills/observability/SKILL.md

View on GitHub ↗

License MITImported 8/31/2026Version v1

Other skills for the same job

Published skills whose descriptions closely match this one, with their headline benchmark lift.

open-gsd/observabilityAdd agent-first observability — structured logs, health endpoints, failure-state persistence, explicit failure modes — so the next agent can diagnose problems unattended. Use when asked to "add logging", "add observability", "add metrics", "make this observable", or when building/refactoring a subsystem that runs unattended (auto-mode engine, background jobs, servers, watchers).Near-identical description+20 pp pass-rate lift

More skills from the same source and nearby in the registry, with their headline benchmark lift.