Set Up cedr With an Agent

Your coding agent can help you choose a setup and apply it. You do not need every product, and a hosted MCP connection does not require the CLI.

Copy This Prompt

Paste this into your coding agent:

Read https://cedr.dev/docs/agents and help me set up cedr. If I already set products up in the cedr web app, use those settings and cover only what is left. Otherwise act as my setup wizard: before changing anything, ask which products I want to enable (Route, Council, Guard, Sync and Monitor) and whether I want Local MCP, Hosted MCP, both or neither, then walk me through each product's setup one step at a time. Explain the choices and recommend a setup for my workflow, but wait for my approval. Ask before installing, changing configuration, uploading data or scheduling jobs. Configure only what I approve and verify each selected part. Never ask me to paste credentials into chat.

Set Up in the App First, or Let Your Agent Lead

There are two ways to start, and you can mix them:

• In the app. Each product page in the app has a Setup tab that walks through the product step by step, and the Overview’s setup guide shows what is left. Choices you save there (routes, Council members, Sync rules, a Monitor budget) are what your agent then applies on your machine. The app also offers prompts filled in with your organization’s settings; review them and confirm which parts you want before letting your agent apply them.
• With your agent as the wizard (recommended). If you have not set anything up in the app, your agent interviews you one step at a time, in the same order as the app’s Setup tabs, recommends an answer at each step and records what you approve.

Agent: ask first whether the person already configured products in the app. If they did, read the saved settings (with Hosted MCP, or ask the person to confirm what the app shows) and cover only what is left. If they did not, act as the setup wizard: work through one product at a time in this order, asking one step at a time.

Product	Setup steps
Route	Providers and plans on this machine; routes to turn on; keep routes local or save them for the organization; set up this machine; connect the agent; check.
Council	Route ready; members; what blocks (severity, quorum, revision rounds); save; connect this machine; first review, only with approval.
Guard	Install the CLI if needed; pin the first repository and review the lock; report to the organization only if approved; CI only if approved; review the first check.
Sync	Install the CLI if needed; start from the repository’s .cedr/ files or the organization’s rules; connect the repository and preview the generated files; run the first check; report only if approved.
Monitor	Agents and folders to count, and how projects are labelled; set up this machine; a monthly budget (optional); invite the team (optional); confirm the first usage, uploading only if approved.

Ask Your Agent in the App

Overview, Route, Council, Guard, Sync, Monitor, API keys, MCP, Logs and Metrics in the app each have an Ask your agent menu at the top right. One click copies a prompt; Preview shows the full text first. Paste it into your coding agent of your choice.

Prompts are filled in with your organization’s settings, such as its ID, saved routes and Council members, and never include keys or tokens. Every prompt tells your agent to explain what it will do and wait for your approval before installing anything, editing configuration, uploading data or scheduling a job. Remove prompts also list everything first, back up configuration before deleting it and never touch your organization’s data in the app.

The menu follows each product’s state. Before a product is set up its setup prompts come first; afterwards the everyday ones lead. A prompt that cannot apply yet, such as Fix a blocked change with no blocked result, is shown greyed out with the reason.

