agentic-mobile-blueprint
AGENTS.md4 starsChanged 6 months agoMITView on GitHub
This document helps LLM agents understand the codebase structure, environment, and available tooling. For coding patterns and conventions, see the skills in .agents/skills/. Every task must be verified, not just coded. Follow this workflow: Before writing any code, confirm the relevant services are running: Reading logs: Each mise run command runs in a terminal whose output is captured in a text file. To read logs: 1. List the terminals folder to see all active terminals 2. Read the terminal file…
- Reads credentials
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,542 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository16 other files it gives its agents.
- apple-appstore-setupSkill
- eas-mobile-deploymentSkill
- edge-functionsSkill
- frontend-developmentSkill
- google-play-setupSkill
- langfuse-tracingSkill
- mobile-developmentSkill
- posthog-analyticsSkill
- push-notificationsSkill
- revenuecatSkill
- sentry-integrationSkill
- social-auth-setupSkill
- stripe-paymentsSkill
- supabase-email-templatesSkill
- template-releaseSkill
- template-upgradeSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
16 rules. About 0 are common, 8 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Every task must be verified, not just coded.
- Distinctive: line 13
Before writing any code, confirm the relevant services are running:
- Very specific: line 15
Run supabase status from the project root to check Supabase (DB, auth, storage, edge runtime)
- Very specific: line 17
If services are down, start them with the appropriate mise run command and keep the terminal open
- Distinctive: line 21
Read the terminal file (or its tail) to see live output, errors, and stack traces
- Distinctive: line 22
After making changes, re-read the same terminal file to check for new errors or successful recompilation
- Very specific: line 31
Write the code changes. Use the skills in .agents/skills/ for coding patterns.
- Distinctive: line 35
After every change, verify it works using the appropriate tools:
- Distinctive: line 56
Never skip verification: If a service isn't running and can't be started, report that clearly rather than assuming the code works.
- Distinctive: line 105
When implementing a cross-cutting feature (e.g.
- Very specific: line 107
Write the edge function in supabase/functions/
- Very specific: line 108
Test via Shell (curl) or browser MCP (Supabase Studio)
- Distinctive: line 111
Read terminal logs across all layers if something fails
- Very specific: line 117
All project tasks are defined in .mise.toml.
- Very specific: line 123
Run mise run configure to set up environment variables interactively.
- Very specific: line 132
Never create
.envfiles directly: Always use mise run configure or edit the existing .env.local files.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Context
This document helps LLM agents understand the codebase structure, environment, and available tooling.
For coding patterns and conventions, see the skills in .agents/skills/.
Task Workflow
Every task must be verified, not just coded. Follow this workflow:
1. Check Environment
Before writing any code, confirm the relevant services are running:
- Run
supabase statusfrom the project root to check Supabase (DB, auth, storage, edge runtime) - List terminal files (
lsthe terminals folder) and read them to find running processes - If services are down, start them with the appropriate
mise runcommand and keep the terminal open
Reading logs: Each mise run command runs in a terminal whose output is captured in a text file. To read logs:
- List the terminals folder to see all active terminals
- Read the terminal file (or its tail) to see live output, errors, and stack traces
- After making changes, re-read the same terminal file to check for new errors or successful recompilation
This gives you three verification channels for every change:
- Terminal logs — compile errors, runtime errors, request logs
- Browser MCP — visual state of frontend and Supabase Studio
- Maestro MCP — visual state of the mobile app on the simulator
2. Implement
Write the code changes. Use the skills in .agents/skills/ for coding patterns.
3. Verify
After every change, verify it works using the appropriate tools:
| Layer | How to verify |
| Edge functions | curl the endpoint or check supabase functions logs. Read the terminal running mise run supabase:function for errors. |
| Frontend | Read the terminal running mise run frontend for compile errors. Use browser_navigate + browser_snapshot to visually confirm. Check browser_console_messages for runtime errors. |
| Mobile | Test on both platforms: start iOS (mise run mobile:ios) and Android (mise run mobile:android). Read their terminal output for Metro/Expo errors. Use Maestro MCP (list_devices, take_screenshot, inspect_view_hierarchy, tap/navigate as needed) on each device to visually confirm the UI on both. |
| Database | Use browser_navigate to Supabase Studio (get port from supabase status) and verify tables/data with browser_snapshot. Or run SQL via supabase db query. |
| Cross-layer | Verify each layer touched. E.g. new API + mobile screen = check edge function logs + take mobile screenshot. |
Mobile — two tracks (do not conflate):
| Track | Purpose | How |
| Regression / pre-deploy | Repeatable full or smoke coverage before production or in CI | YAML under maestro/*.yaml; run with maestro test (or your CI job). |
| Interactive / PR-scoped | Exercise only the changed UI on simulators | Maestro MCP (Cursor or CLI agent with MCP): list_devices, screenshots, view hierarchy, taps. Start mise run mobile:ios / mise run mobile:android in the background as needed. Does not replace maestro test above. |
4. Report
Summarize what was done, what was verified, and include any screenshots or log output as evidence.
Never skip verification. If a service isn't running and can't be started, report that clearly rather than assuming the code works.
Project Structure
├── frontend/ # Next.js web application
├── mobile/ # React Native (Expo) mobile app
├── supabase/ # Backend: database, auth, edge functions
├── trigger/ # Background jobs and workflows
├── workflows/ # GitHub Actions CI/CD
├── scripts/ # Setup and configuration scripts
└── .agents/skills/ # Agent skills (coding patterns per layer)Observability
| Service | Purpose | Where |
| Langfuse | LLM tracing, costs | Edge Functions |
| Sentry | Error tracking | All apps |
| PostHog | Product analytics | Frontend + Mobile |
| Vercel Analytics | Web vitals | Frontend |
Agent Tooling — MCP Servers
You have three MCP servers available. Use them — these are your eyes into the running app. Discover each server's available tools via the MCP tool descriptors.
| MCP Server | Purpose | When to use |
maestro | Mobile simulator access — screenshots, view hierarchy, tap, type, navigate, manage devices | Cursor: MCP is started by the IDE (.cursor/mcp.json → maestro mcp). Ensure maestro is on PATH (e.g. mise run install adds ~/.maestro/bin). Use MCP tools; do not start a second maestro mcp for the agent. For mobile dev, run mise run mobile:ios / mobile:android (background). YAML under maestro/ is for maestro test / pre-deploy. |
cursor-ide-browser | Web browser access — navigate, snapshot, click, fill, console messages, network requests | Verifying frontend at localhost:3000 and Supabase Studio (get URL from supabase status). |
user-context7 | Library documentation retrieval | When you need up-to-date API docs for any library (Expo, Tamagui, Next.js, Supabase, Sentry, etc.). |
Reading Logs (Shell / Terminals)
Each mise run command outputs to a terminal file. Read these for compile errors, runtime errors, and request logs:
- Expo logs: terminal running
mise run mobile:iosormise run mobile:android - Edge function logs: terminal running
mise run supabase:function, orsupabase functions logs <name> - Frontend logs: terminal running
mise run frontend, orbrowser_console_messagesvia browser MCP
Multi-Layer Workflow
When implementing a cross-cutting feature (e.g. new API + mobile screen + admin view):
- Write the edge function in
supabase/functions/ - Test via Shell (
curl) or browser MCP (Supabase Studio) - Build the mobile screen, verify with Maestro MCP on both iOS and Android
- Build the admin view, verify with browser MCP
- Read terminal logs across all layers if something fails
Task Runner (mise)
All project tasks are defined in .mise.toml. Run mise tasks to discover all available commands. Use mise run <task> to execute them. Never run services directly (e.g. npx expo start) — always use the mise tasks.
Environment Setup
Run mise run configure to set up environment variables interactively. This script generates .env.local files for each layer:
| File | Used by |
frontend/.env.local | Next.js dev server |
mobile/.env.local | Expo dev server |
supabase/functions/.env.local | Edge functions (supabase functions serve --env-file) |
trigger/.env.local | Trigger.dev dev server |
Never create .env files directly. Always use mise run configure or edit the existing .env.local files. The .env.local convention is used project-wide — all services read from it.
Required for LLM features: OPENAI_API_KEY or ANTHROPIC_API_KEY or GEMINI_API_KEY, plus LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY.
Required for all apps: SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

