
Debug
When a Symphony run stalls, retries endlessly, or fails mysteriously, this walks you through the correlation dance between Linear tickets and Codex sessions. You'll grep symphony.log for issue_identifier keys, extract session_ids, and trace the lifecycle from startup through completion or failure. The investigation flow is methodical: narrow by ticket, pull the timeline, classify whether it's a stall loop or turn failure or worker crash, then capture evidence with the right identifiers. The commands are straightforward rg oneliners, and the guidance on reading Codex session logs as a three-stage lifecycle (start, stream, terminal event) is actually clarifying. It assumes you know the Symphony runtime already but saves you from wandering through logs blind.
- skills.sh installs
- 551
- GitHub stars
- 82
- last updated
- Aug 21, 2026
Install
$ npx -y skills add odysseus0/symphony --skill debug --agent claude-codeInstalls into .claude/skills of the current project.
Files
Debug
Goals
- Find why a run is stuck, retrying, or failing.
- Correlate Linear issue identity to a Codex session quickly.
- Read the right logs in the right order to isolate root cause.
Log Sources
- Primary runtime log:
log/symphony.log- Default comes from
SymphonyElixir.LogFile(log/symphony.log). - Includes orchestrator, agent runner, and Codex app-server lifecycle logs.
- Default comes from
- Rotated runtime logs:
log/symphony.log*- Check these when the relevant run is older.
Correlation Keys
issue_identifier: human ticket key (example:MT-625)issue_id: Linear UUID (stable internal ID)session_id: Codex thread-turn pair (<thread_id>-<turn_id>)
elixir/docs/logging.md requires these fields for issue/session lifecycle logs. Use
them as your join keys during debugging.
Quick Triage (Stuck Run)
Sponsors
Details
- Repository
- github.com/odysseus0/symphony
- Categories
- Git & Pull Requests, Debugging
- First seen
- Jun 3, 2026