Most teams have a CONTRIBUTING.md or a .cursorrules file. Most teams also have a codebase that quietly stopped respecting it around six months after it was written.

The failure mode is predictable: someone writes the canonical patterns in week one, the team evolves, the document doesn't follow. AI coding assistants trained on those static rule files keep generating code in the style of the team as it was, not as it is. You end up with an AI confidently enforcing conventions the team abandoned two sprints ago while the engineers who merged the last hundred PRs shrug at its suggestions.

Codehabits takes a structurally different approach: skip the documentation layer entirely and mine what the team actually ratified — merged pull requests on GitHub. Their recently shipped MCP server integration for Cursor exposes six tools derived directly from PR history, bringing that evidence-backed convention model into the editor as explicit, on-demand AI capabilities. The install path is five minutes. The implications take longer to think through.

The Convention File Graveyard

Every medium-sized engineering team eventually accumulates the same artifacts: a CONTRIBUTING.md explaining PR structure, an .eslintrc that covers syntax but not semantics, maybe a .cursorrules or AGENTS.md added after someone read a blog post about AI pair programming.

These files share a common lifecycle. Accurate on day one. Drifting within a quarter. Actively misleading by month six — encoding patterns from a team that no longer exists, reflecting architectural decisions that have since been reversed. Nobody's sprint ticket says "update .cursorrules to reflect the auth refactor we merged in March."

Cursor's native .cursor/rules/ directory gives you full explicit control over what the AI sees. For solo developers or small stable teams, it's the right tool: zero external dependencies, works offline, you own every word. But for a team of eight to fifteen people working across an active PR workflow, keeping those files current becomes a project in itself. The discipline required to maintain accuracy scales inversely with how busy the team is — which is exactly when you most need the AI to be right.

GitHub Copilot Enterprise offers org-level custom instructions and fine-tuning, but it's priced for large organizations and doesn't have the real-time PR-mining angle. The gap Codehabits is targeting is specific: mid-size teams with active review workflows who want convention enforcement without maintaining a separate knowledge base.

How the Codehabits MCP Server Works

Installation

The integration requires Node.js 20 or higher. Two commands get you running:

npx @codehabits/cli enable
npx @codehabits/cli mcp-install

The first command generates a .codehabits/ directory in your project root — this is where the team intelligence lives, including a meta.json file and extracted convention data sourced from GitHub PR history. The second command writes the MCP server configuration to .cursor/mcp.json, registering Codehabits as a named server inside Cursor's MCP support layer.

For team-wide rollout, .cursor/mcp.json should be committed to the repository so every developer opening the project in Cursor gets the same server configuration automatically. That commit decision carries its own policy implications, which we'll return to.

The Six Tools

Once registered, the MCP server exposes six tools as explicit callable capabilities inside Cursor's agent:

get_team_context pulls current team conventions for a given area of the codebase, derived from PR history patterns.

check_code validates a snippet or diff against extracted conventions, returning conformance feedback mid-task.

get_knowledge retrieves domain-specific knowledge from historical PRs — useful for areas of the codebase with established but undocumented patterns.

suggest_reviewers routes review suggestions based on historical PR authorship and ownership.

record_feedback feeds explicit human feedback back into the convention model, closing the learning loop.

approve_proposal allows ratification of a proposed convention or approach, which gets recorded for future extractions.

Explicit Tools vs. Passive Context

The architecture here is a deliberate design choice worth examining. These are on-demand tools, not passive context — they fire only when explicitly called. Contrast that with Cursor's Agent Skills (.cursor/rules/ files), which inject context into every prompt at task start whether the current task needs it or not. Passive injection bloats every request with potentially irrelevant tokens; explicit tool calls keep token spend proportional to actual need.

The two mechanisms aren't mutually exclusive. Agent Skills work well for always-relevant project boilerplate: repository structure, tech stack, build commands. MCP tools handle mid-task validation and targeted knowledge retrieval. Used together, they provide layered context delivery — broad strokes at task start, precise lookups on demand.

Where Conventions Come From

The distinguishing claim is that conventions are extracted automatically from merged PR history with no hand-maintained rule files. The .codehabits/ directory stores the extraction output and updates as your PR history grows.

This sidesteps the documentation rot problem because the signal is decisions the team already made and ratified through the review and merge process. A pattern appearing consistently across forty merged PRs is stronger evidence than a pattern written into CONTRIBUTING.md once and never revisited. The extractor doesn't ask you to annotate anything — it reads from what already exists.

The Consequence Nobody Is Talking About

The framing of this tool as an "AI improvement" is accurate but incomplete. The more consequential effect may be what it does to human behavior upstream.

