fixes with skills

Author: anupras-mohapatra-arm

.github/skills/writing-style-review/SKILL.md

@@ -19,7 +19,7 @@ Use this skill for granular prose, voice, readability, terminology, and style re
 ## Voice and tone
 
 - Use second person: `you` and `your` for Learning Path summaries, Learning Path content, install guide content, answers to FAQs, and metadata descriptions. Avoid first person for these content types.
-- Use first person: `I` and `we` for FAQs.
+- Use first person: `I` for FAQ questions only.
 - Use active voice.
 - Use present tense for descriptions.
 - Use imperative mood for commands.

content/learning-paths/cross-platform/adler32/_index.md

@@ -33,7 +33,7 @@ generated_summary_faq:
     checksum project on an Arm Linux system, establish a C baseline, and measure results. First, you'll
     generate the C implementation, create a test program that validates correctness and records
     timing for multiple input sizes, and ask Copilot to produce a GCC-based Makefile tuned for
-    a Neoverse N1 target. Then, you'll to build and run the project, verify outputs, and
+    a Neoverse N1 target. Then, you'll build and run the project, verify outputs, and
     collect timing data. With a working harness and repeatable measurements, you're positioned
     to introduce Arm Neon intrinsics for the Adler32 hot path and compare behavior against the
     baseline C version.
@@ -57,8 +57,8 @@ generated_summary_faq:
       If a flag is not recognized for your CPU, adjust or remove it and rebuild.
   - question: What output should I expect when measuring performance?
     answer: >-
-      The test program measures timing around Adler32 calls on random inputs of 1 kb, 10 kb, 100
-      kb, 1 mb, and 10 mb. You should see per-size timings that you can reuse when evaluating
+      The test program measures timing around Adler32 calls on random inputs of 1 KB, 10 KB, 100
+      KB, 1 MB, and 10 MB. You should see per-size timings that you can reuse when evaluating
       a Neon-based implementation.
 # END generated_summary_faq
 
@@ -106,4 +106,3 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
-

content/learning-paths/cross-platform/automate-mcp-with-testcontainers/_index.md

@@ -38,12 +38,12 @@ generated_summary_faq:
     and execute commands inside it. Then, you'll build a minimal integration test suite for
     the Arm MCP server, focusing on JSON-RPC 2.0 communication over standard input and output.
     Finally, you'll add a GitHub Actions workflow to run the tests on every push and pull request
-    using native Arm64 runners with Docker. By the end, you'll have containerized tests that validate
+    using native arm64 runners with Docker. By the end, you'll have containerized tests that validate
     MCP server behavior locally and in continuous integration.
   faqs:
   - question: How do I know Docker is ready before running the examples?
     answer: >-
-      Run docker info and confirm it returns configuration details without errors. If it fails,
+      Run `docker info` and confirm it returns configuration details without errors. If it fails,
       start the Docker daemon and retry.
   - question: What should I expect when I run the basic Testcontainers example?
     answer: >-
@@ -56,11 +56,11 @@ generated_summary_faq:
       each test run.
   - question: Where can I find a complete reference implementation of the tests?
     answer: >-
-      A full test implementation is available in the Arm MCP repository under mcp-local/tests/.
+      A full test implementation is available in the Arm MCP repository under `mcp-local/tests/`.
       You can consult those files while building your own suite.
   - question: Which events should trigger the GitHub Actions workflow, and where is it defined?
     answer: >-
-      The workflow runs on push and pull_request and is defined at `.github/workflows/integration-tests.yml`.
+      The workflow runs on `push` and `pull_request` and is defined at `.github/workflows/integration-tests.yml`.
       GitHub’s native Arm64 runners include Docker.
 # END generated_summary_faq
 
@@ -117,4 +117,3 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
-

content/learning-paths/cross-platform/aws-greengrass-pacbti-test/_index.md

@@ -22,48 +22,50 @@ prerequisites:
 # START generated_summary_faq
 generated_summary_faq:
   template_version: summary-faq-v3
-  generated_at: '2026-07-02T17:15:02Z'
+  generated_at: '2026-07-02T19:01:20Z'
   generator: ai
   ai_assisted: true
   ai_review_required: true
   model: gpt-5
   prompt_template: summary-faq-v3
   source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
-  summary_generated_at: '2026-07-02T17:15:02Z'
+  summary_generated_at: '2026-07-02T19:01:20Z'
   summary_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
