skill-based cleanup

Author: anupras-mohapatra-arm

content/learning-paths/embedded-and-microcontrollers/advanced_soc/_index.md

@@ -33,8 +33,7 @@ generated_summary_faq:
   faq_source_hash: d8c48c293b2d316d5e68e18ab9e81157ad114a64cf2efa6951374a55d25238d6
   summary: >-
     You'll design and integrate a custom AXI4-Lite peripheral
-    with the ZYNQ Processing System on a Zybo Z7-10 board. First, you'll create a clean Vivado workspace,
-    then you'll follow the **Create and Package New IP** flow to build the peripheral, and add external ports for LEDs and
+    with the ZYNQ Processing System on a Zybo Z7-10 board. First, you'll create a clean Vivado workspace. Then, you'll follow the **Create and Package New IP** flow to build the peripheral, and add external ports for LEDs and
     switches with the shown bit widths. You'll create a block design that connects the peripheral to
     the Cortex-A9–based processing system, followed by generating an HDL wrapper and a bitstream.
     Using Vitis IDE, you'll write a bare-metal C program that reads switch inputs over AXI-Lite and drives LED outputs.
@@ -48,9 +47,9 @@ generated_summary_faq:
     answer: >-
       Select **Create a new AXI4 peripheral**. This generates the template files for an AXI-compliant
       custom IP block.
-  - question: How do I know the led and sw ports are configured correctly?
+  - question: How do I know the `led` and `sw` ports are configured correctly?
     answer: >-
