| name | harness-export |
| description | Use when user invokes /harness-export or wants to save their current harness-kit plugin setup to a shareable harness.yaml file. Detects installed skills, collects source info, and writes the config in Harness Protocol v1 format. Do NOT use for importing or restoring a harness — use /harness-import instead. |
| disable-model-invocation | true |
Export Your Harness Configuration
You are helping the user capture their current harness-kit setup into a harness.yaml file they can share with teammates or commit to their dotfiles repo.
This file follows the Harness Protocol v1 format — the open spec at harnessprotocol.io. It is backward-compatible with harness-import (which handles both old and new formats).
Workflow Order (MANDATORY)
Follow these steps in order. Do not skip any step.
Step 1: Detect installed skills
Scan all four skill directories. Each subdirectory inside these directories is an installed skill:
~/.claude/skills/ — Claude Code global skills.cursor/skills/ — Cursor project-local skills.github/skills/ — Copilot project-local skills.agents/skills/ — agentskills.io standard shared location
ls ~/.claude/skills/ 2>/dev/null
ls .cursor/skills/ 2>/dev/null
ls .github/skills/ 2>/dev/null
ls .agents/skills/ 2>/dev/null
Collect the directory names from each location. Deduplicate by skill name across locations — if the same skill name appears in multiple directories, count it once. Track which platforms each skill was found in.
Show the user the combined result:
Found skills across AI tools:
Claude Code (~/.claude/skills/): research, explain, orient
Cursor (.cursor/skills/): research, explain
Copilot (.github/skills/): research
Shared (.agents/skills/): (none)
Unique skills: research, explain, orient
Use this deduplicated list as your list of installed plugin names for the steps that follow.
If all four directories are empty or missing, tell the user: "No installed skills found in any supported location. Nothing to export." and stop.
Step 2: Ask about sources and metadata
Tell the user what skills you found, then ask:
"I found these installed skills: [list]. A couple of quick questions:
-
For each plugin, which repo is it from? Format: owner/repo — for example harnessprotocol/harness-kit. If a plugin is from harness-kit, just say so and I'll fill it in.
-
What name and description should I give this harness profile? (optional — press enter to skip)
-
Do you have any MCP servers, env variables, or CLAUDE.md instructions you'd like to include? (optional)
Note: MCP server detection is automatic — Step 2.6 will scan .mcp.json, .cursor/mcp.json, and .vscode/mcp.json and ask you separately. You only need to answer about MCP here if you have MCP servers in a non-standard location not covered by those files.
If you've only added harness-kit plugins, just say so."
Wait for the user's response before proceeding.
Step 2.5: Detect cross-platform instruction content
Check whether any cross-platform instruction files exist and contain harness-generated marker blocks:
grep -l "<!-- BEGIN harness:" .cursor/rules/harness.mdc .github/copilot-instructions.md 2>/dev/null
Claude Code instruction files (CLAUDE.md, AGENT.md, SOUL.md) are intentionally excluded — they are managed by the user directly and are not cross-platform sources for export.
If any matching files are found, tell the user what was found and ask. List all slots found in each file — a file may contain multiple harness marker blocks:
"I also found harness-generated instruction content in these files:
.cursor/rules/harness.mdc (contains my-harness:operational and my-harness:behavioral blocks).github/copilot-instructions.md (contains my-harness:operational block)
Would you like me to include the operational and behavioral instruction content in the export?"
(List only the files that actually exist and contain marker blocks — substitute the real profile name from the markers in place of my-harness.)
If the user says yes:
- Extract the content between each
<!-- BEGIN harness:{name}:{slot} --> and <!-- END harness:{name}:{slot} --> marker from those files.
- If the same profile + slot block appears in multiple files with identical content, use it once.
- If the same profile + slot block appears in multiple files with different content, show the user both versions and ask which to use.
- Store the extracted content to include as the
instructions: section in harness.yaml (Step 4).
If the user says no, skip — do not include instruction content from cross-platform files.
If no harness marker blocks are found in any cross-platform file, skip this step silently.
Step 2.6: Detect cross-platform MCP servers
Scan these three files for MCP server definitions:
cat .mcp.json 2>/dev/null
cat .cursor/mcp.json 2>/dev/null
cat .vscode/mcp.json 2>/dev/null
Each file uses the same JSON structure with a top-level mcpServers key. Merge all mcpServers entries across all files found. Deduplicate by server name:
- If the same server name appears in multiple files with the same config, note that it is shared and count it once.
- If the same server name appears in multiple files with different configs, show the user both configs and ask which to keep.
Show the user a summary:
Found MCP servers:
postgres (in .mcp.json and .cursor/mcp.json — same config)
filesystem (in .mcp.json only)
"Would you like to include these in the export? (all / pick / none)"
If the user selects all or pick (and picks at least one), store the chosen servers to write to the mcp-servers: section in harness.yaml (Step 4). Convert from JSON format back to harness YAML format: JSON key type → YAML key transport.
If the user selects none, or if no MCP config files are found, skip this step.
Step 3: Build the plugin entries
For each installed skill, determine its source repo:
Known harness-kit plugins (source: harnessprotocol/harness-kit):
| Plugin | Description |
|---|
| explain | Layered explanations of files, functions, directories, or concepts |
| research | Process any source into a structured, compounding knowledge base |
| lineage | Column-level lineage tracing through SQL, Kafka, Spark, and JDBC |
| orient | Topic-focused session orientation across graph, knowledge, and research |
| capture | Capture session information into a staging file for later reflection |
| review | Code review for a branch, PR, or path — severity labels and cross-file analysis |
| docgen | Generate or update README, API docs, architecture overview, or changelog |
| harness-export | Export your installed plugins to a shareable harness.yaml |
| harness-import | Import a harness.yaml and interactively select plugins to install |
| harness-validate | Validate a harness.yaml file against the Harness Protocol v1 JSON Schema |
| harness-compile | Compile harness.yaml to native config files for Claude Code, Cursor, and Copilot |
| harness-sync | Sync AI tool configuration across Claude Code, Cursor, and Copilot |
| open-pr | Pre-flight checks and PR creation: run tests, open a PR, code review, and check CI |
| merge-pr | PR merge workflow: verify CI and review status, sync with base, confirm, squash merge, and clean up |
| pr-sweep | Cross-repo PR sweep: triage all open PRs, run code reviews, merge what's ready, fix quick CI blockers, and report |
For any installed skill not in this table, ask the user:
"I see [name] installed but don't recognize it. What owner/repo is it from, and what does it do in one sentence?"
Step 4: Write harness.yaml
Write harness.yaml to the current directory (or a path the user specifies). Use the Harness Protocol v1 format:
$schema: https://harnessprotocol.io/schema/v1/harness.schema.json
version: "1"
metadata:
name: my-harness
description: My personal harness configuration.
plugins:
- name: explain
source: harnessprotocol/harness-kit
description: Layered explanations of files, functions, directories, or concepts
With MCP servers (include only if user provided them):
mcp-servers:
postgres:
transport: stdio
command: uvx
args:
- mcp-server-postgres
- ${DB_CONNECTION_STRING}
With env declarations (include only if user has env vars):
env:
- name: DB_CONNECTION_STRING
description: PostgreSQL connection string.
required: true
sensitive: true
With instructions (include only if user wants to bundle CLAUDE.md/AGENT.md content):
instructions:
operational: |
Your operational instructions here.
import-mode: merge
Rules:
version must be the string "1" (quoted), not the integer 1source is owner/repo — no marketplace: key, no marketplaces: section- Only include
mcp-servers, env, instructions, and permissions sections if the user provided content for them
- If instruction content was collected in Step 2.5, include it as the
instructions: section
- If MCP servers were collected in Step 2.6, include them as the
mcp-servers: section (using YAML transport: key, not JSON type:)
- Omit
metadata if the user skipped the name/description questions
- Do NOT include
harness-export or harness-import in the output unless the user explicitly asks
Step 5: Confirm and suggest next steps
Tell the user where the file was written:
"Saved to harness.yaml. To compile it to Cursor and Copilot config files, run /harness-compile.
To share with teammates: commit it to your dotfiles repo. They can import it with /harness-import inside Claude Code, or with the shell fallback:
curl -fsSL https://raw.githubusercontent.com/harnessprotocol/harness-kit/main/harness-restore.sh | bash -s -- harness.yaml
```"
Common Mistakes
| Mistake | Fix |
|---|
Using version: 1 (integer) | Must be version: "1" (string) — this is what distinguishes the protocol format |
Using marketplace: harness-kit | Protocol format uses source: harnessprotocol/harness-kit — no marketplaces: section |
Including harness-export and harness-import in the output | Only include plugins the user actually uses |
| Writing to a path without confirming | Write to ./harness.yaml by default. If user specified a path in the invocation, use that |
Adding mcp-servers: / env: / instructions: as empty sections | Only include these sections when the user has actual content to put in them |
