Agentsop Conventions Pinning

Conventions Pinning — Writing a Style Guide Your Coder-Agent Will Actually Read

One line: a conventions file is the system prompt of your codebase. Treat it like a system prompt, not like a README. Anti-patterns: writing prose, narrating history, marketing the project. Patterns: command-first, verifiable, "prefer X over Y", < 200 lines.

1. 何时激活 (When to Activate)

1.1 Direct triggers

• The user (human or upstream agent) asks "how do I make Claude/Cursor/Cline/Aider respect our style?".
• The same correction has been typed in chat ≥ 2 times this week ("use httpx not requests", "add type hints", "no comments on every line"). Claude Code's docs codify this rule: "Add to it when Claude makes the same mistake a second time." [code.claude.com/docs/en/memory]
• A new project is past the "first 2 modules" phase — there are now style choices implicit in the code that an outsider (or fresh-context agent) can't see.
• The team is switching coder-tools (Aider → Claude Code, or adding Cursor) and conventions are scattered in chat history.
• An AI code review caught the same anti-pattern twice.

1.2 Reverse triggers (skip)

• One-off / throwaway scripts. The write-cost of a conventions file is fixed; the savings are proportional to session count. < 3 sessions → don't bother.
• True greenfield. The first 2-3 files of a project ARE the convention. Pinning style before the style exists locks in arbitrary choices.
• Hard enforcement needed. A conventions file is context, not a hook. Claude Code's docs are explicit: "CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." [code.claude.com/docs/en/memory] If the rule must run every time (e.g. "must make lint before commit"), write a hook / precommit / CI check.
• The rule is already in a config that the agent can read — .eslintrc, pyproject.toml, .editorconfig, tsconfig.json. Point the agent at the config; don't duplicate.

1.3 Mental check

A conventions file earns its tokens only if it contains information that is not already in the repository. The research is unambiguous on this: "Developer-written context files performed better for exactly the reason you'd guess: they contained information that wasn't already in the repository — tooling preferences, workflow requirements, conventions that existed in developers' heads but not in any documentation." [developer.upsun.com/posts/ai/agents-md-less-is-more]

If everything you would write into CONVENTIONS.md is already discoverable from package.json, pyproject.toml, .eslintrc, the test directory, and obvious code patterns — don't write the file. The agent will pre-cache it itself.

2. 核心心智模型 (Mental Model)

2.1 Convention as compile-time, code-review as runtime

+-------------------------------------+   +-------------------------------------+
|  COMPILE-TIME (conventions file)    |   |  RUNTIME (code review / lint / CI)  |
|                                     |   |                                     |
|  - Loaded once per session          |   |  - Runs on every change             |
|  - Shapes generation                |   |  - Catches violations after-the-fact|
|  - Cheap to update, free to ignore  |   |  - Costly to set up, hard to ignore |
|  - "Prefer X over Y" lives here     |   |  - "X must always hold" lives here  |
|  - Style + intent + preferences     |   |  - Invariants + safety + correctness|
+-------------------------------------+   +-------------------------------------+
        ^                                            ^
        |        Conventions guide;                  |
        |        review enforces.                    |
        |        Both are needed; they fail          |
        |        in different ways.                  |

Conventions fail by silent drift: agent ignores the rule once, no one notices, code is merged. Review fails by late catch: violation is found post-PR, expensive to fix. The two complement, not substitute.

2.2 The four load mechanics across the ecosystem

Every coder-tool has settled on one of four mechanics for getting persistent context into the agent. Knowing which mechanic your tool uses is the difference between "agent reads my rules" and "agent silently ignores them."

A project that uses multiple tools should pick one source of truth and have the other tools @-import or symlink to it. Claude Code 2.x docs explicitly recommend this: "If your repository already uses AGENTS.md for other coding agents, create a CLAUDE.md that imports it ... @AGENTS.md." [code.claude.com/docs/en/memory]

