agentleFS
Ampli-GroupAmpli-Group/agentic-mobile-blueprint/AGENTS.md

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

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
  1. Distinctive:

    Every task must be verified, not just coded.

    line 9
  2. Distinctive:

    Before writing any code, confirm the relevant services are running:

    line 13
  3. Very specific:

    Run supabase status from the project root to check Supabase (DB, auth, storage, edge runtime)

    line 15
  4. Very specific:

    If services are down, start them with the appropriate mise run command and keep the terminal open

    line 17
  5. Distinctive:

    Read the terminal file (or its tail) to see live output, errors, and stack traces

    line 21
  6. Distinctive:

    After making changes, re-read the same terminal file to check for new errors or successful recompilation

    line 22
  7. Very specific:

    Write the code changes. Use the skills in .agents/skills/ for coding patterns.

    line 31
  8. Distinctive:

    After every change, verify it works using the appropriate tools:

    line 35
  9. Distinctive:

    Never skip verification: If a service isn't running and can't be started, report that clearly rather than assuming the code works.

    line 56
  10. Distinctive:

    When implementing a cross-cutting feature (e.g.

    line 105
  11. Very specific:

    Write the edge function in supabase/functions/

    line 107
  12. Very specific:

    Test via Shell (curl) or browser MCP (Supabase Studio)

    line 108
  13. Distinctive:

    Read terminal logs across all layers if something fails

    line 111
  14. Very specific:

    All project tasks are defined in .mise.toml.

    line 117
  15. Very specific:

    Run mise run configure to set up environment variables interactively.

    line 123
  16. Very specific:

    Never create .env files directly: Always use mise run configure or edit the existing .env.local files.

    line 132

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

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 status from the project root to check Supabase (DB, auth, storage, edge runtime)
  • List terminal files (ls the terminals folder) and read them to find running processes
  • If services are down, start them with the appropriate mise run command 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:

  1. List the terminals folder to see all active terminals
  2. Read the terminal file (or its tail) to see live output, errors, and stack traces
  3. 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:

LayerHow to verify
Edge functionscurl the endpoint or check supabase functions logs. Read the terminal running mise run supabase:function for errors.
FrontendRead the terminal running mise run frontend for compile errors. Use browser_navigate + browser_snapshot to visually confirm. Check browser_console_messages for runtime errors.
MobileTest 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.
DatabaseUse 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-layerVerify each layer touched. E.g. new API + mobile screen = check edge function logs + take mobile screenshot.

Mobile — two tracks (do not conflate):

TrackPurposeHow
Regression / pre-deployRepeatable full or smoke coverage before production or in CIYAML under maestro/*.yaml; run with maestro test (or your CI job).
Interactive / PR-scopedExercise only the changed UI on simulatorsMaestro 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

ServicePurposeWhere
LangfuseLLM tracing, costsEdge Functions
SentryError trackingAll apps
PostHogProduct analyticsFrontend + Mobile
Vercel AnalyticsWeb vitalsFrontend

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 ServerPurposeWhen to use
maestroMobile simulator access — screenshots, view hierarchy, tap, type, navigate, manage devicesCursor: 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-browserWeb browser access — navigate, snapshot, click, fill, console messages, network requestsVerifying frontend at localhost:3000 and Supabase Studio (get URL from supabase status).
user-context7Library documentation retrievalWhen 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:ios or mise run mobile:android
  • Edge function logs: terminal running mise run supabase:function, or supabase functions logs <name>
  • Frontend logs: terminal running mise run frontend, or browser_console_messages via browser MCP

Multi-Layer Workflow

When implementing a cross-cutting feature (e.g. new API + mobile screen + admin view):

  1. Write the edge function in supabase/functions/
  2. Test via Shell (curl) or browser MCP (Supabase Studio)
  3. Build the mobile screen, verify with Maestro MCP on both iOS and Android
  4. Build the admin view, verify with browser MCP
  5. 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:

FileUsed by
frontend/.env.localNext.js dev server
mobile/.env.localExpo dev server
supabase/functions/.env.localEdge functions (supabase functions serve --env-file)
trigger/.env.localTrigger.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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.