Callstack Agent Skills: React Native guidance your assistant picks by itself

The trigger is a prompt, and the routing is the assistant's judgement

The whole mechanism is described in two sentences in the middle of the readme, and it is the thing to understand before anything else. Once a skill is installed you ask your assistant naturally, and it will select the relevant skill from the context of the task. There is no function to call, no file to name, no flag to pass. The assistant reads your prompt and decides. That is the design and it is also the limitation, because it means three things you would like to know are unknowable from your side. You cannot force a particular skill to load, since nothing in the interface expresses that. You cannot tell afterwards which one loaded, so if a piece of advice appears that you did not expect there is no way to attribute it. And the quality of the result depends on routing, which depends on the assistant's implementation of the skills mechanism rather than on this repository. What you can do is speak the task the way the readme's examples do, and those five examples are the closest thing to a specification of the routing. One is a request to review a screen for performance problems. One is a request to plan an upgrade to the latest supported release. One is a request to assess whether a native product should migrate incrementally. One is a request to build downloadable simulator and emulator artifacts in continuous integration. And one is a request to verify a checkout flow and capture evidence for failures. Each names a task, and each maps onto a skill area, which is the pattern to imitate.

Eight skills live here, three do not, and one bundle pulls both

The skills tables are the second thing to read carefully, because they mix two different sources and the readme tells you so in a sentence most people will skip. Callstack-maintained skills live in this repository, and the testing bundle also includes external skills. Counting the links tells you exactly which is which, and the distinction is a supply-chain fact rather than a technical one. Eight of the eleven have a relative path into this repository, covering performance, navigation, television, library creation, upgrades, continuous integration, migration assessment and brownfield migration. Three are hosted on a third-party registry, and they are the testing ones: a testing library skill, a device automation skill, and an exploratory testing skill. Those three sit under two different account prefixes in their registry paths, and one of them is not under the same account as the other two, so even the external set is not a single source. The consequence is concrete. The build and optimise bundle is entirely this repository. The migration bundle is entirely this repository. The testing bundle is a mixture, and if you install that bundle you are pulling guidance into your assistant's context that this project does not maintain and did not write. The last example prompt in the readme, about verifying a checkout flow and capturing evidence, belongs to that mixed bundle, which means the most agentic workflow offered here is the one with the least provenance. That is not a reason to avoid it, since device automation is genuinely useful, but it is a reason to read those three before you rely on them.

The installer runs an unpinned tool and will take every skill if you let it

Installation is two commands and a wildcard, and both deserve a second look. The command runs a package at the latest tag through the runner, without a version, and then adds the whole repository. The wildcard is the second detail: it selects all skills, and the alternative is to name one. So a single invocation executes an unpinned remote tool and pulls every skill in the repository, which is a normal thing to do with a package manager and not a reason for alarm, but it is also the widest available default. The two controls the interface gives you are both in that command line.

npx skills@latest add callstackincubator/agent-skills --skill '*'

Or one skill by name:

npx skills@latest add callstackincubator/agent-skills --skill react-native-best-practices

Pin the tool's version if you want the installer to be reproducible. Name the skills you want instead of taking them all, which also means a later run adds the new ones rather than silently changing your existing set. Two more things the readme explains. The tool asks which assistant to install for and what scope to use, so it is writing into a directory you choose rather than somewhere hidden, and the choice is interactive. And the assistant list is long, covering a named set of tools including one of the assistants this article is being written for, with a separate guide for the assistants that do not support the mechanism at all. The last point is the one to check first. If your assistant cannot load skills, nothing else in this readme applies, and the manual integration guide is the whole story.

A skill is a markdown file, and a bundle is a manifest that groups them

There is almost no code in this repository, and the structure section makes the deliverable clear in three lines. A directory of standalone skills maintained by the consultancy. A directory of plugin bundles for two named assistants. And a directory of integration and contributor guides. The convention is that each skill starts with a file of a specific name and can include focused material in a subdirectory, and that plugin manifests collect related skills into installable bundles. So a skill is a document with a front door, and a bundle is a manifest that points at several of them. That is the entire format, and it is worth understanding what follows from it being a document rather than a program.

skills/    Standalone Callstack-maintained Agent Skills
plugins/   Claude Code and Codex plugin bundles
docs/      Integration and contributor guides

It can be read before you trust it, which is the main advantage. It has no behaviour, so it cannot execute anything; it is advice your assistant receives and may follow. And it has no version of its own, so freshness is a documentation problem rather than a dependency one. The portability of the format is also explained by the contribution section, which points at a public specification for agent skills hosted on its own site. The skills are not a proprietary format invented for one assistant, which is why a single set of skills can be installed into several different tools, and why an assistant that does not support the specification at all has a manual guide instead. That design decision is doing more work than anything else in the repository, and it is the reason this kind of knowledge package can exist at all.

A contribution bar of three adjectives and one rule about self-containment

