> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rippletide.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Team Governance

> Scale coding conventions across engineers and repositories with shared Context Graphs

## Quick reference

| Action         | Command (typed in Claude session)   |
| -------------- | ----------------------------------- |
| Create team    | `create-team <name>`                |
| Join team      | `join-team <name> [approver_email]` |
| Approve member | `approve-join <team> <otp> <email>` |
| Push to team   | `push-rules <team>`                 |
| Sync from team | `sync-rules <team>`                 |

## The problem at scale

Each coding agent has its own local memory — but none of them talk to each other. When multiple agents run in parallel across your organization, Engineer A's agent enforces one set of conventions while Engineer B's enforces another. The context is there, it's just siloed.

## The `--read-only` flag

When you connect with `--read-only`, the agent can **read** from the graph but cannot **write** to it:

```bash theme={null}
npx rippletide-code --read-only
```

This is what makes team-wide governance possible:

* A **team lead** or **platform engineer** maintains the canonical Context Graph with all conventions, patterns, and policies
* Individual engineers connect to it in read-only mode
* Every agent session inherits the same standards without anyone being able to accidentally overwrite them

## Centralized policy, distributed agents

The Context Graph acts as shared engineering memory. The workflow:

<Steps>
  <Step title="Define your standards">
    A team lead stores conventions in a Context Graph — naming rules, component patterns, architectural decisions. This can be done via the [dashboard](https://app.rippletide.com) or automatically through the CLI with `npx rippletide-code`.
  </Step>

  <Step title="Connect every engineer">
    Each engineer runs the connect command in read-only mode in their project:

    ```bash theme={null}
    npx rippletide-code --read-only
    ```

    Their coding agent now has access to the full set of team standards.
  </Step>

  <Step title="Update once, propagate everywhere">
    When a convention changes (e.g., "we're switching from REST to tRPC"), the team lead updates the graph. Every active agent session picks up the change on the next `recall` or `get_context` call. No PRs to update linting configs. No Slack messages hoping everyone reads them.
  </Step>
</Steps>

## What this looks like in practice

**New engineer onboarding**: Instead of reading a 40-page style guide, their coding agent already knows the conventions. They start writing code that matches the team's patterns from day one.

**Cross-repo consistency**: The same Context Graph can be shared across multiple repositories. Frontend, backend, infrastructure — same naming rules, same error handling, same patterns.

**Audit trail**: Every rule stored in the graph is an entity with a history. You can see what was added, when, and by whom through the [dashboard](https://app.rippletide.com).

## Example: team setup

```bash theme={null}
# 1. Team lead creates the shared graph (read-write)
npx rippletide-code

# 2. Team lead defines conventions via their coding agent
#    e.g. "From now on, use camelCase for all variables"
#    The agent stores this in the Context Graph automatically

# 3. Every engineer connects in read-only
npx rippletide-code --read-only

# 4. Every agent session now enforces the same conventions
```

## Connecting to a teammate's graph

You're not limited to a single shared team graph. You can connect to any colleague's Context Graph if they share their agent ID:

```bash theme={null}
npx rippletide-code --read-only
```

This is useful for pair programming scenarios or when ramping up on a codebase that one person knows well.