Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
73c0e10
Add Arm migration prompt file for VS Code agent
jaidev17 Feb 2, 2026
db98d40
Add arm-migration.md prompt file for codex
jaidev17 Feb 2, 2026
36c48f4
Add kiro arm migration prompt file
jaidev17 Feb 3, 2026
6afb82a
Add cursor arm migration command file
jaidev17 Feb 4, 2026
1520887
Add windsurf arm migration prompt file
jaidev17 Feb 5, 2026
f9c18e2
Add Windsurf arm-migration workflow prompt file
jaidev17 Feb 9, 2026
598f4a3
Rename folder from agent-specific-prompt-files to agent-integrations
jaidev17 Feb 10, 2026
79e502b
Add antigravity arm-migration documentation
jaidev17 Feb 11, 2026
0f47859
Update antigravity arm-migration documentation
jaidev17 Feb 11, 2026
855dd9e
adding slash command file (toml) for gemini cli
jaidev17 Feb 13, 2026
363285e
Codex - Add instructions on how to install Arm MCP server, if it is a…
jaidev17 Feb 13, 2026
c687a9b
Fixing formatting issues in prompt files.
jaidev17 Feb 18, 2026
016cc21
adding agent install instructions markdown file and edit codex prompt…
jaidev17 Mar 9, 2026
a103d92
fixing typos; syntax for json and toml
jaidev17 Mar 11, 2026
a01275c
adding json comment
jaidev17 Mar 11, 2026
97df715
Apply suggestions from code review
jaidev17 Mar 11, 2026
1e5244c
add missing data to kiro prompt files
jaidev17 Mar 11, 2026
ed4f774
add new line at end
jaidev17 Mar 11, 2026
4c07a8e
Apply suggestions from code review
jaidev17 Mar 11, 2026
c003410
pull latest docker image
jaidev17 Mar 11, 2026
99b9598
Add arm-mcp verification to agent prompts
jaidev17 Mar 12, 2026
3e1e01e
Update agent-integrations/windsurf/arm-migration.md
jaidev17 Mar 12, 2026
47f5eb0
Update agent-integrations/vs-code/arm-migration.prompt.md
jaidev17 Mar 12, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions agent-integrations/agent-install-instructions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Arm MCP Server Installation

Search online for the latest MCP configuration instructions for your agent, then configure the Arm MCP server using the Docker image.
Comment thread
jaidev17 marked this conversation as resolved.

Pull the Docker image:

```
docker pull armlimited/arm-mcp:latest
```
Comment thread
jaidev17 marked this conversation as resolved.

Use the following command and args in your MCP configuration (adjusting the format as required by your agent):

For JSON-based configurations:

```json
{
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--pull=always",
"-v", "/path/to/your/workspace:/workspace",
"--name", "arm-mcp",
"armlimited/arm-mcp:latest"
]
Comment thread
jaidev17 marked this conversation as resolved.
}
```

For TOML-based configurations:

```toml
[mcp_servers."arm-mcp"]
type = "stdio"
command = "docker"
args = [
"run",
"--rm",
"-i",
"--pull=always",
"-v",
"/path/to/your/workspace:/workspace",
Comment thread
jaidev17 marked this conversation as resolved.
"--name",
"arm-mcp",
"armlimited/arm-mcp:latest",
]
```

Replace `/path/to/your/workspace` with the absolute path to the project you want to migrate.
31 changes: 31 additions & 0 deletions agent-integrations/antigravity/arm-migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
<!--
Place this file at .agent/workflows/arm-migration.md in your workspace.
Invoke using /arm-migration
-->
---
description: Scan a project and migrate to Arm architecture
---

Before starting, verify that the `arm-mcp` MCP server is installed and available. If you don't have access to the arm-mcp tools (skopeo, check_image, knowledge_base_search, migrate_ease_scan, mca, sysreport_instructions), refer to the [MCP Server Installation Guide](https://github.com/arm/mcp/blob/main/agent-integrations/agent-install-instructions.md) to install it on antigravity.

Your goal is to migrate a codebase from x86 to Arm. Use the mcp server tools to help you with this. Check for x86-specific dependencies (such as build flags, intrinsics, and libraries) and change them to Arm architecture equivalents, ensuring compatibility and optimizing performance. Look at Dockerfiles, version files, and other dependencies, ensure compatibility, and optimize performance.

# Steps
Comment thread
jaidev17 marked this conversation as resolved.
* Look in all Dockerfiles and use the check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary.
* Look at the packages installed by the Dockerfile and send each package to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the contents of any requirements.txt files line-by-line and send each line to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the codebase that you have access to, and determine what the language used is.
* Run the migrate_ease_scan tool on the codebase, using the appropriate language scanner based on what language the codebase uses, and apply the suggested changes. Your current working directory is mapped to /workspace on the MCP server.
* OPTIONAL: If you have access to build tools, rebuild the project for Arm, if you're running on an Arm-based runner. Fix any compilation errors.
* OPTIONAL: If you have access to any benchmarks or integration tests for the codebase, run these and report the timing improvements to the user.

