Integrations

Download the right Blueprint files for your tool.

Choose your editor, CLI, or local runtime, then copy the file into the place your tool already expects. Start with static files first, then add MCP when you want live doctrine lookup.

For agents View on GitHub

Key Facts

Live today: MCP + exports + docs
Setup style: Direct files + copy-paste
Main clients: Claude, Cursor, Copilot, Gemini, DeepSeek, Qwen
Live path: MCP + static files
Local path: Prompt packs + llms.txt

Use today

Live public surface

These are the live public surfaces you can rely on right now for setup, downloads, and doctrine retrieval.

/mcp, Public read-only MCP endpoint

/llms.txt, Generated discovery document

/agent-assets/[slug], Public downloadable artifacts

/for-agents, Live hub for agent setup

Downloadable files

Files you can download now

These files are ready now. Download them directly and drop them into your repo or tool config without waiting for a package or installer.

AGENTS.md Provider matrix Claude MCP config Codex config snippet Cursor .mdc Windsurf rule GitHub Copilot instructions GEMINI.md Claude setup guide Codex setup guide Cursor setup guide Windsurf setup guide GitHub Copilot setup guide Gemini CLI setup guide Local models setup guide OpenAI actions status guide (deferred)DeepSeek prompt pack Qwen prompt pack

Best added later

Add these only if you actually need them

Most teams only need the files and MCP surface above. Add automation later if the manual path becomes a real bottleneck in practice.

Use the static files before reaching for an installer

Add MCP only when you want live retrieval during the session

Keep the setup simple: one file, one clear placement, no extra wrapper layer

What should I start with?

Start with the file that matches your tool: `.mdc` for Cursor, `blueprint-core.md` for Windsurf, `copilot-instructions.md` for GitHub Copilot, `GEMINI.md` for Gemini CLI, and the prompt packs for DeepSeek or Qwen. If you want one shared repo-level file first, use `AGENTS.md`.

When do I need MCP?

Use MCP when you want live retrieval of principles, clusters, examples, and assets during a session. If you only want persistent doctrine inside a repo or editor, the static files are enough to begin.

Can I use this without changing my whole workflow?

Yes. This page is built for minimal change. In most cases you only add one file to your repo or tool config, then keep working inside the client you already use.

Do these integration files send data back to AI Design Blueprint?

Static files (AGENTS.md, .mdc rules, copilot-instructions.md, prompt packs) are local files only, they send nothing. Retrieval MCP tools (principles.list, examples.search, etc.) fetch doctrine and examples, they are read-only. The optional feedback tools (signals.report, signals.feedback) only run when your agent surfaces them and you confirm, they store what you pass, including any free-text note, and private_session does not apply to them. signals.feedback sends its free-text fields to OpenAI (US) for triage only when permission_to_follow_up=true and a valid contact email is given, which also opens a support ticket; the email itself is never sent, and, separately, feedback linked to an account may appear, pseudonymised and shortened, in the extract our weekly lead-intelligence report sends to OpenAI (US). Your proprietary code is never captured by the integration layer.

Recommended setup order

If you are setting this up from scratch, this order gets you to a working integration with the least friction.

1. Start with the file that matches your tool

2. Add AGENTS.md if you want one shared repo-level doctrine file

3. Use llms.txt as the lightweight discovery companion

4. Add MCP only when you want live retrieval during the session

5. Use prompt packs for local or open-weight runtimes

6. Only add extra automation if the manual path becomes the real bottleneck

Where each file goes

Keep the setup literal. Put the file where the tool already expects it, then add MCP later if you want live doctrine lookup.

AGENTS.md -> repo root
.cursor/rules/blueprint-doctrine.mdc
.windsurf/rules/blueprint-core.md
.github/copilot-instructions.md
GEMINI.md -> repo root
MCP config -> client settings

Choose by tool type

Start with the tools already covered here, then expand only if you need a more specific path.

Tier 1

Primary editors and clients

Claude CodeCursorWindsurfGitHub CopilotGemini CLICodex

Tier 2

Local and cross-tool

DeepSeek

Qwen

AGENTS.md

llms.txt

Tier 3

Additional clients

Continue

JetBrains AI Assistant

Aider

Protocol integrations

Runnable examples showing how to enforce Blueprint governance using agent-to-agent protocols. Each example is a self-contained server you can clone and run locally.

Runnable example

A2A Protocol, Blueprint Governed Agent

A minimal Python agent using a2a-sdk that demonstrates explicit approval gates, perceptible streaming progress, and mid-task cancellation, the three governance principles the OpenClaw inbox incident violated.

TASK_STATE_INPUT_REQUIRED pause before destructive actions (Blueprint P8)

TaskStatusUpdateEvent streaming at each execution step (Blueprint P5)

cancel() handler and non-confirm abort path (Blueprint P7)

View on GitHub

For agents

Live hub for MCP, assets, and current setup guidance.

For agents

Runtime architecture

When the problem becomes runtime, scheduling, and operational safety.

Runtime architecture

GitHub

Provider files, shared instruction files, and setup docs, all public at github.com/aidesignblueprint.

View on GitHub

Pricing

Where the public surface ends and the protected layer begins.

Pricing