openspec-trace-logger

Instruments Android call chains with temporary structured trace logs for runtime bug diagnosis.

1|Updated Jun 27, 2026
One-click install
npx skills add https://github.com/TE-QuanBZhang/skills-pool --skill openspec-trace-logger-te-quanbzhang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-trace-logger
Source: https://github.com/TE-QuanBZhang/skills-pool/tree/main/ai-coding/skills/openspec-trace-logger
Command: npx skills add https://github.com/TE-QuanBZhang/skills-pool --skill openspec-trace-logger-te-quanbzhang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Static analysis often fails to explain intermittent, timing-dependent, or state-driven Android bugs. This Skill inserts temporary structured trace logs across a suspected call chain to capture runtime evidence, then removes every instrumentation statement after diagnosis so no log code is ever committed. ## Core Features & Use Cases - Call Chain Discovery: Uses CodeGraph exploration to map upstream callers, downstream callees, async boundaries, and lifecycle hooks before instrumenting anything. - Contract-Based Instrumentation: Applies consistent entry/exit/state/exception log conventions with TAG-based filtering, PII masking, and performance guardrails (rate-limiting, counters, single-shot) for high-frequency functions. - Mandatory Cleanup: Mechanically removes all @TRACE- markers after analysis, verifies with assembleDebug and git diff, and refuses to ship instrumentation. - Use Case: A user reports stale data after pull-to-refresh. The Skill traces LoginRepository.authenticate through its coroutine chain, captures logcat output, identifies that a callback arrives after the fragment is destroyed, and produces an OpenSpec-formatted diagnosis. ## Quick Start Trace the call chain starting at LoginRepository.authenticate with temporary logs so I can capture runtime evidence of why the callback fires after the view is destroyed.

Frequently Asked Questions about openspec-trace-logger

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I trace an Android call chain to debug a runtime issue?

Provide an entry point like LoginRepository.authenticate or describe the buggy behavior. The Skill maps the call chain with CodeGraph, inserts temporary entry/exit/state logs, and gives you an adb logcat filter command to capture the trace.

How do I filter logcat output for trace logs?

Use the generated TAG-based filter: adb logcat -v threadtime | grep -E "\[TRACE-(NAME)\]". Each trace session gets a unique uppercase TAG derived from the entry point so app logs do not interfere.

Does the trace logging code get committed to my repository?

No. All instrumentation is temporary diagnostic scaffolding and is mechanically removed after analysis by searching for @TRACE- markers. Cleanup is verified with rg, a successful assembleDebug build, and git diff before the session ends.

Can I use this with Timber instead of android.util.Log?

Yes. The Skill detects the project's logging framework first. If Timber is present it uses Timber.tag(TAG).d(...) consistently; otherwise it falls back to android.util.Log or any project-wide debug logger utility it finds.

What happens if I instrument a high-frequency function like onDraw?

The Skill detects high-frequency patterns such as onDraw, scroll handlers, and unbounded loops before instrumenting. It then skips the function, applies timestamp-based rate limiting, uses a counter, or logs only the first call to prevent ANR and logcat flooding.

When should I not use runtime trace logging for debugging?

Avoid it when a stack trace already shows a clear single-frame cause, when the issue is purely UI/layout related, or when the bug is a missing permission or manifest misconfiguration. Dedicated crash, UI, or network debugging skills fit those cases better.