Add Arm enablement custom agent prompts#110
Conversation
brikin01
left a comment
brikin01
left a comment
There was a problem hiding this comment.
Thanks for putting this together—I left a few comments, though some are minor, so please use your best judgment. I’m not an expert in this type of analysis, so happy to be corrected if I’ve misunderstood anything
| Invoke using /prompts:arm-enablement in the codex chat. | ||
| --> | ||
| --- | ||
| description: Scan an OSS codebase with Arm MCP and generate a CubeFS-style Arm enablement report as Markdown and PDF |
There was a problem hiding this comment.
Do we want to mention CubeFS-style? Reads a bit specific to me, will users know what that refers to?
|
|
||
| Steps to follow: | ||
|
|
||
| * Detect the project's primary language(s) by inspecting the codebase (`go.mod`, `package.json`, `requirements.txt`, `pom.xml`, `Cargo.toml`, `CMakeLists.txt`, source file extensions). Pick the appropriate `migrate_ease_scan` scanner: `cpp`, `python`, `go`, `js`, or `java`. |
There was a problem hiding this comment.
This line mentions Cargo.toml, which is for Rust, but migrate_ease_scan doesn't have a Rust scanner. Should we include instructions on what to do when there's an unsupported language?
| @@ -0,0 +1,107 @@ | |||
| <!-- Place this prompt file at ~/.codex/prompts/arm-enablement.md to enable it. | |||
There was a problem hiding this comment.
Custom prompt files are now deprecated for Codex and are not invokable in more recent versions of Codex CLI. Can we convert this into a skill file?
|
|
||
| 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, apx_recipe_run, 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 evaluate an open-source codebase for Arm (aarch64) readiness and generate a polished **Arm Enablement Report** in the style of the CubeFS case study, "Arm MCP Server in Action: Enabling multi-arch support for CubeFS." The report must read like a professional external case study for an OSS maintainer, developer-relations team, or CNCF community audience, not like an internal checklist. It must answer: "What is needed to make this project 100% Arm-enabled, and what did the Arm MCP Server discover that ordinary manual review could miss?" |
There was a problem hiding this comment.
Is this CubeFS case study easily findable? A quick Google search doesn't reveal a quick hit. If we reference this, maybe we include a link where we know it will be found?
| * Detect the project's primary language(s) by inspecting the codebase (`go.mod`, `package.json`, `requirements.txt`, `pom.xml`, `Cargo.toml`, `CMakeLists.txt`, source file extensions). Pick the appropriate `migrate_ease_scan` scanner: `cpp`, `python`, `go`, `js`, or `java`. | ||
| * Run `arm-mcp/migrate_ease_scan` against the workspace with the chosen scanner. If the user supplied a GitHub URL and the workspace is not the target checkout, pass the URL as `git_repo` only for the scanner call, then use the local clone for file inspection. Capture every architecture-sensitive finding (file path, line number, category, suggestion). This is the discovery phase and drives the rest of the report. | ||
| * For each Dockerfile, Compose file, and Kubernetes manifest in the repo, list every container image referenced. For each image, call `arm-mcp/check_image` to confirm `linux/arm64` is published. For images pinned by `@sha256:` digest, also call `arm-mcp/skopeo` with `raw=true` to confirm whether the digest resolves to a multi-arch manifest list or a single-arch manifest. Flag any image that is amd64-only or pinned to a single-arch digest. | ||
| * For each dependency declared in package manifests (Dockerfile `apt-get`/`yum`/`apk` lines, `requirements.txt`, `go.mod`, `package.json`, `pom.xml`), call `arm-mcp/knowledge_base_search` and explicitly ask "Is [package] compatible with Arm architecture?" where [package] is the name of the package. Record the verdict and the recommended version if a change is needed. |
There was a problem hiding this comment.
There may not be a satisfactory answer in the knowledge base for many packages, should we mention how to handle that or what should be put into the report? Also how many dependencies do these projects often have? This might be doing a lot of searches and eat up a lot of context.
| Steps to follow: | ||
|
|
||
| * Detect the project's primary language(s) by inspecting the codebase (`go.mod`, `package.json`, `requirements.txt`, `pom.xml`, `Cargo.toml`, `CMakeLists.txt`, source file extensions). Pick the appropriate `migrate_ease_scan` scanner: `cpp`, `python`, `go`, `js`, or `java`. | ||
| * Run `arm-mcp/migrate_ease_scan` against the workspace with the chosen scanner. If the user supplied a GitHub URL and the workspace is not the target checkout, pass the URL as `git_repo` only for the scanner call, then use the local clone for file inspection. Capture every architecture-sensitive finding (file path, line number, category, suggestion). This is the discovery phase and drives the rest of the report. |
There was a problem hiding this comment.
Could we clarify that git_repo is only for initial report-only scans when the current workspace is unrelated? For uncommitted changes and all --apply-fixes validation, require the target repo at /workspace and omit git_repo; otherwise the scanner might create a fresh clone that excludes local fixes and can produce false validation results.
I guess this somewhat overlaps with line 22 above, maybe we can somehow consolidate or clarify better?
| Pitfalls to avoid: | ||
|
|
||
| * Do not equate `grep -r "amd64"` results with actionable findings. `migrate_ease_scan` filters out false positives in vendored dependencies, test fixtures, and assembly files that already carry arm64 build tags. Trust the scanner over manual grep. | ||
| * Do not assume an image is multi-arch because the upstream tag has Arm64 manifests. A `@sha256:` digest pin in a Dockerfile resolves to a single platform manifest and will fail with `exec format error` on Arm hosts. Always inspect digests with `skopeo`. |
There was a problem hiding this comment.
A
@sha256:digest pin in a Dockerfile resolves to a single platform manifest
Is this true? I think maybe it can point to an image index which is multi-platform?
| * If both exporters are unavailable, do not invent a PDF. Leave `arm-enablement-report.md` complete and tell the user exactly which command to run after installing `pandoc` or Node.js. The markdown report remains the source of truth. | ||
| * After export, verify that `arm-enablement-report.pdf` exists and is non-empty. If possible, report its file size. | ||
|
|
||
| If the user has explicitly asked for changes to be applied, after the report is written: apply the fixes from the Implementation Plan in the workspace, commit each fix as a separate change for review-ability, and re-run `migrate_ease_scan` to confirm findings are resolved. If the user asked only for analysis, do not modify any source files; the report alone is the deliverable. |
There was a problem hiding this comment.
I understand applying changes, but maybe it shouldn't commit the fixes? That part should probably be left up to the user--thoughts?
2 participants
Summary
Adds an Arm enablement custom agent workflow modeled after the existing Arm migration agent, with support for both VS Code prompt files and Codex prompt files.
The new prompt evaluates OSS repositories for Arm/aarch64 readiness using Arm MCP tools, generates a maintainer-facing
arm-enablement-report.md, exports a localarm-enablement-report.pdf, and optionally applies minimal fixes when the user explicitly requests--apply-fixes.What changed
agent-integrations/vs-code/arm-enablement.prompt.mdagent-integrations/codex/arm-enablement.mdValidation
Tested locally against
etcd-io/bboltas an OSS demo repository.Generated artifacts locally:
arm-enablement-report.mdarm-enablement-report.pdfThe demo run preserved the expected findings: bbolt was assessed as ready for Arm source/build enablement,
migrate_ease_scanreported zero Go source issues forarmv8-a, no container image surface was found,linux/arm64cross-build validation passed, and benchmark/nightly workflow parity remained as the main recommendation.