Skip to content
Report library
Purpose / Development

Observability And Instrumentation Skill Security Audit

What the author says it does (original text)

Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

The example trusts and propagates a client-supplied request ID

Source references: 3
What we found

The middleware accepts any `x-request-id`, places it in logging context and the response, and the guide calls for downstream propagation, without format, length, uniqueness, or trusted-source validation.

Why this matters

A requester could reuse or forge an ID so unrelated events appear together during incident investigation. Oversized or unusual values could also amplify processing problems in logs, queue metadata, or downstream headers.

The guide makes correlation IDs mandatory, and its example directly accepts a client-supplied `x-request-id`, places it in log context and the response, then calls for propagation across downstream boundaries. If copied without validation elsewhere, an attacker could supply oversized, malformed, or reused IDs that pollute logs, confuse request attribution, and carry untrusted data downstream. This is an example rather than a complete implementation, so validation cannot be proven absent; users can ask for explicit length, character-set, trust-boundary, and regeneration rules.

SKILL.md:79In the instructionsOpen original file
**Correlation IDs are mandatory.** Generate (or accept) a request ID at the system boundary and attach it to every log line, span, and outbound call. Without it, you cannot reconstruct a single request from interleaved logs:```typescript// Express: child logger per request, ID propagated downstreamapp.use((req, res, next) => {  req.id = req.headers['x-request-id'] ?? crypto.randomUUID();  req.log = logger.child({ requestId: req.id });  res.setHeader('x-request-id', req.id);  next();
Show 2 other places
SKILL.md:104In the instructionsOpen original file
Both fields have to cross the same boundaries as the correlation ID — queue metadata, HTTP headers — or a worker re-derives the entry point and guesses. A field that merely correlates with an entry point is a hint, not an attribution: anything that can invoke the job can reproduce it.
SKILL.md:83In the instructionsOpen original file
// Express: child logger per request, ID propagated downstreamapp.use((req, res, next) => {  req.id = req.headers['x-request-id'] ?? crypto.randomUUID();  req.log = logger.child({ requestId: req.id });  res.setHeader('x-request-id', req.id);  next();});
Low risk

Temporarily lowering alert thresholds can trigger real on-call notifications

Source references: 3
What we found

The verification step says to fire every new alert and suggests temporarily lowering its threshold, but does not explicitly confine this to an isolated environment or test notification channel.

Why this matters

If performed on production alert rules, it could create false pages, disrupt responders, and temporarily alter detection behavior for real incidents.

The guide requires every new alert to be test-fired and explicitly suggests temporarily lowering its threshold, but that instruction is not limited to staging or a test notification channel. If applied to a production alert, it could page real responders, causing disruption, mistaken escalation, or alert fatigue. The nearby “in staging” wording applies only to the log-error check and does not clearly constrain the later alert step. Users can ask that testing be restricted to an isolated environment or use a muted/test recipient with advance notice to responders.

SKILL.md:172In the instructionsOpen original file
### 7. Verify the telemetry itselfInstrumentation is code; it can be wrong. Before calling the work done, trigger the paths and look at the actual output:- Force an error in staging → find it in the logs by `requestId`, confirm fields are structured (not `[object Object]`)- Send test traffic → confirm metric series appear with the expected labels and sane values- Follow one request across services in the tracing UI → no broken spans- Fire each new alert once (lower the threshold temporarily) → confirm it reaches the right channel and the runbook link works
Show 2 other places
SKILL.md:165In the instructionsOpen original file
Rules for every alert you create:1. **It must be actionable.** If the response is "ignore it, it self-heals", delete the alert.2. **It links to a runbook** — even three lines: what it means, first query to run, escalation path.3. **It has a threshold and duration** justified by the SLO or by historical data, not by a guess.4. Use two severities only: **page** (user-facing, act now) and **ticket** (degradation, act this week). A third tier becomes noise that trains people to ignore everything.
SKILL.md:174In the instructionsOpen original file
Instrumentation is code; it can be wrong. Before calling the work done, trigger the paths and look at the actual output:- Force an error in staging → find it in the logs by `requestId`, confirm fields are structured (not `[object Object]`)- Send test traffic → confirm metric series appear with the expected labels and sane values- Follow one request across services in the tracing UI → no broken spans- Fire each new alert once (lower the threshold temporarily) → confirm it reaches the right channel and the runbook link works
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

6 instruction sections

This Skill is an observability implementation guide. It asks users to define operational questions before choosing structured logs, metrics, traces, and alerts. The supplied code is illustrative and contains no installation command, file-modification script, or telemetry export destination.

View source
SKILL.md:27In the instructionsOpen original file
### 1. Define "working" before instrumentingTelemetry without a question is noise. Before adding any instrumentation, write down 2–4 questions an on-call engineer will ask about this feature:
SKILL.md:42In the instructionsOpen original file
### 2. Pick the right signal for each question| Signal | Answers | Cost profile | Example ||---|---|---|---|| **Structured log** | "What happened in this specific case?" | Per-event; grows with traffic | `payment_failed` with provider error code || **Metric** | "How often / how fast, in aggregate?" | Fixed per series; cheap to query | p99 latency of provider calls || **Trace** | "Where did time go across services?" | Per-request; usually sampled | One slow checkout, broken down by hop |

It explicitly forbids logging secrets, tokens, passwords, full personal information, or whole request bodies, and calls for allowlisted fields plus inspection of actual output. This reduces telemetry-leak risk, although enforcement depends on the implementation produced from the guide.

View source
SKILL.md:106In the instructionsOpen original file
**Never log secrets, tokens, passwords, or full PII.** This is a hard rule from the `security-and-hardening` skill — telemetry pipelines are a classic data-leak path. Allowlist fields; don't log whole request bodies.
SKILL.md:213In the instructionsOpen original file
- [ ] Every log sink written by more than one entry point carries an entry-point field, set where the run starts and propagated with the correlation ID rather than inferred downstream- [ ] No secrets, tokens, or unredacted PII in any log line (spot-check actual output)- [ ] RED metrics exist for every new endpoint and every external dependency, with bounded label sets

It recommends OpenTelemetry auto-instrumentation for HTTP, gRPC, and common database clients, with context propagated through HTTP and queues. This broadens the runtime data collected and transmitted; the exact fields and destination depend on the actual SDK, instrumentation, and backend configuration, which are not included in the supplied source.

View source
SKILL.md:136In the instructionsOpen original file
Use OpenTelemetry — it's the vendor-neutral standard, and auto-instrumentation covers HTTP, gRPC, and common DB clients with near-zero code:```typescript// tracing.ts — must be imported before anything elseimport { NodeSDK } from '@opentelemetry/sdk-node';import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';const sdk = new NodeSDK({  serviceName: 'checkout-service',  instrumentations: [getNodeAutoInstrumentations()],});sdk.start();```
SKILL.md:150In the instructionsOpen original file
Add manual spans only around meaningful internal units of work (e.g., `applyDiscounts`, `chargeProvider`) and attach the attributes on-call will filter by. Propagate context across every async boundary — HTTP headers, queue message metadata — or the trace dies at the gap. Sample head-based at a low rate by default; keep 100% of errors if your backend supports tail sampling.
Start here · InstructionsSKILL.md
observability-and-instrumentation
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Read keys or account settings
SKILL.md:101In the instructionsOpen original file
// POST /jobs/:id/replay -> runLog('replay_endpoint', req.id)// CLI invocation        -> runLog('cli', process.env.RUN_ID ?? crypto.randomUUID())```
Lines read
221
File checksum (to compare versions)
952d058f971fecf46bb8e84d4fb9f45b1a36cf32fb794a799dca609535119ea6