Paperclip Agent Rules

An application for coordinating AI agents, tasks, approvals, and company operations.

Overview

Paperclip starts with an ordered reading list, then states the rules its agent control plane must preserve. It defines company boundaries, shared contracts, data destinations, and review expectations, with separate steps for database changes and browser checks.

Documents

├── 
├── .github
│   └── 
├── doc
│   ├── connections
│   │   └── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   └── 
├── packages
│   ├── plugins
│   │   └── plugin-llm-wiki
│   │       ├── agents
│   │       │   └── wiki-maintainer
│   │       │       └── 
│   │       └── templates
│   │           └── 
│   ├── shared
│   │   └── src
│   │       └── telemetry
│   │           └── 
│   └── teams-catalog
│       └── catalog
│           ├── bundled
│           │   ├── company-defaults
│           │   │   └── core-exec-team
│           │   │       └── agents
│           │   │           ├── ceo
│           │   │           │   └── 
│           │   │           ├── cto
│           │   │           │   └── 
│           │   │           └── qa
│           │   │               └── 
│           │   ├── product
│           │   │   └── product-design
│           │   │       └── agents
│           │   │           └── ux-designer
│           │   │               └── 
│           │   └── software-development
│           │       └── product-engineering
│           │           └── agents
│           │               ├── cto
│           │               │   └── 
│           │               ├── qa
│           │               │   └── 
│           │               └── senior-coder
│           │                   └── 
│           └── optional
│               └── content
│                   └── content-machine
│                       └── agents
│                           └── content-lead
│                               └── 
├── server
│   └── src
│       ├── built-ins
│       │   └── agents
│       │       ├── reflection-coach
│       │       │   └── 
│       │       └── summarizer
│       │           └── 
│       └── onboarding-assets
│           ├── ceo
│           │   └── 
│           ├── default
│           │   └── 
│           └── first-task
│               └── chief-of-staff
│                   └── 
├── 
└── 

Techniques in this file

01 / Router files

Separate the implementation contract from long-term context

The reading list distinguishes the current V1 build contract from the longer-horizon product specification. Naming each role tells contributors which document should decide the scope of an implementation.

Source excerpt starting at line 20.
`doc/SPEC.md` is long-horizon product context.`doc/SPEC-implementation.md` is the concrete V1 build contract.

02

State invariants across layers

The root guide lists cross-layer control-plane invariants, including atomic checkout, approval gates, budget stops, and mutation logging. These constraints apply across schemas, APIs, and interfaces.

Source excerpt starting at line 89.
3. Preserve control-plane invariants.- Single-assignee task model- Atomic issue checkout semantics- Approval gates for governed actions- Budget hard-stop auto-pause behavior- Activity logging for mutating actions

03 / House vocabulary

Classify data paths before assigning review

First-party telemetry, operator tracing, and local run events map to different source paths and review rules. Classify them by path, not by words in a filename.

Source excerpt starting at line 105.
7. Name the three data paths correctly.This repo has three separate data paths. Do not confuse them. Match a change to a path by its file path, not by the word "observability" or "telemetry" alone.

04

Match review to where data goes

Default outbound telemetry requires contract and docs updates plus privacy review. Opt-in tracing and local run logs have separate rules, so one policy does not govern all three.

Source excerpt starting at line 125.
- **Telemetry change (strict review).** The author updates the generated contract first. The author updates `packages/shared/src/telemetry/README.md` in the same pull request. The author requests a privacy review. Reason: a Telemetry event goes to a Paperclip endpoint by default, so a mistake sends data immediately.

05 / Verification by change type

Name what the default test command excludes

The file says the cheap default runs Vitest and keeps browser suites opt-in. It reserves the fuller check for a PR-ready hand-off or changes whose scope needs it.

Source excerpt starting at line 161.
This is the cheap default and only runs the Vitest suite. Browser suites stay opt-in: ```shpnpm test:e2epnpm test:release-smoke``` Run the browser suites only when your change touches them or when you are explicitly verifying CI/release flows.

06 / Pointing at the source of truth

Enforce UI tokens with a named check

The design-system section points to the token layer, spells out the disallowed literal values, and names the command that catches violations. Its allowlist lives with the implementation rather than in an agent's judgment.

Source excerpt starting at line 225.
`DESIGN.md` at the repo root is the source of truth for UI design decisions. The token-only rule applies to all `ui/` changes: every color, spacing, radius, type, shadow, and motion value in `ui/src/components/**` and `ui/src/pages/**` comes from the token layer in `ui/src/index.css` — no hex, raw px, arbitrary Tailwind bracket values, or raw `font-size`/`fontSize` declarations in components, outside the documented allowlist in `ui/src/index.css`. Run `pnpm check:token-gates` (`scripts/check-token-gates.mjs`) before committing UI changes — it fails on any violation not covered by that allowlist.

Ideas for your repo

  1. Distinguish current implementation scope from long-term product context.
  2. Write down the invariants that must hold across schema, API, and UI changes.
  3. Use concrete code paths and data destinations to select the right review.
  4. State which suites a default test command does not run.
  5. Pair design rules with an executable check and a defined exception list.
Sponsored byModem

Give your agents the whole story.

These instructions explain how to work in Paperclip. Modem shows your agents what customers said, who is affected, and what changed.

See how Modem works