The coding agent says it's done, and I want to see how it actually did it

When you have a coding agent run a skill, the most frustrating moment often comes after it finishes: it says it's done, and all you see is the final reply. What it asked along the way, which version of the plan you approved, what you rejected in permission prompts, and which files it ultimately changed are all scattered across a long session. To review a failed run, you have to dig through logs and rely on memory.

skill-trace is a local read-only dashboard built specifically to fill this gap. It reads the session logs and skill directories that Claude Code, Codex, and OpenCode have already written to disk, and breaks a skill run into a replayable record. You don't need to install anything into the agent, and it doesn't change the agent's settings or context. It doesn't improve generation quality; it solves post-hoc explanation.

Here, a skill can be understood as a reusable workflow or instruction bundle loaded by the agent, usually a folder containing SKILL.md. A run starts when the agent loads a skill or you type /skill-name, and ends at the next skill or an unrelated request. Answering its questions in the middle, replying briefly with yes or 2, or adding messages while it runs all stay within the same run.

A run is split into three parts: what you asked for, how it proceeded, and what it ultimately delivered. Tool calls are collapsed into groups; expand them to see the complete input and output for each step. The play button lets you replay step by step.

What truly affects the outcome are the moments of human intervention, and the dashboard pulls them out separately: questions and options Claude asked, what you selected or typed yourself; plans and feedback you approved or sent back; actions you rejected in permission prompts; and messages, answers, and interruptions added during the run.

The timeline view places each step on a timeline, colors them by tool type, and even includes the time spent waiting for your reply. Hover to inspect a step, click to view details.

The skills view lists local, project, plugin, and built-in skills, with run counts, average duration, and 14-day trends. Open one to read the rendered SKILL.md, browse files, and view run history. The overview page summarizes what is currently running, when skills generally run, and which are used most.

At the top you can switch between Claude Code, Codex, and OpenCode, and every skill and run carries a source tag. The settings page lets you correct directories that were detected incorrectly and track only the skills you care about. The page updates in real time; skills that are currently running appear in the overview, and those that have stopped to wait for a reply are marked as Waiting for you.

The privacy boundary is fairly clear: the service only listens on 127.0.0.1, makes no network requests, collects no telemetry, and even bundles fonts locally. It only writes its own config file at ~/.config/skill-trace/config.json. The page can display full requests and tool outputs, which may contain secrets, so don't expose the port publicly.

Installation requires Node.js 20.19 or newer.

git clone https://github.com/Gamehu/skill-trace.git
cd skill-trace
npm install
npm run build
npm start

Then open http://localhost:4317. Use a skill in Claude Code, and the run will appear in real time. If you don't have any run records yet, you can first run npm run build && npm run demo to see generated data, which includes a session that keeps updating in real time.

A few limitations are stated explicitly: Codex runs are inferred from recorded SKILL.md reads, so skills that leave no observable file reads may be missed; OpenCode uses skill tool records in opencode.db, and under Node 20 it also requires the sqlite3 command to be available on the system.

People in the comments have already raised two very practical requests: add a filter specifically to see whether any changes still happen after you press stop, to confirm whether the interruption took effect; and put rejected plans side by side with the final diff to explain those agent PRs that look baffling. The second request is quite telling: many runs have strange results because the reason is hidden in the middle: a plan was rejected, a permission was blocked, or a follow-up question was ignored.

The project is open source under MIT, with the repository on GitHub: https://github.com/Gamehu/skill-trace