How to Set Up Graftcode's AI Coding Rules in Any IDE

Coding assistants are becoming important in development workflows. Developers use tools like Claude Code, Cursor, GitHub Copilot, and Windsurf to generate code and automate tasks that are often handled manually.

The challenge is that these tools typically follow common development patterns. When asked to connect applications and services, they often generate REST APIs, controllers, routes, and integration layers because that's how most modern software is built.

In this blog post, you'll learn how Graftcode helps solve that problem: a tool that exposes backend methods as installable packages your applications and AI agents can call directly, without working with APIs, building REST endpoints, or duplicating logic.

This post walks through what that command does, how it fits into the rest of the Graftcode toolchain (the Gateway, Grafts, and Graftcode Vision), and how to verify it's actually working before you trust it with real code.

What You Will Learn

By the end of this post, you will be able to:

• Explain what Graftcode is and what problem it solves
• Install Graftcode's AI-agent rules in a project with one command
• Understand how the Gateway, Grafts, and the rules fit together
• Host a module with Graftcode Gateway and install a Graft that calls it
• Give your AI agent a first, safe prompt to confirm everything is wired up correctly

What Is Graftcode?

Graftcode is a tool that lets you call backend functions and methods from another runtime without manually building REST APIs, writing HTTP client code, or creating custom SDKs. Instead of treating your backend as a collection of endpoints, Graftcode generates a strongly typed Graft package that applications can install via a package manager and use to call backend methods directly.

Graftcode uses its Gateway to expose selected backend classes and methods and generates a package, called a Graft, that you can install directly in your application.

Adopting Graftcode is meant to:

• Reduce the need for manually wiring communication layers such as REST, gRPC, Thrift, or other API-based integrations between applications
• Cut the amount of integration code in a codebase by a wide gap
• Make AI-assisted development easier, since there's less boilerplate for an agent to read, which results in lower token usage and simpler code review
• Make every exposed method usable as an MCP tool, so AI agents can call it directly
• Support modular monoliths, where modules can be developed, exposed, and recombined independently.

That's a lot of moving parts to explain to a coding agent from scratch every time you start a session.

Major Components of Graftcode

Component	Role
Graftcode Gateway (gg)	Hosts your module's runtime and exposes its public methods
Graft	A generated, strongly typed client installed via a package manager in the project
Hypertube	The runtime bridge that lets calls cross languages and processes
Graftcode Vision	A visual UI of what Graftcode exposes
AI rules	Instruction files that teach a coding agent Graftcode's conventions

You install the rules once per project. The Gateway and Grafts are the pieces that actually carry your application's traffic.

Prerequisites

