Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
akillness avatar

Langsmith

  • 209 installs
  • 40 repo stars
  • Updated August 4, 2026
  • akillness/oh-my-skills

Trace, evaluate, and debug LangChain/LangGraph agent runs in LangSmith to catch regressions, latency spikes, and bad tool calls in production LLM apps.

About

Uses LangSmith to inspect LangChain and LangGraph traces, score outputs, build evaluation datasets, and debug failing tool calls so teams maintain reliable, measurable agent behavior after deployment.

  • LangSmith trace inspection
  • LLM run debugging
  • Dataset evaluations
  • Prompt and chain regression tests
  • Production agent observability

Langsmith by the numbers

  • 209 all-time installs (skills.sh)
  • Ranked #2,828 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/akillness/oh-my-skills --skill langsmith

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs209
repo stars40
Last updatedAugust 4, 2026
Repositoryakillness/oh-my-skills

What it does

Trace, evaluate, and debug LangChain/LangGraph agent runs in LangSmith to catch regressions, latency spikes, and bad tool calls in production LLM apps.

Files

SKILL.mdMarkdownGitHub ↗

LangSmith

When to use this skill

  • The user already chose LangSmith and needs the smallest useful packet for tracing, evals, review, prompt ownership, or trace propagation.
  • A request mentions LangChain tracing, `@traceable` / `traceable`, `wrap_openai` / `wrapOpenAI`, annotation queues, run trees, trace IDs, datasets, or experiment comparison.
  • The team needs to decide whether a change needs debugging traces, an offline eval gate, an online review queue, Prompt Hub / prompt-registry work, or multi-service lineage.
  • The user has some LangSmith setup already, but confidence is still low and they need an audit / gap review.

Do not use this skill as the main workflow when:

  • The real job is generic dashboards / alerts / SLOs / telemetry ownershipmonitoring-observability
  • The real job is existing-log root-cause triagelog-analysis
  • The real job is code-level reproduction / bug isolationdebugging
  • The real job is deployment / rollout choreographydeployment-automation
  • The real job is generic exported-metrics interpretation or KPI synthesisdata-analysis
  • The real job is runtime guardrails / approvals / policy middleware → the relevant security or policy skill

Core idea

langsmith should behave like a workflow packet router, not a giant SDK encyclopedia.

1. Label the request before naming APIs. 2. Choose one primary packet. 3. Pick the smallest instrumentation / eval / review surface that answers the question. 4. Return a compact operator brief. 5. Route adjacent observability, debugging, deployment, and policy work outward fast.

Read these support docs before choosing the packet:

  • references/intake-packets-and-route-outs.md
  • references/modes-and-routing.md
  • references/python-sdk.md
  • references/typescript-sdk.md
  • references/cli.md

Instructions

Step 1: Normalize the request

Convert the prompt into this intake packet first:

langsmith_packet:
  primary_packet: trace-debug | eval | review | prompt-registry | propagation | audit
  app_shape: chat | rag | tool-calling | agent | batch-job | multi-service | mixed | unknown
  runtime: python | typescript | mixed | cli-only | unknown
  request_type: setup | debug | pre-ship gate | production review | prompt decision | cross-service tracing | audit
  current_evidence: traces | datasets | evaluators | feedback queues | prompt versions | exported runs | none
  confidence_problem: missing traces | noisy traces | no regression gate | weak review rubric | prompt drift | broken lineage | mixed | unknown
  route_after: stay-here | monitoring-observability | log-analysis | debugging | deployment-automation | data-analysis

Choose one primary packet for the run. If two seem plausible, pick the one that reduces uncertainty fastest.

Step 2: Choose the packet

