Skip to content

flutter-read-logs: add plugin for reading run logs as context#3

Open
papeye wants to merge 2 commits into
mainfrom
flutter-read-logs
Open

flutter-read-logs: add plugin for reading run logs as context#3
papeye wants to merge 2 commits into
mainfrom
flutter-read-logs

Conversation

@papeye
Copy link
Copy Markdown

@papeye papeye commented Jun 3, 2026

What

Adds a new flutter-read-logs plugin: a /read-logs skill that pulls the running app's latest flutter run output into context (auth flow, a crash, a race, "why did X happen at runtime"), plus a flutter-read-logs-usage routing skill and a README documenting setup.

Why

There was no way for Claude to see a running app's output — diagnosing runtime behaviour meant copy-pasting terminal logs. This captures flutter run output per-project and surfaces the relevant slice on demand. Piloted in a LeanCode app (meg-app) before extracting it here.

How it works

  • Logs captured per-project to /tmp/flutter-<repo>.log, derived from --git-common-dir so the main checkout and all worktrees share one file. Overwritten each launch; lives in /tmp.
  • Two capture formats, auto-detected: Zed script transcript and VS Code/Cursor dart.dapLogFile (DAP; app output extracted from event:"output" lines via a grep-prefiltered python/jq pass).
  • Reading is task-led, not a flat tail: reads the whole short run, or investigates a long one against the prompt (errors, event ordering, a feature…). Errors are one lens, not the only one.
  • Flags stale runs (age + Dart files changed since capture) and, on first use, guides editor setup (and offers to apply it) — VS Code/Cursor dapLogFile keeps F5; Zed wraps the run task in script (macOS + Linux forms). Never commits; warns before editing a tracked config file. Sensitive-data caution included.

Notes

  • Setup lives canonically in the plugin README.md; the read-logs skill repeats it inline (with a note) because it applies setup at runtime — the sanctioned exception in the contributor guide.
  • Draft until I run a VS Code end-to-end pass (auto-add dapLogFile → simulator F5 → read) and CI is green. Couldn't run go run ./cmd/validate-plugins locally (no Go); relying on CI.

Ad

i_created_a_claude_code_comamn.mp4

@papeye papeye requested review from Copilot and wzslr321 June 3, 2026 12:45
@papeye papeye marked this pull request as ready for review June 3, 2026 12:45
@papeye papeye requested a review from mkucharski17 June 3, 2026 12:46
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new flutter-read-logs plugin to the LeanCode Claude Code plugins set, enabling on-demand ingestion of the most recent flutter run output (captured per-project under /tmp) so runtime behavior can be investigated without manual log copy/paste.

Changes:

  • Introduces the /read-logs skill plus a flutter-read-logs-usage routing/help skill.
  • Adds plugin documentation (plugins/flutter-read-logs/README.md) and initial changelog/manifest.
  • Registers the plugin in the root README and marketplace manifest.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
README.md Adds flutter-read-logs to the top-level plugin list.
plugins/flutter-read-logs/skills/read-logs/SKILL.md New /read-logs skill with path resolution, format normalization, and setup guidance.
plugins/flutter-read-logs/skills/flutter-read-logs-usage/SKILL.md New usage/routing skill for setup and when-to-use guidance.
plugins/flutter-read-logs/README.md Plugin-level README describing setup and workflow.
plugins/flutter-read-logs/CHANGELOG.md Initial plugin changelog entry.
plugins/flutter-read-logs/.claude-plugin/plugin.json Plugin manifest for Claude Code marketplace tooling.
.claude-plugin/marketplace.json Registers the new plugin and its skills in the marketplace index.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +76 to +92
CLEAN="${L%.log}.clean.log"
if head -50 "$L" | grep -q '\[DAP\]\|"event":"output"'; then
echo "[format: DAP — extracting app output]"
# grep first: only the output-event lines reach the JSON parser, not the whole protocol —
# so extraction cost tracks app output, not total DAP traffic.
grep '"event":"output"' "$L" | python3 -c '
import json, sys
for line in sys.stdin:
i = line.find("{")
if i < 0: continue
try: m = json.loads(line[i:])
except Exception: continue
if m.get("event") == "output":
sys.stdout.write(m.get("body", {}).get("output", ""))
' > "$CLEAN" 2>/dev/null
# jq fallback if python3 is unavailable:
# grep '"event":"output"' "$L" | sed -E 's/^[^{]*//' | jq -rj 'select(.event=="output") | .body.output' > "$CLEAN"
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worked for me fine but I'll verify

Comment on lines +100 to +101
(If a DAP log can't be extracted because neither `python3` nor `jq` is present, tell the
user to `brew install jq` and fall back to reading matching raw lines so they're not blocked.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants