Kiro and Cursor Rules: Move Instructions Between Editors
Kiro and Cursor both use file-based instruction documents to guide their AI, but the formats, locations, and scope mechanisms differ. Here is how to translate project guidance between them, and what belongs in neither.
Updated 7 min read
Kiro and Cursor are both AI-assisted coding editors that read project-level instruction documents before they act. When you move between them — or use both on the same project — you need to translate the instructions each editor reads. The format is different, the file location is different, and the way instructions are scoped to specific files differs too.
The work itself should not move with the editor. Projects, decisions, task history, and where you left off belong in fenbs outside either tool, so the next session — whether in Kiro, Cursor, or something else — starts from the same record rather than an editor-specific copy.
How Kiro and Cursor handle project instructions
| Cursor | Kiro | |
|---|---|---|
| Instruction file location | .cursor/rules/ directory or .cursorrules at the root | .kiro/steering/ directory |
| File format | Markdown (.mdc) with optional YAML frontmatter | Markdown with YAML frontmatter |
| Global instructions | Settings > Rules for AI or ~/.cursor/rules/ | Steering documents can be marked as always-included |
| File-scoped instructions | globs field in frontmatter targets specific paths | inclusion field in frontmatter controls when a doc is loaded |
| Instructions for agentic tasks | Rules files apply throughout agentic sessions | Spec documents define requirements for agentic task flows |
| What they do not store | Decisions, history, lessons, where you left off | Decisions, history, lessons, where you left off |
| fenbs | Connects over MCP; rules files and fenbs context work together | Connects over MCP; steering docs and fenbs context work together |
Cursor rules: format and scope
Cursor rules live in .cursor/rules/ as Markdown files with a .mdc extension. Each file can have a YAML frontmatter block that sets a description and a globs field: a pattern that controls which files trigger that rule. A rule with globs: "**/*.test.ts" is only loaded when the assistant is working on test files. A rule with no globs is always loaded.
The .cursorrules file at the project root is the older format: a single plain-text file loaded for every session. Both formats are supported. The .cursor/rules/ approach is more flexible for large projects where different parts of the codebase have different conventions.
Kiro steering documents: format and scope
Kiro steering documents live in .kiro/steering/ as Markdown files with YAML frontmatter. Each document has an inclusion field that controls when it is loaded: always means it is included in every session, fileMatch means it is included when the assistant is working on matching files, and manual means it is only loaded when explicitly referenced.
Kiro also uses spec documents for agentic task flows: structured requirement documents that describe what a feature should do before the agent starts implementing it. These are separate from steering documents and serve a different purpose. See what is Kiro for a fuller introduction to how the editor approaches AI-assisted development.
Translating instructions between the two editors
When moving from Cursor to Kiro (or back), the core content of your instructions usually translates directly: build commands, naming conventions, what the AI may not do. The main work is adapting the format and scope mechanism.
# Cursor format (.cursor/rules/testing.mdc) --- description: Test conventions for this project globs: "**/*.test.ts,**/*.spec.ts" --- ## Testing rules - Use Vitest for unit tests. - Run tests with: pnpm test - Do not mock modules that are simple pure functions. --- # Kiro format (.kiro/steering/testing.md) --- inclusion: fileMatch fileMatch: ["**/*.test.ts", "**/*.spec.ts"] --- ## Testing rules - Use Vitest for unit tests. - Run tests with: pnpm test - Do not mock modules that are simple pure functions.
The rule content is identical. The difference is in the frontmatter syntax and where the file lives. Write a script or use your editor's search-and-replace to convert the frontmatter when you need to work in both tools. The body of each rule file needs no changes.
Keep the work outside both editors
Connect both Kiro and Cursor to fenbs over MCP. The project context, Decisions and rules, Where we left off, and task history stay in fenbs and are available to whichever editor you open next. Switching tools does not mean starting the project explanation over again.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
What belongs in neither rules file
Both Cursor rules and Kiro steering documents are the right place for code conventions: commands, naming patterns, file restrictions. They are the wrong place for the reasoning behind those conventions, decisions that have changed over time, or progress on the current task.
Those belong in fenbs. A Cursor rule that says "use Vitest for unit tests" is clear. The Decision in fenbs that says "switched from Jest to Vitest in September because of Vite compatibility — do not switch back without checking the build pipeline" is what makes that rule intelligible six months later.
Decisions about architecture — why the project uses a monorepo, why a particular data fetching pattern was standardized, which parts of the codebase are actively being refactored — change over time and belong in fenbs, not in a rules file committed to version control where they accumulate without clear ownership.
Record the reasons behind your rules in fenbs
Add the reasoning behind each major coding convention to fenbs as a Decision. When you update a rule — new test runner, different naming pattern, changed branch policy — record a new Decision alongside it. Every connected assistant reads the current decisions before it acts, in any editor that supports MCP.
This is especially useful when a team uses different editors. One developer using Cursor and another using Kiro will have different rule files, but both connect to the same fenbs project. The Decisions they both read are the canonical answer to "why does this convention exist?" — not the comment in a rules file that one editor's developer may never see.
Who should use which editor
Cursor is a mature AI coding editor with a large user base, extensive rules documentation, and broad MCP support. It suits developers who want a well-documented, stable environment with strong community resources. The Cursor alternatives guide compares it to other tools if you are still deciding.
Kiro is an AWS-backed editor with a stronger emphasis on structured agentic workflows through spec documents. It suits developers who want a more opinionated approach to AI-assisted features, where a feature is specified before it is built. If your team already lives in the AWS ecosystem, Kiro may feel more natural.
Using both is a reasonable choice. Different projects may suit different tools, and some teams have developers who prefer different editors. The key is making sure the shared project context lives outside both, so switching does not cost you the work history.
How to do this with fenbs
- Create a free account and add your project to fenbs. Write the shared project context as Decisions and rules: the conventions that should apply regardless of which editor someone uses.
- Connect Cursor to fenbs from Integrations. Connect Kiro to fenbs from the same page using the MCP connection. Both editors can read the same project context.
- Keep editor-specific rules (Cursor format, Kiro format) in their respective directories. Keep the reasoning behind those rules in fenbs Decisions.
- When switching editors, translate the frontmatter format. The rule body and the fenbs Decisions both work without changes in either editor.
What to watch for
The most common mistake when running both editors on the same project is letting the rules files diverge. If you update the Cursor rule and not the Kiro steering document, a developer using Kiro gets outdated instructions. Treat both files as configuration that must be kept in sync, or consolidate the shared content in fenbs and keep the editor-specific files as thin wrappers.