How to Install the Engine From Your Link — Step by Step for Each Tool

In short

After payment you get a /install/<token> link. On that page you pick a target — Claude Code, Cursor, or VS Code / any agent via AGENTS.md — and download the zip of your engine. Installation comes down to "unpack the archive into your project folder and click Trust once": the files are already laid out where the tool reads them (.claude/…, .cursor/…, or AGENTS.md at the repo root). If you'd rather have the model run the install for you, the package ships an INSTALL-PROMPT.md: paste it in whole together with the archive and the model will unpack, create the folders, request the access it needs, and run a readiness checklist. The safety net (git hook + CI) ships inside the package and works on every target.

What it is

After payment you get an install link (/install/<token>) — a hosted page where you download the package of your vibe coding engine for the target you need, plus a ready-made installer prompt. From there, installing means unpacking the archive into your project folder and clicking Trust once. Everything else — subagents, commands, rules, guard hooks, MCP servers, and the module layers you extended the engine with — is already laid out inside the archive.

Why it works this way

The package arrives with the layout already prepared for your target tool: files sit exactly where Claude Code (.claude/…), Cursor (.cursor/…), or any agent via AGENTS.md reads them. You don't need to understand the internals or assemble configs by hand — the engine is laid out so it gets picked up automatically. There's also INSTALL-PROMPT.md, a verbatim instruction for the target model, if you'd rather have it run the install and the verification.

Common steps (the same for everyone)

1. Open the install link from your account — it's already tied to your purchase and ready to go.
2. Pick a target: Claude Code, Cursor, or VS Code / any agent (AGENTS.md).
3. Download the zip for that target.
4. Unpack it into your project folder (empty or existing), click Trust, and check that /quest responds.

Secrets (GITHUB_MCP_PAT, for example) are set in the environment, not in files — the engine only tells you the names. The package needs no database connection string at all: the base Quest engine ships no DB servers.

For each tool

Claude Code

1. Unpack the archive into your project folder. Inside you'll already find .claude/ (agents, commands, skills, hooks, settings.json), .mcp.json, AGENTS.md, and CLAUDE.md. Nothing needs moving by hand.
2. Open the folder in Claude Code and click Trust in the trust dialog — this is the only manual step. It activates the guard hooks and the MCP servers from the package.
3. If you ALREADY had your own CLAUDE.md, don't overwrite it: just append the line @AGENTS.md (the packaged CLAUDE.md is a thin shim that does exactly that).
4. Verification: /quest <task> responds; /hooks shows guard-dangerous; subagents appear in /agents. If /quest is missing, the files didn't land in .claude/commands/.

Cursor

1. Unpack so that .cursor/rules/*.mdc and .cursor/mcp.json land at the project root. Cursor understands .mdc rules natively (always / auto-glob / agent / manual).
2. MCP secrets go in the environment; .cursor/mcp.json references them through placeholders.
3. Being honest: the guard denylist in Cursor is a strict instruction (ADVISORY). Hard ENFORCED blocking on this target comes through the portable safety floor, which is already in the package (see below).

VS Code (and any other agent — via AGENTS.md)

1. Put AGENTS.md at the repository root — VS Code/Copilot, Codex, Jules, Zed, Cursor, and others all read it.
2. Configure the MCP servers from the "MCP" section in your client (secret values come from the environment).
3. The guard denylist is ADVISORY here too; the ENFORCED layer comes from the portable safety floor in the package.

The portable safety floor — already in the package, not on the roadmap

Whatever the target, the package installs a portable ENFORCED layer that works outside Claude Code as well:

• .engine/hooks/pre-commit — a self-contained POSIX git hook (plain sh + grep, no Node): it scans staged files and blocks the commit if a secret or a destructive marker shows up. Arm it once with git config core.hooksPath .engine/hooks && chmod +x .engine/hooks/pre-commit.
• .github/workflows/engine-guard.yml — CI that runs the same scan on every push and PR, enforced whether or not the local hook is armed.
• .engine.json — the package manifest with a deterministic contentHash (sha256 over the whole file layout), so you can see exactly what got installed and whether the package has been altered.

In other words, blocking dangerous operations isn't a "someday" promise: the local hook and the CI job ship in the archive today.

Worked example (Claude Code)

Input: you bought Quest, opened the install link, downloaded forge-core-claude-code.zip, and unpacked it into your project folder.

What you do: open the folder in Claude Code and click Trust. If you like, paste INSTALL-PROMPT.md and the model will run the readiness checklist itself. The prompt reads roughly like this (abridged):

"Install the 'Quest' engine (forge-core@2.0.0), target Claude Code. The files are already laid out in .claude/ — check that they're in place. Create the engine's working folders (.engine/…) that aren't in the archive. If GitHub MCP needs access, ask for the secret name (GITHUB_MCP_PAT), explain why, and wait for the value to appear in the environment; do NOT write the value into any file. Run the readiness checklist and report the result for every item. From there, work through the quest engine, phases: Analysis → Spec → Plan → Implementation → Delivery → Learning."

Result: the engine is installed and live right after Trust. A team of 8 specialists is picked up (product-owner, analyst, architect, designer, engineer, reviewer, security, quest-verifier) along with 13 review prisms, and .mcp.json wires up the tools (secrets stay placeholders). You can hand it your first task through /quest.

Honest caveats

• The ENFORCED in-the-moment block on dangerous commands (the PreToolUse hook) is Claude Code only today. In Cursor and via AGENTS.md the denylist is ADVISORY — but the portable safety floor (pre-commit + CI) draws an ENFORCED boundary on any target right now.
• The package is plaintext on your disk: it's visible and readable. We don't hide that.
• Counting installs (the number of seats in your license) is the install page's job; the engine itself is autonomous once installed — tasks, decisions, and the backlog live locally in .engine/.