Once engineers understand that PR merge decisions feed back into the convention model, review becomes higher-stakes in a specific way: approving inconsistent code isn't just accepting tech debt, it's encoding that inconsistency into the system the whole team's AI tools will learn from. Reviewers have a concrete incentive to be explicit and consistent in what they ratify. The real ROI, measured over twelve months on an active codebase, may show up less in AI output quality and more in tighter, more intentional review culture.

This is not a marginal observation. Review culture is notoriously resistant to improvement through policy or tooling alone. Most attempts address the symptom — inconsistency in merged code — rather than the incentive structure: reviewers currently have no feedback mechanism for the downstream consequences of their approval decisions. A system that makes those consequences visible, even indirectly through AI behavior, changes that loop.

The flip side is that this only holds if your review culture starts from a reasonable baseline. The system has no way to distinguish a high-signal merge from a rubber-stamp approval. A team that habitually approves WIP commits or tolerates inconsistent style will train the extractor on noise, and the tools will reflect that noise back with misplaced confidence. In that sense, deploying Codehabits is also a diagnostic. If the convention suggestions look incoherent, that's information about your PR workflow, not just about the tool.

What Teams Should Actually Do

Pin the CLI Version

Running npx @codehabits/cli mcp-install without pinning resolves the latest published version of the package on every invocation. A breaking change or behavior drift ships to your entire team the next time anyone restarts Cursor, with no review step in your own CI pipeline. For individual experimentation this is an acceptable tradeoff. For teams where AI convention suggestions have become part of code review, pin the CLI version and treat upgrades as a deliberate team decision.

Establish a Token Policy Before Committing mcp.json

Committing .cursor/mcp.json to the repository is necessary for team consistency, but the server requires repo read access to analyze PR history. Before committing: decide whether individual developers authenticate with their own GitHub tokens or whether a shared service account handles PR analysis. The token scope required has implications for what else that credential can access, and a personal token getting rotated will silently break the integration for everyone until someone investigates. Neither approach is wrong, but the choice should be explicit.

Audit Historical Authorship Before Enabling Reviewer Routing

The suggest_reviewers tool routes based on historical PR authorship. The engineer who owned the authentication module eighteen months ago will get suggested on every auth-adjacent PR, even after moving to the infrastructure team. This creates noise for them and false confidence for authors who believe the right person is reviewing. Before enabling reviewer routing in production, audit whether historical ownership reflects your current team structure — and establish a process for correcting it as people change roles.

Expect a Cold-Start Period

Any project under roughly six months old, or with fewer than around fifty merged PRs, will produce low-confidence conventions. The extractor is working from too thin a sample to identify consistent patterns, but the tools will still respond — the output quality is lower, and that degradation isn't surfaced explicitly. If you're adopting Codehabits on a young codebase, instrument the confidence signals yourself rather than expecting graceful degradation.

The recency problem is more subtle but worth planning for. PR history carries no metadata that distinguishes organizational intent across time. Conventions from three years ago when the team had four engineers look identical to conventions from last quarter when the team restructured. A pattern the team quietly abandoned eighteen months ago may still appear in enough historical PRs to register as live. There's no built-in recency weighting — that awareness has to come from the humans reviewing what the tool surfaces.

Use It Alongside, Not Instead Of, Explicit Rules

For conventions that are genuinely stable and team-critical — error handling patterns, security requirements, public API surface rules — maintain explicit .cursor/rules/ files alongside the MCP integration. The MCP tools handle the conventions that emerge organically from PR history and would otherwise rot in a static document. Explicit rules handle the invariants you can't afford to leave to statistical inference.

Takeaway

Codehabits' MCP integration is solving a real problem with a structurally sound approach. Mining merged PRs as the convention source rather than maintaining separate rule files is the right architecture for teams with active review workflows. It eliminates the documentation rot problem by grounding the convention model in decisions that were already made and ratified.

The production risks are real and manageable: pin the CLI version, establish a GitHub token policy before committing the MCP config, don't expect graceful degradation on young or low-volume codebases, and audit historical PR authorship before trusting reviewer routing.

The deeper point is worth sitting with: if you evaluate this tool purely on whether it improves AI code generation quality, you're measuring the wrong variable. The more significant effect is what it does to the review culture the convention model learns from. That's a slower, harder-to-quantify improvement — and the most durable one available here.

Sources & Editorial Disclosure

This article was researched and written with AI assistance (Claude by Anthropic) as part of StackRadar's automated editorial pipeline. Content was synthesised from the following public developer community sources: Dev.to.

All technical claims, version numbers, benchmarks, and project details should be independently verified against official documentation or the original sources listed above. StackRadar analyses and synthesises publicly available information and does not claim original authorship of the underlying events, projects, or research described. Mention of any project, product, or organisation does not constitute an endorsement by StackRadar. This content is provided for informational purposes only — 2026-06-18.