/conventions

Conventions

Applicability

• Platforms: iOS and Android
• React Native: 0.76+ (New Architecture interop assumed unless a checklist item says otherwise)

When to Use

• Setting up a new React Native project or feature
• Writing new code that should match the project's structure and style
• Reviewing a change for consistency with project conventions

These conventions are intended to apply across all work rather than to one activity. See also architecture, testing, and code-review.

Severity

Findings from this skill are should-fix. They do not block a merge.

Guidance

Project Structure

Follow the folder layout the app already uses. Apply the feature-folder checks when starting a new app, or when that app already uses feature folders.

• New files match the surrounding layout
• When using feature folders: one feature per folder under src/features/{name}/, shared code only through shared/, and a barrel index.ts for the public API
• Concerns separated: screens (layout), components (reusable UI), hooks (logic), utils (pure functions)

TypeScript

• No any — use a precise type or unknown and narrow

Incorrect:

function Profile({ user }: { user: any }) {
  return <Text>{user.name}</Text>;
}

Correct:

interface ProfileProps {
  user: { name: string };
}

function Profile({ user }: ProfileProps) {
  return <Text>{user.name}</Text>;
}

• No @ts-ignore without an inline explanation of why
• Component props use a named interface, not an inline object type

Naming

• New app files use the casing already in the tree
• Components use PascalCase; hooks use useCamelCase; constants use UPPER_SNAKE_CASE

Skill folders in this repository use kebab-case. That rule is for this repo, not for the app under review.

File size

A file past roughly 300 lines, or a function past roughly 50, is a prompt to split. It is not a review finding on its own.

Hygiene

• No console.log left in committed code — use a logging utility
• No commented-out code in commits
• No TODO without a linked ticket

Commits & Reviews

• Changes kept focused — one logical change per pull request where practical
• Focused-skill checklists run before requesting review (see the code-review skill)

Pitfalls

• Conventions only help if applied consistently; one feature that ignores the structure makes the whole codebase harder to navigate.
• Treating file-size limits as hard rules rather than signals leads to awkward splits — use them as a prompt to reconsider, not a strict cutoff.