The contribution section is three lines long and it is the best statement of intent in the readme. Contributions should be actionable, easy for an agent to discover, and complete enough to use without hidden context. Each of those three is a real constraint rather than a platitude. Actionable means the skill has to tell an assistant to do something, not to consider something, which rules out a lot of the material people want to contribute. Discoverable means the description has to be phrased so a router can match it to a task, which is why every skill in the tables has an explicit line saying what it is for rather than a prose summary. And the self-containment rule is the one with teeth. A skill that assumes context the assistant does not have is worse than no skill, because the assistant will apply it confidently and incompletely, and nothing in the mechanism will tell you. That is a failure mode specific to this design and it is named here, which suggests the maintainers have seen it. Three documents govern a contribution: the external specification, a conventions document in the guides directory, and a maintainer checklist inside the agent instruction file at the root. The existence of a maintainer checklist rather than a review-by-feel standard is the thing to notice. The same root file also carries the checklist for the repository itself, so the bar for adding a skill is written down next to the instructions for working on the project.

The guidance names specific versions, which is its strength and its shelf life

Each skill's description is a list of the concrete things it covers, and reading them together tells you how opinionated this material is. The performance skill names frame rate, startup time, rendering, memory, bundle size, animations and native integration. The navigation skill names a specific major version of the navigation library and the specific things within it, including stacks, tabs, drawers, headers, sheets and safe-area behaviour. The television skill covers focus, remote input, playback, performance, packaging and accessibility, which is the full surface of that platform rather than the first two items. The library creation skill names the tool it teaches, so the skill and the command share a name. The upgrade skill covers template diffs, dependency and native project updates, and verification of the upgrade afterwards, which is the three-part shape of a version bump in a native project. The migration skills are the most interesting: one is an assessment that audits a product and its codebases, chooses a path, and defines a representative checkpoint, and the other is the phased integration into existing applications. That phrase about a representative checkpoint is the kind of specificity that separates material written by people who have done the migration from material written about it, and it is the one item in this repository that is worth reading before you install anything. The cost of this specificity is versioning. A skill that names a major version of a navigation library is useful on that version and quietly wrong on the next one, and nothing in the skill says when it was last checked.

Distilled from published work, with no publication date carried over

The related resources section is short and it is the provenance of everything in the skills. A free ebook on React Native optimisation is described as the foundation for the performance skill. A blog post on AI-supported brownfield migration is described as explaining the workflow behind the brownfield skills. A second ebook covers incremental adoption for teams with existing native applications. And a separate repository is linked as containing runnable examples for a compiler, dedicated native SDKs, and a size-reduction tool, which is the one item here that is code you can execute rather than prose. So the skills are a distillation of material the consultancy has already published and presumably edited, which is the strongest quality argument available for this repository: the guidance has an editorial process behind it rather than being assembled from documentation. The weakness is the mirror image of that strength. The ebooks and posts have publication dates and revision histories. The skills do not, at least not in the parts the readme reproduces. A team reading the skill in 2027 has no way to tell from the skill whether the advice still matches the version of the framework it names, and the readme's only freshness signal is the date of the last push to the repository, which tells you the files were touched and not what they say. If a decision matters, the underlying publication is the thing to check.

No releases, five tool configurations, and the honest alternative

Two final facts about the packaging. The repository publishes no tagged releases at all, and the last push was in mid-September 2026, which means an install takes whatever the default branch contains at the moment you run the command. There is no version to pin, no changelog to read before upgrading, and no way to say to a colleague which revision of the guidance your assistant is holding. For a repository of documents that is a weaker problem than it would be for code, because the worst case is stale advice rather than a broken install, but it is still a real gap for a team that wants reproducibility. The second fact is the top-level file list, which contains four separate configuration directories for coding assistants and editors, plus two agent instruction files at the root. A project that ships guidance for assistants is of course configured for assistants itself, and having a maintainer checklist inside one of those files is the tidy way to do it. So the honest alternative to all of this is worth naming. You can read the published ebooks and posts yourself and apply them deliberately, which is slower and means nothing depends on routing, and you can point an assistant at a specific document as context rather than installing a skill that it will decide to use. Or, if your team already has internal conventions, you can write your own skills in the same public format, which the specification is designed to allow. What installing these skills buys you is the assistant applying the guidance at the moment of the task without being reminded, and what it costs is that you no longer know which of it was applied.

Editorial conclusion

This repository is worth adopting if you are a React Native team that already trusts the source of the guidance, because the material is drawn from a consultancy's published work on production applications rather than assembled from documentation, and the format is a public specification so the skills are not tied to one assistant. Two things to know before you install. The selection is the assistant's judgement, not yours, so if a skill is not being applied the first thing to check is whether the prompt named the task clearly enough, and the readme's own example prompts are the best starting vocabulary. And the install command runs an unpinned package from a registry and accepts a wildcard, so the two controls you actually have are to pin that tool's version and to name the skills you want rather than taking all of them. Verify three things. Whether the assistant you use supports the skills mechanism at all, since the readme has a separate manual guide for the ones that do not. Whether the external skills in the testing bundle, which come from a third-party registry rather than this repository, are ones you want in your assistant's context. And how old the guidance is, since the repository publishes no releases and nothing in a skill states when it was last checked against the version of the framework it names.

Frequently asked questions

Official sources

1. callstackincubator/agent-skills on GitHub
2. Issues
3. License: MIT
4. README