Harness Export

---
name: harness-export
description: Export the harness to another AI client — Copilot agent profiles, Cursor rules — with an honest capability report of what does and doesn't carry over.
---


# /harness-export — cross-client export (Phase 7)

Export this project's harness for the client named in `$ARGUMENTS`. AGENTS.md is the shared
core (B10): Copilot and Codex read it natively — and Copilot reads CLAUDE.md too — so
instructions usually need **zero conversion**. What needs compiling is the agent roster.

## Step 0 — Workspace scope
`.harness/profile.yaml` in the current directory → normal per-repo run, continue at Step 1,
nothing below applies. Missing, but `workspace.yaml` or `repos.txt` is present instead → this
is a **workspace root**:

1. Ask once (AskUserQuestion): export for **every** bootstrapped unit, **specific units** (name
   them), or let you **suggest** units — propose any unit that doesn't yet have the target
   client's exported artifacts (`.github/agents/` for copilot, `.cursor/rules/` for cursor; for
   codex, nothing is ever missing since it reads `AGENTS.md` natively — say so and skip the
   suggestion for that client), and confirm the proposed list before proceeding.
2. Skip and report any listed unit with no `.harness/profile.yaml`/`AGENTS.md` yet — point at
   `/harness-init` for it.
3. For each chosen unit, in order: `cd` into it and run Steps 1-5 of this same command,
   directly, same "continue the flow yourself" approach as `/harness-init` Step 1b.
4. Report one consolidated capability table across all processed units, alongside each unit's
   own Step 5 report.

Neither a local profile nor a workspace manifest/inventory present → tell the user to run
`/harness-init` first and stop.

## Step 1 — Instructions layer (verify, don't convert)
Confirm AGENTS.md exists with the generated block (run `/harness-init` first if not). Report:
- **codex**: reads AGENTS.md natively → done; no files to write. Note: Claude hooks have no
  Codex equivalent — gate behavior is instruction-backed only there (B4 portability table).
- **copilot**: reads AGENTS.md (root + nested) and CLAUDE.md natively.
- **cursor**: project rules come from exported `.mdc` files (next step).

## Step 2 — Agent roster
**copilot, preferred route**: the framework dual-publishes a Copilot CLI plugin — point the
user at `copilot plugin marketplace add <marketplace-repo>` +
`copilot plugin install se-harness-copilot@<marketplace>` (agents + skills + commands in one
step; regenerated by `scripts/build-copilot-plugin.sh`). The file export below remains for the
**coding agent on github.com** (repo-level `.github/agents/`) and for cursor:
```
bash tools/harness/export-agents.sh <client> .
```
- **copilot** → `.github/agents/<name>.md` agent profiles (name/description frontmatter, body
  verbatim, tool restrictions carried as body guidance since tool names don't map 1:1).
  Org/enterprise-wide distribution: move profiles to the org's `.github-private` repo (B10).
- **cursor** → `.cursor/rules/<name>.mdc` (description-triggered rules; Cursor has no subagent
  isolation, so these activate contextually rather than as delegated agents — say so).

## Step 3 — Hooks (copilot only)
Copilot supports lifecycle hooks on the **coding agent + Copilot CLI**
(`.github/hooks/*.json` — [reference](https://docs.github.com/en/copilot/reference/hooks-reference)),
with different semantics than Claude Code: deny = JSON `permissionDecision` output, **exit 2
does not block**, other non-zero exits fail-closed. Export via the bundled adapter — never
wire the scripts in directly:
```
mkdir -p tools/harness .github/hooks
cp tools/harness/{copilot-hook-adapter.sh,gate-check.sh,org-validate.sh,memory-log-commit.sh,contract-check.sh} tools/harness/
cp ../se-harness/templates/copilot-hooks.json .github/hooks/se-harness.json
```
Tell the user to verify the gate actually denies (payload field names differ between the
coding agent and CLI surfaces) and that hooks do NOT run in VS Code Chat. Cursor/codex: no
hook surface — skip.

## Step 4 — MCP layer
MCP is the genuinely portable layer (B4): point the user at this project's `.mcp.json` and the
target client's MCP import mechanism. Do not duplicate server configs into client-specific
formats — reference, don't fork.

## Step 5 — Honest capability report (always end with this)
| Surface | Carries over? |
|---|---|
| AGENTS.md instructions | ✅ native (copilot, codex) / via rules (cursor) |
| Agent roster | ✅ compiled (copilot profiles, cursor rules) — no isolation/tool-scoping parity |
| HITL gates (hooks) | ⚠ copilot: ✅ coding agent + CLI via adapter (Step 3), ❌ VS Code Chat · cursor/codex: ❌ — AGENTS.md workflow text + CI are the enforcement there |
| Skills (context-injector, wiki-*, grill) | ❌ Claude-only — conventions survive as instructions, automation doesn't |
| MCP servers | ✅ portable via each client's MCP config |
| `.harness/` artifacts (profile, REQs, memory) | ✅ plain files — any client can read them |

The exported setup is a **capability subset**, not a port. If the team's primary client isn't
Claude Code, the gates and memory automation need re-implementing on that client's extension
surface — flag it, don't imply parity.