Skills reference #
Litmus ships a set of AI workflow prompts that drive Claude / Copilot / Cursor / Cline through hardware-test authoring tasks. This page is the inventory: what each prompt does, what it calls, and how it's installed.
For motivation (why AI integration at all), see concepts/why-ai-integration. For setup commands (litmus setup <client>), see how-to/mcp-integration.
Prerequisites. These prompts run inside an AI client (Claude Code, Copilot, Cursor, or Cline) that you've connected to Litmus with
litmus setup <client>. The client launches thelitmus mcp serveserver on demand over stdio — you don't start it yourself.
Three layers #
- Workflows (3 prompts) — multi-step prompts you invoke directly; they drive the whole datasheet-to-tests flow.
- Sub-agent templates (5 prompts) — single-job prompts the workflows spawn as sub-agents; not invoked directly.
- Slash commands (2 per client) — client-specific wrappers that invoke the workflows from your editor's prompt UI.
All three layers ship as plain markdown — read any prompt on GitHub, or in the litmus/skills/ directory of your installed copy.
Workflows #
User-invocable. Multi-step. STOP at every approval gate.
datasheet-to-test #
| Source | workflow/datasheet-to-test.md |
| Input | A part datasheet PDF |
| Output | parts/<id>.yaml, stations/<id>.yaml, tests/test_<id>.py, tests/test_<id>.yaml |
| Phases | Parse datasheet → save part spec → recommend instruments → create station config → generate tests → execute |
| MCP tools used | litmus_project (init, save, read), litmus_match, litmus_run, litmus_open, litmus_discover |
Approval gates at every phase. The user reviews extracted specs, picked instruments, station wiring, and the generated test before the agent moves on.
datasheet-to-catalog #
| Source | workflow/datasheet-to-catalog.md |
| Input | An instrument datasheet PDF |
| Output | A catalog/<instrument>.yaml entry with channels, capabilities, accuracy specs |
| Approach | Section-by-section: split → extract → write → mechanical audit + semantic review → fix-loop until clean |
| Sub-agents spawned | section-splitter, section-extractor, section-writer, section-reviewer, scaffold-writer |
Thorough. Use when you need accuracy specs and condition-indexed bands captured correctly. Slower than catalog-scaffold but produces audit-clean catalog entries.
catalog-scaffold #
| Source | catalog-scaffold.md |
| Input | An instrument make + model (no datasheet PDF needed) |
| Output | A catalog/<instrument>.yaml entry from the model's prior knowledge |
| When to use | Well-known instruments (Keysight 34461A, Keithley 2400, etc.) where the model can recall specs without re-reading the datasheet |
Fast path. For instruments the model doesn't know well, use datasheet-to-catalog instead.
Sub-agent templates #
Single-responsibility prompts the workflows spawn as sub-agents. Not invoked directly. Each names a recommended model size for its job — the Tier column below.
| Template | Job | Tier |
|---|---|---|
section-splitter | Read a datasheet PDF, divide into processing sections (page ranges). No YAML, no extraction. | mid-to-high |
section-extractor | Read PDF pages, produce a complete structured inventory file. Extraction only, no schema knowledge. | high |
section-writer | Convert a pre-extracted inventory into catalog YAML capabilities. Does NOT re-read the PDF. | high |
section-reviewer | Review AND fix catalog YAML against the inventory. Semantic checks only, no PDF access. | high |
scaffold-writer | Read targeted pages and write the device-level YAML (channels, interfaces, board attributes). Does NOT extract capabilities. | high |
The single-responsibility split is deliberate. Each agent does one job with a narrow context; the workflow chains them with a fix loop (extractor → writer → reviewer → fix → reviewer until clean). A single agent doing all four jobs is more error-prone; the chain catches mistakes at each boundary between agents.
Slash commands #
Per-client wrappers that invoke the workflows from your editor's slash-command UI.
| Command | Clients | Invokes |
|---|---|---|
/catalog-from-datasheet [pdf] [yaml] | Claude Code, Copilot | datasheet-to-catalog workflow on a single PDF |
/process-catalog | Claude Code, Copilot | Walks catalog/QUEUE.md, runs /catalog-from-datasheet on each pending entry |
Installed automatically by litmus setup <client>:
| Client | Setup command | Where commands install |
|---|---|---|
| Claude Code | litmus setup claude-code | ./.claude/commands/ (project-local) |
| GitHub Copilot | litmus setup copilot | .github/prompts/ (project-local) |
| Claude Desktop | litmus setup claude-desktop | n/a — slash commands not supported; MCP only |
| Cursor | litmus setup cursor | n/a — slash commands not supported; MCP only |
| Cline | litmus setup cline | n/a — slash commands not supported; MCP only |
Claude Desktop, Cursor, and Cline get the MCP server registration (so the agent can call litmus_* tools), but workflow invocation is conversational: "run the datasheet-to-test workflow on this PDF" instead of typing a slash command. The workflow prompt itself is the same.
MCP tools the workflows call #
The 13 MCP tools exposed by the litmus mcp serve server (the AI client launches it on demand over stdio; you don't run it yourself). Per-tool parameter detail in the API reference.
| Tool | Workflows that use it |
|---|---|
litmus_project (init / save / read / lookup_enum / enum_reference) | All workflows |
litmus_match | datasheet-to-test |
litmus_run | datasheet-to-test |
litmus_open | datasheet-to-test |
litmus_discover | datasheet-to-test |
litmus_schema | (available; rarely called by workflows directly) |
litmus_events, litmus_sessions, litmus_channels, litmus_files, litmus_runs, litmus_steps, litmus_metrics | Post-run analysis (available to any agent) |
MCP prompts #
Workflows that MCP clients can fetch as a prompt — an alternative to slash commands for clients that surface a prompt list.
| Prompt | Returns | Equivalent to |
|---|---|---|
datasheet-to-test | The full workflow text | The slash command, but discoverable via the MCP prompts list |
What the setup commands install #
For reference, the full per-client install scope of litmus setup <client>:
litmus setup claude-code #
- Registers the MCP server:
claude mcp add litmus -- <litmus-bin> mcp serve - Copies slash command stubs:
skills/commands/claude-code/*.md→./.claude/commands/ - Writes or merges
./CLAUDE.mdfromskills/templates/project-instructions.md(Litmus context the agent always reads)
litmus setup copilot #
- Writes
.vscode/mcp.json(MCP server registration) - Writes
.github/copilot-instructions.md(Litmus context for Copilot Chat) - Copies slash command stubs:
skills/commands/copilot/*.prompt.md→ project
litmus setup claude-desktop #
Builds a litmus.mcpb Desktop Extension bundle on the user's Desktop. Double-click to install. --legacy writes JSON config to ~/.config/Claude/claude_desktop_config.json instead.
litmus setup cursor #
Writes .cursor/mcp.json in the project directory.
litmus setup cline #
Writes cline_mcp_settings.json to VS Code user settings (~/.config/Code/User/ on Linux, ~/Library/Application Support/Code/User/ on macOS, ~/AppData/Roaming/Code/User/ on Windows).
All litmus setup commands accept --print-only to show the config that would be written without modifying anything on disk.
Reference material the workflows load #
| File | Used as background context by |
|---|---|
refs/profiles.md | Workflows that touch profile config — explains the facet-query selection model |
templates/project-instructions.md | Installed as the project's CLAUDE.md / copilot-instructions.md so the agent has Litmus context in every conversation |
See also #
- Concepts: why AI integration — motivation
- How-to: datasheet-to-test workflow — end-to-end walkthrough
- How-to: MCP integration — registering the server with each AI client
- Reference: MCP tools — per-tool parameter detail