Skip to content

rn-code-architect

The architect agent produces decisive, actionable implementation blueprints for new features. It analyzes existing codebase patterns, then specifies every file to create or modify with detailed change descriptions, component designs, and a phased build sequence.

PropertyValue
ModelOpus
ColorGreen
Skillsrn-testing, rn-best-practices
ToolsGlob, Grep, LS, Read

The architect is read-only. It designs but does not implement.

  • “design the architecture for a shopping cart feature”
  • “plan how to add real-time sync to the tasks screen”
  • Phase 4 of the rn-feature-dev pipeline

Before designing, identifies:

  • Router type (Expo Router file-based vs React Navigation config-based)
  • State manager (Redux Toolkit, Zustand, React Query, MobX, plain React state)
  • Styling system (StyleSheet, NativeWind, Tamagui, styled-components)
  • Folder structure (feature-based, layer-based, or hybrid)
  • testID conventions and TypeScript usage patterns

Makes decisive choices (one approach, no alternatives) ensuring:

  • Seamless integration with existing code patterns
  • Every interactive element gets a testID
  • Store slices have readable dot-paths for cdp_store_state
  • Applies Vercel RN Best Practice rules (CRITICAL and HIGH)

Specifies every file to create or modify with detailed change descriptions.

The architect enforces these constraints from the best practices skill:

RuleConstraint
RN-1.1, 1.2 (CRITICAL)No && with falsy values. All strings inside <Text>
RN-2.x (HIGH)All scrollable data uses FlashList/LegendList. List items receive primitives
RN-3.x (HIGH)Only animate transform and opacity
RN-4.1 (HIGH)Never store scroll position in useState
RN-5.1 (HIGH)Only native navigators (native-stack, native tabs)
RN-9.x (MEDIUM)Pressable over TouchableOpacity, expo-image over Image
  1. Patterns and Conventions Found with file:line references
  2. Architecture Decision with rationale (one approach only)
  3. Component Design (file path, responsibilities, props interface, dependencies)
  4. Implementation Map (files to create/modify with change descriptions)
  5. Data Flow (user action to state change to re-render to API call)
  6. Build Sequence (store first, then API, then components, then navigation, then dev setup)
  7. Critical Details (error handling, loading states, empty states, edge cases)
  8. Verification Parameters (primaryComponent, storeQueryPath, entryRoute, navigationAction, primaryInteractionTestID)
  9. E2E Proof Flow (numbered step table with action, tool, screenshot filename, expected state)

The architect provides exact values for live verification so Phase 5.5 can execute mechanically:

primaryComponent: <main component name or testID>
storeQueryPath: <dot-path for cdp_store_state>
entryRoute: <deep link URI as fallback>
navigationAction: <cdp_evaluate expression for in-app navigation>
primaryInteractionTestID: <testID of the main interactive element>
expectedInteractionEffect: <what happens after interaction>
requiresFullReload: <true/false>

A minimum 3-step numbered table covering the happy path, at least one state transition, and at least one edge case. Every step specifies the exact testID or CDP expression, expected state, and screenshot filename.