Your data
"A migration that has run is never deleted." "Seed data goes in in this order." "Every query names its tenant."
Team packs · coming in Cotterpin 0.3.0
Your team's own rules for AI coding agents, checked on every developer's machine
Every team has rules no language pack can know: never delete a migration, always go through the billing client, never hard-code a tenant. A team pack turns them into gates and agent guards that live in your own repository, so every developer and every agent on it works to the same rules, and nothing about them leaves your machines.
The rules that live in people's heads
Language packs catch what every Java, .NET, Python, Angular or Terraform team gets wrong. The costly mistakes are usually your own: the rule a senior engineer explains in review, again, to a person or an agent that was never told. An agent can't follow a rule nobody wrote down. A team pack is where you write it down, once, as a check.
Your architecture
"Payments go through the billing client, never straight to the provider." "The web layer never imports the database package."
Your process
"Deploy scripts are changed only with the platform team." "Feature flags are removed within two releases." "Nobody edits generated code."
What a team pack is
A folder in your repository
.cotterpin/packs/<name>/, written by your team and reviewed in your own pull requests, like any other code. Clone the repository and you have the pack.
Gates and agent guards
Its gates check the files a change touches, beside the language packs' gates. Its guards judge each agent action before it runs. Each refusal explains itself in your team's own words, with the fix.
Pinned by your lock
Every file of the pack is pinned by sha256 in .cotterpin.lock.json. Before any command uses the pack, each file is checked, and the pack runs from exactly the bytes that were checked.
Never sent to Cotterpin
A team pack is never uploaded, stored or served by Cotterpin. It travels the way your code does: through your own git. Nothing is downloaded when a teammate first uses it.
Edited by hand? Not used.
A pack whose files differ from the lock is not served, and Cotterpin says which file differs and how to re-pin it. Nobody runs a rule the team did not review.
Yours to keep
Creating or extending a pack needs a current licence (Pro or Team). If a subscription ends, every pack you have stays in your repository and keeps running, reporting instead of blocking.
From a rule to every machine, in five steps
- pack newStart
.cotterpin/packs/billing/with empty gates, guards and explanations. - writeAdd the rule and the words a developer or agent sees when it refuses.
- updatePin every file of the pack by sha256 in the lock.
- reviewCommit the pack and the lock together; your team reviews the pull request.
- pullEvery teammate who pulls is checked by the same rule, from the same bytes.
See it work
Six moments in a team pack's life, with the commands and the words Cotterpin prints. Pick one; each plays as it would in your terminal. Illustrations: team packs arrive with Cotterpin 0.3.0.
Illustration · coming in 0.3.0
Illustration · coming in 0.3.0
Illustration · coming in 0.3.0
Illustration · coming in 0.3.0
Illustration · coming in 0.3.0
Illustration · coming in 0.3.0
What Cotterpin sees of your pack: nothing
Your rules name your packages, paths and conventions, so they stay where your code is. The licence check runs on each developer's machine and sends nothing about the pack.
| What | Where it lives | Sent to Cotterpin? |
|---|---|---|
| The pack's gates, guards and explanations | Your repository, .cotterpin/packs/ | Never |
| The pins (sha256 of every file) | Your repository, .cotterpin.lock.json | Never |
| What a gate or guard found | The developer's machine | Never |
| Your source, diffs and prompts | Your machines, and the model provider you chose | Never |
| The licence check | The developer's machine, against a signed licence | Only what licensing already sends: licence id and a hashed machine fingerprint (Privacy Policy) |
Team pack or personal pack?
Ask one question: who should this rule bind? Everyone working on the repository: it belongs in the team pack. Just you: put it in a personal pack, your own rules for that one repository, kept on your machine and never committed. Contractors working across several clients' repositories keep one per repository, and nothing in one ever reaches another. Coming in 0.3.0.
| Team pack | Personal pack | |
|---|---|---|
| Binds | Everyone working on the repository | Just you, in that one repository |
| Lives | In the repository, .cotterpin/packs/, committed | On your machine, outside the repository, never committed |
| Reviewed | In your team's pull request | By you: you pin it yourself, at your own terminal |
| Runs | After the language packs | After the team pack, only adding to it: it can never switch a team rule off |
| Enforces | With a seat; reports without one | On Pro or Team; on Watch it reports what it would have caught |
| The company's say | It is the company's | A repository can turn personal packs off in its policy |
| When the work ends | It stays with the repository | One command removes it from your machine |
Cotterpin asks
Start a pack with cotterpin pack new and it asks who the rules should bind, recommending a personal pack when you can't write the team's yet.
Start personal, then propose it
Not sure? Keep a new rule to yourself until it has proven itself, then cotterpin pack personal propose copies it into the team pack, ready for your team's pull request.
Always clear whose rule it is
A personal rule's id starts p-, a team rule's starts with the team pack's name, so every refusal says whose rule it is and where to change it.
Across your organisation
Infrastructure, backend, database and frontend each have their own team and their own rules. Team packs follow the same lines.
Each repository keeps its own pack
The backend team owns the backend's rules; the platform team owns the infrastructure's. Each pack is reviewed by the team whose repository it is in. Coming in 0.3.0.
One pack for organisation-wide rules
Rules every repository shares, published once to your own package registry. Each repository's lock pins a version; the platform team releases an update and each team adopts it in an ordinary pull request. Coming in a future release.
Signed by your team
A team admin's key signs each pack release, and the lock trusts that key: a pack must match its pins and carry your team's signature. Coming in a future release.
Seats for a team
On Team, a seat belongs to one person, and that person's seat covers them in every repository your organisation owns. Team single sign-on (Okta, Microsoft Entra ID, Google Workspace or GitHub) assigns each seat to the identity your provider confirms, and someone your provider removes stops renewing. Team is priced per seat: see Pricing.
Enforced with a seat
A team pack blocks on machines with a seat. A developer without one still gets the pack's findings, reported and never blocking, so no one is surprised by a rule they can't see.
One machine at a time
A seat is held by one machine at a time. Moving between your own laptop and desktop is seamless; sharing a seat between people locks each other out. Coming in a future release.
A Team console
Seats bought, assigned and spare; who holds each one and where it is active; requests to approve; leavers freed when your identity provider removes them. Seat data only: never code or packs. Coming in a future release.
Illustration · coming in a future release
Questions
Who can write a team pack?
Anyone on your team, with any editor or agent, on their own machine. Starting or extending a pack through Cotterpin needs a current licence (Pro or Team). Whatever is written, it runs only after it is pinned in the lock and committed, so it goes through your review like any other change.
What can a team pack contain?
Gates that check the files a change touches, guards that judge each agent action before it runs, and the explanation of each refusal: what happened, why it matters, and the fix. A pack's rule ids start with the pack's name, so a refusal always says whose rule it is.
Does Cotterpin ever see or host our pack?
No. A team pack is never uploaded to, stored on or served by Cotterpin. It reaches each developer through your own git, and a first run downloads nothing.
What stops someone loosening a rule on their own machine?
The lock. Every file of the pack is pinned by sha256; a file that differs is refused by name and the pack isn't served until it is re-pinned or restored. Re-pinning changes the lock, and the lock's diff goes through your review.
What happens if our subscription ends?
You keep every pack: it's in your repository. Cotterpin still checks and runs it, but without a seat it reports instead of blocking, like the rest of Cotterpin in Watch. Creating or extending packs through Cotterpin needs a licence again.
Should a rule go in the team pack or my personal pack?
Ask who it should bind. Everyone working on the repository: the team pack, committed and reviewed by your team. Just you: a personal pack, kept on your machine for that one repository and never committed. Unsure? Start personal, and once the rule has proven itself, cotterpin pack personal propose moves it into the team pack for your team's review.
Who owns what a team pack contains?
Your rules are yours. Where Cotterpin generates part of a pack for you, you keep a perpetual licence to use it inside your organisation, as our Terms of Service set out.
When can we use it?
Team packs arrive with Cotterpin 0.3.0, and Founding Developers are first in line. Organisation-wide packs, team signatures, seat moves and the Team console follow in later releases; the roadmap tracks them.
Bring your team's rules to every agent.
Team packs arrive with Cotterpin 0.3.0. Founding Developers are first in line.