# Pitfalls to avoid

* Don't confuse a software version with a language wrapper package version. For example, when checking the Python Redis client, check the Python package name "redis" rather than the Redis server version. Setting the Python Redis package version to the Redis server version in requirements.txt will fail.
* NEON lane indices must be compile-time constants, not variables.
* If you're unsure about Arm equivalents, use knowledge_base_search to find documentation.
* Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.

If you have good versions to update for the Dockerfile, requirements.txt, and other files, change them immediately without asking for confirmation.

Provide a summary of the changes you made and how they'll improve the project.
30 changes: 30 additions & 0 deletions agent-integrations/codex/arm-migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
<!-- Place this prompt file at ~/.codex/prompts/arm-migration.md to enable it.
Invoke using /prompts:arm-migration in the codex chat.
-->
---
description: Scan a project and migrate to Arm architecture
---

Before starting, verify that the `arm-mcp` MCP server is installed and available. If you don't have access to the arm-mcp tools (skopeo, check_image, knowledge_base_search, migrate_ease_scan, mca, sysreport_instructions), refer to the [MCP Server Installation Guide](https://github.com/arm/mcp/blob/main/agent-integrations/agent-install-instructions.md) to install it on codex.

Your goal is to migrate a codebase from x86 to Arm. Use the mcp server tools to help you with this. Check for x86-specific dependencies (such as build flags, intrinsics, and libraries) and change them to Arm architecture equivalents, ensuring compatibility and optimizing performance. Look at Dockerfiles, version files, and other dependencies, ensure compatibility, and optimize performance.

Steps to follow:
* Look in all Dockerfiles and use the check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary.
* Look at the packages installed by the Dockerfile and send each package to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the contents of any requirements.txt files line-by-line and send each line to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the codebase that you have access to, and determine what the language used is.
* Run the migrate_ease_scan tool on the codebase, using the appropriate language scanner based on what language the codebase uses, and apply the suggested changes. Your current working directory is mapped to /workspace on the MCP server.
* OPTIONAL: If you have access to build tools, rebuild the project for Arm, if you're running on an Arm-based runner. Fix any compilation errors.
* OPTIONAL: If you have access to any benchmarks or integration tests for the codebase, run these and report the timing improvements to the user.

Pitfalls to avoid:

* Don't confuse a software version with a language wrapper package version. For example, when checking the Python Redis client, check the Python package name "redis" rather than the Redis server version. Setting the Python Redis package version to the Redis server version in requirements.txt will fail.
* NEON lane indices must be compile-time constants, not variables.
* If you're unsure about Arm equivalents, use knowledge_base_search to find documentation.
* Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.

If you have good versions to update for the Dockerfile, requirements.txt, and other files, change them immediately without asking for confirmation.

Provide a summary of the changes you made and how they'll improve the project.
28 changes: 28 additions & 0 deletions agent-integrations/cursor/arm-migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<!--
Place this file at .cursor/commands/arm-migration.md in your workspace
Invoke in chat: /arm-migration
-->

Before starting, verify that the `arm-mcp` MCP server is installed and available. If you don't have access to the arm-mcp tools (skopeo, check_image, knowledge_base_search, migrate_ease_scan, mca, sysreport_instructions), refer to the [MCP Server Installation Guide](https://github.com/arm/mcp/blob/main/agent-integrations/agent-install-instructions.md) to install it on cursor.

Your goal is to migrate a codebase from x86 to Arm. Use the mcp server tools to help you with this. Check for x86-specific dependencies (such as build flags, intrinsics, and libraries) and change them to Arm architecture equivalents, ensuring compatibility and optimizing performance. Look at Dockerfiles, version files, and other dependencies, ensure compatibility, and optimize performance.

Steps to follow:
* Look in all Dockerfiles and use the check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary.
* Look at the packages installed by the Dockerfile and send each package to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the contents of any requirements.txt files line-by-line and send each line to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the codebase that you have access to, and determine what the language used is.
* Run the migrate_ease_scan tool on the codebase, using the appropriate language scanner based on what language the codebase uses, and apply the suggested changes. Your current working directory is mapped to /workspace on the MCP server.
* OPTIONAL: If you have access to build tools, rebuild the project for Arm, if you're running on an Arm-based runner. Fix any compilation errors.
* OPTIONAL: If you have access to any benchmarks or integration tests for the codebase, run these and report the timing improvements to the user.

Pitfalls to avoid:

* Don't confuse a software version with a language wrapper package version. For example, when checking the Python Redis client, check the Python package name "redis" rather than the Redis server version. Setting the Python Redis package version to the Redis server version in requirements.txt will fail.
* NEON lane indices must be compile-time constants, not variables.
* If you're unsure about Arm equivalents, use knowledge_base_search to find documentation.
* Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.

