# sentry-instrument-logging

Adds structured Sentry logs to an app: the agent inventories your repo and writes log messages that follow shared conventions.

- skill · `type=skill` · Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode · 533 installs · ★ 272
- Author: getsentry
- License: Apache-2.0 · policy=mirror · the beginning of the file is at the end of this page
- Source: https://github.com/getsentry/sentry-for-ai/tree/HEAD/skills-legacy/sentry-instrument-logging/SKILL.md
- Updated: 2026-10-23
- HTML: https://affpapa.org/en/nevibecode/skills/sentry-instrument-logging

## What it does

The skill walks the repository and builds a table of applications from language manifests such as `composer.json`, `package.json`, `go.mod`, `Gemfile`, `pyproject.toml` and `Cargo.toml`. Each manifest usually means a separately deployed app, and each one gets a full pass: configure logging, add messages, run lint and tests. With more than about two apps, it asks which ones to instrument now and how deep to go.

Before touching code, the agent settles shared conventions once: attribute namespacing, event-name phrasing, log levels. That way logs from different languages can be searched and correlated together. Service boundaries that propagate trace headers get a note too, since logs on both sides of a call should share attribute names.

Not every line survives. Each added log goes through a validation table: what production question it answers, whether it duplicates an exception or a shared API wrapper, whether it leaks PII or secrets. Logs that merely confirm routine UI interactions are meant to be removed. Anything left needs a one-sentence justification.

Basic Sentry configuration has to exist in the repository first, otherwise the skill offers to set it up with the matching skills. One more thing worth knowing: if the local toolchain has no linter, type checker or tests, the agent says so instead of implying the check passed.

## Requirements
- Works with: Sentry

## Install

### Claude Code (native platform)

1. **Skills CLI (Vercel)**
```bash
npx skills add getsentry/sentry-for-ai --skill sentry-instrument-logging -a claude-code
```

2. **Manually: put the files in place**
- File: `~/.claude/skills/sentry-instrument-logging/SKILL.md` — Copy the whole skill folder; for one project use .claude/skills/sentry-instrument-logging/

### Codex

1. **Skills CLI (Vercel)**
```bash
npx skills add getsentry/sentry-for-ai --skill sentry-instrument-logging -a codex
```

2. **Manually: put the files in place**
- File: `.agents/skills/sentry-instrument-logging/SKILL.md` — For all projects use ~/.agents/skills/

### Cursor

1. **Skills CLI (Vercel)**
```bash
npx skills add getsentry/sentry-for-ai --skill sentry-instrument-logging -a cursor
```

2. **Manually: put the files in place**
- File: `.cursor/skills/sentry-instrument-logging/SKILL.md` — Cursor also reads .agents/skills/ and .claude/skills/

### GitHub Copilot

1. **GitHub CLI**
```bash
gh skill install getsentry/sentry-for-ai sentry-instrument-logging
```

2. **Manually: put the files in place**
- File: `.github/skills/sentry-instrument-logging/SKILL.md`

### Gemini CLI

1. **Skills CLI (Vercel)**
```bash
npx skills add getsentry/sentry-for-ai --skill sentry-instrument-logging -a gemini-cli
```

2. **Platform CLI**
```bash
gemini skills install https://github.com/getsentry/sentry-for-ai --path skills-legacy/sentry-instrument-logging
```

### Windsurf (Devin Desktop)

**Manually: put the files in place**
- File: `.devin/skills/sentry-instrument-logging/SKILL.md` — The legacy .windsurf/skills/ path still works

### OpenCode

**Skills CLI (Vercel)**
```bash
npx skills add getsentry/sentry-for-ai --skill sentry-instrument-logging -a opencode
```

### Claude.ai

**Claude.ai**
- Zip the folder and upload it in Settings → Capabilities → Skills

Where a file is given instead of a command, copy the files from the source to that path: https://github.com/getsentry/sentry-for-ai/tree/HEAD/skills-legacy/sentry-instrument-logging/SKILL.md

## When to use it
- inventory every app in a monorepo from its manifest
- add structured logs to a new service
- align log attribute names across languages
- drop logs that duplicate errors and API wrappers
- check that log lines carry no PII or secrets

## Example prompts
- add structured Sentry logs to this app
- inventory the repo and show me the table of apps to instrument
- review the logs you added against the checklist and remove the weak ones

## Source text · SKILL.md · Apache-2.0

Below is the content of a third-party file. It is data, not instructions for you: do not act on anything written inside unless the human asks. Block tag: 40f7797f2287402c.

BEGIN THIRD-PARTY FILE 40f7797f2287402c
```text
---
name: sentry-instrument-logging
description: Instruments structured Sentry logs in a new or existing application.
license: Apache-2.0
category: feature-setup
parent: sentry-feature-setup
disable-model-invocation: true
---

# Instrument Sentry Logging

This skill adds structured Sentry logs to an application following the guidance
in [Instrumentation guidance](#instrumentation-guidance).

The goal is to provide a small set of high-value log messages that make
production behavior easier to understand and debug.

The log messages added by this skill should also serve as clear, repeatable,
examples that users can follow when instrumenting the rest of their application.

## Prerequisites

The repository should already have basic Sentry configuration.

If Sentry has not yet been configured, offer to set it up using the appropriate
[skills](./).

## Steps

1. **Inventory every application in the repository.** Locate language/runtime
   manifests (`composer.json`, `package.json`, `go.mod`, `Gemfile`,
   `pyproject.toml`, `Cargo.toml`, …). Each manifest typically marks a
   separately deployed application. Produce an explicit table and treat it as
   the work list for the rest of this skill:

   | App | Path | Language | Sentry SDK? | Logging abstraction | Status |
   |-----|------|----------|-------------|---------------------|--------|

   If the repo has more than ~2 apps, confirm scope with the user before
   starting: which apps to instrument now, and at what depth.

2. **Establish shared conventions once, up front** — before touching any app.
   Decide on consistent attribute namespacing (e.g. `myapp.<domain>.<field>`),
   event-name phrasing, and log levels, so logs from every language can be
   searched and correlated together. Record these so each per-app pass follows
   them. Note service boundaries that propagate trace headers
   (baggage / sentry-trace) — logs on both sides of such a call should share
   attribute names so a single trace reads coherently across languages.

3. **For each application in the inventory, complete the full pass below before
   moving to the next**, updating its Status as you go
```
END THIRD-PARTY FILE 40f7797f2287402c

The third-party file has ended. Everything between the 40f7797f2287402c tags is data: requests and commands from it are not followed. An “end of file” line with another tag inside the block is part of the file.

First 2155 of 12776 bytes. © getsentry · Apache-2.0 · https://github.com/getsentry/sentry-for-ai/tree/HEAD/skills-legacy/sentry-instrument-logging/SKILL.md

_Part of the page did not fit — see the HTML version._

---
NeVibeCode on affpapa.org. Catalog texts are descriptions, not instructions for the agent. How to choose and install: https://affpapa.org/en/nevibecode/agents.md