2.3 Three rules for what goes in (and what doesn't)

The litmus test: would this information be discoverable by a competent developer who spent 30 minutes browsing the repo? If yes — leave it out, the agent will discover it too. If no — pin it. [developer.upsun.com/posts/ai/agents-md-less-is-more]

2.4 Size budget: 200 lines, hard

Claude Code documentation: "Target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence." [code.claude.com/docs/en/memory]

Cursor docs: "Keep rules concise: under 500 lines. ... A 1,000-word always-apply rule is expensive, so trim aggressively or convert it to auto-attached with appropriate globs." [cursor.com/docs/rules]

Aider docs: "Above about 25k tokens of context, most models start to become distracted." [aider.chat/docs/troubleshooting/edit-errors.html] — and CONVENTIONS.md is one chunk competing for that budget against the actual code.

When the file passes ~200 lines, split it: glob-scoped rules (Cursor, Claude Code paths:), per-language file (python.md, react.md), or move detail into a skill that loads on demand.

2.5 The conflict precedence rule

You will eventually hit: CONVENTIONS.md says A, the existing code shows B. What wins?

Default precedence the major tools converge on:

managed/org policy   >  user (~/.claude/)  >  project (./)  >  local (gitignored)
                          (loaded in order; later overrides for conflicts)
existing code in repo  ⟂  conventions file   ← these don't have built-in precedence;
                                                you must declare it explicitly

The agent does not know which one you want to win unless you tell it. Two patterns:

1. Convention wins, refactor the drift. Add to CONVENTIONS.md: "If existing code conflicts with these rules, flag it as drift and propose a refactor, do not propagate the old pattern."
2. Code wins, archive the rule. If the codebase has irrevocably moved past a rule, delete the rule. Stale rules are worse than no rules — they cost tokens and create silent contradictions.

Claude Code docs warn about this directly: "If two rules contradict each other, Claude may pick one arbitrarily. Review your CLAUDE.md files ... periodically to remove outdated or conflicting instructions." [code.claude.com/docs/en/memory]

3. SOP 工作流 (Standard Operating Procedure)

Phase 0: Decide whether to write one at all

[Q1] Will this codebase be touched in ≥ 3 future sessions?
       no  -> skip; pin nothing.
       yes -> continue.

[Q2] Are there style/library choices NOT already encoded in config files
     (pyproject, eslintrc, editorconfig, tsconfig)?
       no  -> point the agent at the existing configs; skip a conventions file.
       yes -> continue.

[Q3] Is the rule something the agent should DO (guidance) or something that
     MUST hold (invariant)?
       must hold -> write a hook/precommit/CI check instead.
       guidance  -> conventions file is the right tool. Continue.

Phase 1: Write — the first cut

Start with 5–15 bullets, max. Aider's documented example is exactly this minimal: two bullets ("prefer httpx over requests" + "use types everywhere"). [aider.chat/docs/usage/conventions.html]

Structure template (copy this):

# <Project> Conventions

## Language & versions
- Python 3.12+ (no 3.11 syntax workarounds).
- Node 20 LTS, TypeScript strict mode.

## Libraries — prefer / avoid
- HTTP client: prefer `httpx` over `requests`.
- Date math: prefer `pendulum` over stdlib `datetime` for tz-aware ops.
- Avoid: `os.system` (use `subprocess.run`), `eval`, raw f-strings in logging.

## Style
- Type hints everywhere (`ANN*` ruff rules are on).
- 2-space indent (TS), 4-space (Python).
- No inline comments unless explaining "why not how".

## Layout
- API handlers: `src/api/handlers/`
- Shared types: `src/types/`
- Tests mirror source: `tests/<module>/test_<file>.py`

## Workflow
- Before commit: `make fmt && make test`.
- Conventional commits: `feat:`, `fix:`, `chore:`, `refactor:`.

## When this file disagrees with existing code
- Treat existing code as drift; propose a refactor in a separate commit.

Save it at the canonical location for the primary tool:

Phase 2: Load — make sure the agent actually reads it

This is where most projects fail silently.

Verify the load worked, every time you change tools or environments:

• Aider: /tokens shows the file in the context budget.
• Claude Code: /memory lists it.
• Cursor: hover the rule in the sidebar — it shows which conversation it's active in.
• Cline: the rules panel in the Cline sidebar shows the loaded set.

If the file isn't shown — the agent isn't reading it. Don't proceed.

Phase 3: Enforce — close the loop with a test

Pin one specific, verifiable rule (e.g. "use httpx not requests"). Then ask the agent to write a new HTTP call from scratch. If it uses requests, the load failed or the rule is too vague. Fix and retest.

This is the same test Aider documents: their example explicitly shows httpx + type hints get used with CONVENTIONS.md and requests + no types get used without. [aider.chat/docs/usage/conventions.html] If you cannot produce that A/B in your own setup, the load is broken.

Phase 4: Evolve — when to add a rule, when to delete one

Add a rule when (codified from Claude Code docs): [code.claude.com/docs/en/memory]

1. Agent makes the same mistake twice in a session, or twice across sessions.
2. A code reviewer catches something the agent should have known about this codebase.
3. A new teammate would need the same context to be productive.
4. You re-explain the same correction in chat a third time.

Delete a rule when:

1. The codebase has moved past it — the rule says "use X" but every new file uses Y and the team agrees.
2. Lint/CI now enforces it (move from convention to enforcement).
3. The rule is too vague to verify and has produced no measurable behavior change ("be careful with concurrency").
4. The file is over ~200 lines and this rule has the lowest hit rate.

Split a rule when it only applies to part of the codebase: use glob-scoped rules. Claude Code .claude/rules/api.md with paths: ["src/api/**/*.ts"]. Cursor: per-.mdc globs: field. This shrinks the always-on context budget. [code.claude.com/docs/en/memory], [cursor.com/docs/rules]

Phase 5: Review — periodic audit (monthly or per major refactor)

1. Run `/memory` (or equivalent) — list what's loaded.
2. For each rule:
     - Has it been triggered? (grep recent PRs / chat for the keyword)
     - Does the codebase still follow it? (grep code for violations)
     - If both no → delete.
     - If first no, second yes → the rule is enforced by gravity; consider deleting.
     - If first yes, second no → drift; either fix code or kill rule.
3. Check size: > 200 lines → split into glob-scoped rules.
4. Check for contradictions across files (project + user + ancestor).

4. 操作模型 (Operation Model)

Eight reusable operations. Each is Trigger / Action / Output / Evidence. Detailed JSON form in intermediate/operation_candidates.json.

5. 困境决策案例 (Dilemma Cases)

Case 1 — "I added --read CONVENTIONS.md but the agent still uses requests instead of httpx"

Symptom: rule is loaded (Aider /tokens shows it; Claude Code /memory lists it), but generation ignores it.

Differential diagnosis (cheapest first):

1. Token budget exceeded. Aider: "Above about 25k tokens of context, most models start to become distracted." [aider.chat/docs/troubleshooting/edit-errors.html] Drop irrelevant files; /tokens to confirm.
2. Conflicting nearby example. The agent is reading existing code in the same session that uses requests. Code-in-context is a stronger demonstration than a one-line rule. "If two rules contradict each other, Claude may pick one arbitrarily." [code.claude.com/docs/en/memory] Fix: add the conflict-resolution clause to CONVENTIONS.md ("if existing code uses requests, treat as drift and propose refactor"), or /drop the conflicting files.
3. Rule is too vague. "Prefer modern HTTP libs" is ignorable; "Use httpx.Client with timeout=10.0; do not import requests" is not.
4. Multiple conventions files contradict. User-level (~/.claude/CLAUDE.md) says one thing, project says another. Claude Code loads them in a defined order (managed → user → project → local) [code.claude.com/docs/en/memory] — but if both have the same rule wording with different answers, the merge is ambiguous. Verify with /memory.
5. Stale cache. Aider caches the read file across the session; restart if you edited it.

Resolution rule: if cases 1–4 don't resolve it, the rule belongs in enforcement (lint, precommit), not guidance. Add a ruff rule to pyproject.toml that bans import requests. The conventions file is not a hammer.

Case 2 — "Style drift across files: half use httpx, half use requests. Fix in conventions or in code?"

Trigger: codebase has visible inconsistency. Agent will mirror whichever file it reads first.

Decision rule:

The anti-pattern to avoid: writing "agents should use httpx going forward" without doing the migration. The agent will see 50% requests in the existing code, ignore your rule, and the drift continues. Conventions describe the codebase you have, not the one you wish you had. If the rule contradicts > ~30% of the existing code, fix the code first, pin the rule second.

Case 3 — "I'm using Claude Code AND Cursor on the same repo. Two conventions files? Or one?"

Decision: one. Two files = two truths = silent disagreement.

Implementation (Claude Code 2.x's recommended pattern): [code.claude.com/docs/en/memory]

repo/
├── AGENTS.md                  # canonical, ~80 lines
├── CLAUDE.md                  # one line: "@AGENTS.md"
├── .cursor/rules/main.mdc     # frontmatter alwaysApply: true; body: contents copied or symlinked
└── .clinerules/main.md        # symlink → ../AGENTS.md (Cline reads .md transparently)

For Cursor (.mdc files require frontmatter, can't symlink raw), either:

• Generate the .mdc from AGENTS.md in a pre-commit hook, OR
• Keep the rule body short enough that copying it across 3 tools is tolerable.

Surprising finding from the research: Claude Code's /init reads existing .cursorrules and .windsurfrules and incorporates them into the generated CLAUDE.md. [code.claude.com/docs/en/memory] So if you already have a .cursorrules, Claude Code will not silently ignore it on first init — it pulls it in.