---
title: "Steering files"
section: "develop-with-ai"
platforms: ["android", "angular", "flutter", "javascript", "nextjs", "react", "react-native", "swift", "vue"]
gen: 2
last-updated: "2026-07-13T22:13:20.000Z"
url: "https://docs.amplify.aws/react/develop-with-ai/steering-files/"
---

Steering files are project-level configuration files that guide AI coding assistants with your project's conventions, patterns, and constraints. When an AI assistant reads these files, it generates code that follows your team's standards and Amplify best practices.

## Why use steering files

AI assistants work best when they understand your project's context. Without steering files, the assistant may:
- Use outdated API patterns or incorrect import paths
- Generate code that doesn't match your auth/data model conventions
- Miss Amplify-specific patterns like `defineAuth()`, `defineData()`, or `defineStorage()`

Steering files solve this by giving the assistant persistent context about your project.

## Kiro steering

[Kiro](/[platform]/develop-with-ai/kiro/) uses steering files to maintain consistency across your project. Create steering rules that describe your Amplify project conventions:

- Data model naming patterns and authorization rules
- Auth configuration preferences (social providers, MFA settings)
- Frontend framework patterns (React hooks, Next.js App Router vs Pages Router)
- Testing conventions

Learn more in the [Kiro steering documentation](https://kiro.dev/docs/features/steering/).

## CLAUDE.md for Claude Code

If you use [Claude Code](https://docs.anthropic.com/en/docs/claude-code), create a `CLAUDE.md` file in your project root. This file is automatically loaded into every conversation.

Example `CLAUDE.md` for an Amplify project:

```markdown
# Project conventions

This is an AWS Amplify Gen 2 project using TypeScript.

## Structure
- `amplify/` — Backend resources (auth, data, storage, functions)
- `amplify/data/resource.ts` — Data model schema using `@aws-amplify/backend`
- `amplify/auth/resource.ts` — Auth configuration using `defineAuth()`
- `src/` — Frontend application code

## Amplify patterns
- Use `a.model()` for data models with `.authorization()` chains
- Use `allow.owner()` for user-owned data, `allow.guest()` for public read
- Import client operations from `aws-amplify/api` with `generateClient<Schema>()`
- Use `Amplify.configure(outputs)` with the generated `amplify_outputs.json`

## Testing
- Run `npx ampx sandbox` for local development
- Backend changes auto-deploy on file save during sandbox
```

## Cursor rules

For [Cursor](https://cursor.com), create rules in the `.cursor/rules/` directory:

```
.cursor/
  rules/
    amplify.mdc     # Amplify-specific conventions
```

Example `.cursor/rules/amplify.mdc`:

```markdown
---
description: Amplify Gen 2 conventions
globs: amplify/**/*
---

- Backend resources are defined in `amplify/` using TypeScript
- Data models use `a.schema({})` with `a.model()` definitions
- Authorization uses `.authorization(allow => [...])` chains
- Auth is configured with `defineAuth()` in `amplify/auth/resource.ts`
- Storage uses `defineStorage()` in `amplify/storage/resource.ts`
- Use `@aws-amplify/backend` for backend definitions
- Use `aws-amplify` for frontend client operations
```

## Amazon Q Developer context

[Amazon Q Developer](/[platform]/develop-with-ai/q-developer/) supports workspace context through the `@workspace` command. You can add reference files to help Q Developer understand your Amplify conventions:

- <a href="/images/gen2/q-developer/general.md" download>general.md</a> — General Amplify Gen 2 conventions and file structure
- <a href="/images/gen2/q-developer/authentication.md" download>authentication.md</a> — Auth configuration patterns and examples
- <a href="/images/gen2/q-developer/modeling-schema.md" download>modeling-schema.md</a> — Data model schema best practices
- <a href="/images/gen2/q-developer/modeling-relationships.md" download>modeling-relationships.md</a> — Data relationship patterns

Download these files and place them in a `context/` folder in your project root.

## AWS Blocks integration

If your project uses [AWS Blocks](/[platform]/build-a-backend/aws-blocks/) alongside Amplify, you can guide AI coding assistants to follow the Blocks integration patterns — defining backend capability in `aws-blocks/index.ts`, authenticating with your Amplify Cognito pool, and calling the generated typed client instead of constructing requests by hand.

### Use the official AWS Blocks skill (recommended)

AWS publishes an [AWS agent toolkit](https://github.com/aws/agent-toolkit-for-aws) — official, AWS-supported skills and plugins for AI coding agents — that includes an **`aws-blocks` skill**. The skill loads on demand when your task involves AWS Blocks (for example, when your project has an `aws-blocks/` directory or imports `@aws-blocks` packages) and keeps the assistant aligned with the current Blocks APIs and best practices, so you don't have to hand-maintain steering rules.

Install it once for your assistant:

<details><summary>Claude Code</summary>

```bash
/plugin install aws-core@claude-plugins-official
```

If you see a "Plugin not found" error, refresh the marketplace index first with `/plugin marketplace update claude-plugins-official`.

</details>

<details><summary>Skills CLI (Cursor, and other tools)</summary>

```bash
npx skills add aws/agent-toolkit-for-aws/skills --skill aws-blocks
```

</details>

<details><summary>Codex</summary>

```bash
codex plugin marketplace add aws/agent-toolkit-for-aws
```

Then launch Codex, run `/plugins`, and install the **aws-core** plugin.

</details>

For the full list of tools and setup options, see the [AWS agent toolkit](https://github.com/aws/agent-toolkit-for-aws) repository.

### Add project-level rules

Adding AWS Blocks to an existing Amplify project doesn't scaffold an `AGENTS.md` — `create-blocks-app` only generates one when you create a standalone Blocks app. So for an Amplify project, the official `aws-blocks` skill above is the simplest way to keep assistants aligned.

If you prefer file-based rules that live in your repo, add an `AGENTS.md` (or your tool's steering file — `CLAUDE.md`, `.cursor/rules/`, `.kiro/steering/`) yourself. Rather than copying a list of rules that can drift out of date as the Blocks APIs evolve, point that file at the authoritative sources — the [`aws-blocks` skill](https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/core-skills/aws-blocks) and the `AGENTS.md` that `create-blocks-app` generates for a standalone Blocks app.

## Tips for effective steering

- **Be specific about imports** — Tell the assistant which packages to import from (`@aws-amplify/backend` for backend, `aws-amplify` for frontend)
- **Document your auth model** — Describe which authorization strategies your app uses (owner-based, group-based, public)
- **Include file paths** — Reference where backend resources are defined so the assistant edits the right files
- **Keep it updated** — Update steering files when you add new Amplify features or change conventions
