Convert code-inline-reviewer rules into proactive coding guidelines for Claude

[mountiny]

Problem Statement

The code-inline-reviewer.md agent contains 18 well-defined rules for React Native best practices, but these rules are only applied after code is written (during PR review). Claude should follow these same guidelines while writing code to prevent violations from being introduced in the first place.

Current State

• Code Review Agent: Contains detailed rules with IDs, conditions, reasoning, and good/bad examples
• Coding Guidelines: The existing CLAUDE.md and cursor rules don't include these specific patterns

Rules to Convert

Performance Rules (PERF-1 through PERF-13)

• PERF-1: No spread in list item's renderItem
• PERF-2: Return early before expensive work
• PERF-3: Use OnyxListItemProvider hooks instead of useOnyx in renderItem
• PERF-5: Use shallow comparisons instead of deep comparisons
• PERF-6: Derive state from props
• PERF-7: Control component resets via key prop
• PERF-8: Handle events in event handlers
• PERF-9: Avoid useEffect chains
• PERF-10: Communicate with parent components without useEffect
• PERF-11: Optimize data selection and handling
• PERF-12: Prevent memory leaks in components and plugins
• PERF-13: Avoid iterator-independent function calls in array methods

Consistency Rules (CONSISTENCY-1 through CONSISTENCY-5)

• CONSISTENCY-1: Avoid platform-specific checks within components
• CONSISTENCY-2: Avoid magic numbers and strings
• CONSISTENCY-3: Eliminate code duplication
• CONSISTENCY-4: Eliminate unused and redundant props
• CONSISTENCY-5: Justify ESLint rule disables / Ensure proper error handling

Clean React Patterns (CLEAN-REACT-PATTERNS-1 through CLEAN-REACT-PATTERNS-3)

• CLEAN-REACT-PATTERNS-1: Favor composition over configuration
• CLEAN-REACT-PATTERNS-2: Let components own their behavior and effects
• CLEAN-REACT-PATTERNS-3: Design context-free component contracts

Proposed Solution

Create a new cursor rule file (e.g., .cursor/rules/react-native-coding-standards.mdc) or update CLAUDE.md with condensed, actionable guidelines derived from the review rules. The format should be optimized for code generation (imperative "do this" rather than "flag when").

Implementation Approach

1. Extract the "Good" patterns from each rule as the primary guidance
2. Include "Avoid" patterns as warnings
3. Condense reasoning into brief explanations
4. Organize by category (Performance, Consistency, Patterns)
5. Keep examples concise but illustrative

Acceptance Criteria

• New cursor rule or CLAUDE.md section with all 18 rule patterns
• Rules are written as proactive coding guidelines (not review criteria)
• Each guideline includes a brief example
• Guidelines are discoverable by Claude when writing React Native code

[adhorodyski]

I think we could employ skills there with success, will chat more with @kacper-mikolajczak

[adhorodyski]

@kacper-mikolajczak you might want to see if some perf and arch rules cannot be merged together in the process.

[kacper-mikolajczak]

Definitely, I will try to reduce the context bloat by compacting/merging the rules into clear guidelines!

[kacper-mikolajczak]

In general, I am positive of converting rules into guidelines that can be used during local development to tighten the feedback loop even more and save resources.

I think we could employ skills there with success

Agree, this seems to be natural approach to follow. We have already integrated Callstack's best practices to aid in development. While we are likely to start discussion on integrating other skill resource (like Vercel skills package), I'd say we in parallel start thinking about possible duplication - our rules already overlap with CK skills and chance we are going to eat our own tail will grow with time. Keeping context at reasonable size should be one of our long term goals.

We are going to pivot more and more into empowering agents and working towards our own structured set of knowledge base that could be fed into any form of agents (either be it developer or reviewer). I'd love to make that happen 🤞

[kacper-mikolajczak]

Tiny PR fixing rules naming to stick to conventions: #81568

[kacper-mikolajczak]

Here's a initial draft.

It consist of two phases, first one was translation of rules into a skill that completes requirements from the issue without touching old setup. You can review it here: 27ae744

The next step is unification the rules under skills. With this setup, rules are in an abstracted form that is going to be picked up both during dev and review, effectively de-duplicating our setup for the future.

Here is the final form: #81604

Please let me know, what you think!