Apple runtime telemetry workflow
Skill gaelic-ghost/socket/plugins/apple-dev-skills/skills/apple-runtime-telemetry-workflow
The Source for macOS Agent Workflows
npx -y skills add gaelic-ghost/socket --skill apple-runtime-telemetry-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 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 privacy-aware Apple unified logging and signposts in macOS, iOS, and related Apple apps. Use when designing Logger categories, diagnosing intermittent runtime behavior, collecting focused evidence, or measuring an operation with OSSignposter.
SKILL.md
2.8 KB, as published. Nobody here has run it
Apple Runtime Telemetry Workflow
Purpose
Add the smallest useful unified-log and signpost evidence to diagnose a concrete runtime question. This workflow owns Logger, subsystem/category design, privacy, evidence capture, and OSSignposter boundaries. It does not own generic server observability, analytics, crash reporting services, or broad event collection.
Workflow
- State the question to answer: lifecycle, command, window/scene transition, failure classification, or duration. Do not add telemetry without a specific observation need.
- Choose a stable subsystem and a narrow category named for the owning feature. Keep a local logger close to that feature instead of creating an application-wide logging manager.
- Emit a small lifecycle record at the transition and a precise error or fault record at a classified failure. Include non-sensitive identifiers only when they make the event actionable.
- Leave interpolated values private by default. Mark a value
.publiconly after confirming that it has no user, account, file-path, content, credential, or other sensitive-data meaning. - Use
OSSignposteronly when duration or event timing is the question. Begin and end the same measured operation, retain the interval state correctly, and inspect the result in Instruments rather than treating an ordinary log line as a timing measurement. - Reproduce the relevant flow and inspect the evidence in Xcode's debug console, Console, or the
logtool. Filter by the documented subsystem/category and preserve only the minimal output needed to support the diagnosis. - Remove temporary high-volume records after the investigation, or keep a small durable lifecycle/error set with a clear operational value.
Guards
- Do not create a logging manager, repository, analytics pipeline, telemetry daemon, or remote collector for ordinary app diagnostics.
- Do not put secrets, personal data, file contents, raw request bodies, authorization material, or full unreviewed object descriptions in logs.
- Do not use
OSLogStore.local()as a default app feature; Apple documents that local-store access needs an admin account and thecom.apple.logging.local-storeentitlement. - Do not claim a signpost proves a performance improvement until an Instruments capture measures the same scenario.
- Hand ETTrace, memgraphs, leaks, and trace comparison to
ios-runtime-forensics-workflow; hand build/run mechanics toxcode-build-run-workflow.
References
references/logger-privacy-and-evidence.mdreferences/signposts-and-runtime-capture.md