backend-integrate

backend-integrate

Give Copilot and Claude Code the full context they need to integrate any downstream service — automatically.

One command. The agent fetches the right files, asks the right questions, and builds the integration track by track.

---

The problem

Integrating a downstream backend service is one of the most context-heavy tasks a developer faces. Before writing a single line of code, you need to understand:

• What endpoints exist and what they accept
• How authentication works (API key? OAuth? mTLS?)
• What environment variables to add
• What the request/response shapes look like
• How errors are structured and which ones to retry
• What patterns your own codebase expects

Then you need to somehow convey ALL of that to Copilot in a chat window — or just wing it and fix the mistakes.

backend-integrate solves this. Point it at the downstream service's GitHub repo, tell it which integration guide to read, and it handles the rest.

---

Install

GitHub Copilot CLI

copilot plugin install sagar-rai/backend-integrate

Claude Code

# Add this repo as a marketplace (one-time)
/plugin marketplace add sagar-rai/backend-integrate

# Install the plugin
/plugin install backend-integrate@backend-integrate

Both require gh auth login to be active.

---

Quick start

Just describe what you want to integrate:

Integrate the payment service from github.com/acme/payment-svc — use INTEGRATION.md for context, I need to add checkout support

I need to call the notification service (github.com/org/notify-svc, context file: DOWNSTREAM.md) to send order confirmation emails

Add support for the inventory service — repo is github.com/org/inventory, integration guide is docs/INTEGRATION.md

The more specific your command, the more precise the integration. Here's a real-world example integrating a gRPC service — pointing at a specific RPC, a specific client class to update, and a specific repository pattern to follow:

use docs/billing-engine-grpc-integration-guide.md from acme/billing-engine repo to integrate
ListPaymentMethods rpc from ProductAPI service — integrate the call in
BillingEngineClient, update the billing-engine-client version in build.sbt to the latest,
and see other methods to see how this call is being called from the repository layer in the project
and integrate a similar refresh in BillingEngineRepository

Copilot will take it from there.

---

How it works

1. FETCH      gh CLI downloads the integration context .md + scans the repo
              for protos, OpenAPI specs, client examples, env config, models
                │
                ▼
2. ANALYZE    Copilot reads all files and synthesizes the integration surface:
              endpoints, auth mechanism, required config, data models
                │
                ▼
3. CLARIFY    Copilot asks you 7 questions about your service before planning:
              language/framework, patterns, error handling, tests, config
                │
                ▼
4. PLAN       A file-level integration plan is presented for your approval
                │
                ▼
5. BUILD      Parallel fleet agents implement the integration simultaneously:
              client → service layer → config → DI wiring → tests → docs
                │
                ▼
6. CLEAN UP   All temporary files removed from ~/.agents/session/<uuid>/

---

What Copilot will ask you

Before generating any code, Copilot asks 7 required questions to ensure the integration fits your codebase:

1. Language & framework — Go+Gin, Java+Spring Boot, Node+Express, Python+FastAPI, etc.
2. Scope — which specific endpoints/features you need (confirmed against what was found)
3. Existing patterns — do you have an HTTP client wrapper or gRPC client to follow?
4. Error handling — propagate up, fallback values, retry with backoff?
5. Tests — unit tests, integration tests, which framework?
6. Architecture — which service/repository layer should the integration live in?
7. Config management — env vars, config files, Vault, AWS SSM?

These questions prevent the most common integration mistakes: wrong error handling, mismatched patterns, missing config, untested code.

---

What gets built

A typical integration produces: