mirror of
https://github.com/hatchet-dev/hatchet.git
synced 2026-05-01 07:00:13 -05:00
feat(agents): add new agent instruction tools (#3059)
This commit is contained in:
Gabe Ruttner
@@ -31,7 +31,7 @@ const nextConfig = {
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/:path((?!api|home|cli|v1|v0|compute|sdk|contributing|self-hosting|launches|blog|llms|favicon\\.ico|.*\\.png|.*\\.gif|.*\\.svg|_next/.*|monitoring\-demo\.mp4).*)',
|
||||
source: '/:path((?!api|agent-instructions|home|cli|v1|v0|compute|sdk|contributing|self-hosting|launches|blog|llms|favicon\\.ico|.*\\.png|.*\\.gif|.*\\.svg|_next/.*|monitoring\-demo\.mp4).*)',
|
||||
destination: '/home/:path*',
|
||||
permanent: false,
|
||||
},
|
||||
@@ -40,6 +40,11 @@ const nextConfig = {
|
||||
destination: "https://app.posthog.com/:path*",
|
||||
permanent: false,
|
||||
},
|
||||
{
|
||||
source: "/home/install-docs-mcp",
|
||||
destination: "/home/coding-agents",
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: "/home/basics/overview",
|
||||
destination: "/home/setup",
|
||||
|
||||
@@ -31,6 +31,14 @@ export default {
|
||||
toc: false,
|
||||
},
|
||||
},
|
||||
"agent-instructions": {
|
||||
title: "Agent Instructions",
|
||||
type: "page",
|
||||
display: "hidden",
|
||||
theme: {
|
||||
toc: false,
|
||||
},
|
||||
},
|
||||
sdks: {
|
||||
title: "SDK Reference",
|
||||
type: "menu",
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
export default {
|
||||
"setup-cli": "Setup CLI",
|
||||
"start-worker": "Start Worker",
|
||||
"trigger-and-watch": "Trigger & Watch",
|
||||
"debug-run": "Debug a Run",
|
||||
"replay-run": "Replay a Run",
|
||||
};
|
||||
@@ -0,0 +1,80 @@
|
||||
# Debug a Hatchet Run
|
||||
|
||||
These are instructions for an AI agent to diagnose why a Hatchet run failed, is stuck, or behaved unexpectedly. Follow each step in order.
|
||||
|
||||
## Step 1: Get Run State
|
||||
|
||||
```bash
|
||||
hatchet runs get RUN_ID -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
Examine the JSON response:
|
||||
|
||||
- `.run.status` -- the overall run status (`QUEUED`, `RUNNING`, `COMPLETED`, `FAILED`, `CANCELLED`)
|
||||
- `.run.displayName` -- the workflow name
|
||||
- `.run.input` -- the input that was provided when the workflow was triggered
|
||||
- `.tasks[]` -- each task in the run, with its own `status`, `displayName`, and `output` or `errorMessage`
|
||||
- `.tasks[].startedAt` and `.tasks[].finishedAt` -- timing information
|
||||
|
||||
## Step 2: Get Event Log
|
||||
|
||||
```bash
|
||||
hatchet runs events RUN_ID -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
The event log shows the full lifecycle of the run. Each event has:
|
||||
|
||||
- `eventType` -- what happened (e.g. `QUEUED`, `STARTED`, `FINISHED`, `FAILED`, `CANCELLED`)
|
||||
- `message` -- human-readable description
|
||||
- `taskDisplayName` -- which task the event belongs to
|
||||
- `timestamp` -- when it happened
|
||||
|
||||
Read events in chronological order to understand the sequence of what happened.
|
||||
|
||||
## Step 3: Get Logs
|
||||
|
||||
```bash
|
||||
hatchet runs logs RUN_ID -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
This prints the application-level log output from the task code (e.g. print statements, logger calls). For multi-task (DAG) runs, logs from all tasks are merged and sorted by timestamp with task name prefixes.
|
||||
|
||||
## Diagnostic Cheat Sheet
|
||||
|
||||
### Task stuck in QUEUED (no STARTED event)
|
||||
|
||||
The task was never picked up by a worker. Likely causes:
|
||||
|
||||
- **No worker is running.** Start one with `hatchet worker dev -p HATCHET_PROFILE`.
|
||||
- **Worker does not register this task type.** The task name in the workflow definition must match what the worker code registers. Check the worker startup logs.
|
||||
- **Worker is connected to a different tenant/profile.** Verify the worker and the trigger use the same `-p` profile.
|
||||
|
||||
### Task FAILED
|
||||
|
||||
Check the logs output from Step 3 for a stack trace or error message. Common causes:
|
||||
|
||||
- Unhandled exception in the task code.
|
||||
- Timeout exceeded.
|
||||
- A dependency (database, API, etc.) was unreachable.
|
||||
|
||||
The events from Step 2 will show a `FAILED` event with an error message.
|
||||
|
||||
### Task CANCELLED
|
||||
|
||||
Check the events for a `CANCELLED` event. The message field indicates the cancellation source:
|
||||
|
||||
- Manual cancellation via the dashboard or CLI.
|
||||
- Parent workflow cancellation (for DAG workflows).
|
||||
- Timeout-based cancellation.
|
||||
|
||||
### Run COMPLETED but output is wrong
|
||||
|
||||
If the run completed but produced unexpected results:
|
||||
|
||||
1. Check `.tasks[].output` in the run state (Step 1) to see what each task returned.
|
||||
2. Check the logs (Step 3) to trace the execution flow.
|
||||
3. Check `.run.input` to verify the correct input was provided.
|
||||
|
||||
### Slow execution
|
||||
|
||||
Compare `startedAt` and `finishedAt` timestamps for each task in Step 1 to identify which task is the bottleneck. Check if there is a long gap between the run being triggered and the first task starting (indicates queuing delay, possibly due to worker capacity).
|
||||
@@ -0,0 +1,78 @@
|
||||
# Replay a Hatchet Run
|
||||
|
||||
These are instructions for an AI agent to replay a previously executed Hatchet run, optionally with modified input. Follow each step in order.
|
||||
|
||||
## Step 1: Inspect the Original Run
|
||||
|
||||
First, understand what happened in the original run:
|
||||
|
||||
```bash
|
||||
hatchet runs get RUN_ID -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
From the response, note:
|
||||
|
||||
- `.run.displayName` -- the workflow name (needed if re-triggering with new input)
|
||||
- `.run.input` -- the original input JSON
|
||||
- `.run.status` -- why you might be replaying (e.g. `FAILED`)
|
||||
- `.tasks[].status` and `.tasks[].errorMessage` -- which specific tasks failed and why
|
||||
|
||||
## Step 2a: Replay with the Same Input
|
||||
|
||||
If you want to re-run the exact same workflow with the same input (e.g. after fixing a bug in the task code):
|
||||
|
||||
```bash
|
||||
hatchet runs replay RUN_ID -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
This creates a new run of the same workflow with the same input. The response includes the new run IDs in `.ids[]`.
|
||||
|
||||
## Step 2b: Replay with New Input
|
||||
|
||||
If you need to change the input (e.g. fixing bad input data), you must trigger a new run instead of using replay:
|
||||
|
||||
Write the new input JSON to a uniquely-named temp file:
|
||||
|
||||
```bash
|
||||
HATCHET_INPUT_FILE="/tmp/hatchet-input-$(date +%s)-$$.json"
|
||||
cat > "$HATCHET_INPUT_FILE" << 'ENDJSON'
|
||||
NEW_INPUT_JSON
|
||||
ENDJSON
|
||||
```
|
||||
|
||||
Then trigger a fresh run using the workflow name from Step 1:
|
||||
|
||||
```bash
|
||||
RUN_ID=$(hatchet trigger manual -w WORKFLOW_NAME -j "$HATCHET_INPUT_FILE" -p HATCHET_PROFILE -o json | jq -r '.runId')
|
||||
```
|
||||
|
||||
Clean up the temp file:
|
||||
|
||||
```bash
|
||||
rm -f "$HATCHET_INPUT_FILE"
|
||||
```
|
||||
|
||||
## Step 3: Watch the New Run
|
||||
|
||||
After either Step 2a or 2b, you have a new run ID. Poll for completion:
|
||||
|
||||
```bash
|
||||
hatchet runs get <NEW_RUN_ID> -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
Check `.run.status` and `.tasks[].status` every 5 seconds until all reach a terminal state (`COMPLETED`, `FAILED`, `CANCELLED`).
|
||||
|
||||
If the new run also fails, use the debug instructions:
|
||||
|
||||
1. `hatchet runs logs <NEW_RUN_ID> -p HATCHET_PROFILE` for application logs
|
||||
2. `hatchet runs events <NEW_RUN_ID> -o json -p HATCHET_PROFILE` for lifecycle events
|
||||
|
||||
## Common Replay Workflow
|
||||
|
||||
The typical flow when an agent is iterating on task code:
|
||||
|
||||
1. Trigger a run and it fails
|
||||
2. Read the logs/events to understand why
|
||||
3. Fix the code (the worker auto-reloads if `reload: true` in `hatchet.yaml`)
|
||||
4. Replay the run with `hatchet runs replay RUN_ID -o json -p HATCHET_PROFILE`
|
||||
5. If it fails again, repeat from step 2
|
||||
@@ -0,0 +1,75 @@
|
||||
# Install and Set Up the Hatchet CLI
|
||||
|
||||
These are instructions for an AI agent to install the Hatchet CLI and configure a profile. Follow each step in order.
|
||||
|
||||
## Step 1: Check if Already Installed
|
||||
|
||||
```bash
|
||||
hatchet --version
|
||||
```
|
||||
|
||||
If this prints a version number, the CLI is already installed. Skip to Step 3 (profile setup).
|
||||
|
||||
If the command is not found, proceed to Step 2.
|
||||
|
||||
## Step 2: Install the CLI
|
||||
|
||||
On macOS, Linux, or WSL:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://install.hatchet.run/install.sh | bash
|
||||
```
|
||||
|
||||
Alternatively, on macOS via Homebrew:
|
||||
|
||||
```bash
|
||||
brew install hatchet-dev/hatchet/hatchet --cask
|
||||
```
|
||||
|
||||
After installation, verify it worked:
|
||||
|
||||
```bash
|
||||
hatchet --version
|
||||
```
|
||||
|
||||
## Step 3: Check for Existing Profiles
|
||||
|
||||
```bash
|
||||
hatchet profile list
|
||||
```
|
||||
|
||||
If a profile already exists that connects to the correct Hatchet instance, note its name and use it as the `-p` flag in all subsequent commands. You are done.
|
||||
|
||||
If no profiles exist or the correct one is missing, proceed to Step 4.
|
||||
|
||||
## Step 4: Create a Profile
|
||||
|
||||
You need a Hatchet API token. Ask the user for one if you do not have it. Then create a profile:
|
||||
|
||||
```bash
|
||||
hatchet profile add --name HATCHET_PROFILE --token <API_TOKEN>
|
||||
```
|
||||
|
||||
Replace `HATCHET_PROFILE` with a descriptive name (e.g. `local`, `staging`, `production`) and `<API_TOKEN>` with the actual token.
|
||||
|
||||
To set it as the default profile (so `-p` is optional in future commands):
|
||||
|
||||
```bash
|
||||
hatchet profile set-default --name HATCHET_PROFILE
|
||||
```
|
||||
|
||||
## Step 5: Verify Connectivity
|
||||
|
||||
Test that the profile works by listing workflows:
|
||||
|
||||
```bash
|
||||
hatchet runs list -o json -p HATCHET_PROFILE --since 1h --limit 1
|
||||
```
|
||||
|
||||
If this returns a JSON response (even with an empty rows list), the profile is correctly configured and connected.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- **"command not found"** after install: The CLI binary may not be on your PATH. Check `~/.local/bin/hatchet` or re-run the install script.
|
||||
- **Authentication error**: The API token may be invalid or expired. Ask the user for a new token and run `hatchet profile update`.
|
||||
- **Connection refused**: The Hatchet server may not be running. For local development, start it with `hatchet server start`.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Start a Hatchet Worker in Dev Mode
|
||||
|
||||
These are instructions for an AI agent to start a Hatchet worker using the CLI. Follow each step in order.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need a `hatchet.yaml` file in the project root. If one does not exist, create it with the following structure:
|
||||
|
||||
```yaml
|
||||
dev:
|
||||
runCmd: "python src/worker.py"
|
||||
files:
|
||||
- "**/*.py"
|
||||
reload: true
|
||||
```
|
||||
|
||||
Adjust `runCmd` to match the project's language and entry point:
|
||||
|
||||
- Python: `poetry run python src/worker.py` or `python src/worker.py`
|
||||
- TypeScript/Node: `npx ts-node src/worker.ts` or `npm run dev`
|
||||
- Go: `go run ./cmd/worker`
|
||||
|
||||
The `files` list contains glob patterns for file watching. The `reload: true` setting enables automatic worker restart when watched files change.
|
||||
|
||||
## Start the Worker
|
||||
|
||||
Run the following command in a **background terminal** (the worker is a long-running process that must stay alive):
|
||||
|
||||
```bash
|
||||
hatchet worker dev -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
The worker will connect to Hatchet using the specified profile and begin listening for tasks.
|
||||
|
||||
## Important Notes
|
||||
|
||||
- The worker **must be running** before you trigger any workflows. If a workflow is triggered with no worker running, tasks will remain in QUEUED status indefinitely.
|
||||
- When `reload: true` is set, the worker automatically restarts when any watched file changes. This means you can edit task code and the worker picks up changes without manual restart.
|
||||
- To disable auto-reload, add `--no-reload`.
|
||||
- To override the run command without editing `hatchet.yaml`, use `--run-cmd "your command here"`.
|
||||
- If the worker fails to start, check that the profile exists (`hatchet profile list`) and that the Hatchet server is reachable.
|
||||
|
||||
## Optional: Pre-commands
|
||||
|
||||
You can add setup commands that run before the worker starts:
|
||||
|
||||
```yaml
|
||||
dev:
|
||||
preCmds:
|
||||
- "poetry install"
|
||||
- "npm install"
|
||||
runCmd: "poetry run python src/worker.py"
|
||||
files:
|
||||
- "**/*.py"
|
||||
reload: true
|
||||
```
|
||||
|
||||
These run once each time the worker starts (including on reload).
|
||||
@@ -0,0 +1,75 @@
|
||||
# Trigger a Workflow and Watch for Completion
|
||||
|
||||
These are instructions for an AI agent to trigger a Hatchet workflow and poll until it completes. Follow each step in order.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A Hatchet worker must be running (`hatchet worker dev -p HATCHET_PROFILE`). If no worker is running, the task will stay QUEUED forever.
|
||||
- You must know the workflow name and have the input JSON ready.
|
||||
|
||||
## Step 1: Write Input to a Temp File
|
||||
|
||||
Write the input JSON to a uniquely-named temp file to avoid collisions with other sessions:
|
||||
|
||||
```bash
|
||||
HATCHET_INPUT_FILE="/tmp/hatchet-input-$(date +%s)-$$.json"
|
||||
cat > "$HATCHET_INPUT_FILE" << 'ENDJSON'
|
||||
INPUT_JSON
|
||||
ENDJSON
|
||||
```
|
||||
|
||||
Replace `INPUT_JSON` with the actual JSON payload for the workflow.
|
||||
|
||||
## Step 2: Trigger the Workflow
|
||||
|
||||
```bash
|
||||
RUN_ID=$(hatchet trigger manual -w WORKFLOW_NAME -j "$HATCHET_INPUT_FILE" -p HATCHET_PROFILE -o json | jq -r '.runId')
|
||||
```
|
||||
|
||||
The `-o json` flag makes the command output `{"runId": "...", "workflow": "..."}` to stdout. The command above captures the run ID directly into `$RUN_ID` for the next steps.
|
||||
|
||||
## Step 3: Poll for Completion
|
||||
|
||||
Run the following command every 5 seconds until the run reaches a terminal state:
|
||||
|
||||
```bash
|
||||
hatchet runs get <RUN_ID> -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
Parse the JSON response and check the status:
|
||||
|
||||
- Look at `.run.status` for the overall run status and `.tasks[].status` for individual task statuses.
|
||||
- Terminal statuses are: `COMPLETED`, `FAILED`, `CANCELLED`.
|
||||
- Non-terminal statuses are: `QUEUED`, `RUNNING`. Keep polling if you see these.
|
||||
|
||||
## Step 4: Handle Failure
|
||||
|
||||
If the run status is `FAILED`, gather diagnostic information:
|
||||
|
||||
### Fetch logs
|
||||
|
||||
```bash
|
||||
hatchet runs logs <RUN_ID> -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
This prints application-level log output (e.g. print statements, logger calls from your task code). Look for error messages, stack traces, or unexpected output.
|
||||
|
||||
### Fetch events
|
||||
|
||||
```bash
|
||||
hatchet runs events <RUN_ID> -o json -p HATCHET_PROFILE
|
||||
```
|
||||
|
||||
This returns the lifecycle event log showing how the task was dispatched, started, and failed. Look at the `eventType` and `message` fields to understand the failure sequence.
|
||||
|
||||
## Step 5: Clean Up
|
||||
|
||||
```bash
|
||||
rm -f "$HATCHET_INPUT_FILE"
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
- **Task stays QUEUED**: The worker is not running, or the workflow/task name does not match what the worker registered. Start or restart the worker.
|
||||
- **Task FAILED immediately**: Check the logs for a stack trace. The task code likely threw an exception.
|
||||
- **Task CANCELLED**: Something cancelled the run externally. Check events to see the cancellation source.
|
||||
@@ -302,15 +302,6 @@ function handleToolsList(id: string | number | null): JsonRpcResponse {
|
||||
required: ["query"],
|
||||
},
|
||||
},
|
||||
{
|
||||
name: "get_full_docs",
|
||||
description:
|
||||
"Get the complete Hatchet documentation as a single document. Useful for comprehensive context.",
|
||||
inputSchema: {
|
||||
type: "object",
|
||||
properties: {},
|
||||
},
|
||||
},
|
||||
],
|
||||
},
|
||||
};
|
||||
@@ -471,6 +462,24 @@ function handleGetFullDocs(id: string | number | null): JsonRpcResponse {
|
||||
};
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Agent instruction tools
|
||||
// ---------------------------------------------------------------------------
|
||||
const PAGES_DIR = path.join(process.cwd(), "pages", "agent-instructions");
|
||||
|
||||
function readAgentPage(slug: string): string | null {
|
||||
// Try generated markdown first, fall back to MDX source
|
||||
const llmsPath = path.join(LLMS_DIR, "agent-instructions", `${slug}.md`);
|
||||
if (fs.existsSync(llmsPath)) {
|
||||
return fs.readFileSync(llmsPath, "utf-8");
|
||||
}
|
||||
const mdxPath = path.join(PAGES_DIR, `${slug}.mdx`);
|
||||
if (fs.existsSync(mdxPath)) {
|
||||
return fs.readFileSync(mdxPath, "utf-8");
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Notifications (no response needed)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
@@ -12,7 +12,7 @@ export default {
|
||||
},
|
||||
"hatchet-cloud-quickstart": "Hatchet Cloud Quickstart",
|
||||
setup: "Advanced Setup",
|
||||
"install-docs-mcp": "Install Docs MCP",
|
||||
"coding-agents": "Using Coding Agents",
|
||||
"--guide": {
|
||||
title: "Fundamentals",
|
||||
type: "separator",
|
||||
|
||||
@@ -0,0 +1,151 @@
|
||||
import { Callout, Steps, Tabs } from "nextra/components";
|
||||
import {
|
||||
McpUrl,
|
||||
CursorDeeplinkButton,
|
||||
CursorMcpConfig,
|
||||
ClaudeCodeCommand,
|
||||
CursorTabLabel,
|
||||
ClaudeCodeTabLabel,
|
||||
OtherAgentsTabLabel,
|
||||
} from "@/components/McpSetup";
|
||||
|
||||
# Using Coding Agents
|
||||
|
||||
Hatchet is designed to work well with AI coding agents. This page covers how to give your agent access to Hatchet documentation and step-by-step skills for common CLI operations.
|
||||
|
||||
<Callout type="info">
|
||||
**Prerequisite:** The `hatchet skills install` and `hatchet docs install`
|
||||
commands require the Hatchet CLI. See the [CLI reference](/cli) for
|
||||
installation instructions.
|
||||
</Callout>
|
||||
|
||||
## Agent Skills
|
||||
|
||||
Agent skills are reference documents that teach AI coding agents how to use the Hatchet CLI — triggering workflows, starting workers, debugging runs, and more.
|
||||
|
||||
Run the following command in your project root to install the skill package:
|
||||
|
||||
```bash copy
|
||||
hatchet skills install
|
||||
```
|
||||
|
||||
This creates a `skills/hatchet-cli/` directory with step-by-step reference files and appends a section to your project's `AGENTS.md` (and `CLAUDE.md`) pointing agents to the right file for each task.
|
||||
|
||||
**Install to a custom directory:**
|
||||
|
||||
```bash copy
|
||||
hatchet skills install --dir ./my-project
|
||||
```
|
||||
|
||||
After installation, commit the `skills/` directory and `AGENTS.md` to version control so all agents working in the repo benefit automatically.
|
||||
|
||||
### Available references
|
||||
|
||||
| Reference | When to use |
|
||||
| --------------------------------- | ----------------------------------------------------- |
|
||||
| `references/setup-cli.md` | Installing the CLI, creating or listing profiles |
|
||||
| `references/start-worker.md` | Starting a dev worker for local development |
|
||||
| `references/trigger-and-watch.md` | Triggering a workflow and polling for completion |
|
||||
| `references/debug-run.md` | Diagnosing a failed, stuck, or unexpected run |
|
||||
| `references/replay-run.md` | Re-running a previous workflow with same or new input |
|
||||
|
||||
## MCP Server
|
||||
|
||||
Hatchet documentation is available as an **MCP (Model Context Protocol) server**, so AI coding assistants like Cursor and Claude Code can search and reference Hatchet docs directly.
|
||||
|
||||
MCP endpoint: <McpUrl />
|
||||
|
||||
<Tabs items={[<CursorTabLabel />, <ClaudeCodeTabLabel />, <OtherAgentsTabLabel />]}>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Tabs items={['Hatchet CLI', 'One-Click Install', 'Manual Config']}>
|
||||
<Tabs.Tab>
|
||||
|
||||
```bash copy
|
||||
hatchet docs install cursor
|
||||
```
|
||||
|
||||
This creates a `.cursor/rules/hatchet-docs.mdc` file and prints the one-click deeplink.
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
Install the Hatchet docs MCP server in Cursor with one click:
|
||||
|
||||
<CursorDeeplinkButton />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Steps>
|
||||
|
||||
### Open Cursor Settings
|
||||
|
||||
Go to **Cursor Settings** → **MCP** → **Add new MCP server**.
|
||||
|
||||
### Add the server configuration
|
||||
|
||||
<CursorMcpConfig />
|
||||
|
||||
### Use in chat
|
||||
|
||||
Reference Hatchet docs in any Cursor chat with `@hatchet-docs` or ask questions and the agent will automatically search the docs.
|
||||
|
||||
</Steps>
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Tabs items={['Hatchet CLI', 'Command']}>
|
||||
<Tabs.Tab>
|
||||
|
||||
```bash copy
|
||||
hatchet docs install claude-code
|
||||
```
|
||||
|
||||
If `claude` is on your PATH, this runs the command automatically. Otherwise it prints it for you to copy.
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
Run this command in your terminal:
|
||||
|
||||
<ClaudeCodeCommand />
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
For any AI tool that supports [llms.txt](https://llmstxt.org/), Hatchet docs are available at:
|
||||
|
||||
| Resource | URL |
|
||||
|----------|-----|
|
||||
| **llms.txt** (index) | [docs.hatchet.run/llms.txt](https://docs.hatchet.run/llms.txt) |
|
||||
| **llms-full.txt** (all docs) | [docs.hatchet.run/llms-full.txt](https://docs.hatchet.run/llms-full.txt) |
|
||||
| **Per-page markdown** | `docs.hatchet.run/llms/{section}/{page}.md` |
|
||||
| **MCP endpoint** | <McpUrl /> |
|
||||
|
||||
Every documentation page also includes a `<link rel="alternate" type="text/markdown">` header
|
||||
pointing to its markdown version, and a "View as Markdown" link at the top of the page.
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
|
||||
## llms.txt
|
||||
|
||||
For any AI tool that supports [llms.txt](https://llmstxt.org/), Hatchet docs are available at:
|
||||
|
||||
| Resource | URL |
|
||||
| ---------------------------- | ------------------------------------------------------------------------ |
|
||||
| **llms.txt** (index) | [docs.hatchet.run/llms.txt](https://docs.hatchet.run/llms.txt) |
|
||||
| **llms-full.txt** (all docs) | [docs.hatchet.run/llms-full.txt](https://docs.hatchet.run/llms-full.txt) |
|
||||
| **Per-page markdown** | `docs.hatchet.run/llms/{section}/{page}.md` |
|
||||
| **MCP endpoint** | <McpUrl /> |
|
||||
|
||||
Every documentation page also includes a `<link rel="alternate" type="text/markdown">` header
|
||||
pointing to its markdown version, and a "View as Markdown" link at the top of the page.
|
||||
@@ -1,97 +0,0 @@
|
||||
import { Callout, Steps, Tabs } from "nextra/components";
|
||||
import {
|
||||
McpUrl,
|
||||
CursorDeeplinkButton,
|
||||
CursorMcpConfig,
|
||||
ClaudeCodeCommand,
|
||||
CursorTabLabel,
|
||||
ClaudeCodeTabLabel,
|
||||
OtherAgentsTabLabel,
|
||||
} from "@/components/McpSetup";
|
||||
|
||||
# Install Docs MCP
|
||||
|
||||
Hatchet documentation is optimized for LLMs and available as an **MCP (Model Context Protocol) server**, so AI coding assistants like Cursor and Claude Code can search and reference Hatchet docs directly.
|
||||
|
||||
MCP endpoint: <McpUrl />
|
||||
|
||||
<Tabs items={[<CursorTabLabel />, <ClaudeCodeTabLabel />, <OtherAgentsTabLabel />]}>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Tabs items={['Hatchet CLI', 'One-Click Install', 'Manual Config']}>
|
||||
<Tabs.Tab>
|
||||
|
||||
```bash copy
|
||||
hatchet docs install cursor
|
||||
```
|
||||
|
||||
This creates a `.cursor/rules/hatchet-docs.mdc` file and prints the one-click deeplink.
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
Install the Hatchet docs MCP server in Cursor with one click:
|
||||
|
||||
<CursorDeeplinkButton />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Steps>
|
||||
|
||||
### Open Cursor Settings
|
||||
|
||||
Go to **Cursor Settings** → **MCP** → **Add new MCP server**.
|
||||
|
||||
### Add the server configuration
|
||||
|
||||
<CursorMcpConfig />
|
||||
|
||||
### Use in chat
|
||||
|
||||
Reference Hatchet docs in any Cursor chat with `@hatchet-docs` or ask questions and the agent will automatically search the docs.
|
||||
|
||||
</Steps>
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
<Tabs items={['Hatchet CLI', 'Command']}>
|
||||
<Tabs.Tab>
|
||||
|
||||
```bash copy
|
||||
hatchet docs install claude-code
|
||||
```
|
||||
|
||||
If `claude` is on your PATH, this runs the command automatically. Otherwise it prints it for you to copy.
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
Run this command in your terminal:
|
||||
|
||||
<ClaudeCodeCommand />
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab>
|
||||
|
||||
For any AI tool that supports [llms.txt](https://llmstxt.org/), Hatchet docs are available at:
|
||||
|
||||
| Resource | URL |
|
||||
|----------|-----|
|
||||
| **llms.txt** (index) | [docs.hatchet.run/llms.txt](https://docs.hatchet.run/llms.txt) |
|
||||
| **llms-full.txt** (all docs) | [docs.hatchet.run/llms-full.txt](https://docs.hatchet.run/llms-full.txt) |
|
||||
| **Per-page markdown** | `docs.hatchet.run/llms/{section}/{page}.md` |
|
||||
| **MCP endpoint** | <McpUrl /> |
|
||||
|
||||
Every documentation page also includes a `<link rel="alternate" type="text/markdown">` header
|
||||
pointing to its markdown version, and a "View as Markdown" link at the top of the page.
|
||||
|
||||
</Tabs.Tab>
|
||||
</Tabs>
|
||||
Reference in New Issue
Block a user