Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计通过

agent-telemetryAgent 遥测

Agent Skill

agent-telemetry 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

360

周安装

15

GitHub Stars

4

下载量

120
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:agent-telemetry(Agent 遥测)
来源仓库:https://github.com/petekp/agent-skills
仓库路径:skills/agent-telemetry
安装命令:
npx skills add https://github.com/petekp/agent-skills --skill agent-telemetry
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/petekp/agent-skills --skill agent-telemetry

简介

用于查找、检索和筛选相关信息。agent-telemetry 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

  • 适合在关键词、任务场景或来源线索下快速定位候选结果。
  • 可结合来源仓库和原始 README 继续核验具体用法。
  • 安装前建议确认权限范围、维护状态及是否会触发联网或命令执行。
  • 当前归类为研究检索,但名称暗示其可能用于 Agent 监控。

SKILL.md

Agent Telemetry

Make application runtime behavior queryable by coding agents through structured logging and telemetry endpoints.

Core Problem

Coding agents debugging issues often can't answer "what actually happened at runtime?" because:

  • Logs don't exist, or are unstructured console.log noise
  • Logs exist but there's no documented way for agents to query them
  • Agent docs (CLAUDE.md, AGENTS.md) don't mention how to access telemetry

Workflow

Phase 1: Audit Current State

Determine what telemetry already exists.

1. Check for logging infrastructure:

# Find logging configuration and usage
grep -r "winston\|pino\|bunyan\|log4j\|slog\|Logger\|logging\.config" --include="*.{ts,js,py,rb,go,rs}" -l .
# Find log output configuration
grep -r "LOG_LEVEL\|LOG_FORMAT\|LOG_FILE\|OTEL_\|SENTRY_DSN" .env* config/ -l 2>/dev/null

2. Check for existing telemetry endpoints:

# Health/debug/metrics endpoints
grep -r "health\|metrics\|debug\|status\|readiness\|liveness" --include="*.{ts,js,py,rb,go}" -l src/ app/ 2>/dev/null

3. Check agent docs for log access instructions:

# Do agent docs mention logs?
grep -ri "log\|telemetry\|debug\|observ" CLAUDE.md AGENTS.md .claude/*.md .cursor/*.md 2>/dev/null

4. Classify the result:

FindingAction
No structured logging existsGo to Phase 2
Logging exists but no agent accessGo to Phase 3
Logging + access exists but undocumentedGo to Phase 4
Everything in placeValidate and suggest improvements

Phase 2: Add Structured Logging

If no structured logging exists, add it. See references/logging-setup.md for framework-specific patterns.

Principles:

  • Use structured JSON logs, not string interpolation
  • Include correlation IDs for request tracing
  • Log at boundaries: incoming requests, outgoing calls, errors, state transitions
  • Use consistent field names: timestamp, level, message, requestId, userId, duration, error

Where to add logging (priority order):

  1. Request/response middleware (every request gets logged)
  2. Error handlers (unhandled errors get captured with context)
  3. External service calls (DB queries, API calls, queue operations)
  4. Business logic decision points (state transitions, authorization decisions)

Minimum viable logging — add a request logger middleware that captures:

{timestamp, level, requestId, method, path, statusCode, duration, userId?}

This single addition makes most debugging possible.

Phase 3: Expose Logs to Agents

Agents need a way to query logs without SSH access or cloud console dashboards. Provide at least one of:

Option A: Log file (simplest) Write structured logs to a known file path agents can read directly.

# Agent reads recent errors
tail -100 logs/app.json | jq 'select(.level == "error")'

# Agent reads logs for a specific request
grep "requestId.*abc123" logs/app.json | jq .

Option B: Dev log endpoint (recommended for web apps) Add a development-only endpoint that returns recent log entries with filtering.

GET /__dev/logs?level=error&last=50
GET /__dev/logs?path=/api/users&last=20
GET /__dev/logs?requestId=abc-123

This endpoint must:

  • Only be available in development (NODE_ENV=development or equivalent)
  • Return JSON array of log entries
  • Support filtering by level, path, timerange, requestId
  • Limit response size (default 100 entries)

See references/dev-endpoint.md for implementation patterns by framework.

Option C: CLI query tool Wrap log access in a script agents can execute:

# Query recent errors
./scripts/query-logs.sh --level error --last 50

# Query by request path
./scripts/query-logs.sh --path /api/users --since "5 minutes ago"

Choose based on project context:

Project TypeBest Option
Next.js / Express / Rails with local devOption B (dev endpoint)
CLI tool or background workerOption A (log file)
Docker-based developmentOption A (mounted log volume) or Option C
Monorepo with multiple servicesOption C (unified query script)

Phase 4: Document in Agent Docs

This is critical. Without documentation, agents won't know telemetry exists.

Update CLAUDE.md (or equivalent agent doc) with a Debugging section:

## Debugging

### Querying Application Logs

Structured JSON logs are available at [location].

**Quick commands:**

View recent errors

[command to view errors]

View logs for a specific endpoint

[command to filter by path]

View logs for a specific request

[command to filter by request ID]

View logs from the last N minutes

[command to filter by time]


**Log format:**

{ "timestamp": "ISO-8601", "level": "info|warn|error", "message": "Human-readable description", "requestId": "correlation-id", "method": "GET", "path": "/api/resource", "statusCode": 200, "duration": 45 }


**Common debugging workflows:**

- User reports error → query by time range and error level
- Flaky test → query by endpoint path during test run
- Performance issue → query by path, sort by duration

Key rules for the documentation:

  • Include copy-pasteable commands (agents execute, not read)
  • Show the log schema so agents know what fields to filter on
  • List 3-4 common debugging workflows with exact commands
  • Mention where log config lives for agents that need to adjust log levels

Phase 5: Validate

Test the full loop:

  1. Trigger a request — hit an endpoint or run an operation
  2. Query the logs — use the documented method to find the log entry
  3. Verify agent usability — can an agent find the relevant log in <3 commands?
  4. Check error capture — trigger an error and verify it appears with full context

If any step fails, iterate on the logging or documentation.

Anti-Patterns

Anti-PatternWhy It's BadDo Instead
console.log("here")No structure, no context, no filteringStructured JSON with consistent fields
Logs only in cloud dashboardAgents can't access Datadog/CloudWatchLocal file or dev endpoint
Log everything at debug levelToo noisy, can't find signalLog at boundaries, use appropriate levels
Logging sensitive dataPII in logs is a liabilityRedact tokens, passwords, PII
No request correlationCan't trace a request across log linesAdd requestId to every log entry
Docs say "check the logs" with no howAgent doesn't know where or howExact commands with examples

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude

33.34%
按下载量换算40

Codex

32.9%
按下载量换算39

Cursor

18.5%
按下载量换算22

Gemini CLI

10.69%
按下载量换算13

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills