codex-expo-run-actions
Wire Expo projects into the Codex app with project-local run scripts and .codex/environments/environment.toml actions. Use when the user wants the Codex app Run button, build/run actions, action buttons, or a stable Expo start/run workflow from Codex.
- License 许可
- MIT
- 最近更新
- 2026-04-28
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- codex-expo-run-actions
- license
- MIT
- version
- 1.0.0
- description
- Wire Expo projects into the Codex app with project-local run scripts and .codex/environments/environment.toml actions. Use when the user wants the Codex app Run button, build/run actions, action buttons, or a stable Expo start/run workflow from Codex.
02 资源文件 1
- 参考文档references/expo-run-button-bootstrap.md4.9 KB
03 SKILL.md 正文
Codex Run Actions for Expo
Use this skill to connect an Expo project to the Codex app action bar.
The goal is one project-local script plus .codex/environments/environment.toml,
so the user can press Run in the Codex app and see the Expo CLI / Metro logs in
an action terminal.
Workflow
-
Confirm the current workspace is an Expo app.
- Look for
package.json. - Look for
app.json,app.config.js,app.config.ts, orexpoinpackage.json. - Do not wire the Codex action at a monorepo root if the Expo app is in a child package.
- Look for
-
Discover the package runner.
- Prefer the package manager declared in
packageManager. - Otherwise infer from lockfiles.
- The generated run script should still have a safe fallback to
npx expo.
- Prefer the package manager declared in
-
Create or update
script/build_and_run.sh.- Use the reference file for the script shape.
- Default no-argument mode starts the Expo dev server:
expo start. - Keep the dev server in the foreground so the Codex action terminal owns logs and Ctrl-C behavior.
- Support optional modes for direct buttons:
--iosstarts Expo and opens iOS simulator.--androidstarts Expo and opens Android.--webstarts Expo for web.--dev-clientstarts in dev-client mode.--tunnelstarts a tunnel.--export-webexports web.
-
Write
.codex/environments/environment.toml.- Always add or update one primary action named
Run. - Wire
Runto./script/build_and_run.sh. - Add direct
Run iOS,Run Android,Run Web, orRun Dev Clientactions only when the user asks for those buttons or the project clearly needs them. - If the environment file already exists, update the existing matching action instead of duplicating it.
- Always add or update one primary action named
-
Use the action script as the default local run path.
- After wiring, run
./script/build_and_run.sh --helpor a short non-server mode if you need to sanity-check syntax. - Do not start a long-lived Metro server during a setup-only task unless the user asked you to run the app.
- After wiring, run
References
references/expo-run-button-bootstrap.md: canonical Exposcript/build_and_run.shand Codex environment action examples.
Guardrails
- Try Expo Go /
expo startfirst; do not default the Codex Run button toexpo run:ios,expo run:android, prebuild, or EAS Build. - Do not wire cloud actions such as
eas build,eas submit, or store deployment into Codex buttons unless the user explicitly asks and accepts the auth / time / cost tradeoff. - Do not create a nested git repo.
- Do not put secrets in
.codex/environments/environment.tomlor in the run script. - Do not background Metro from the run script; the action terminal should show the active server logs.
- Do not hard-code npm if the project uses pnpm, yarn, or bun.
Output Expectations
When setup changes are made, summarize:
- the Expo app root you wired
- the run script path
- the Codex environment file path
- the actions added or updated
- how to launch the same path from shell
04 同仓库更多 Skills
render-workflows
Sets up, develops, tests, and deploys Render Workflows. Covers first-time scaffolding (via CLI or manual), SDK installation (Python or TypeScript), task patterns (retries, subtasks, fan-out), local development, Dashboard deployment, and troubleshooting. Use when a user wants to set up Render Workflows for the first time, scaffold a workflow service, add or modify workflow tasks, test workflows locally, or deploy workflows to Render.
render-monitor
Monitor Render services in real-time. Check health, performance metrics, logs, and resource usage. Use when users want to check service status, view metrics, monitor performance, or verify deployments are healthy.
render-migrate-from-heroku
Migrate from Heroku to Render by reading local project files and generating equivalent Render services. Triggers: any mention of migrating from Heroku, moving off Heroku, Heroku to Render migration, or switching from Heroku. Reads Procfile, dependency files, and app config from the local repo. Optionally uses Heroku MCP to enrich with live config vars, add-on details, and dyno sizes. Uses Render MCP or Blueprint YAML to create services.
render-deploy
Deploy applications to Render by analyzing codebases, generating render.yaml Blueprints, and providing Dashboard deeplinks. Use when the user wants to deploy, host, publish, or set up their application on Render's cloud platform.
render-debug
Debug failed Render deployments by analyzing logs, metrics, and database state. Identifies errors (missing env vars, port binding, OOM, etc.) and suggests fixes. Use when deployments fail, services won't start, or users mention errors, logs, or debugging.
minimal-skill
Minimal example skill for plugin-eval tests. Use when the user wants a compact demonstration of a well-structured skill.