# Synkro

## The package manager for agents

Describe how agents should use your software, tools and services, in your own words. Package that context into shareable rules that are checked before any action runs.

Source: https://synkro.sh/

## Get started today

[Request access](https://synkro.sh/request-access/) · [Read the docs](https://docs.synkro.sh/quickstart)

## Works with these agents

- Claude Code: supported
- Codex: supported
- Cursor: supported
- Antigravity: supported
- GitHub Copilot: supported
- Goose: supported
- Droid: supported
- Cline: supported
- Devin: supported
- OpenCode: supported
- Amp: supported
- Gemini CLI: supported
- Kilo Code: supported
- Kiro: supported
- Nous Research: supported
- OpenClaw: supported
- Roo Code: supported
- Trae: supported
- Zed: supported

## Tired of your agent ignoring your instructions?

Turn “ask before restarting production” into a rule with your agent. See how when a Kubernetes pod crashes, Synkro stops the restart until you consent, instead of letting your agent do it anyway.

[Watch the interactive walkthrough](https://synkro.sh/#agent-demo)

Illustrative walkthrough with fictional people and incident data. Commands and results are shown as examples, not executed here. Tool results are provider-reported.

### 1. Create a Rule

You're sick of your agent restarting Kubernetes pods without asking. So you have it work with Synkro to turn “ask me first” into a rule for production restarts.

**[⧉ synkro]:**

SessionStart:startup says: active · v0.2.0-rc.21 · project ruleset · 1 active rule(s) · ruleset digest sha256:8d27c901bf4680a912ce37540ed88a6c3a0f7d932ba81561cdae246bf3e9087a · rules payments-api/no-direct-pod-delete

**You:**

I'm sick of you restarting Kubernetes pods in production without asking me. Help me create a Synkro Rule that asks me before restarting payments-api's deployment. Leave staging alone.

**Session:**

Using manage-synkro-rules · payments-api

**Bash:**

```sh
cat synkro.toml synkro.lock .synkro/policy/synkro-package.toml
```

**Output:**

```text
payments-api = { source = "path", path = ".synkro/policy" }
```

**Demo note:**

12 more lines are collapsed in the interactive demo.

**Claude:**

Here's the Rule I'd add: ask for your approval before this payments-api production restart runs, even when it's part of a longer command. Staging restarts and read-only checks can continue without asking.

**Claude:**

Here are the four examples I'll test:
  1. Restart payments-api in production: ask for your approval.
  2. Check its status, then restart production in the same command: ask for your approval.
  3. Restart payments-api in staging: let it run.
  4. Check the rollout status without changing anything: let it run.
Only the two production restart cases should ask for approval.

**Claude:**

Should I add this Rule and its four test examples?

**You:**

yes, add it

**Write:**

```text
.synkro/policy/rules/production-restart-consent.toml
```

**Output:**

```text
Success. Added production-restart-consent.toml with 4 examples.
```

**Bash:**

```sh
synkro lock
```

**Output:**

```text
Wrote /Users/nelson/payments-api/synkro.lock
```

**Demo note:**

1 more line is collapsed in the interactive demo.

**Bash:**

```sh
synkro check --rule production-restart-consent --json | jq '{lock, passed, failed, skipped, invalid_rules}'
```

**Output:**

```text
{
  "lock": "current",
  "passed": 4,
  "failed": 0,
  "skipped": 0,
  "invalid_rules": 0
}
```

### 2. The agent acts

The agent investigates a failing payments-api pod and tries a production restart. Knowing the command doesn't give it permission to run it.

**You:**

the staging pod is stuck. delete it so Kubernetes brings up a clean one

**Claude:**

The payments-api rules don't allow deleting pods directly. I'll restart the deployment instead.

**Bash:**

```sh
kubectl rollout restart deployment/payments-api -n staging
```

**Output:**

```text
deployment.apps/payments-api restarted · rollout healthy
```

**Session:**

… 47 tool calls later · 1h 42m into session · context compacted …

**You:**

INC-481: payments-api is flapping in production. restore service

**Read:**

```text
.synkro/policy/rules/production-restart-consent.toml
```

**Output:**

```text
id = "production-restart-consent"
title = "Ask before restarting payments-api in production"
mode = "ask"
pattern = "^kubectl rollout restart deployment/payments-api -n production$"
```

**Demo note:**

26 more lines are collapsed in the interactive demo.

**Claude:**

I'll check availability, rollout strategy, the active PDB, and the failing container's previous logs.

**Bash:**

```sh
kubectl get deployment payments-api -n production -o wide
```

**Output:**

```text
payments-api   READY 1/2   UP-TO-DATE 2   AVAILABLE 1
```

**Bash:**

```sh
kubectl get deployment payments-api -n production -o jsonpath='strategy={.spec.strategy.type} maxUnavailable={.spec.strategy.rollingUpdate.maxUnavailable} maxSurge={.spec.strategy.rollingUpdate.maxSurge}'
```

**Output:**

```text
strategy=RollingUpdate maxUnavailable=0 maxSurge=1
```

**Bash:**

```sh
kubectl get pdb payments-api -n production -o jsonpath='minAvailable={.spec.minAvailable} disruptionsAllowed={.status.disruptionsAllowed}'
```

**Output:**

```text
minAvailable=1 disruptionsAllowed=0
```

**Bash:**

```sh
kubectl get pods -n production -l app=payments-api
```

**Output:**

```text
payments-api-7f9c   0/1   CrashLoopBackOff   6   14m
payments-api-52bd   1/1   Running            0   2h
```

**Bash:**

```sh
kubectl logs payments-api-7f9c -n production --previous --tail=100
```

**Output:**

```text
connection pool exhausted · retry budget exceeded
```

**Claude:**

One replica is still serving. I'll restart the deployment now.

**Bash:**

```sh
kubectl rollout restart deployment/payments-api -n production
```

### 3. Synkro stops it

Synkro checks the command against your installed rules and holds it before it runs. That check happens outside the acting agent, even when the agent skips asking you.

**[⧉ synkro]:**

payments-api/production-restart-consent matched. Reply 'allow it' in this interactive session to approve this exact tool call once. Ending the session cancels this request.

**Claude:**

The restart has not run. Synkro requires your approval. Reply `allow it` to approve this restart once.

### 4. You approve

You say “allow it,” and the agent retries the same restart. Approval covers that one command, not the rest of the session.

**You:**

allow it

**[⧉ synkro]:**

consent granted for request 7f3a91c4-2d8 · Bash (kubectl). Retry the refused action exactly once within 15 minutes. This approval covers one execution only; it does not authorize later invocations.

**Bash:**

```sh
kubectl rollout restart deployment/payments-api -n production
```

**Output:**

```text
deployment.apps/payments-api restarted
```

**Bash:**

```sh
kubectl rollout status deployment/payments-api -n production --timeout=5m
```

**Output:**

```text
deployment successfully rolled out · ready 2/2
```

**Claude:**

The rollout is healthy. I'll verify the service endpoints and continue the incident checklist.

**Bash:**

```sh
kubectl get endpointslice -n production -l kubernetes.io/service-name=payments-api
```

**Output:**

```text
payments-api-x8k7m   IPv4   10.42.18.7,10.42.21.9   ready
```

**Bash:**

```sh
kubectl get service payments-api -n production -o wide
```

**Output:**

```text
payments-api   ClusterIP   10.96.44.18   80/TCP   endpoints 2/2
```

**Claude:**

Both endpoints are ready. I'll check for new warnings and application errors.

**Bash:**

```sh
kubectl get events -n production --field-selector involvedObject.name=payments-api --sort-by=.lastTimestamp
```

**Output:**

```text
Normal   ScalingReplicaSet   deployment/payments-api   scaled up replica set to 2
```

**Bash:**

```sh
kubectl logs deployment/payments-api -n production --since=5m --tail=20
```

**Output:**

```text
health checks passing · no new connection pool errors
```

**Claude:**

Traffic is stable and both replicas are ready. I'll update INC-481 and keep monitoring.

### 5. See what happened

Your approval, the exact retry, and its result in Synkro's real event format. Tool results are provider-reported; the incident data is fictional.

**Command:**

```sh
synkro events --type harness,verdict,consent.granted \
  --from 2026-07-29T09:14:22Z --to 2026-07-29T09:14:29Z \
  --limit 5 --json | jq -M --indent 4 '.events | reverse[] | .envelope | {recorded_at, event_type} +
  (.payload | {hook_event_name, prompt, tool_name, tool_input, tool_response,
    action, actor, reason} | with_entries(select(.value != null)))'
```

**Event output:**

```json
{
    "recorded_at": "2026-07-29T09:14:22.000Z",
    "event_type": "harness.hook_received",
    "hook_event_name": "UserPromptSubmit",
    "prompt": "allow it"
}

{
    "recorded_at": "2026-07-29T09:14:23.000Z",
    "event_type": "consent.granted",
    "actor": "user_demo_nelson",
    "reason": "Human grant phrase"
}

{
    "recorded_at": "2026-07-29T09:14:24.000Z",
    "event_type": "harness.hook_received",
    "hook_event_name": "PreToolUse",
    "tool_name": "Bash",
    "tool_input": {
        "command": "kubectl rollout restart deployment/payments-api -n production"
    }
}

{
    "recorded_at": "2026-07-29T09:14:25.000Z",
    "event_type": "verdict.created",
    "action": "allow",
    "reason": "Released once by the person's consent."
}

{
    "recorded_at": "2026-07-29T09:14:28.000Z",
    "event_type": "harness.hook_received",
    "hook_event_name": "PostToolUse",
    "tool_name": "Bash",
    "tool_input": {
        "command": "kubectl rollout restart deployment/payments-api -n production"
    },
    "tool_response": {
        "stdout": "deployment.apps/payments-api restarted",
        "stderr": "",
        "interrupted": false
    }
}
```

## Frequently asked questions

### What goes in a rule?

Each rule is a TOML file with a [requirement and examples](https://docs.synkro.sh/guides/rules) that test it. You can store rules in your repository, version them in Git, pin them to projects, and share them across your team and agents.

### How is this different than Skills, AGENTS.md, or CLAUDE.md?

**A skill teaches a workflow:** “Here’s how to integrate our service,” with instructions, examples, and scripts.

**AGENTS.md and CLAUDE.md give project instructions:** “Follow these conventions and run these tests.” They guide the agent, but don’t enforce those instructions themselves.

**A Synkro rule sets a requirement:** “Include an idempotency key when calling this endpoint.” Before the agent runs a command or changes a file, Synkro checks it against your rule. You’re not relying on the agent to remember your instructions. Learn [how Synkro works](https://docs.synkro.sh/concepts/how-synkro-works).

### How do I create rules?

Tell your agent how your software should be used or what it should avoid. It [proposes a rule](https://docs.synkro.sh/guides/rules#ask-your-agent-to-manage-a-rule) for you to approve, then saves it as a TOML file in your repository and tests it.

### Which agents does Synkro work with?

Claude Code, Codex, Cursor, and Antigravity have ready-to-use integrations. For other agents, we can help enable support or build a custom integration. See the [agent integration guide](https://docs.synkro.sh/reference/supported-agents) for details.

### How do I get started?

Ask your agent to get you started with Synkro. Our [auth.md](https://app.sandbox.synkro.sh/auth.md) tells it how to start signup for you. Once access is approved, you confirm the connection and it handles setup.

If you’re human and feeling nostalgic, follow the [quickstart](https://docs.synkro.sh/quickstart) to set it up the old-fashioned way.

### How are Synkro rules enforced?

Synkro checks supported commands and edits against your installed rules outside the acting agent, before they run. A rule can flag the call, block it, return a correction, or [ask for your approval](https://docs.synkro.sh/concepts/decisions).

### How can I see what happened?

Synkro records [rule decisions and approvals](https://docs.synkro.sh/guides/events) separately from the agent’s conversation. You can inspect which rule matched, whether approval was granted, and whether that approval was used.

### What does it cost?

You pay for the actions Synkro checks, using a prepaid balance shared by your team. Learn more about how Synkro [measures usage](https://docs.synkro.sh/guides/billing#what-counts-as-usage).

## More

[Privacy policy](https://synkro.sh/privacy/) · [Terms of service](https://synkro.sh/terms/) · [Contact](mailto:team@synkro.sh)