Callstack React Native Agent Skills Review: 12 Skills, Accurate Routing, and Zero Checklist Gain

Test snapshot: 2026-08-09

Project: callstackincubator/agent-skills

Repository snapshot: 1,589 stars, 115 forks, last pushed 2026-08-08

License: MIT ｜ Scale: 12 SKILL.md files

Evidence boundary: 60% of the conclusions below come from L0 static audit, L1 routing tests, and L2 output comparisons. This round did not install dependencies, build the fixture, start Metro, connect a device, or run screenshot regression.

The short answer

Callstack’s React Native Skills are the most restrained of the four mobile-development collections we compared. The 12 SKILL.md files total 17,284 tokens, the median is 1,224, and none exceeds 5,000 tokens. Routing is equally disciplined: all 13 in-scope React Native prompts selected the right route, while seven out-of-scope prompts produced zero false triggers.

The answer is less exciting if the question is “will it make a model fix a React Native performance fixture better?” In the 500-item list A/B test, the bare model and the Skill-injected model both scored 12/12. All three bare-model runs independently found the most subtle issue: a Row component declared inside its parent function. The collection therefore scores 3.7/5 overall: excellent writing and routing, but no measurable checklist gain on a well-known performance problem.

Its useful delta is elsewhere:

1. Process discipline. Every B run explicitly said it could not complete Measure → Optimize → Re-measure → Validate without a device and the profiling tools. The bare model never made that limitation explicit.
2. One narrow technical difference. All three B runs converted the search input to an uncontrolled input, avoiding the JS↔native round trip of a controlled TextInput. The A group did this zero times.

Use it as a second pair of eyes for RN performance, navigation, migrations, and native integration. Do not use it as an automatic acceptance gate, and do not skip real-device verification because the maintainers include React Native core contributors.

Scorecard

What is in the repository?

The 12 entries form three layers: eight first-party skills, three vendored skills, and one internal validator.

First-party skills

• react-native-best-practices: performance, the JS thread, Hermes, FlashList, memory leaks, animation, and native modules.
• react-navigation: React Navigation configuration and common routing problems.
• upgrading-react-native: React Native upgrades.
• create-react-native-library: creating native React Native libraries.
• react-native-brownfield-migration: introducing RN into an existing native application.
• assess-react-native-migration: migration feasibility and risk assessment.
• react-native-tv-best-practices: RN on TV platforms.
• github-actions: GitHub Actions automation for RN projects.

Vendored skills

agent-device, dogfood, and react-native-testing are synchronized from external sources. They cover device operations, an internal dogfooding workflow, and React Native Testing Library-oriented work.

Internal tooling

validate-skills is a repository-maintenance command, not an everyday application-development skill. Counting it reflects the repository as shipped, but it should not be treated as product coverage.

The difference from Expo’s official collection is important: Expo owns the framework and EAS services; Callstack is a third-party engineering organization with deep RN expertise. Its value is therefore performance and engineering practice, not first-party product configuration.

How we tested it

We used three evidence layers rather than treating GitHub stars as a quality claim.

L0: Full static audit

All 12 SKILL.md files were checked for core fields, relative links, body size, attached references, and provenance metadata. The result was 12/12 complete core fields, zero broken links, and zero SKILL.md files above 5,000 tokens.

L1: Description-only routing

The model saw only the name + description for the 12 skills. It could not read their bodies. We used 13 in-scope RN prompts plus seven out-of-scope prompts covering Flutter, PRDs, backend APIs, push notifications, review rejection, dark mode, and database selection.

L2: An RN performance A/B fixture

The fixture is a 500-product React Native list with ten planted performance defects. The user reports only three symptoms: dropped frames while scrolling, a full-page freeze on every search keystroke, and a background task that appears to survive navigation away. Group A used the bare model; Group B received react-native-best-practices. Each ran three times and was scored against a 12-item checklist.

What L3 did not prove

This round did not run npm install, a real build, Metro, a simulator, a physical device, or screenshot regression. A 12/12 result therefore means the generated code passed static checks. It does not mean the app reaches 60 FPS on your device or can be merged unchanged.

L0: The smallest collection of the four

