The package manager for agents

Name: Synkro
Author: Synkro

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.

Get started today

Request access Read the docs

Works with these agents

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.

Loading the interactive walkthrough…

Read the walkthrough

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

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

Output

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

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

Output

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

Bash
```
synkro lock
```

Output

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

Demo note

1 more line is collapsed in the interactive demo.

Bash

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

Output

{
  "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

kubectl rollout restart deployment/payments-api -n staging

Output

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

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

Output

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

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

Output

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

Bash

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

Output

strategy=RollingUpdate maxUnavailable=0 maxSurge=1

Bash

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

Output
```
minAvailable=1 disruptionsAllowed=0
```

Bash

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

Output

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

Bash

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

Output

connection pool exhausted · retry budget exceeded

Claude

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

Bash

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

kubectl rollout restart deployment/payments-api -n production

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

Bash

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

Output

deployment successfully rolled out · ready 2/2

Claude

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

Bash

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

Output

payments-api-x8k7m   IPv4   10.42.18.7,10.42.21.9   ready

Bash

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

Output

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

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

Output

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

Bash

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

Output

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

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

{
    "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 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.

How do I create rules?

Tell your agent how your software should be used or what it should avoid. It proposes 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 for details.

How do I get started?

Ask your agent to get you started with Synkro. Our 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 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.

How can I see what happened?

Synkro records rule decisions and approvals 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.