Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/chohra-med/expo_boilerplate/app_rulesgit clone --depth 1 https://github.com/chohra-med/expo_boilerplateWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/chohra-med/expo_boilerplate/app_rules)<a href="https://agentmods.dev/rules/chohra-med/expo_boilerplate/app_rules"><img src="https://agentmods.dev/badge/rules/chohra-med/expo_boilerplate/app_rules.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.12680 | $0.12680 |
| Opus 5 | $0.06340 | $0.06340 |
| Sonnet 5 | $0.02536 | $0.02536 |
| Haiku 4.5 | $0.01268 | $0.01268 |
Grade A, and why
app_rules scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 2,008 lines — stays where its author put it; the contents beside it link to each section on GitHub.
MobileLauncher LT - Development Rules & Guidelines
This document outlines the essential rules and guidelines for developing with the MobileLauncher LT boilerplate. Follow these rules to maintain consistency, scalability, and code quality across the project.
🏗️ Architecture Rules
1. Feature-First Structure
- Always organize code by business features, not technical layers
- Each feature must be self-contained with its own:
components/- Feature-specific UI componentsscreens/- Screen componentshooks/- Custom hooks for business logicstore/- Redux slice and selectorsapi/- RTK Query endpointsservices/- Business logic servicestypes/- TypeScript type definitionsindex.ts- Barrel exports
Example:
src/features/auth/
├── components/
│ ├── login-form.tsx
│ └── index.ts
├── screens/
│ ├── login-screen.tsx
│ └── index.ts
├── hooks/
│ ├── use-auth.ts
│ └── index.ts
├── store/
│ ├── auth-slice.ts
│ ├── auth-selector.ts
│ └── index.ts
├── api/
│ ├── auth.api.ts
│ └── index.ts
├── services/
│ ├── auth.service.ts
│ └── index.ts
├── types/
│ ├── index.ts
├── index.ts
2. Shared Resources
- Extract common functionality to global directories (
src/ui/,src/services/,src/utils/) - Never duplicate code - if used in 2+ features, move to shared
- Use absolute imports with
#root/prefix for clean imports - Expo ecosystem: use expo.dev ecosystem for packages and yarn to install packages.
Example:
// ❌ Wrong - duplicated across features
// features/auth/components/button.tsx
// features/settings/components/button.tsx
// ✅ Correct - shared component
// src/ui/components/button.tsx
import { Button } from '#root/ui/components/button';
// ✅ Correct - shared utility
// src/utils/format-date.ts
import { formatDate } from '#root/utils/format-date';
🎨 UI Component Rules
3. Component Design
- Use Restyle for all styling - never use StyleSheet directly
- Create type-safe components with proper TypeScript interfaces
- Export prop interfaces for reusability
- Use React.memo for performance optimization
- Follow single responsibility principle
- Memorzie Functions: use useCallback for functions
- Avoid inline functions: extract functions outside render or use useCallback
- Avoid inline styling: use theme values and component variants instead
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 2,008 lines · 12,680 tokens per session scan A 30a1b15267ae
app_rules is a cursor rule published in the GitHub repository chohra-med/expo_boilerplate (32 stars, last pushed 4d ago), licensed MIT. It adds 12,680 tokens to every session, about $0.0634 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
optimize-dry-solid-principles-cursorrules-prompt-f
Cursor rules for optimization development with DRY and SOLID principles integration.
context-management
Context window management — prevents AI from losing track during long sessions.
hydration-safety
React hydration mismatch prevention.
middleware-auth
Next.js middleware auth — prevents auth logic being placed in middleware instead of route handlers.
project-context
Core project context — tech stack, folder structure, and global conventions.
supabase-auth-security
Supabase auth security — enforces getUser() over getSession() on the server.