Getting Started¶
Install From A Checkout¶
python3 -m venv .venv # Python 3.10+
.venv/bin/pip install -e .
This installs the package in editable mode and adds the ghostlab and rehearsal console scripts. Prefer ghostlab in new docs and scripts. (Contributors who also want the test/build/docs toolchain use pip install -r requirements-dev.txt instead — see CONTRIBUTING.md.)
ghostlab --help
ghostlab --version
Create A Job (Recommended Starting Point)¶
A job is one MCP evaluation, and everything about it lives in one folder. ghostlab create asks only for what it can't infer — a name and a target — then inspects the target immediately so the job is validated and its capabilities are populated in one step:
ghostlab create
# ? Job name: cortex-eval
# ? Target MCP URL or config path: http://localhost:8000/mcp
# → Created job 'cortex-eval' … then runs discover and prints the tool inventory
Everything else (persona/scenario counts, gates, prompts) uses documented defaults you edit in job.yaml — pass --personas, --scenarios-per-persona, --min-pass-rate, or --aut-runner to set them up front. Add --no-discover to just scaffold without inspecting.
It scaffolds a self-contained directory:
jobs/cortex-eval/
job.yaml # the whole config: target, hosts, generation, test, prompts, gates
test-plan.yaml # produced by `ghostlab plan`
workspace/ # discover/generated/test artifacts + ghostlab.sqlite3
runs/ # dual-agent run output
job.yaml is populated with editable defaults for every knob — persona/scenario counts, suites, judge, gates, and a prompts: section where you can override any built-in prompt (each entry is blank = use the built-in; the file header lists the {placeholders} each prompt accepts). An explicit CLI flag still wins over a job.yaml setting, which wins over the code default.
Non-interactive (for scripts/CI):
ghostlab create --name cortex-eval --target http://localhost:8000/mcp \
--aut-runner runners/codex-cortex-local-aut.json --yes
Bring your existing MCP config¶
--target also accepts the standard mcpServers config you already give Codex, Claude Desktop, Cursor, or VS Code — GhostLab normalizes it into a target (issue #32). This covers local stdio servers and remote HTTP/SSE servers alike:
// mcp.json
{
"mcpServers": {
"obsidian": { "command": "npx", "args": ["-y", "obsidian-mcp"], "env": { "VAULT": "/notes" } },
"github": { "url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" } }
}
}
ghostlab create --name gh --target ./mcp.json --server github # pick a server by name
ghostlab inspect --target ./mcp.json --server obsidian # inspect works the same way
When a config has a single server, --server is optional; with several, GhostLab lists them and asks you to choose.
Auth without leaking secrets: header/env values may reference environment variables (${GITHUB_TOKEN}), which are expanded at connection time — so the token stays in your shell, not in the tracked job.yaml. If you have only a URL, the wizard can add the header for you:
export GITHUB_TOKEN=ghp_xxx
ghostlab create --name gh --target https://api.githubcopilot.com/mcp/ \
--header 'Authorization: Bearer ${GITHUB_TOKEN}' --yes
A 401 from discover/inspect means the server got no (or a wrong) auth header — check that the header is present in the target and that the referenced env var is exported.
Then run the loop against the job by name (--job), no paths to juggle:
ghostlab discover --job cortex-eval # inspect + lint + refresh capabilities
ghostlab plan --job cortex-eval # coverage-driven test-plan.yaml
ghostlab test --job cortex-eval # execute across host adapters
ghostlab review --job cortex-eval # readiness report / release gate
Inside a job directory you can drop --job entirely — the commands auto-detect job.yaml in the current folder.
Run A Mock Scenario¶
Mock runners let you exercise the orchestrator without spending coding-agent credits.
ghostlab run \
--target examples/target.json \
--scenario examples/scenario.json \
--aut-runner runners/mock-aut.json \
--user-runner runners/mock-user.json
Run output is written under runs/<run-id>/:
events.jsonl: structured event log.report.md: readable run summary.target.mcp.json: generated MCP server config for the target.
Inspect A Real MCP Target¶
ghostlab inspect --target examples/target.json
# or a standard MCP client config:
ghostlab inspect --target ./mcp.json --server obsidian
inspect connects directly to the MCP server, runs the initialize handshake, lists tools/resources/prompts, and writes an inspect.json plus readable inspect.md. It does not need Codex or another agent. --target accepts either a GhostLab target JSON or a standard mcpServers config (use --server to pick one when it defines several).
Build A Capability Profile¶
ghostlab profile --inspect runs/<id>-inspect/inspect.json
The profile combines deterministic taxonomy with a Codex-generated domain summary and workflow map. Scenario and dataset generation use this profile as their source of truth.