DOCSEARCHbyAlgolia
Submit Docs

LangChain Skills

repository·main·Indexed 21 days ago

https://github.com/langchain-ai/langchain-skills

Specialized agent skills for building and managing agents using LangChain, LangGraph, and Deep Agents. Designed for consumption by coding agents like Claude Code, Cursor, and Windsurf via the Agent Skills specification. Includes skills for ecosystem priming, dependency management, RAG pipelines, LangGraph persistence, and evaluation engineering using Harbor.

Tokens
61.9K
Snippets
142
Records
224
Agent score
75%

What's inside langchain-skills

  1. What is a Harness in Harbor?

    main

    In the Harbor ecosystem, a Harness represents the complete Agent being evaluated. It is the core logic and configuration that Harbor executes.

    The Harness owns:

    • Model configuration, prompts, the execution loop, routing, retries, and stopping conditions.
    • Repository-defined tool definitions, implementations, and argument/result parsing.
    • Middleware, hooks, memory, session state, and context assembly.
    • The Harbor adapter used to start the agent and record its rollout.

    The Environment owns:

    • External context such as files, data, services behind tools, permissions, network, time, and mutable external state.

  2. Preserve the production interface in the Harness

    main

    To maintain fidelity, follow the production boundary: keep repository-defined tool behavior (definition, validation, parsing, retries) within the Harness, and replace only the underlying dependency (the endpoint or data) within the Environment.

    Harness: `search_docs(query)` tool definition, validation, result parsing, retries
