跪拜 Guibai
← All articles
Frontend

How to Wire Company-Wide Coding Standards into Cursor Agent Skills

By 繁华若梦759 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Cursor and similar coding agents default to generic patterns that ignore a team's API wrappers, permission directives, and interaction conventions. This architecture makes those conventions machine-readable and scoped to load only when relevant, so the agent behaves like a colleague who already knows the repo's rules rather than a stranger who needs re-briefing every session.

Summary

A two-layer architecture pairs a project constitution (AGENTS.md) with on-demand Agent Skills so Cursor follows team-specific rules for API layers, loading states, and form behavior without bloating every prompt. The constitution locks in tech stack, directory responsibilities, and modification boundaries that apply to every conversation. Skills are loaded only when triggered by natural-language phrases like "self-test" or "pre-test check," keeping context lean.

A concrete frontend-self-test Skill walks through git diff output against a 14-category interaction standard, producing Pass / Risk / Needs Manual Verification judgments with file:line references. The Skill's process is kept short in SKILL.md, while the detailed must-do/prohibited rules live in a separate reference.md — a progressive-disclosure pattern that prevents context explosion.

Company-wide standards are shared via git submodule and synced into .cursor/skills so behavior is reproducible across machines, teammates, and cloud agents. The approach replaces a single bloated rules file with a constitution plus a directory of narrowly scoped, judgeable skills that translate generic standards into project-specific implementations like Element Plus loading directives and unified request wrappers.

Takeaways
AGENTS.md should contain only constraints that always hold true — tech stack, directory layout, package manager, modification boundaries — not lengthy interaction standards.
Agent Skills use progressive disclosure: SKILL.md holds the short process and description, while detailed rules live in reference.md and are read only when the skill executes.
Trigger words must be natural phrases the team actually uses ("self-test," "pre-test check"), not internal codenames, because the agent matches against conversational intent.
Company-level standards belong in a shared repo pulled via git submodule and synced into .cursor/skills; personal ~/.cursor/skills/ won't work for teammates or cloud agents.
The self-test Skill locks agent behavior: only judge changed files, follow explicit judgment criteria, don't invent new loading patterns, and don't modify code unless asked.
Judgment criteria are written as Pass / Risk / Needs Manual Verification, with risks required to include file:line references and sorted by severity (data corruption before copy nitpicks).
Project adaptation means translating generic rules into existing implementations — for example, "button must enter loading state" maps to the repo's existing LoadingDialog + :loading + finally pattern.
A sync script (skills:sync:cursor) is essential; forgetting to pull the submodule after clone causes the agent to silently ignore registered skills.
Conclusions

The biggest failure mode isn't a bad prompt — it's context dilution. When interaction standards are always loaded, the agent loses precision on the actual code change. Splitting constitution from on-demand skills solves this by keeping the system prompt lean.

Making an agent follow team conventions is fundamentally a scoping problem, not a prompting problem. The article's five-step lock-down (only diffed files, only explicit criteria, don't invent patterns, don't modify unprompted, fixed output template) is more valuable than the checklist itself.

The submodule-to-.cursor/skills sync pipeline reveals a gap in current agent tooling: discovery paths aren't portable across machines. Until agents natively read from version-controlled paths, a sync script is the practical bridge to team-wide reproducibility.

Writing judgment criteria as test-case-like predicates ("list has been re-requested" rather than "experience feels smooth") is what makes an agent's output stable enough for a QA handoff. Vague standards produce vague reports that nobody trusts.

Concepts & terms
Progressive Disclosure
A design pattern where an agent first sees only a skill's name and short description; the full process and detailed reference files are read only when the skill is triggered. Keeps the main context small while making deep detail available on demand.
Project Constitution (AGENTS.md)
A repository-level file that declares always-applicable constraints: tech stack, directory responsibilities, package manager, modification boundaries, and verification rules. It answers "which project am I in?" for the agent in every conversation.
Agent Skill
A version-controlled directory (SKILL.md + optional reference.md and scripts) that Cursor loads on demand when trigger phrases match the conversation. Encodes a reusable process like self-testing or release checks rather than static project facts.
Judgment Criteria (判定口径)
Explicit, test-case-like predicates embedded in interaction standards that tell an agent exactly how to decide Pass vs. Risk. For example, "addition success is judged by 'list has been re-requested,' not by whether the new row appears on the current page."
Source: juejin.cn ↗ Google Translate ↗ Backup ↗