agentleFS
moasqmoasq/ios-dev-agent/.cursor/rules/scope.mdc

ios-dev-agent / rules

Cursor rule4 starsChanged 6 months agoMITView on GitHub

iOS development rule

The file

We split this scope.mdc into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default to 1–2 screens maximum unless the user explicitly asks for more.

    line 15
  2. Distinctive:

    If the user mentions specific features, build those and ONLY those.

    line 17
  3. Distinctive:

    Every screen MUST be fully functional — real navigation, real data flow, real interactions.

    line 32
  4. Distinctive:

    Do NOT create stub/placeholder views that show "Coming soon" or "TODO".

    line 33
  5. Distinctive:

    Do NOT create empty tab views just to fill a TabBar.

    line 34
  6. Distinctive:

    Prefer fewer polished screens over many incomplete screens.

    line 35
  7. Distinctive:

    When the user asks for an "app clone" (e.g., "TikTok clone", "Spotify clone"), build the ONE defining feature that makes that app …

    line 40

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule 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
scope.mdc
---
description: iOS development rule
globs: "**/*.swift"
alwaysApply: true
---

# Scope Rules — Build the Minimum Functional App

## Golden Rule: Small and Working > Big and Broken

A small app that works perfectly is ALWAYS better than a big app with broken features. Your goal is to impress the user with a polished, functional experience — not to overwhelm them with stub screens.

## Screen Limits

- Default to **1–2 screens maximum** unless the user explicitly asks for more.
- Pick only the **MOST CRITICAL features** that make the app functional.
- If the user mentions specific features, build those and ONLY those.

### Examples

| User says | Build | Do NOT build |
|---|---|---|
| "notes app" | list + editor (2 screens) | folders, tags, search, sharing, trash, settings |
| "music app" | library list + now playing (2 screens) | browse, radio, search, social, lyrics |
| "TikTok clone" | scrollable video feed (1 screen) | discover, create, inbox, profile, comments |
| "weather app" | current weather + forecast (1 screen) | hourly breakdown, maps, alerts, settings |
| "todo app" | task list with add/complete (1 screen) | categories, due dates, recurring, sharing |
| "chat app" | conversation list + chat (2 screens) | contacts, settings, profile, media gallery |

## Quality Over Quantity

- Every screen MUST be fully functional — real navigation, real data flow, real interactions.
- Do NOT create stub/placeholder views that show "Coming soon" or "TODO".
- Do NOT create empty tab views just to fill a TabBar.
- Prefer fewer polished screens over many incomplete screens.
- Build EXACTLY what the user asked for, nothing more. User intent is king.

## Feature Scoping

- When the user asks for an "app clone" (e.g., "TikTok clone", "Spotify clone"), build the ONE defining feature that makes that app recognizable, not every feature the real app has.
- The defining feature of TikTok is the vertical video feed. The defining feature of Spotify is the music library + player. The defining feature of Instagram is the photo feed.
- Additional features can be added later via edit requests — that's what the edit flow is for.

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.