Page	Prompt	What it does
Overview	Set up cedr	Uses what you saved in the app, otherwise walks you through setup a step at a time.
Overview	Next: set up Route, Council, Guard, Sync or Monitor	The same as that product’s setup prompt; listed for each product not set up yet.
Overview	Weekly check-in	Summarises the last 7 days across your products and what needs attention.
Overview	Health check	Runs cedr doctor and checks each product on this machine, changing nothing.
Overview	Start fresh	Backs up and clears cedr’s local settings, keeps the CLI, then runs setup again.
Overview	Remove cedr from this machine	Removes every product’s settings, MCP connections, schedules and the CLI, after listing each one.
Route	Tune my routes	Suggests route and provider changes from your picks and verdicts.
Route	Troubleshoot Route	Runs cedr doctor and finds why picks fall back or never sync.
Route	Set up this machine	Installs the CLI if needed and writes routes.toml from your saved routes.
Route	Connect my agent	Registers cedr MCP so your agent picks a route before delegating.
Route	Remove Route from this machine	Removes routes.toml, its sync and the agent instructions; keeps the CLI.
Council	Review my current change	Plans a council review of your working change and reports the gate.
Council	Fix a blocked change	Works through the latest blocked result and runs the review again.
Council	Tune my council	Suggests member, quorum or severity changes from past results.
Council	Set up Council here	Configures this machine for your saved members and rules.
Council	Remove Council from this machine	Removes the council route and review instructions; Route stays.
Guard	Fix Guard findings	Works through the findings of the repo that needs it most, then verifies again.
Guard	Review server updates	Checks newer versions of pinned servers and explains what changed.
Guard	Pin this repo	Lints, pins and verifies the repo’s skills and MCP servers.
Guard	Add Guard to CI	Adds the cedr GitHub Action so every pull request is checked.
Guard	Remove Guard from this repo	Removes the lock, surfaces and Guard’s CI check from this repo.
Sync	Fix this repo	Resolves drift, hand edits and rule findings, then checks again.
Sync	Roll out new org rules	Pulls the latest org rules into each repo for review.
Sync	Troubleshoot Sync	Finds why a repo does not check or report.
Sync	Set up this repo	Imports or starts .cedr/, previews, compiles and checks.
Sync	Draft org rules	Drafts organization rules from how your repos are set up today.
Sync	Add Sync to CI	Adds the cedr GitHub Action and a weekly repair job.
Sync	Remove Sync from this repo	Stops generating; keeps or restores your agent files; removes the CI check.
Monitor	Analyse my usage	Explains where tokens and spend go, and how to cut them.
Monitor	Troubleshoot missing data	Checks sources, config and pushes when usage stops arriving.
Monitor	Set up this machine	Writes monitor.toml with your exclusions; uploads only if you approve.
Monitor	Roll out to my team	Helps teammates set up with the same exclusions and labels.
Monitor	Remove Monitor from this machine	Removes monitor.toml, the schedule and status-line uploads.
API keys	Store a key safely	Saves a new key on this machine or as a CI secret; the key never enters the chat.
API keys	Remove a stored key	Deletes a stored copy of a key; revoking it happens in the app.
MCP	Connect my agent	Connects your agent to Hosted or Local MCP, then makes a test read.
MCP	Disconnect my agent	Removes the cedr and cedr-cloud MCP servers; revoking access happens in the app.
Logs	Review suspicious activity	Flags unfamiliar devices, wrong passwords and error spikes, and what to revoke.
Metrics	Diagnose errors and limits	Explains error rates, rate-limit hits and busy minutes per key.

To remove a product by hand or without the app, see each product’s setup page, and Start Fresh or Remove cedr for the whole machine.

1. Agree on the Scope

Setup starts with your choices

1. ChooseProducts, agents and MCP connection
2. →ApproveChanges, uploads and automation
3. →ConfigureOnly the agreed parts
4. →VerifyReport results and skipped parts

Your agent recommends a setup. You decide what it may enable; skipped products stay skipped.

Agent: ask these questions before running setup commands or editing files. You may recommend a combination, but the person decides. Record the approved choices so skipped parts stay skipped.

Choice	Explain and ask
Products	Route picks models; Council combines independent reviews; Guard pins skills and MCP servers; Sync generates repository agent setup; Monitor reports usage and limits. Which should be enabled?
Agent and scope	Which coding agents and providers are used on this machine? Which repository, if any, is in scope? Should an MCP connection apply to this user or only this project?
MCP connection	Local MCP, Hosted MCP, both or neither? Use the distinctions below.
Organization uploads	Keep activity local, or send the selected products’ reports to a chosen organization? Explain each upload before enabling it.
Monitor privacy	Which folders must never be collected? Which agents should be counted? Send project names, hashes or no labels? Is uploading retained history acceptable?
Automation	Enable Route background sync, Monitor uploads, CI checks or scheduled repair pull requests? Approve these separately.

Summarize the choices and wait for approval. Installing a tool does not authorize every feature it provides. If a dependency is needed, explain it and ask; do not silently enable another product.

Choose an MCP Connection

• Local MCP (cedr): the CLI runs on this machine over stdio. It provides live routing, Council planning, local Sync checks and Monitor reports. It needs the CLI, but no hosted MCP connection.
• Hosted MCP (cedr-cloud): connects to https://mcp.cedr.dev/mcp over HTTPS for organization routes, synced activity and hosted tools. It needs browser sign-in or a private API key, but no CLI. Its machine snapshots are not live routing picks.
• Both: use the two distinct server names and choose the server for the data needed. Connecting both does not itself enable synchronization.
• Neither: use the CLI commands or the app directly. MCP is optional.

See the MCP overview for a comparison. Hosted-only setup skips CLI installation, local product configuration and cedr doctor.

2. Protect Existing Setup and Credentials

