Per-Tool Export: What Gets Generated for Claude / Cursor / AGENTS.md

In short

An engine is a typed engine-mod/v1 spec, and a deterministic compiler builds a package from it for exactly three targets: Claude Code (a plugin with subagents, commands, rules and hooks), Cursor (.cursor/rules/*.mdc rules with frontmatter) and the universal AGENTS.md, which VS Code Copilot, Codex, Jules, Zed and others read. There's no separate "vscode" target — AGENTS.md covers it. Only the canonical spec is edited; the target formats are build artifacts, so there's no drift between targets. Every package includes a README, INSTALL.md and a ready installer prompt. Switch tools and you export the same engine for a new target instead of rewriting the discipline from scratch.

What it is. An engine on qvib.pro isn't "one more prompt" — it's a typed spec (engine-mod/v1): a team of roles, judge prisms, orchestration, rules, skills/MCP/knowledge. From that ONE spec a deterministic compiler (exporters.ts, dispatched through exportMod(spec, target)) builds a package for a specific tool. Exactly three targets are supported: claude-code, cursor, agents-md — an unknown target throws Unknown export target (there's no "vscode" in the list; VS Code/Copilot are served through the universal AGENTS.md).

Why this way. Different tools understand different formats. Cursor ignores an .mdc rule with no frontmatter; Claude Code has plugins, subagents and hooks; the universal AGENTS.md is read by Codex, Jules, Zed, Cursor and others. Adapter-first: only the canonical spec is edited, and the target formats are build artifacts, so there's no drift between targets.

When to pick what.

• Claude Code → a full plugin: .claude-plugin/plugin.json, agents/*.md (each role becomes a subagent), commands/<engine>.md (a slash command carrying the full workflow), prisms as independent subagent reviewers with a verdict/findings/oneChange output contract, .mcp.json, .claude/rules/*.md (always/manual — plain md; auto — paths frontmatter; an agent rule ships as a skill, because Claude's rules have no agent-requested equivalent), plus hooks/ and skills/.
• Cursor → .cursor/rules/<slug>.mdc (the always-on core) plus a separate .mdc per granular rule with its own frontmatter for the activation mode (globs as a comma-separated string, otherwise Cursor silently won't apply it), and .cursor/mcp.json.
• AGENTS.md → one self-contained AGENTS.md at the repo root: team, engine, skills, knowledge, MCP block, rules, secrets. Maximum compatibility.

EVERY package also includes README.md (target-specific instructions plus secrets), INSTALL.md (the "until I'm ready" path: folders → access → checklist) and INSTALL-PROMPT.md — ready text you paste into your model, and it installs the engine itself.

Worked example: exporting Quest for Cursor

Input: the engine has an i18n-sync rule with auto activation and globs: ['**/locales/*.json'], and a secrets-hygiene rule with always activation.

What the engine does (the compiler):

1. The dispatcher calls exportCursor(spec).
2. The core → .cursor/rules/forge-core.mdc with alwaysApply: true frontmatter (charter + roles + engine + invariants).
3. i18n-sync → its own .cursor/rules/i18n-sync.mdc with frontmatter { description, globs: '**/locales/*.json', alwaysApply: false } — Cursor applies it only to locale files.
4. secrets-hygiene → its own .mdc with alwaysApply: true.
5. Secrets are rendered ONLY as names/placeholders ${NAME} — a value never lands in a file (there's a test for this: "the secret does NOT end up as a value in .mcp.json").
6. A portable safety net is added: .engine/hooks/pre-commit (POSIX sh + grep, no Node) and .github/workflows/engine-guard.yml — both run the SAME scan for secrets and destructive markers and exit non-zero on a match.

Result: a folder with .cursor/rules/*.mdc, .cursor/mcp.json, README.md, INSTALL.md, INSTALL-PROMPT.md and the safety net. You download a zip (engine-cursor.zip); unpack it into the project and the rules apply on every agent request.

Straight talk about guarantees (ENFORCED vs ADVISORY)

A hard guarantee (an exit code that physically blocks the action) exists in two places, and both are real in the code:

• Claude Code — the PreToolUse hook guard-dangerous.sh: it blocks BEFORE the tool runs (rm -rf, DROP TABLE, git push --force, curl | bash).
• All targets — the portable safety floor: a git hook (ENFORCED after git config core.hooksPath .engine/hooks) plus CI (always ENFORCED on push/PR).

But the TEXT of the rules, prisms and invariants that the model reads in Cursor/AGENTS is ADVISORY: a strict instruction, with no runtime to physically block it. The package states this plainly in INSTALL.md. The point of the engine is to make the advisory part such a literal recipe that even a weak target model follows it.

The engine's full workflow is inlined into the package in its entirety — it works offline and doesn't depend on our servers.