U-AMOS: The Claude Code Skill That Made React Native AI Development Actually Work

U-AMOS is the Universal AI Memory Operating System I built after 6 months of losing fights with Claude Code on React Native projects. The short version: prompts plateau, durable context compounds. The longer version is the 8-step workflow, how it packages as a Claude Code skill, what the memory bank looks like across 9 tiered files, and the honest list of things it still does not solve. Numbers from my own logs: hallucinations 42% to 3%, tokens per session 48,000 to 4,200, debugging time 4 hours/week to 20 minutes/week. Not a controlled experiment. The trend is the point.

The problem U-AMOS solves

You start a new Claude Code session. You explain your project. The model produces decent code for 3-4 prompts. By prompt 7, it has invented a component that does not exist, imported from a path you never used, and called an API that lives only in its training data.

You start the next session. You explain the project again. Same drift, different details.

In my logs across 6 months of paid use, ~42% of Claude-generated diffs in early sessions contained at least one of: hallucinated import, fake API call, duplicate component, wrong package. The instinct is “write a longer system prompt.” That works for the next 3 prompts and then fails the same way. Prompts are stateless. The model has no memory between sessions.

U-AMOS is the patch. Memory bank tiered by access frequency. Context map for the codebase. Rule priority system. Plan/act mode. A 7-point checklist that runs before any code is generated. Packaged as a Claude Code skill so it installs in one command and activates automatically when relevant.

Step 1: Tier the memory bank into hot / warm / cold

Three folders, three access frequencies.

• Hot (memory/hot/): always loaded. Project name, tech stack, conventions, current sprint goal. ~300-500 lines total. Re-read every session.
• Warm (memory/warm/): loaded when the topic is relevant. Architecture decisions, feature index, design system tokens, API contracts. ~1500-3000 lines. Loaded by keyword match.
• Cold (memory/cold/): loaded on explicit request only. Postmortems, deprecated approaches, alternative designs considered but rejected. Unbounded.

The split matters because Claude has a context window, not an infinite one. Stuffing everything into the system prompt burns context on irrelevant memory. The tiered structure lets the model pull only what is needed.

Step 2: Build the context map

A single file (memory/hot/context-map.md) that indexes the codebase. Not the code itself. The structure.

# Context Map

## Features (feature-first folders under src/features/)
- auth: Supabase, Apple/Google. Owner: real wiring in auth/api/use-auth.ts.
- onboarding: 4 A/B variants in AI Pro. Gate flag in app slice.
- todos: full CRUD. RTK Query. Owner: todos/api/todos.api.ts.