-      Confirm led is an output and sw is an input, each with the width shown in the steps (four
+      Confirm `led` is an output and `sw` is an input, each with the width shown in the steps (four
       bits). They should appear as external ports in the block design and connect to your custom
       peripheral.
   - question: What should I do before generating the bitstream?

content/learning-paths/embedded-and-microcontrollers/alif-image-classification/_index.md

@@ -51,20 +51,20 @@ generated_summary_faq:
       The steps assume this core for building, flashing, and running the application.
   - question: What artifacts should I expect after compiling on the Arm cloud instance?
     answer: >-
-      You should have ExecuTorch static libraries and a compiled MobileNetV2 model targeted for
+      You'll have ExecuTorch static libraries and a compiled MobileNetV2 model targeted for
       the Ethos-U85. These outputs are linked into the `mv2_runner` firmware project.
   - question: After duplicating the Blinky example, which project files need to be updated?
     answer: >-
-      Rename blinky.cproject.yml to `mv2_runner.cproject.yml` and replace internal references from
+      Rename `blinky.cproject.yml` to `mv2_runner.cproject.yml` and replace internal references from
       `blinky` to `mv2_runner`. This establishes a new CMSIS project for the application.
-  - question: Where do I place the provided main.cpp and how do I verify it works?
+  - question: Where do I place the provided `main.cpp` and how do I verify it works?
     answer: >-
       Place `main.cpp` in the `mv2_runner` project directory as instructed. When you flash and run
       the firmware, check the SEGGER RTT console for the printed classification result.
   - question: What memory changes are required for the model and runtime to fit?
     answer: >-
       Increase MRAM allocation for the embedded model (about 3.7 MB) and code (around 800 KB),
-      and provision approximately 7.6 MB of SRAM for inference buffers. Update stack/heap sizes
+      and provision approximately 7.6 MB of SRAM for inference buffers. Update stack and heap sizes,
       and the linker script in the CMSIS project accordingly.
 # END generated_summary_faq
 

content/learning-paths/embedded-and-microcontrollers/avh_greengrass/_index.md

@@ -34,7 +34,7 @@ generated_summary_faq:
     You'll use Arm Virtual Hardware (AVH) with AWS IoT Greengrass to
     deploy IoT software to a virtual Raspberry Pi 4. First, you'll start a Raspberry Pi instance in
     AVH, then use the AWS console to create and manage a Greengrass deployment that defines pre-built
-    components and their configurations. You'll walk through where to create a deployment in
+    components and their configurations. You'll learn where to create a deployment in
     AWS IoT Core and how to adjust it by adding, removing, or reconfiguring components. By the
     end, you'll create a Greengrass deployment and apply it to the virtual device so you can iterate
     on component selection and configuration using the standard Greengrass deployment workflow.
@@ -45,7 +45,7 @@ generated_summary_faq:
       Greengrass. You'll use it to apply or update components on your device.
   - question: Where do I create a Greengrass deployment in the AWS console?
     answer: >-
-      Go to **IoT Core**, then navigate to **Manage -> Greengrass devices -> Deployments** and click **Create**.
+      Go to **IoT Core**, then navigate to **Manage > Greengrass devices > Deployments** and select **Create**.
   - question: Can I change which components are in a deployment after I create it?
     answer: >-
       Yes. You can modify a deployment to change configurations, add components, or remove components.

content/learning-paths/embedded-and-microcontrollers/avh_matter/_index.md

@@ -49,7 +49,7 @@ generated_summary_faq:
     answer: >-
       The path uses the `lighting-app` example from the repository. Run it on the Arm Virtual Hardware
       instances and stop it with `Ctrl+C` when moving on to the CI/CD setup.
-  - question: Why are the existing workflows removed from .github/workflows?
+  - question: Why are the existing workflows removed from `.github/workflows`?
     answer: >-
       The upstream repository includes many workflows for different configurations. For this path,
       you'll remove them and add a single workflow so the fork builds and tests the targeted configuration

content/learning-paths/embedded-and-microcontrollers/avh_ppocr/_index.md

@@ -46,8 +46,7 @@ generated_summary_faq:
       deploy the inference model without training.
   - question: What is exported from PaddlePaddle before compilation?
     answer: >-
-      You'll export a Paddle inference model that TVMC can compile. The exact file names or directory
-      layout aren't explicitly listed.
+      You'll export a Paddle inference model that TVMC can compile.
   - question: Which target should I choose when running TVMC?
     answer: >-
       Compile the model for the Arm Corstone-300 Fixed Virtual Platform with Cortex-M55 processors.

content/learning-paths/embedded-and-microcontrollers/avh_vio/_index.md

@@ -43,7 +43,7 @@ generated_summary_faq:
       the example peripheral.
   - question: What do I need to install to run the example’s Python UI?
     answer: >-
-      We install the Tkinter package for Python in the AVH terminal with: `sudo apt install -y
+      Install the Tkinter package for Python in the AVH terminal with: `sudo apt install -y
       python3-tk`.
   - question: Where is the LED example located after I clone the repository?
     answer: >-

content/learning-paths/embedded-and-microcontrollers/cloud-native-deployment-on-hybrid-edge-systems/_index.md

@@ -53,7 +53,7 @@ generated_summary_faq:
       pull the image before running it with containerd.
   - question: Which container runtime does K3s use in this setup?
     answer: >-
-      K3s is configured to use containerd via the container-runtime-endpoint flag set to `unix://var/run/containerd/containerd.sock`
+      K3s is configured to use `containerd` via the `container-runtime-endpoint ` flag set to `unix://var/run/containerd/containerd.sock`
       in the provided install command.
   - question: How long should the K3s installation take, and what should I do next?
     answer: >-

content/learning-paths/embedded-and-microcontrollers/cmsis_rtx/_index.md

@@ -48,13 +48,13 @@ generated_summary_faq:
       threads.
   - question: How many threads does the example create and where are they started?
     answer: >-
-      The example starts three threads from app_main using osThreadNew(). The number and names
+      The example starts three threads from `app_main` using `osThreadNew()`. The number and names
       are arbitrary and serve to illustrate basic thread creation.
   - question: What steps build and run the project in Keil MDK, and what should I monitor during
       execution?
     answer: >-
-      Save all files, click Build (F7), then Debug (Ctrl+F5) to launch the FVP. Open the RTX RTOS
-      view and the **Serial Windows > Debug (printf)** window, click Run (F5), and observe thread
+      Save all files, click Build (`F7`), then Debug (`Ctrl+F5`) to launch the FVP. Open the RTX RTOS
+      view and the **Serial Windows > Debug (printf)** window, click Run (`F5`), and observe thread
       activity and output before stopping.
   - question: When should I use Event Recorder and how do I route STDOUT to it?
     answer: >-

content/learning-paths/embedded-and-microcontrollers/cmsis_rtx_vs/_index.md

@@ -31,13 +31,13 @@ generated_summary_faq:
   faq_generated_at: '2026-07-08T15:27:34Z'
   faq_source_hash: 989064eaa54dfab7f135038e3c3f0bfa932ba95512ca1dcdc36c034edf731445
   summary: >-
-    This Learning Path guides learners through creating, configuring, and debugging an RTX5-based
-    application in Keil Studio for VS Code using the CMSIS-RTOS2 API. You create a CMSIS Solution
+    You'll create, configure, and debug an RTX5-based
+    application in Keil Studio for VS Code using the CMSIS-RTOS2 API. First, you'll create a CMSIS Solution
     project, select required components in the **Run-Time Environment**, and add system startup so
     RTX5 can initialize the SysTick timer with `SystemCoreClockUpdate()` before starting the scheduler.
-    The path implements an `app_main` thread that launches multiple worker threads, then builds
+    Then, you'll implement an `app_main` thread that launches multiple worker threads and builds
     the project using the CMSIS extension. Using the Cortex-M4 Fixed Virtual Platform as the target,
-    learners run and step through the program and verify execution by observing periodic thread
+    you'll run and step through the program and verify execution by observing periodic thread
     messages printed in the **Debug Console**.
   faqs:
   - question: Which target should I use if I don’t have hardware available?
@@ -46,12 +46,12 @@ generated_summary_faq:
       applies to other devices supported by CMSIS-Pack.
   - question: How do I start a debug session in Keil Studio for VS Code?
     answer: >-
-      Click the **Debug** icon or open the **Run and Debug** view, then choose the configured debug connection
+      Select the **Debug** icon or open the **Run and Debug** view, then choose the configured debug connection
       to launch the FVP. Use the standard debugging controls to step through your code.
   - question: How do I know the RTOS is running correctly?
     answer: >-
-      After initialization, the Debug Console displays messages from your threads. Look for output
-      similar to: “[model] hello from thread 1/2/3”.
+      After initialization, the **Debug Console** displays messages from your threads. Look for output
+      similar to: `[model] hello from thread 1/2/3`.
   - question: Where do main.c and app_main.c come from?
     answer: >-
       `main.c` is created automatically in the Source Files group when you set up the CMSIS Solution

content/learning-paths/embedded-and-microcontrollers/deploy-ml-model-to-npu-with-topo/_index.md

@@ -50,7 +50,7 @@ generated_summary_faq:
   faqs:
   - question: How do I confirm the FRDM i.MX 93 target is ready before deploying?
     answer: >-
-      Run topo health --target <user>@<target-ip>. The host and target sections should show successful
+      Run `topo health --target <user>@<target-ip>`. The host and target sections should show successful
       checks for SSH and the container engine, and the target should also report Remoteproc Runtime
       and Remoteproc as healthy.
   - question: Which components run on Cortex-A and Cortex-M33, and how do they communicate?
@@ -69,9 +69,9 @@ generated_summary_faq:
       repository, make it a normal Compose project, then add Topo metadata and Remoteproc Runtime
       services. The Template is bootstrapped from Compose services, Remoteproc Runtime metadata,
       and Topo arguments.
-  - question: What should I check if topo health reports a failure?
+  - question: What should I check if `topo health` reports a failure?
     answer: >-
-      Resolve the specific errors shown by topo health before continuing. Confirm SSH access to
+      Resolve the specific errors shown by `topo health` before continuing. Confirm SSH access to
       the target, verify the container engine is available on both host and target, and ensure
       Remoteproc Runtime is present on the target.
 # END generated_summary_faq