$npx -y skills add sickn33/agentic-awesome-skills --skill agenttrace-session-auditAudit local AI coding-agent sessions with agenttrace for cost, tool failures, latency, anomalies, health, diffs, and CI gates.
| 1 | # agenttrace Session Audit |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill to inspect local AI coding-agent sessions with |
| 6 | [agenttrace](https://github.com/luoyuctl/agenttrace). It focuses on the process |
| 7 | behind a run: token and cost spikes, tool failures, retry loops, latency gaps, |
| 8 | anomalies, health scores, and session-to-session diffs. |
| 9 | |
| 10 | agenttrace is local-first and reads session logs from tools such as Claude Code, |
| 11 | Codex CLI, Gemini CLI, Aider, Cursor exports, OpenCode, Qwen Code, Kimi, and |
| 12 | generic JSON or JSONL traces. |
| 13 | |
| 14 | ## When to Use This Skill |
| 15 | |
| 16 | - Use when a user asks why an AI coding run was slow, expensive, shallow, or unreliable. |
| 17 | - Use when reviewing local agent logs before retrying a failed or suspicious task. |
| 18 | - Use when building a lightweight CI health gate for AI-assisted coding sessions. |
| 19 | - Use when comparing two attempts and looking for changed tool paths, retries, or cost patterns. |
| 20 | |
| 21 | ## How It Works |
| 22 | |
| 23 | ### Step 1: Discover Available Sessions |
| 24 | |
| 25 | Prefer an installed `agenttrace` binary when it is available on `PATH`. If the |
| 26 | current repository is `luoyuctl/agenttrace`, use `go run ./cmd/agenttrace` |
| 27 | instead. |
| 28 | |
| 29 | ```bash |
| 30 | agenttrace --doctor |
| 31 | agenttrace --overview |
| 32 | ``` |
| 33 | |
| 34 | If no sessions are detected, report the directories checked by `--doctor` and |
| 35 | ask for the exported session file or log directory. |
| 36 | |
| 37 | ### Step 2: Produce a Human-Readable Audit |
| 38 | |
| 39 | Use Markdown when the user wants a concise report they can inspect or share. |
| 40 | |
| 41 | ```bash |
| 42 | agenttrace --overview -f markdown -o agenttrace-overview.md |
| 43 | ``` |
| 44 | |
| 45 | In the report, lead with the highest-risk sessions and explain why they matter: |
| 46 | critical anomalies, repeated tool failures, token or cost waste, long latency |
| 47 | gaps, low health scores, and suspiciously shallow sessions. |
| 48 | |
| 49 | ### Step 3: Inspect One Session or Directory |
| 50 | |
| 51 | Use the latest session for a quick check, or pass an explicit export path when |
| 52 | the user provides one. |
| 53 | |
| 54 | ```bash |
| 55 | agenttrace --latest |
| 56 | agenttrace --latest -f json |
| 57 | agenttrace path/to/session-or-export.json |
| 58 | agenttrace --overview -d path/to/session-dir |
| 59 | ``` |
| 60 | |
| 61 | ### Step 4: Compare Attempts When Semantics Matter |
| 62 | |
| 63 | Token and latency metrics can look healthy even when an agent confidently takes |
| 64 | the wrong implementation path. When the risk is semantic drift, pair the trace |
| 65 | audit with a diff against a previous or known-good attempt. |
| 66 | |
| 67 | Look for: |
| 68 | |
| 69 | - changed files or commands that diverge from the intended task |
| 70 | - missing tests or verification steps compared with the reference attempt |
| 71 | - repeated edits around the same files without a clear reason |
| 72 | - lower cost that came from skipping necessary exploration |
| 73 | |
| 74 | ### Step 5: Add Automation Gates |
| 75 | |
| 76 | For CI or repeatable team workflows, use JSON output or health thresholds. |
| 77 | |
| 78 | ```bash |
| 79 | agenttrace --overview -f json -o agenttrace-overview.json |
| 80 | agenttrace --overview --fail-under-health 80 --fail-on-critical --max-tool-fail-rate 15 |
| 81 | ``` |
| 82 | |
| 83 | Tune thresholds to the project. A strict gate is useful for critical workflows; |
| 84 | a reporting-only command is better while the team is learning its baseline. |
| 85 | |
| 86 | ## Examples |
| 87 | |
| 88 | ### Quick Local Review |
| 89 | |
| 90 | ```bash |
| 91 | agenttrace --overview |
| 92 | agenttrace --latest |
| 93 | ``` |
| 94 | |
| 95 | Use this after a long coding-agent run to decide whether the next prompt should |
| 96 | split the task, avoid a failing tool path, add missing tests, or reset context. |
| 97 | |
| 98 | ### CI Health Check |
| 99 | |
| 100 | ```bash |
| 101 | agenttrace --overview --fail-under-health 80 --fail-on-critical |
| 102 | ``` |
| 103 | |
| 104 | Use this when agent session logs are available in CI and the team wants a simple |
| 105 | guard against critical anomalies or unhealthy runs. |
| 106 | |
| 107 | ## Best Practices |
| 108 | |
| 109 | - Start with `--doctor` when session discovery is uncertain. |
| 110 | - Report missing fields plainly; do not invent cost, model, latency, or health data. |
| 111 | - Treat prompts, code, and session contents as private local data. |
| 112 | - Prefer JSON output for automation and Markdown output for human review. |
| 113 | - Use trace metrics for process failures and diff/reference review for semantic drift. |
| 114 | |
| 115 | ## Limitations |
| 116 | |
| 117 | - agenttrace can only analyze logs that are present locally or provided as exports. |
| 118 | - Some agents do not expose enough fields to infer cost, model, cache use, or latency. |
| 119 | - Healthy trace metrics do not prove the final code is correct; still run tests and review diffs. |
| 120 | - CI gates should start as advisory until the team understands normal baseline behavior. |
| 121 | |
| 122 | ## Security & Safety Notes |
| 123 | |
| 124 | - Do not upload private session logs to external services unless the user explicitly approves it. |
| 125 | - Do not overwrite user reports unless they requested that exact output path. |
| 126 | - Avoid printing secrets found in p |