Conciseness

The body is efficient and assumes competence — it gives migration-specific judgment ("Shutdown ordering matters: flush traces, then metrics, then logs. Use a timeout (10-30s)", effort percentages, the Fiber gotcha) rather than explaining OTel concepts. Not a 5 because the framework table carries several information-free "N/A" rows and the Phase 3 per-language difficulty list partially duplicates content delegated to context-propagation-patterns.md; not a 3 because there is no real padding — every section carries non-obvious guidance.

Actionability

Guidance is concrete and executable in the main: exact API calls in the table ("c.UserContext()", "c.Request.Context()"), specific orderings and timeouts, and a precise bridging directive ("Prometheus bridge reads from the existing registry... existing `prometheus.NewCounterVec(...)` calls continue unchanged"). Not a 5 because there is no copy-paste-ready code or command inline — code is deferred to reference files; not a 3 because the directives are exact method names, orderings, and priorities, far beyond pseudocode, and detail is deliberately delegated to well-signaled references.

Workflow Clarity

Six phases are explicitly sequenced ("The migration follows six phases in order. Each phase is independently deployable and verifiable") with an explicit per-phase checkpoint ("After each phase, verify that instrumentation is correct and complete") and a bundled verification checklist. Not a 5 because no error-recovery feedback loop (what to do when verification fails) is articulated in the body — it must be inferred from the checklist reference; not a 3 because checkpoints are explicit, not implicit, and a checklist for the complex process exists.

Progressive Disclosure

The body is a true overview that delegates detail to one-level-deep, clearly signaled references; all five bundled files in references/ (framework-middleware, context-propagation-patterns, bridge-libraries, verification-checklist, migration-pitfalls) are referenced at the exact point of need, and cross-skill pointers (otel-instrumentation, beeline-migration) are explicit. Content is appropriately split and navigation is easy.

Specificity

The opening sentence names one concrete action ("Retrofitting OpenTelemetry into an existing, uninstrumented application"), and the trigger list enumerates several more specific capabilities — "thread context through my code", "bridge Prometheus metrics to OTel", "logging bridge", "slog bridge", "logback bridge". Not a 5 because verification appears only as a trigger phrase ("verify my instrumentation") rather than a stated capability, so coverage has a minor gap; not a 3 because well more than 1-2 concrete actions are explicitly named.

Completeness

Explicitly answers 'what' ("Retrofitting OpenTelemetry into an existing, uninstrumented application") and 'when' via a dedicated, concrete trigger-phrase list — equivalent explicit trigger guidance that lifts the completeness cap. Matches the anchor example's pattern of a clear what plus explicit use-when triggers.

Trigger Term Quality

Comprehensive natural-term coverage with synonyms ("OTel" / "OpenTelemetry"), user-voiced phrasings ("how do I sequence an OTel migration", "keep existing logging working with OTel", "add OTel without breaking Prometheus"), and symptom-based triggers ("traces are disconnected", "orphaned spans", "Fiber context gotcha"). Clearly exceeds the 'a few natural terms missing' anchor at 4.

Distinctiveness Conflict Risk

Clear niche (brownfield retrofit into an existing, uninstrumented app) with explicit boundary guidance: "For greenfield instrumentation use otel-instrumentation; for Beelines use beeline-migration." Distinct, specific triggers (Fiber gotcha, Prometheus bridging) make wrong-skill triggering unlikely.