## Cross-cutting layers
- Store: Redux Toolkit, slices in src/features/*/store/*.slice.ts
- Data: RTK Query, base in src/api/base-query.ts
- Theme: Restyle tokens in src/ui/theme/
- Persistence: MMKV encrypted, key in src/storage/mmkv.ts

The context map is the part most “AI dev workflow” posts get wrong. They focus on prompts. The map is what makes the prompts cheap. Claude reads the map once, then knows where to look. Tokens drop because the model stops scanning the whole repo.

Step 3: Encode rule priority

Not all rules carry the same weight. The priority order:

• Safety rules (do not delete files without confirmation, do not commit secrets)
• Architecture rules (feature-first folders, RTK Query for data, Restyle for theme)
• Style rules (function vs arrow, named exports, file naming)
• Personal preferences (verbose vs terse, comments allowed or not)

When rules conflict, higher-priority wins. The rules.md file in the skill encodes this explicitly. The model is told “if a style rule contradicts an architecture rule, follow the architecture rule.” This sounds obvious. Without it, you get well-styled hallucinations.

Step 4: Plan/Act mode

Before generating code, the model first produces a plan. Numbered. Each step gated.

PLAN MODE
1. Read src/features/onboarding/onboarding.types.ts
2. Read src/features/onboarding/screens/index.ts
3. Add new screen step-five.tsx under src/features/onboarding/screens/
4. Update navigator config in src/navigation/onboarding-navigator.tsx
5. Add types to onboarding.types.ts

Approve plan? (y / edit / n)

You approve. The model switches to act mode. Each step is executed and verified. If a step fails (file not found, import error), it pauses and asks.

This single pattern cut my “AI shipped broken code” rate by about 60% in my logs. The plan surfaces wrong assumptions before they become commits.

Step 5: Run the 7-point anti-hallucination checklist

Before any file write, the model runs through:

• Do the imports actually exist in package.json?
• Are the imported paths actually files in the repo?
• Does the API I am calling match the signature in the relevant *.types.ts?
• Am I duplicating an existing component or util?
• Does the file location match the feature-first convention?
• Are the Restyle tokens I am using defined in the theme?
• Are there existing tests that this change will break?

If any check fails, the model surfaces the failure instead of writing the code. The checklist runs as a Claude Code tool call. Fast. Reliable.

Step 6: Capture decisions to warm memory

After a non-trivial change, the model writes a note to memory/warm/decisions/. One file per decision. Title, context, options considered, choice, reason.

The decisions log is what makes the next session faster. The model can read why something was done, not just what was done.

Step 7: Periodic memory garbage collection

Once a week, run a maintenance command (/u-amos:gc). The skill scans the warm and cold tiers, flags stale entries, merges duplicates, archives obsolete decisions. Without GC, the memory bank grows until it stops being useful.

This is the step most teams skip and then wonder why U-AMOS stops working. The memory has to stay clean. Treat it like the codebase.

Step 8: Package as a Claude Code skill

The whole system installs via ~/.claude/skills/u-amos/. The skill manifest declares activation triggers (file patterns, project name patterns, keyword triggers). When you open a project that has the U-AMOS markers in place, the skill activates automatically. No manual setup per session.

# ~/.claude/skills/u-amos/manifest.yaml
name: u-amos
description: Universal AI Memory Operating System for React Native projects
triggers:
  - file_pattern: "memory/hot/context-map.md"
  - file_pattern: "CLAUDE.md"
    contains: "U-AMOS"
commands:
  - /u-amos:plan
  - /u-amos:act
  - /u-amos:check
  - /u-amos:gc
  - /u-amos:decide

That is the part that turns a workflow into a reusable tool. Without packaging, U-AMOS is “a folder of files I copy between projects.” With packaging, it is a skill that activates when relevant and does not when not.

What changes on day 1 of a new RN project

Concrete differences in the first 60 minutes of starting a new project with U-AMOS pre-wired:

• The CLAUDE.md already exists. The context map already points to feature folders.
• The first prompt does not need to explain the architecture. The model has it.
• The first code generation runs through plan/act. No surprise diffs.
• The 7-point checklist catches the first hallucination before it hits disk.
• Token usage on the first session drops from ~12K to ~3K in my own measurements.

The pattern compounds. Session 2 is faster because the decisions log carries forward. Session 7 is dramatically faster because the warm tier has accumulated the actual patterns of this specific project.

The honest limitations

What U-AMOS does not solve.

• It does not make Claude smarter on bad inputs. If your codebase is structurally bad, U-AMOS surfaces that bad structure faster but does not fix it.
• The 42% to 3% number is mine. Your numbers will be different depending on codebase, prompts, and model version. The shape of the improvement is consistent across the dozen devs who have tried it. The magnitude varies.
• Memory bank maintenance is real work. Plan on 15-20 minutes per week of GC. If you skip it, the warm tier becomes noise and the gains evaporate.
• It assumes you use Claude Code. Cursor and Copilot have analogous patterns but U-AMOS is built for Claude Code's skill + memory + sub-agent model. Portability work is on the backlog, not shipped.
• It is opinionated about RN. The default context map and rules assume feature-first folders, Redux Toolkit, RTK Query, Restyle. If your stack is different, you rewrite the templates.

Where to start

The U-AMOS skeleton ships pre-wired in AI Mobile Launcher Standard ($99) and AI Pro ($199). Open the repo, the memory bank is already structured, the skill is installed, the rules are written. Day 1 productivity, not day 10.

Wire RN is the other half of this story. When you build an AI-native React Native app, you need the dev workflow (U-AMOS) and the runtime UI primitives for AI-driven interfaces (Wire RN). Both ship in AI Mobile Launcher AI Pro. Wire RN is also OSS at getwireai.com. One issue per week on AI-native mobile development at codemeetai.substack.com.

FAQ

What is U-AMOS in one sentence?

U-AMOS (Universal AI Memory Operating System) is an 8-step workflow that gives Claude Code persistent memory and structural context across sessions on a React Native project, packaged as an installable Claude Code skill.

Why is U-AMOS better than just a long CLAUDE.md?

A long CLAUDE.md burns context window before any work starts. U-AMOS tiers memory by access frequency (hot / warm / cold), so the model loads only what is relevant per task. The result is more useful context per token spent and dramatically less “explaining the project from scratch” overhead.

Can I use U-AMOS with Cursor or GitHub Copilot?

Not directly. U-AMOS is built around Claude Code's skill, memory, and sub-agent primitives. Cursor has its own rules system and Copilot has Workspace. The 8-step structure is portable as a workflow; the packaging is Claude-specific.

How does U-AMOS relate to claude code react native workflows?

U-AMOS is the specific Claude Code workflow I run on every RN project. It encodes the patterns (tiered memory, context map, plan/act mode, anti-hallucination checks) that I found through 6 months of trial and measurement. It is one example of what a serious Claude Code skill for React Native looks like.

Where does U-AMOS fit in the AI Mobile Launcher product line?

U-AMOS ships pre-wired in every paid tier of AI Mobile Launcher. Standard ($99) includes the full skeleton, the SDD sub-agents, and the rule set. AI Pro ($199) adds the AI-feature-specific rules (local LLM, cloud LLM routing, streaming). Lite (free OSS on GitHub) has the structure but limited feature wiring.

Related reading

• Claude Code for React Native: complete setup
• Avoid AI code slop in React Native
• What is an AI-native codebase?