Skip to main content
Glama

generate-claude-md

Create a CLAUDE.md file to define project rules for AI-assisted development, including tech stack overview, architecture guidelines, code conventions, and MCP tool usage instructions.

Instructions

Generate a CLAUDE.md file with project rules for Claude Code. Includes tech stack overview, architecture rules, code conventions, and MCP tool usage instructions so Claude automatically calls the right pattern tools during development.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNameYesApp name
appDescriptionNoShort description of the app
featuresNoList of main features

Implementation Reference

  • Implementation of the generateClaudeMd function which constructs the CLAUDE.md markdown content.
    export function generateClaudeMd(options: ClaudeMdOptions): string {
      const { appName, appDescription, features } = options;
    
      const descriptionSection = appDescription
        ? `\n## Description\n${appDescription}\n`
        : "";
    
      const featuresSection =
        features && features.length > 0
          ? `\n## Features\n${features.map((f) => `- ${f}`).join("\n")}\n`
          : "";
    
      return `# ${appName}
    ${descriptionSection}${featuresSection}
    ## Tech Stack
    
    - **Framework**: Expo (Managed Workflow)
    - **Navigation**: Expo Router (file-based routing)
    - **Language**: TypeScript (strict mode)
    - **Styling**: NativeWind v4 (Tailwind CSS)
    - **State Management**: Zustand + MMKV (persist)
    - **API**: Axios + TanStack Query
    - **Build**: EAS Build + OTA Updates
    
    ## Architecture
    
    ### File-based Routing (Expo Router)
    - Files in \`app/\` = routes
    - \`app/_layout.tsx\` = root layout (providers, auth guard)
    - \`app/(tabs)/\` = tab navigator group
    - \`app/(auth)/\` = auth screens group
    
    ### Logic/UI Separation — THE CORE RULE
    - **Route file** (\`app/*.tsx\`) = logic container (hooks, store access, handlers, navigation)
    - **Screen UI** (\`src/screens/*UI.tsx\`) = pure UI (props-driven, no store/API/navigation)
    - UI components do NOT import router, store, or API — everything via props
    
    ### Project Structure
    \`\`\`
    app/                    # Expo Router routes
    ├── _layout.tsx         # Root layout (providers + auth guard)
    ├── (auth)/
    │   ├── _layout.tsx     # Auth stack
    │   └── login.tsx       # LoginRoute (logic only)
    └── (tabs)/
        ├── _layout.tsx     # Tab bar
        ├── index.tsx       # HomeRoute
        └── catalog.tsx     # CatalogRoute
    
    src/
    ├── screens/            # Screen UI components (pure UI)
    │   ├── LoginScreenUI.tsx
    │   └── CatalogScreenUI.tsx
    ├── components/
    │   └── ui/             # Button, TextInput, Card, Avatar
    ├── store/              # Zustand stores (auth.ts, cart.ts)
    ├── services/
    │   ├── api/            # Axios client + domain services
    │   └── storage/        # MMKV adapter (mmkv.ts)
    ├── hooks/              # TanStack Query hooks (useProducts, useAuth)
    ├── constants/          # colors.ts, layout.ts, config.ts
    ├── types/              # TypeScript types (models.ts, api.ts)
    └── utils/              # Pure helpers (validators, formatters)
    \`\`\`
    
    ## MCP Tool Usage
    
    This project uses the \`react-native-expo-mcp\` server. Claude should call these tools automatically:
    
    | When you are... | Call this tool |
    |---|---|
    | Creating a component, button, card, list item | \`get-component-patterns\` |
    | Creating a new screen or route | \`get-screen-architecture\` |
    | Working with navigation, routes, or auth guard | \`get-navigation-patterns\` |
    | Creating a Zustand store or working with global state | \`get-state-patterns\` |
    | Creating API services or data fetching hooks | \`get-api-patterns\` |
    | Styling components with NativeWind | \`get-styling-patterns\` |
    | Optimizing lists, images, bundle, or animations | \`get-performance-patterns\` |
    | Deciding where to place a new file | \`get-project-structure\` |
    | Writing TypeScript types or interfaces | \`get-typescript-patterns\` |
    | Debugging memory leaks or performance issues | \`get-memory-optimization\` |
    
    ## Code Rules
    
    ### Code Style
    - **Always use \`const\` arrow functions** — never \`function\` declarations
    - Routes: \`const MyRoute = () => {...}; export default MyRoute;\`
    - Components: \`export const Button = ({...}: Props) => {...};\`
    - Hooks: \`const useMyHook = () => {...};\`
    - Never use anonymous default exports: \`export default () => {}\`
    
    ### Components
    - Use \`Pressable\` instead of \`TouchableOpacity\`
    - Use \`expo-image\` instead of \`Image\`
    - Use \`className\` (NativeWind) for styles
    - Enable **React Compiler** (\`babel-plugin-react-compiler\`) — it auto-memoizes components, hooks, and dependencies. Do NOT use \`React.memo\`, \`useMemo\`, or \`useCallback\` manually
    - Composable pattern for complex components (ProductCard.Image, ProductCard.Title)
    
    ### State Management
    - **Zustand** for client state (auth, cart, preferences)
    - **TanStack Query** for server state (products, orders, profiles)
    - Always use **selectors**: \`useStore((s) => s.field)\` — never destructure the whole store
    - \`useShallow\` for multiple values from one store
    - MMKV persistence for auth and user preferences
    
    ### API
    - Axios instance with interceptors (auth token injection, 401 auto-logout)
    - Domain-grouped services: \`authService\`, \`productService\`
    - Custom TanStack Query hooks: \`useProducts\`, \`useLogin\` — never call \`useQuery\` directly in components
    - Query key convention: \`['entity', ...params]\`
    
    ### Navigation
    - \`router.push()\` / \`router.replace()\` for navigation
    - \`useLocalSearchParams<T>()\` for typed route params
    - AuthGuard in root \`_layout.tsx\` — wait for \`navigationRef.isReady()\`
    - Deep linking works automatically via file structure
    
    ### TypeScript
    - Strict mode always enabled
    - No \`any\` (use \`unknown\` with type guard if needed)
    - Typed route params with \`useLocalSearchParams<T>()\`
    - Path aliases: \`@/\` → \`./src/\`
    
    ### Styling
    - NativeWind (Tailwind CSS) for 95% of styles
    - Colors via Tailwind theme (\`tailwind.config.js\`) + JS constants (\`src/constants/colors.ts\`)
    - \`cssInterop\` to enable className on third-party components
    - Rule: if a value is used in 2+ files → move it to \`constants/\`
    
    ### Performance
    - \`FlashList\` or \`FlatList\` for lists (NEVER ScrollView + map)
    - \`getItemLayout\` for FlatList when item height is fixed
    - \`expo-image\` with \`cachePolicy="memory-disk"\`
    - WebP format for all images
    - Direct submodule imports to enable tree-shaking (avoid barrel exports)
    - Reanimated worklets for 60+ FPS animations
    
    ### Language
    - **All generated code, comments, and file content must be in English** — regardless of the user's language
    - Variable names, component names, types, and comments — always English
    `;
    }
  • src/index.ts:301-326 (registration)
    Registration of the generate-claude-md tool in the MCP server.
    server.tool(
      "generate-claude-md",
      "Generate a CLAUDE.md file with project rules for Claude Code. Includes tech stack overview, architecture rules, code conventions, and MCP tool usage instructions so Claude automatically calls the right pattern tools during development.",
      {
        appName: z.string().describe("App name"),
        appDescription: z
          .string()
          .optional()
          .describe("Short description of the app"),
        features: z
          .array(z.string())
          .optional()
          .describe("List of main features"),
      },
      async ({ appName, appDescription, features }) => {
        const content = generateClaudeMd({
          appName,
          router: "expo-router",
          appDescription,
          features,
        });
        return {
          content: [{ type: "text", text: content }],
        };
      }
    );
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a file but does not describe where the file is saved, whether it overwrites existing files, what permissions are needed, or the format of the output. For a tool that creates documentation, this lack of operational details is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the main action ('Generate a CLAUDE.md file') and elaborates on its contents. It avoids redundancy and wastes no words, though it could be slightly more structured by separating key components like tech stack and conventions into bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (generating a structured documentation file) and the absence of annotations and output schema, the description is minimally adequate. It outlines what the tool does but lacks details on behavioral aspects, output format, and integration with sibling tools, leaving gaps for the agent to navigate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the parameters (appName, appDescription, features). The description adds no additional meaning beyond what the schema provides, such as how these inputs influence the generated content or examples of usage. Baseline 3 is appropriate when the schema handles all parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Generate a CLAUDE.md file') and resources ('project rules for Claude Code'), and distinguishes it from siblings by specifying its unique output (a documentation file with tech stack, architecture rules, code conventions, and MCP tool usage instructions) rather than generating code files or retrieving patterns like other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions the tool's purpose but does not specify prerequisites, appropriate contexts, or when to choose it over sibling tools like 'setup-new-project' or 'generate-project-files', leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZaharGusyatin/react-native-expo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server