• Respect the repository’s instructions and existing configuration owners. Inspect generated-file notices and change the source rather than overwriting generated output.
• Back up configuration before editing it, preserve unrelated settings and servers, and show the proposed diff. Do not commit, push, change a subscription or deploy unless asked.
• Show commands and useful results with secrets redacted. Never print credential files, expanded authorization headers, tokens or provider keys.
• For CLI uploads, have the person create an appropriately scoped key at API keys and save it privately to ~/.config/cedr/api-key. Check mode 600 without reading its contents. The CLI reads the key itself. CI uses a repository secret named CEDR_API_KEY that the person supplies.
• For Hosted MCP, prefer browser sign-in. The person completes sign-in and consent themselves. For key authentication, use the client’s supported secret store or reference; never put a literal key in source-controlled configuration.
• Never run an untrusted skill, package or MCP server to evaluate its safety. Registering the approved cedr local server is separate from executing the servers Guard inspects. Never describe a configuration as safe because a check passed.

3. Install Only What Is Needed

For selected local products or Local MCP, follow Install the CLI. Check cedr --version; install or update only after approval. Use an official GitHub release and check its archive against that release’s SHA256SUMS. Stop on a mismatch. Do not install through a script piped to a shell or with administrator privileges.

Explain the CLI’s anonymous usage data, including its opt-out, before the first run. If the person declines telemetry, set CEDR_TELEMETRY=0 in the command environment from the first invocation.

Local CLI use does not require an account. If hosted features are selected, let the person sign in at app.cedr.dev and confirm the organization ID from Settings or MCP. Never create or sign in to an account on their behalf.

4. Configure the Selected Products

Run only the approved rows. If a linked app prompt includes an unapproved upload or schedule, skip that step and explain why.

Product	Setup and verification
Route	Follow Set Up Route, confirm providers on this machine, and check cedr route list and cedr route pools. Enable Route sync only if organization uploads were approved.
Council	Follow Set Up Council, choose members, quorum and blocking severity. It uses routes.toml but does not require enabling every Route workflow. Planning records picks; running a real review also consumes the selected providers’ capacity, so ask before the first review.
Guard	Follow Pin and Verify a Repository. Review lint findings and the lock diff before accepting the baseline. Run cedr verify; use cedr push only if reporting was approved.
Sync	Follow Set Up Sync. Import, choose targets, preview with cedr sync --dry-run, review and compile, then run cedr sync check. Pull organization rules only when selected and available on the plan; upload only with approval.
Monitor	Follow Set Up Monitor. Write exclusions and source choices before any collection command. Inspect cedr monitor sources, then a local report. Upload retained history and install scheduling only if each was approved.

If both Sync and Guard are selected, compile Sync’s files before creating Guard’s baseline. This lets Guard pin the generated configuration you intend to use.

5. Connect the Selected MCP Servers

For Local MCP, follow Local MCP, preserve existing connections, reconnect the client and discover its tools. Verify with a read appropriate to the approved product, such as route_list for Route or sync_check with the selected repository path for Sync. Tool discovery does not authorize running Monitor collection or making routing picks.

For Hosted MCP, follow Hosted MCP. Request read access for setup, let the person complete authentication, then discover tools and call route_list for the selected organization. Ask separately for write access if needed later. Explain that authorization follows the person’s memberships; the setup prompt’s organization is a default, not an access restriction.

For both, configure cedr and cedr-cloud separately. For neither, skip this section.

6. Add Optional Automation

• Guard CI checks pins and lint findings.
• Sync CI checks generated configuration; scheduled repair pull requests need additional permissions and separate approval.
• Monitor scheduling sends usage periodically. To stop it, remove the schedule and disable status-line uploads.

Scope the workflow to the selected products. The shared GitHub Action can run both Guard and Sync checks: explain that behavior before adding it. Omit push-org and the API key when no organization upload was approved.

7. Verify and Hand Back

For a CLI setup, run cedr doctor and distinguish failures in selected products from checks for features the person intentionally skipped. Do not enable a skipped product just to make every diagnostic pass. Hosted-only setup uses the connection and read-call checks above instead.

Finish with what was enabled, what was skipped, configuration paths changed, verification results, approved uploads and schedules, and any steps the person still needs to complete. If a check fails, report the actionable error and the smallest proposed fix. Never claim setup succeeded from tool discovery alone.

When Something Fails

Symptom	Next step
no API key or a readable-by-others key file	The person saves the key privately; check mode 600 without displaying it.
not_a_member	Confirm the organization ID and the signed-in person’s membership.
plan_required	Check Plans; keep approved local functionality working and ask before any plan change.
A client cannot connect to hosted MCP	Check remote HTTP and authentication support; do not install an unapproved proxy.
Sync refuses an existing file	Review the import and owning source before considering replacement.
Missing Monitor sources or plan readings	Follow Monitor troubleshooting.