If you have good versions to update for the Dockerfile, requirements.txt, and other files, change them immediately without asking for confirmation.

Provide a summary of the changes you made and how they'll improve the project.
36 changes: 36 additions & 0 deletions agent-integrations/gemini/arm-migration.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# Gemini CLI Custom Slash Command: /arm-migration
#
# Location: Place this file in your project's .gemini/commands/ directory
# For project-scoped: <project>/.gemini/commands/arm-migration.toml
# For user-scoped: ~/.gemini/commands/arm-migration.toml
#
# Usage: Run the command in Gemini CLI by typing:
# /arm-migration

description = "Migrates a codebase from x86 to Arm architecture with compatibility checks and optimizations."

prompt = """
Before starting, verify that the `arm-mcp` MCP server is installed and available. If you don't have access to the arm-mcp tools (skopeo, check_image, knowledge_base_search, migrate_ease_scan, mca, sysreport_instructions), refer to the [MCP Server Installation Guide](https://github.com/arm/mcp/blob/main/agent-integrations/agent-install-instructions.md) to install it on gemini.

Your goal is to migrate a codebase from x86 to Arm. Use the mcp server tools to help you with this. Check for x86-specific dependencies (such as build flags, intrinsics, and libraries) and change them to Arm architecture equivalents, ensuring compatibility and optimizing performance. Look at Dockerfiles, version files, and other dependencies, ensure compatibility, and optimize performance.

Steps to follow:
* Look in all Dockerfiles and use the check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary.
* Look at the packages installed by the Dockerfile and send each package to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the contents of any requirements.txt files line-by-line and send each line to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the codebase that you have access to, and determine what the language used is.
* Run the migrate_ease_scan tool on the codebase, using the appropriate language scanner based on what language the codebase uses, and apply the suggested changes. Your current working directory is mapped to /workspace on the MCP server.
* OPTIONAL: If you have access to build tools, rebuild the project for Arm, if you're running on an Arm-based runner. Fix any compilation errors.
* OPTIONAL: If you have access to any benchmarks or integration tests for the codebase, run these and report the timing improvements to the user.

Pitfalls to avoid:

* Don't confuse a software version with a language wrapper package version. For example, when checking the Python Redis client, check the Python package name "redis" rather than the Redis server version. Setting the Python Redis package version to the Redis server version in requirements.txt will fail.
* NEON lane indices must be compile-time constants, not variables.
* If you're unsure about Arm equivalents, use knowledge_base_search to find documentation.
* Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.

If you have good versions to update for the Dockerfile, requirements.txt, and other files, change them immediately without asking for confirmation.

Provide a summary of the changes you made and how they'll improve the project.
"""
31 changes: 31 additions & 0 deletions agent-integrations/kiro/arm-migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
<!--
Place this file at .kiro/steering/arm-migration.md in your workspace.
Invoke using #arm-migration
-->
---
inclusion: always
---

Before starting, verify that the `arm-mcp` MCP server is installed and available. If you don't have access to the arm-mcp tools (skopeo, check_image, knowledge_base_search, migrate_ease_scan, mca, sysreport_instructions), refer to the [MCP Server Installation Guide](https://github.com/arm/mcp/blob/main/agent-integrations/agent-install-instructions.md) to install it on kiro.

Your goal is to migrate a codebase from x86 to Arm. Use the MCP server tools to help you with this. Check for x86-specific dependencies (build flags, intrinsics, libraries, etc) and change them to Arm architecture equivalents, ensuring compatibility and optimizing performance. Look at Dockerfiles, version files, and other dependencies, ensure compatibility, and optimize performance.

Steps to follow:
* Look in all Dockerfiles and use the check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary.
* Look at the packages installed by the Dockerfile and send each package to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the contents of any requirements.txt files line-by-line and send each line to the knowledge_base_search tool to check each package for Arm compatibility. If a package isn't compatible, change it to a compatible version. When invoking the tool, explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package.
* Look at the codebase that you have access to, and determine what the language used is.
* Run the migrate_ease_scan tool on the codebase, using the appropriate language scanner based on what language the codebase uses, and apply the suggested changes. Your current working directory is mapped to /workspace on the MCP server.
* OPTIONAL: If you have access to build tools, rebuild the project for Arm, if you're running on an Arm-based runner. Fix any compilation errors.
* OPTIONAL: If you have access to any benchmarks or integration tests for the codebase, run these and report the timing improvements to the user.

Pitfalls to avoid:

* Don't confuse a software version with a language wrapper package version. For example, when checking the Python Redis client, check the Python package name "redis" rather than the Redis server version. Setting the Python Redis package version to the Redis server version in requirements.txt will fail.
* NEON lane indices must be compile-time constants, not variables.
* If you're unsure about Arm equivalents, use knowledge_base_search to find documentation.
* Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.

If you have good versions to update for the Dockerfile, requirements.txt, and other files, change them immediately without asking for confirmation.

Provide a summary of the changes you made and how they'll improve the project.
Loading
Loading