Problem
The diagnose skill's instrument → run → strip loop is one of the largest avoidable token sinks in the whole flow. The orchestrator pays full token price to manually Read+Edit probe logger.debug(...) statements in and back out across many files — pure mechanical churn with zero epistemic value.
Concrete recent example (traffease rolling-avg trend bug): ~9 logger.debug("rollavg.*") seam probes added across 7 files, then removed across the same 7 (helpers, unused logger imports, biome-ignore band-aids). That was many orchestrator turns of careful hand-editing. It should be near-free.
Two independent levers, roughly in priority order.
Lever 1 — make add/remove deterministic + delegated (don't hand-edit)
Removal — deterministic, no LLM needed. If probes follow a marker convention (a tag prefix like logger.debug("<slug>.*" or a // DIAG:<slug> sentinel bracketing each block), a script can detect each block's start/end and strip them all + their now-unused imports/helpers deterministically. Make "tag every probe with the run slug" a skill rule precisely so cleanup is a one-command diag strip <slug>.
Add/remove via a fast-edit preset. A /fast-edit preset with a prewritten prompt that uses openagents (composer-2.5) or the Claude SDK to add/remove the instrumentation. The orchestrator never writes the probe code itself.
Apply the #28 spec-writing pipeline to log-adding. (see #28) The exact same title→context→spec flow fits instrumentation:
- orchestrator writes only the hypotheses + target seams (terse, cheap — like the spec title)
- → pass that + full repo context once to cursor agent 1 → it writes the concrete per-seam probe edits (the detailed ~1k spec)
- → cursor agent 2 applies them
- Outcome: orchestrator emits a very concise intent; the context is read once by a cheap agent; great probes land fast. This is already the spirit of
feedback_fast_edit_fanout_instrumentation — formalize it as the default for diagnose's Phase 5.
Lever 2 — lean on PASSIVE auto-instrumentation, add far fewer bespoke logs
The bigger structural win: most diagnostic signal can come from existing, already-configured auto-instrumentation instead of hand-written logger.debug. All services already wire the heavy Sentry integrations; they just go dark in dev. Point them at the local sink (auto-DSN + ENABLE_LOGS) and you get, for ~zero added code:
- HTTP request spans across every service hop
- DB / Postgres query spans (per-query timing + SQL)
- Framework request/response spans (Express / FastAPI)
- LLM spans — crucially the agent integration (LangChain): per-agent / per-LLM-call visibility with no manual probes
trace_id auto-propagated across hops → one WHERE trace_id=… reconstructs a cross-service request- Performance benchmarking falls out of span
duration_ms for free
So the diagnose skill should default to: first query what passive instrumentation already captured (HTTP/DB/LLM spans by trace_id/run_id), and only add bespoke probes for the genuine gaps. That collapses most of Lever 1's churn because there's far less to add/strip in the first place.
(Reference: traffease has a CROSS-SERVICE-LOGS-SPEC.md plan to flip Node/Agent/Backend to auto-DSN + enable_logs in dev, mirroring what React already does — the concrete enablement work this lever depends on.)
Asks
Related: #28 (spec-writing flow this reuses).
Problem
The diagnose skill's instrument → run → strip loop is one of the largest avoidable token sinks in the whole flow. The orchestrator pays full token price to manually Read+Edit probe
logger.debug(...)statements in and back out across many files — pure mechanical churn with zero epistemic value.Concrete recent example (traffease rolling-avg trend bug): ~9
logger.debug("rollavg.*")seam probes added across 7 files, then removed across the same 7 (helpers, unusedloggerimports, biome-ignore band-aids). That was many orchestrator turns of careful hand-editing. It should be near-free.Two independent levers, roughly in priority order.
Lever 1 — make add/remove deterministic + delegated (don't hand-edit)
Removal — deterministic, no LLM needed. If probes follow a marker convention (a tag prefix like
logger.debug("<slug>.*"or a// DIAG:<slug>sentinel bracketing each block), a script can detect each block's start/end and strip them all + their now-unused imports/helpers deterministically. Make "tag every probe with the run slug" a skill rule precisely so cleanup is a one-commanddiag strip <slug>.Add/remove via a fast-edit preset. A
/fast-editpreset with a prewritten prompt that uses openagents (composer-2.5) or the Claude SDK to add/remove the instrumentation. The orchestrator never writes the probe code itself.Apply the #28 spec-writing pipeline to log-adding. (see #28) The exact same title→context→spec flow fits instrumentation:
feedback_fast_edit_fanout_instrumentation— formalize it as the default for diagnose's Phase 5.Lever 2 — lean on PASSIVE auto-instrumentation, add far fewer bespoke logs
The bigger structural win: most diagnostic signal can come from existing, already-configured auto-instrumentation instead of hand-written
logger.debug. All services already wire the heavy Sentry integrations; they just go dark in dev. Point them at the local sink (auto-DSN +ENABLE_LOGS) and you get, for ~zero added code:trace_idauto-propagated across hops → oneWHERE trace_id=…reconstructs a cross-service requestduration_msfor freeSo the diagnose skill should default to: first query what passive instrumentation already captured (HTTP/DB/LLM spans by trace_id/run_id), and only add bespoke probes for the genuine gaps. That collapses most of Lever 1's churn because there's far less to add/strip in the first place.
(Reference: traffease has a
CROSS-SERVICE-LOGS-SPEC.mdplan to flip Node/Agent/Backend to auto-DSN +enable_logsin dev, mirroring what React already does — the concrete enablement work this lever depends on.)Asks
strip <slug>cleanup./fast-editpreset(s) for add + remove, wired to the Experiment with improved openagents spec writing flow #28 title→context→spec pipeline.Related: #28 (spec-writing flow this reuses).