-  faq_generated_at: '2026-07-02T17:15:02Z'
+  faq_generated_at: '2026-07-02T19:01:20Z'
   faq_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
   summary: >-
-    This Learning Path guides you through registering a Raspberry Pi 5 and an NVIDIA Jetson Thor
-    as AWS IoT Greengrass core devices, building a custom component that checks for Arm Pointer
-    Authentication (PAC) and Branch Target Identification (BTI), and deploying it to both devices
-    using a Greengrass thing group. The Raspberry Pi 5 (Armv8.2-A) acts as the negative comparison
-    platform, while the Jetson Thor (Armv9-A) provides the positive case. After uploading the
-    component artifact to Amazon S3 and completing the deployment, you use MQTT to trigger the
-    checks and compare results, confirming the expected difference in PAC/BTI support.
+    You'll configure two Arm devices as AWS IoT Greengrass
+    core devices, build a custom component that checks Pointer Authentication (PAC) and Branch
+    Target Identification (BTI), and deploy that component to both targets via a Greengrass
+    thing group. You'll upload the component artifact to Amazon S3, create a Greengrass deployment
+    in the AWS console, and use MQTT to trigger the checks. The Raspberry Pi 5 (Armv8.2-A) serves
+    as a negative comparison for PAC/BTI, while the Jetson Thor (Armv9-A) provides a positive
+    control. By completing the steps, you'll compare per-device results and recognize unsupported
+    versus supported PAC/BTI behavior across Armv8 and Armv9 platforms.
   faqs:
-  - question: How do I know both devices are ready before I create the deployment?
+  - question: How do I know each device is ready to receive a Greengrass deployment?
     answer: >-
-      Check that each device is set up as an AWS IoT Greengrass core device and added to the thing
-      group you plan to target (for example, My_PAC_BTI_Test_Devices). If both appear when selecting
-      the group during deployment creation, you are ready to proceed.
-  - question: Which device should report PAC/BTI support after the test runs?
+      In AWS IoT Core, confirm the device is registered as a Greengrass core device and appears
+      in the thing group you plan to deploy to. If it is not in the group, add it before creating
+      the deployment.
+  - question: What result should I expect from the PAC/BTI test on Raspberry Pi 5 versus Jetson
+      Thor?
     answer: >-
-      Jetson Thor (Armv9-A) should report support for both PAC and BTI. Raspberry Pi 5 (Armv8.2-A)
-      should report that neither feature is supported.
-  - question: What should I check after uploading the component artifact to Amazon S3?
+      Raspberry Pi 5 (Armv8.2-A) should report PAC and BTI as not supported. Jetson Thor (Armv9-A)
+      should report both PAC and BTI as supported.
+  - question: Where should I store the custom component artifact before creating the deployment?
     answer: >-
-      Confirm the bucket exists and that the artifact file appears in the bucket. Ensure you reference
-      the correct bucket and object when creating the custom component.
-  - question: How do I trigger the PAC/BTI check once the deployment is complete?
+      Upload the component artifact to an Amazon S3 bucket created in the AWS console. Keep the
+      default bucket settings for this tutorial and ensure the artifact is available for the component
+      to use during deployment.
+  - question: Which target should I select to deploy the component to both devices at once?
     answer: >-
-      Use MQTT as described in the steps to publish the trigger for the component and then review
-      the returned messages. The results indicate PAC/BTI support for each device.
-  - question: What should I check if one device does not produce results after I publish the MQTT
-      message?
+      Select a Greengrass thing group (for example, My_PAC_BTI_Test_Devices) as the deployment
+      target. This delivers the same component set to both core devices in the group.
+  - question: How do I trigger and validate the PAC/BTI checks after deployment?
     answer: >-
-      Verify the device is in the selected thing group and that the deployment targeted that group.
-      If the device is not set up as a Greengrass core device, complete that setup and redeploy.
+      Use MQTT to trigger the checks as described in the steps, then review the results reported
+      for each device. Expect outputs that let you interpret PAC/BTI support per platform.
 # END generated_summary_faq
 
 author:
@@ -119,4 +121,3 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
-

content/learning-paths/cross-platform/build-a-reachy-robot-app-on-pi/_index.md

@@ -25,49 +25,48 @@ prerequisites:
 # START generated_summary_faq
 generated_summary_faq:
   template_version: summary-faq-v3
-  generated_at: '2026-07-02T17:15:58Z'
+  generated_at: '2026-07-02T19:04:59Z'
   generator: ai
   ai_assisted: true
   ai_review_required: true
   model: gpt-5
   prompt_template: summary-faq-v3
   source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
