Macos telemetry probe

Skill Xopoko/plug-n-skills/plugins/build-swift-apps/skills/macos-telemetry-probe

Ready-to-install skills and plugins for Codex, Claude Code, and AI coding agents: practical workflows for app delivery, architecture, research, design, and agent tooling.

Install

npx -y skills add Xopoko/plug-n-skills --skill macos-telemetry-probe

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Add and verify lightweight macOS runtime telemetry with `Logger`/`os.Logger`, `log stream`, Console filters, signposts, and build-run checks.

SKILL.md

2.0 KB, as published. Nobody here has run it

macOS Telemetry Probe

Add high-signal app instrumentation without leaving noisy permanent logs. Prefer Apple's unified logging and verify events after build/run.

Rules

Use Logger from OSLog.
Give each feature a clear subsystem/category.
Log meaningful lifecycle/user events: windows, sidebar/inspector selection, commands, menu bar actions, sync/load milestones, fallback/error paths.
Keep info logs stable; use debug for noisy state.
Never log secrets, tokens, personal data, or raw document contents.
Add signposts only for timing/performance spans.

import OSLog

private let logger = Logger(
  subsystem: Bundle.main.bundleIdentifier ?? "SampleApp",
  category: "Sidebar"
)

@MainActor
func selectItem(_ item: SidebarItem) {
  logger.info("Selected sidebar item: \(item.id, privacy: .public)")
  selection = item.id
}

Use feature categories like Windowing, Commands, MenuBar, Sidebar, Sync, or Import.

Workflow

Identify the behavior needing observability.
Add one useful log per action boundary or key state transition.
Build/run with macos-runtime-debugger; if present, prefer ./script/build_and_run.sh --telemetry or --logs.
Exercise the UI/command path.

Verify through Console or:

log stream --style compact --predicate 'process == "AppName"'
log stream --style compact --predicate 'subsystem == "com.example.app" && category == "Sidebar"'

Keep useful logs; remove or demote temporary noise.

Verification

Confirm the app builds, the relevant action emits exactly one clear line or bounded sequence, logs filter by process/subsystem/category, no sensitive payloads are written, and temporary debug noise is gone. If the task is mainly crash/backtrace work, switch to macos-runtime-debugger.

Gives 0 of the 12 instructions most monitoring observability skills give

Counted across 481 of the 483 authors here whose files we hold, read 2026-08-06

link every alert to a runbookin 43 of 481, across 35 files
use structured json loggingin 36 of 481, across 31 files
alert on user-facing symptomsin 20 of 481, across 15 files
emit structured JSON logs with stable event namesin 18 of 481, across 13 files
propagate trace context across boundariesin 16 of 481
use histograms for latency trackingin 14 of 481, across 9 files
use OpenTelemetry for distributed tracingin 13 of 481, across 8 files
include a correlation ID on every log linein 13 of 481, across 8 files
Define service level objectivesin 10 of 481, across 7 files
Call useAzureMonitor before importing other modulesin 9 of 481, across 2 files
stop and ask for clarification if inputs are missingin 9 of 481, across 2 files
define on-call questions before adding telemetryin 9 of 481, across 4 files

Said here and by no other author read

use Logger from OSLog
assign each feature a subsystem and category
log lifecycle and user events
use debug logs for noisy state
add signposts for timing spans
add one log per action boundary

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.