PacketUse whenMain outputTypical signals
trace-debugThe real question is “what happened?”trace-debug packetmissing visibility, wrappers/decorators, trace coverage, metadata discipline
evalA change needs pre-ship or regression confidenceeval packetdataset creation, evaluators, experiments, baseline/candidate comparison
reviewTraces exist but trust is weak in productionreview packetannotation queues, feedback criteria, human scoring, inline review
prompt-registryPrompt/version ownership is the bottleneckprompt packetPrompt Hub, prompt versions, Git sync, compare prompt variants
propagationOne request spans services, jobs, tools, or agentspropagation packetparent/child trace IDs, cross-service headers, multi-hop lineage
auditLangSmith is present but still not usefulaudit packetnoisy traces, missing IDs, absent evals, unclear prompt ownership

Packet rules:

  • Prefer trace-debug when the team cannot explain the run tree.
  • Prefer eval when the next risk is shipping without a regression gate.
  • Prefer review when real-user output needs human or structured quality feedback.
  • Prefer prompt-registry only when prompt/version choice is the actual bottleneck.
  • Prefer propagation when one request fans out beyond a single service boundary.
  • Prefer audit when the system already “has LangSmith” but confidence is still low.

Step 3: Pick the smallest useful surface

SurfaceUse whenStrengthsRisks
Provider wrappers (wrap_openai, wrap_anthropic, wrapOpenAI)Need quick model-call coverageFastest path to visible tracesMisses higher-level workflow context if used alone
Decorators / traceable()Need named spans around app functionsClear span boundaries, reusableStill needs deliberate placement
Manual trace blocks / tracing contextNeed scoped or temporary visibilityGood for audits and suspicious blocksEasy to under-instrument
Annotation queues + feedback criteriaNeed structured human reviewPreserves rubric and reviewer flowReview ownership still has to be designed
Dataset + experiment workflowNeed benchmark or regression checksGives pre-ship comparisonCan drift into generic eval theory if not bounded
CLI export/list/get flowsNeed audit/export operations more than instrumentationGood for scripts and inspectionNot a substitute for instrumentation design
Cross-service propagation headers / metadataNeed end-to-end lineagePreserves parent/child contextEasy to forget at service boundaries

Rules:

  • Prefer the smallest surface that answers the present question.
  • Always name project/workspace/environment grouping.
  • Preserve run_id, trace_id, and metadata if humans or downstream tools will review runs later.
  • Include shutdown flush / wait behavior for CLIs, workers, and short-lived jobs.

Step 4: Choose the eval or review layer only when needed

LayerUse whenNotes
Deterministic / code evaluatorOutput can be checked mechanicallyBest first choice for structure/factual rules
LLM-as-judge (openevals)Quality is subjective or reference-lightUseful, but not ground truth
Human reviewStakes are high or nuance dominatesNeeds rubric, reviewer, and cadence
Pairwise comparisonTwo prompts/models/app versions are being comparedGood for baseline vs candidate decisions
Online evaluatorProduction traffic needs ongoing scoringPair with explicit alert/review semantics

Do not pretend one layer replaces the others.

Step 5: Return one compact LangSmith brief

Default response shape:

## LangSmith brief
- Packet: trace-debug | eval | review | prompt-registry | propagation | audit
- App shape: ...
- Runtime: ...
- Current evidence: ...

## Chosen surface
- wrappers / decorators / manual trace / dataset+experiment / review queue / prompt registry / propagation headers

## Required config
- `LANGSMITH_API_KEY`
- project/workspace/environment
- endpoint/workspace overrides if self-hosted

## Required IDs / metadata
- `run_id`, `trace_id`, tags, metadata fields, user/session identifiers as needed

## Verification step
- one trace query, one experiment comparison, one queue review check, or one prompt-version sanity check

## Route-out
- next neighboring skill if the bottleneck moves

Keep it compact. The point is to leave the user with one smallest next artifact, not a wall of SDK notes.

Step 6: Packet-specific heuristics

For trace-debug
  • Start from the missing visibility surface: app span, tool calls, retrieval, provider call, or worker boundary.
  • Prefer wrappers plus a few high-value decorators over tracing everything blindly.
  • Return the first trace query/filter the team should run once instrumentation lands.
For eval
  • Define the smallest dataset that reflects the risky change.
  • Separate deterministic checks from LLM-as-judge or human review.
  • Name baseline/candidate comparison, experiment naming, concurrency/cost limits, and the ship/no-ship decision point.
