registry: add Arm software tools

[annietllnd]

Will review with Zach before merging

[zachlasiuk]

Notes from initial review before our face to face discussion:

PR #3 Review Notes

Running notes for: #3

Overall feedback

The context-first structure is sound and should support efficient retrieval by
agents. However, it is difficult for a human reviewer to see all newly added
resources together because the same entries are repeated across several context
files. It would be helpful to provide a generated, consolidated view for review
purposes while retaining the context-first files as the agent-facing source.

The proposed context YAML files also need discussion with STE before launch so
we can confirm which developer personas and contexts to prioritize. We can
refine the taxonomy in a fast follow, but the initial set should be reasonably
aligned with Arm's priority target audiences. Developer Marketing and the UX
Research team may be the best groups to consult because they are likely to own
or maintain our developer personas.

Suggested changes

• Consider generating a consolidated view of all unique resources so reviewers
  can evaluate additions without scrolling through repeated entries in every
  context file.

• Validate the initial developer contexts and personas with STE, Developer
  Marketing, and/or UX Research before launch.

• Revise the Arm MCP Server wording wherever it appears so it does not frame the
  resource specifically for cloud developers. The containing context YAML file
  already establishes the relevant persona or vertical. For example, an entry
  in compiled-languages.yaml should be assumed to be useful in that context;
  its when_to_use text and example should focus on the resource's applicable
  tasks and capabilities rather than repeating or introducing a different
  vertical.

• Consider making this a general writing rule: entries should not repeat the
  persona or vertical represented by their parent file. This will keep
  when_to_use descriptions concise and prevent context-specific wording from
  becoming misleading when an identical resource entry appears in multiple
  files.

• Test the value and token cost of the category metadata, ideally with Kavya,
  across the models we expect to use. The original design grouped resources
  under category subheadings within each YAML file, which may be easier for an
  agent to scan and avoids repeating the same field on every entry. We should
  compare that structure with the current per-resource category field and
  confirm whether the repeated metadata materially improves search, filtering,
  or resource selection.

• Consider removing mcp-servers as a separate category and placing MCP servers
  under sdks-tools. This may be a better logical fit, and Arm is unlikely to
  have enough MCP servers to justify a dedicated category.

• Consider combining learning-paths with knowledge-bases. Learning Paths are
  another form of developer knowledge resource, and a separate category may not
  add enough retrieval value to justify the additional taxonomy.

• Consider separating software and libraries from developer tools rather than
  grouping both under sdks-tools. Both sets are likely to grow substantially,
  and distinct categories would make the registry easier to scan and maintain.

Candidate resources to add

Knowledge bases

• Arm Architecture Reference Manuals — expand coverage beyond A-profile to all
  relevant architecture profiles.
• Arm Developer: Laptops and Desktops
  — likely positioned as Windows on Arm content.
• SOAFEE and/or
  Project Cassini.

SDKs and tools

• Arm Development Studio
• Arm Keil MDK
• Arm Keil Studio
• CMSIS
• Arm Performance Studio
• WindowsPerf
• Rename or broaden “KleidiAI” to “Kleidi Libraries” to represent the wider
  Kleidi portfolio.
• Arm Software Developers on GitHub — a
  general pointer for useful Arm projects that are not listed individually.

Questions

• Which team owns the authoritative developer personas we want this registry to
  support at launch?

• Should the contribution guidance explicitly say that when_to_use and
  example_use_case should avoid naming a vertical already represented by the
  parent context file?

• Does listing category inside every resource provide measurable retrieval
  value to an agent, or would grouping resources under category headings be
  equally effective and more token-efficient?

• Do we intend to support firmware developers, whose work is lower-level than
  the software and application developers currently emphasized? If so, that
  substantially expands the relevant resource set—for example Trusted
  Firmware, OP-TEE, U-Boot, PSA Certified, and Parsec—and may require another
  pass over the taxonomy and launch scope.

• Should the registry extend beyond resources delivered directly by Arm to
  include highly useful upstream and third-party resources in the Arm
  ecosystem, such as GCC and related toolchains? If so, what inclusion and
  curation criteria should distinguish essential ecosystem resources from an
  unmanageably broad catalog?

• Is the ExecuTorch Arm Backend entry necessary as a standalone resource? It
  lives in the main ExecuTorch repository and appears to be included with
  ExecuTorch by default. If users receive it as part of ExecuTorch rather than
  installing or consuming it separately, a dedicated registry entry may be
  redundant.

What looks good

• The context-first organization is a strong fit for efficient, task-relevant
  agent retrieval.