-  summary_generated_at: '2026-07-02T17:15:58Z'
+  summary_generated_at: '2026-07-02T19:04:59Z'
   summary_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
-  faq_generated_at: '2026-07-02T17:15:58Z'
+  faq_generated_at: '2026-07-02T19:04:59Z'
   faq_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
   summary: >-
-    This Learning Path guides you to build a distributed edge AI application where a Raspberry
-    Pi 5 performs on-device gesture recognition with MediaPipe and TensorFlow Lite and sends commands
-    to a Reachy Mini robot running in a MuJoCo simulation on a development machine. You set up
-    the Pi, enable Git LFS to retrieve the gesture model, run the app, and open a browser dashboard
-    on port 8042 to deliver thumbs-up or thumbs-down verdicts that trigger Reachy’s reactions.
-    The steps explain how the Pi connects to the robot daemon over the network and how to operate
-    the dashboard, then walk through the code structure that separates perception, logic, robot
-    motion, and static assets so you can extend or adapt the project.
+    You'll build a distributed edge AI application that runs MediaPipe
+    gesture inference on a Raspberry Pi 5 and drives a Reachy Mini robot in a MuJoCo simulation.
+    First, you'll start the simulator on a development machine, prepare the Pi with Raspberry Pi OS and
+    Git LFS so the gesture model downloads correctly, then run the app and open a browser dashboard
+    to monitor the camera feed and verdicts. A thumbs-up or thumbs-down from the webcam triggers
+    victory or defeat motions in the simulated robot. You'll also learn about the project layout
+    so you can locate perception, app logic, motion, and dashboard components in the codebase to iterate on.
   faqs:
-  - question: I cloned the project but the gesture model file is tiny—did Git LFS work?
+  - question: Which address should I open to view the dashboard?
     answer: >-
-      Verify that you installed and enabled Git LFS before cloning. Re-clone with LFS enabled
-      and check that assets/gesture_recognizer.task is a large binary file, not a small text pointer.
-  - question: The dashboard doesn’t open at http://localhost:8042—what should I try?
+      If you use VS Code Remote SSH port forwarding, open `http://localhost:8042` on your laptop.
+      Otherwise, browse to `http://<pi-ip-address>:8042` from any machine on the same network.
+  - question: How do I find the Raspberry Pi IP address for the dashboard?
     answer: >-
-      If you use VS Code Remote SSH, confirm that port forwarding is active. Otherwise, open http://<pi-ip-address>:8042
-      from a browser on the same network and make sure the app is running on the Raspberry Pi.
-  - question: How do I know the Raspberry Pi is connected to the MuJoCo simulation?
+      Run `hostname -I` on the Raspberry Pi to print its IP address. Then use that address with
+      port `8042` in your browser.
+  - question: How do I confirm the gesture model downloaded correctly with Git LFS?
     answer: >-
-      When you show a thumbs-up or thumbs-down, the simulated Reachy Mini should perform the corresponding
-      victory or defeat reaction. If nothing happens, check that both machines are on the same
-      network and that the connection settings in main.py point to the correct host.
-  - question: Can I run the Raspberry Pi headless for this app?
+      Check that `assets/gesture_recognizer.task` exists as a real model file, not a tiny pointer
+      file. If you cloned before enabling Git LFS, enable LFS and re-clone the repository.
+  - question: The dashboard loads but the MuJoCo simulation does not move—what should I check?
     answer: >-
-      Yes. Open the dashboard from another machine using the Raspberry Pi’s IP address and port
-      8042; the Pi does not need a local display.
-  - question: Where do I change gesture handling or robot moves in the code?
+      Verify the MuJoCo simulation is running on your development machine and that the Pi can
+      reach it over the network. Also review `main.py` because it contains the settings used for
+      the distributed simulation route.
+  - question: What result should I expect when a thumbs-up or thumbs-down is detected?
     answer: >-
-      Edit gesture.py to adjust recognition or mapping and moves.py to change motion routines.
-      Use main.py to wire the app and update the settings used for the distributed simulation
-      route.
+      You should see the simulated Reachy Mini play a victory or defeat motion, and the web dashboard
+      should reflect the verdict. This indicates the camera, inference, network, and simulator
+      are connected end to end.
 # END generated_summary_faq
 
 author: Matt Cossins
@@ -123,4 +122,3 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
-