For review
  • Define feedback keys, scale semantics, reviewer ownership, and queue cadence.
  • Preserve run_id / trace_id so feedback attaches to the right artifact later.
  • Route broader support-ops workflows out if the issue is bigger than output review.
For prompt-registry
  • Explicitly decide whether Prompt Hub / LangSmith should own the prompt or whether Git/app config should stay canonical.
  • Connect prompt versions to evals or experiments; do not treat registry as a separate island.
  • Be explicit when public hub browsing is reference-only rather than the team's source of truth.
For propagation
  • Name parent/child headers, metadata handoff rules, and which services must preserve trace context.
  • Keep distributed-systems reliability and alerting concerns routed to generic observability where appropriate.
For audit
  • Rank gaps by severity: missing coverage, bad metadata, absent evals, weak review flow, prompt/version ambiguity, broken flush or lineage.
  • Recommend the first ratchet, not a giant reinstall plan.

Step 7: Route out aggressively

Switch as soon as LangSmith is no longer the main bottleneck:

  • Generic telemetry / dashboards / alerts / SLOsmonitoring-observability
  • Existing-log root-cause triagelog-analysis
  • Reproduction and bug isolationdebugging
  • Rollout / deploy / environment promotiondeployment-automation
  • Exported metrics, experiments, or KPI interpretationdata-analysis
  • Policy / approval / runtime guardrails → the relevant security or policy skill

Examples

Example 1: Trace-debug packet

Prompt:

Add LangSmith to this FastAPI RAG service so we can debug why answer quality regressed after a retriever change.

Good response shape:

  • choose trace-debug
  • recommend wrappers plus targeted higher-level spans if retrieval/tools must be visible
  • define project/tags/metadata and a flush step for short-lived runs
  • route generic service-health observability outward

Example 2: Eval packet

Prompt:

Before we ship this prompt rewrite, build a LangSmith eval workflow with a baseline, a candidate, and one judge for subjective quality.

Good response shape:

  • choose eval
  • define dataset, evaluator mix, experiment naming, and verification step
  • separate deterministic checks from LLM-as-judge and human review
  • keep rollout orchestration out of scope

Example 3: Review packet

Prompt:

We already have LangSmith traces, but support leads still do not trust the AI assistant. Set up a review workflow with human scoring.

Good response shape:

  • choose review
  • define feedback keys, rubric, queue ownership, and run-ID preservation
  • keep the answer grounded in review workflow rather than generic prompt management

Example 4: Prompt-registry packet

Prompt:

Should these prompts live in LangSmith Prompt Hub or stay in Git?

Good response shape:

  • choose prompt-registry
  • compare platform-owned vs Git-owned prompt source of truth
  • connect the choice to experiments and release confidence
  • stay honest when Prompt Hub is optional

Example 5: Propagation packet

Prompt:

One chat request fans out to workers and tools. How do we keep one trace through LangSmith?

Good response shape:

  • choose propagation
  • define parent/child IDs, metadata propagation, and service boundaries
  • route generic distributed-systems observability outward when needed

Best practices

1. Start with the packet, not the SDK call. 2. Treat LangSmith as a trace/eval/review substrate, not the entire production control plane. 3. Preserve run_id, trace_id, tags, and metadata deliberately. 4. Prefer the smallest useful surface that answers the present question. 5. Keep deterministic checks, LLM judges, and human review distinct. 6. Be explicit when Prompt Hub is optional or reference-only. 7. Include flush/wait behavior for scripts, workers, and cron-style jobs. 8. End with one verification step and one route-out.

References

  • references/intake-packets-and-route-outs.md
  • references/modes-and-routing.md
  • references/python-sdk.md
  • references/typescript-sdk.md
  • references/cli.md
  • Official docs: https://docs.langchain.com/langsmith
  • SDK repo: https://github.com/langchain-ai/langsmith-sdk
  • OpenEvals: https://github.com/langchain-ai/openevals

Related skills

AI & Agent Buildingagentsllmautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.