• A terminal: PowerShell on Windows, or a standard shell on Linux/macOS
• A module or library you want to expose, written in one of Graftcode's supported runtimes (.NET, Java, Python, Ruby, Node.js, or PHP)
• A package manager for the calling side of the connection (npm, NuGet, pip, etc., depending on the client's language)
• An AI coding agent that reads your project's files. Graftcode Rules currently support selected agentic IDEs and coding assistants, including Cursor, Claude Code, Claude Desktop, VS Code, Windsurf, and other compatible IDEs. The generated rules are stored as plain project files that supported tools can read and use when generating code.

Step 1: Install Graftcode's AI Rules

From the root of the project you want your agent to work in, run the command for your OS. These are the exact commands published in Graftcode's main GitHub repository.

PowerShell:

iwr grft.dev/get | iex

Linux / macOS:

curl -fsSL grft.dev/get | sh

Alternative, using wget:

wget -qO- grft.dev/get | sh

Graftcode's repository shows how these rules are set in a project. An AI agent can build anything from a modular monolith to a distributed system on top of Graftcode using prompts alone, whether starting a new project, migrating an existing application, or extending an existing one.

Rather than repeatedly explaining Graftcode concepts in prompts, developers can rely on the generated rules to provide architectural guidance. This helps coding agents produce more consistent and accurate implementations, particularly in larger and more complex systems.

If you want to check exactly what gets installed before you trust it, the raw rule and instruction files are public in the /rules directory of Graftcode's repository. Graftcode describes these files as what lets agents like Claude understand and correctly use Graftcode when generating or refactoring code.

Step 2: Install Graftcode Rules

The generated rules teach your coding agent how Graftcode applications should be structured. They provide guidance on exposing modules, consuming Grafts, working with Graftcode Gateway, and building applications using Graftcode patterns rather than traditional API-centric architectures.

Once installed, the rules become part of your project and are available to supported coding assistants whenever they generate or modify code.

Step 2a: Running Graftcode Gateway Locally

To expose modules and make them available through Graftcode, you'll need to run Graftcode Gateway.

The graftcode-gateway repository documents the installation process and runtime options. The rules can guide coding agents through this setup automatically, but it's useful to understand what is happening underneath.

1. Package your library
2. Navigate to the output folder
3. Download Graftcode Gateway (Refer to this guide to learn how to install the Gateway)

Windows Installation

iwr https://grft.dev/get | iex

Linux / macOS Installation

curl -fsSL https://grft.dev/get | sh

Or with wget

wget -qO- https://grft.dev/get | sh

Once the Gateway (gg) is available, point it at your built module:

gg --modules ./MyService.dll

Step 2b: Running Gateway in Containers

The generated rules can also instruct supported coding assistants to create Dockerfiles and containerized development environments that include Graftcode Gateway.

This means developers are not limited to manually installing and running Gateway on their local machine. Depending on the project, the agent can generate the required container configuration and run Gateway inside Docker as part of the application environment.

This is particularly useful for teams that standardize on containerized development workflows or want a reproducible setup across multiple environments.

Advanced Gateway Configuration

For more control, the Gateway accepts several flags. A fuller example from the repository, hosting a .NET Core module with Graftcode Vision enabled:

./gg --runtime netcore --modules /path/to/your.dll --GV --port 8888 --httpPort 8889 --mcpBaseClass Mynamespace.MyClass

Then keep the flags table, runtime table, and GG_DEBUG section exactly as you already have them.

Flag	Purpose
--modules	Path to the built library or module to host
--runtime	Which language runtime the Gateway should target
--GV	Enables Graftcode Vision, a live view of what's exposed
--port	Port used for the actual Graftcode traffic
--httpPort	Port used to serve Graftcode Vision (ports to 81 by default)
--mcpBaseClass	The class containing the static methods exposed to an MCP client

There's also a GG_DEBUG environment variable, which activates console logging of the raw byte arrays going in and out of the Gateway; it’s useful if you need to see exactly what's going wrong while you're debugging a connection.

Step 3: Let the Agent Generate the Graft Integration

Once your service is running through Graftcode Gateway, the next step is connecting a client to it. Supported coding agents can generate this integration automatically using the installed rules, including installing the required Graft package when needed.

npm install --registry https://grft.dev/YOUR_PROJECT_ID @graft/your-service-name

Before calling any methods, configure the Graft to point at the running Gateway instance:

import { GraftConfig } from "@graft/your-service-name";

GraftConfig.host = "ws://localhost:8080/ws";

The host value should point to the Gateway instance exposing your service. If you're using a different port or a Project Key deployment, use the address provided by Graftcode Vision or your deployment configuration.

import { EnergyPriceCalculator } from "@graft/your-service-name";

const price = await EnergyPriceCalculator.GetPrice();

Graftcode also handles keeping that client current: when the exposed API changes, it notifies your package manager that a new version of the Graft is available, the same way any other dependency update would show up.

Step 4: Let The AI Agent Get To Work

With the rules installed and a Gateway and Graft in place from Steps 2 and 3, you can leave everything for your agent to handle. Instead of asking it to "add a REST endpoint" or "write an HTTP client," you can prompt it the way you would any other task. For example, "expose this method to the frontend" and let it apply the same logic described in the installed rules.

Before trusting it with a real change, try running it safely via a read-only prompt first, the same way you'd check any new tool in your workflow:

Look at the /rules folder in this project without changing anything.
Summarize how I can expose a method as a Graft and how a client project is expected to use the method. Lastly, cite the specific rule files you used.

If the agent can correctly describe the Graft/Gateway pattern back to you, citing the actual files it read, you know the rules are installed and being picked up.

Key Takeaways

• Graftcode allows applications to call backend methods through generated Grafts instead of manually writing API integration code.
• Installation in just one: iwr grft.dev/get | iex on Windows, or curl -fsSL grft.dev/get | sh on Linux/macOS, installs the AI-agent rules that teach a coding agent this model.
• The same install command also appears in the Gateway's own setup steps for downloading the gg binary that actually hosts a module.
• gg supports multiple runtimes and provides features such as Graftcode Vision and MCP support.
• Clients install a generated Graft through their normal package manager and call the exposed methods directly.

Installing the rules doesn't change what Graftcode does under the hood; a Gateway still hosts the methods, a Graft still calls them, and Hypertube still bridges the two.

What changes is who has to understand that model before it's useful: instead of a developer reading through the docs and briefing an agent by hand, the agent reads the same instructions Graftcode publishes and applies them the next time you ask it to connect two pieces of code.