Environment: search endpoint, frozen documents/index, latency and error responses

  3. How the RAG pipeline works

    main

    Retrieval Augmented Generation (RAG) enhances LLM responses by fetching relevant context from external knowledge sources. The process is divided into three main stages:

    1. Index: Load documents $\rightarrow$ Split documents $\rightarrow$ Embed $\rightarrow$ Store in a vector store.
    2. Retrieve: Query $\rightarrow$ Embed query $\rightarrow$ Search vector store $\rightarrow$ Return relevant documents.
    3. Generate: Pass retrieved documents + original query $\to$ LLM $\to$ Final Response.

    Key components include Document Loaders (ingestion), Text Splitters (chunking), Embeddings (vector conversion), and Vector Stores (storage and search).

  4. Configure models and providers for LangGraph TypeScript

    main

    LangGraph works with any LangChain chat model. When setting up, you should specify a provider:model string.

    Supported Formats:

    • openai:gpt-5.5
    • anthropic:claude-sonnet-5
    • google-genai:gemini-2.5-flash-lite
    • Default: anthropic:claude-sonnet-5

    Implementation Note: Instead of using hardcoded Anthropic implementations, use initChatModel("<MODEL>") (or the equivalent for your provider) to initialize the chosen model. If using Claude Sonnet 5+, do not include temperature, top_p, or top_k parameters as they are unsupported.

  5. Project layout for Managed Deep Agents

    main

    Managed Deep Agents follow a code-first, file-based project layout where the location of a file determines its role in the managed runtime. The path passed to mda dev or mda deploy is the project root.

    File/FolderRole
    agent.py / agent.tsRequired: Must export a named agent created via define_deep_agent / defineDeepAgent.
    instructions.mdManaged system prompt, synced to Context Hub.
    tools/Authored LangChain tools the agent imports.
    middleware/Authored middleware the agent imports.
    connectors/mcp.pyRemote MCP server declarations.
    schedules/<name>.pyManaged cron schedules.
    skills/<name>/SKILL.mdDeploy-owned skills, synced to Context Hub.
    sandbox/Managed sandbox configuration (e.g., index.ts or __init__.py).
    sandbox/setup.shProvisioning script that runs once when a sandbox is created.
    .envContains deployment auth and runtime secrets (not archived).

  6. Use Deterministic Gates for Objective Facts

    main

    Do not use an LLM to verify objective facts. Instead, use code-based deterministic gates to decide the following:

    • Whether execution or tests passed.
    • Whether output was successfully parsed.
    • Whether a required artifact exists.
    • Whether a required or prohibited state change occurred.

    What to avoid in LLM prompts: Never use the following as reward conditions or judge criteria unless they are the explicit capability being tested:

    • Response length
    • Specific keywords
    • Citation count
    • Exact phrasing
    • Tool-call count
    • Reference similarity

  7. How Skills and Memory differ in Deep Agents

    main

    Deep Agents use two distinct mechanisms for context: Skills and Memory.

    • Skills use progressive disclosure. They consist of SKILL.md files stored in directories. Agents only load the content of a skill when it becomes relevant to the task, making them ideal for large documentation or task-specific instructions.
    • Memory (defined in AGENTS.md) is always loaded at startup. It is used for general preferences and compact context that the agent should always be aware of.

  8. Concept: The Environment in Eval Engineering

    main

    In the context of evaluation engineering, the Environment is a resettable container or 'world' that surrounds the Harness. It provides the necessary context and tools for a task to be executed and verified.

    What the Environment owns:

    • Infrastructure: OS, packages, files, and workspace layout.
    • Data & Knowledge: Backing documents, records, indexes, policies, and fixtures.
    • Services: The state and services behind Harness tools.
    • Control: Identity, permissions, network, clock, and feature flags.
    • Lifecycle: Initial state, observable effects, and the ability to reset between trials.

    What the Environment does NOT own:

    • The Harness's prompts, execution loop, or model decisions.
    • Repository-defined tool code, retries, or parsing logic.
    • The final response generation.

    Note: A tool server supplied to the Harness at runtime may live within the Environment.

  9. Match Verifier Evidence to Capability Types

    main

    The evidence provided to a Verifier must be tailored to the specific type of task being evaluated. The Verifier must determine the outcome independently from raw evidence and should not trust service-provided success flags.

    Capability TypeEvidence Strategy
    Retrieval or Q&AClassify claims as supported, contradicted, or unsupported against supplied sources. Note: Citations alone do not prove support.
    AnalysisProvide the independently recomputed result, required filters, and tolerances. Judge the conclusion and material caveats.
    CodingUse behavior and regression tests for correctness. Use the LLM judge only for semantic requirements that tests cannot decide.
    Stateful WorkObserve required and prohibited changes between initial and final states. Ignore unrelated fields unless they cause collateral effects.
    Tool UseGrade Harness-recorded calls and Environment-observed results/state. Never accept an agent-authored tool-use list as proof.

  10. Understand the LangChain ecosystem layers

    main

    The LangChain ecosystem consists of three layered open-source tools and an observability platform. Choosing the right layer depends on your project's complexity:

    1. Deep Agents (Harness): The top layer. Use this for long-running tasks requiring planning, file management, subagent delegation, and persistent memory. It is built on top of LangChain and LangGraph.
    2. LangGraph (Runtime): The middle layer. Use this for custom orchestration, deterministic control flows (loops, branching), and stateful workflows that require precise control over graph edges.
    3. LangChain (Framework): The bottom layer. Use this for single-purpose agents with fixed tools, RAG pipelines, or simple prompt chains. It provides the basic abstractions for models and tools.
    4. LangSmith (Observability): A cross-cutting platform for evaluation and monitoring, recommended regardless of which layer you choose.

  11. How LangGraph human-in-the-loop patterns work

    main

    LangGraph's human-in-the-loop patterns allow you to pause graph execution, surface data to users, and resume with their input. This is achieved through three core components:

    • interrupt(value): Pauses execution and surfaces the provided value to the caller (appearing in the result under __interrupt__).
    • Command(resume=value): Resumes execution, providing the value back to the interrupt() call as its return value.
    • Checkpointer: A required mechanism (e.g., InMemorySaver for dev or PostgresSaver for prod) to save the graph state while paused.
    • Thread ID: A required identifier passed via {"configurable": {"thread_id": "..."}} to every invoke or stream call to track the specific execution session.

    Critical Behavior: When a graph resumes, the node restarts from the beginning. Any code written before the interrupt() call in that node will re-run upon resumption.

    # Example of the core pattern
from langgraph.types import interrupt, Command

def my_node(state):
    # 1. Pause and surface value
    user_input = interrupt("Do you approve?") 
    # 2. When resumed via Command(resume=...), user_input gets the value
    return {"status": user_input}

  12. Organize Harbor task and run evidence directory structure

    main

    When using Harbor, follow a specific directory structure to separate task definitions from execution evidence.

    • Task Source: Place under evals/. Each directory containing a task.toml is considered a task. This directory should only contain instruction.md, environment/ assets, tests/ (Verifier code), and hidden judge evidence. Do not include plans, trace exports, audit files, credentials, or copied run output here.
    • Run Evidence: Generated run evidence must be stored under evals/jobs/.
    • Adapters and Configs: Use harbor_agents/ for Harness adapters (only when required) and configs/ for non-default configurations.

    Directory Layout Example:

    evals/
├── <task-id>/
│   ├── task.toml
│   ├── instruction.md
│   ├── environment/
│   └── tests/
├── harbor_agents/              # Harness adapter, only when required
├── configs/                    # only when non-default config is required
└── jobs/                       # generated run evidence