react-navigation shows the progressive-disclosure design: a 631-token entry points to 17,267 tokens of references, a 27.36 ratio. Navigation questions can load navigation material; list-performance questions can load list material instead of injecting an entire RN manual into every request.

The writing discipline is unusually clear—but not fully enforced

Callstack’s AGENTS.md says to add only context the model does not already know, write third-person descriptions, state What + When, keep references one level deep, avoid redundancy, and keep bodies under 500 lines. It is the clearest authoring guide among the four collections.

The static audit confirms that body length and third-person descriptions comply. But the 83 first-party reference files contain 299 one-level-deep violations. For example, js-lists-flatlist-flashlist.md links onward to js-profile-react.md and js-measure-fps.md. Those “See also” links may be useful, but they contradict the repository’s own rule.

The reason is structural: /validate-skills is a manual slash command rather than a CI check. Expo puts the same 500-line limit into CI; Callstack currently relies mostly on documentation. Human-friendly rules are followed, while rules that require automated discovery drift.

Metadata in POWER.md may be invisible to standard parsers

The react-native-best-practices directory contains a non-standard POWER.md that duplicates frontmatter and adds author and keywords. A parser that reads only SKILL.md will not see those fields. That is why L0 reports only 8% author coverage and 0% keywords: the information exists in one place, but not where the standard reader expects it.

Profiler screenshots are a meaningful extra asset

react-native-best-practices/references/images/ contains 12 profiler screenshots: flamegraphs, memory-heap snapshots, bundle treemaps, Xcode Instruments, FlashList comparisons, controlled-TextInput round trips, FPS graphs, and view-hierarchy examples. The repository is about 22 MB, with the images accounting for much of that size.

This is not merely decoration. It gives an agent visual examples that connect profiler output to diagnosis. Across the four collections, this is the only one with a systematic set of performance-analysis screenshots. Images still explain evidence; they do not replace sampling on a real device.

Provenance is still the weak spot

React Native’s New Architecture, FlashList v2, Hermes, and SDK combinations are version-sensitive. Without updated, last_verified, or review_by, an agent has no automatic signal that an otherwise good recommendation may need checking against today’s toolchain.

L1: The best routing result of the four

The result is:

• in-scope: 13/13, or 100%;
• out-of-scope false triggers: 0/7;
• no RN skill was incorrectly assigned to Flutter, backend, or generic product work.

react-native-best-practices has a broad-looking description mentioning FPS, TTI, bundle size, memory leaks, rerenders, animations, Hermes, the JS thread, the bridge, FlashList, native modules, and jank. Yet it never swallowed an unrelated prompt because the description is anchored by “React Native performance optimization” and RN-specific terms.

The reusable lesson is simple: platform- and framework-specific vocabulary is a better routing guardrail than claiming to cover everything.

The coverage gap: no E2E owner

The prompt “add unit tests and E2E tests to an RN project” routes to the component-testing direction, but no skill clearly owns Detox or Maestro. A user may receive sound RNTL advice while still having to design device-level navigation, permission, login, and deep-link regression coverage.

L2: 12/12 against 12/12—why use it at all?

Checklist result: no gain

All three bare-model runs found the subtle bug: Row lived inside the parent component, so every parent render created a new component type and could remount 500 rows. Both groups also independently added a leaf timer component, getItemLayout, precomputed lowercase search fields, and a fix for a module-level array mutated by .sort().

This is not evidence that the Skill is badly written. It shows that a public, classic RN performance problem is saturated in modern model training. Virtualization, memoization, stable callbacks, and timer cleanup are now common knowledge for the bare model.

Supplementary measurement: uncontrolled input is the stable difference

All B runs read js-uncontrolled-components.md and moved the search input away from the controlled path. A controlled input creates a JS↔native round trip per keystroke; when the input only initiates a search and does not need to drive a render every frame, an uncontrolled path can remove one source of pressure.

The scope matters: controlled inputs are not always wrong, and a Skill does not make the lag disappear automatically. It supplies an additional option for one high-frequency input scenario, which still needs profiling on the target device.

Progressive disclosure saves a measured 68%–72% of context

Of 29 optional references, B1 read seven and brought 14,559 tokens into context. B2 and B3 each read six and brought 12,870 tokens. Loading all 29 would cost 45,231 tokens, so the observed savings were 68%, 72%, and 72%.

The selected files were nearly identical across runs: lists/FlashList, uncontrolled components, concurrent React, memory leaks, React profiling, and FPS measurement. This shows that progressive disclosure is not simply splitting a large file. The useful piece is the Problem → Skill Mapping index that tells the agent which page to open.

B improved honesty, not checklist scores

The workflow requires Measure → Optimize → Re-measure → Validate. Every B run said that the environment lacked the device and tools needed for flashlight measure, agent-device react-devtools profile, or Perf Monitor, so it could only perform static optimization. None of the A runs made the same limitation explicit.

That is a practical form of quality: the Skill separates “I generated a plausible patch” from “I proved the patch works.” For performance work, that boundary can be more valuable than another useMemo.

How it compares with the other mobile collections

Across four rounds, the bare-model median rose from 9 to 10 to 10 to 12. The implication is important: for public, classic mobile-development problems, the bare model is getting very strong. Choose a Skill based on whether it adds something the model cannot infer from general knowledge—version conventions, internal process, device tooling, or organizational policy—not merely whether the injected run also gets a perfect score.

Strengths and weaknesses

Strengths

• Small resident footprint: only 826 catalog tokens.
• Clear boundaries: 13/13 in-scope routing and 0/7 false triggers.
• Useful progressive disclosure: Problem → Skill Mapping narrows 29 references to six or seven.
• Distinct performance evidence: 12 profiler screenshots are diagnostic examples, not decoration.
• Process honesty: the workflow explicitly asks for measurement and re-measurement.
• Good RN engineering coverage: brownfield, native libraries, TV, navigation, and upgrades are more specific than a generic prompt.

Weaknesses

• Little marginal gain on classic performance tasks: zero checklist delta in this fixture.
• No E2E owner: RNTL component tests are not Detox/Maestro device regression.
• Incomplete enforcement: 299 one-level reference violations show that manual validation drifts.
• Non-standard metadata: POWER.md author/keywords may be ignored by standard readers.
• No freshness signal: no updated, last_verified, or review_by fields.
• Real-device validation remains yours: profiling, network conditions, low-end Android, and iOS hardware still need CI or lab coverage.

Practical adoption guide

If you maintain an RN app

Install it and trigger it by task instead of permanently injecting every reference. For performance work, start with the list/FlashList, uncontrolled-input, memory-leak, and FPS material; open the deeper react-navigation references only for navigation tasks. Record your RN, Hermes, Fabric/New Architecture, FlashList, and device versions when reviewing a patch.

If you are doing brownfield or native-library work

The migration, native-library, and brownfield skills are more valuable here than a generic “write a module” prompt. Still give both iOS and Android build logs, minimum versions, CocoaPods/Gradle settings, and rollback plans to real CI.

If you need E2E

Do not treat a react-native-testing trigger as complete end-to-end coverage. Add an explicit Detox or Maestro owner, device matrix, permission/login/deep-link scenarios, and screenshot regression policy.

If you are deciding whether to install

Run your own high-frequency tasks once with the bare model. If it already passes every check, the Skill’s value may be process discipline, organizational convention, or a rare version rule rather than a prettier patch. Measure the A/B delta before keeping it permanently resident.

Verdict

Worth installing, as long as you know what it provides.

This is the smallest and most accurate-routing RN collection in the comparison, particularly useful for teams that want an agent to stay inside the RN boundary while consulting profiler examples and migration practice. It is not a magic switch that makes ordinary RN patches correct: on this classic list-performance fixture, the bare model already scored three perfect runs.

The most reusable ideas are not individual useMemo suggestions. They are the Problem → Skill Mapping index for progressive disclosure and the Measure → Optimize → Re-measure → Validate workflow. The most urgent repository improvements would be turning /validate-skills into CI and adding last_verified or review_by to version-sensitive skills.

Treat this review as a bounded experiment. It demonstrates routing accuracy, context savings, process honesty, and one narrow uncontrolled-input difference. It does not demonstrate that your app will be faster on a real device, nor does it replace security review, E2E, builds, or release testing.

References

• Callstack agent-skills GitHub repository
• React Native documentation
• React Native Performance overview
• FlashList documentation