tweaks to generated summaries and faqs

anupras-mohapatra-arm · anupras-mohapatra-arm · commit 21f6be4f0fd0 · 2026-06-29T13:40:32.000-05:00
diff --git a/content/learning-paths/servers-and-cloud-computing/adler32-kiro/_index.md b/content/learning-paths/servers-and-cloud-computing/adler32-kiro/_index.md
@@ -34,13 +34,13 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:15:35Z'
   faq_source_hash: 707a88ccf315ebefda3768211ac8a0ae0d142e6e28aca5597f6730b9e091d249
   summary: >-
-    In this Learning Path, you transform a scalar Adler-32 checksum in C into a vector-length-agnostic
+    You'll transform a scalar Adler-32 checksum in C into a vector-length-agnostic
     SVE implementation on Arm Neoverse servers with help from an AI coding assistant connected to
-    the Arm MCP server. You start by setting up a small project and capturing a reproducible scalar
+    the Arm MCP server. First, you'll set up a small project and capture a reproducible scalar
     baseline, then apply the `NMAX` technique to defer modulo operations and expose vectorization
-    opportunities. You learn core SVE concepts in context, including predication with `svwhilelt`,
+    opportunities. You'll learn core SVE concepts in context, including predication with `svwhilelt`,
     reductions with `svaddv` for the `a` accumulator, and building the `b` accumulator with `svdot`
-    and weighted contributions. After each stage, you validate correctness against the scalar version
+    and weighted contributions. After each stage, you'll validate correctness against the scalar version
     and measure performance changes.
   faqs:
   - question: How do I know my environment is ready to use SVE intrinsics?
diff --git a/content/learning-paths/servers-and-cloud-computing/aks/_index.md b/content/learning-paths/servers-and-cloud-computing/aks/_index.md
@@ -31,7 +31,7 @@ generated_summary_faq:
   faq_source_hash: 01c5cc8930650a8d81d67d4c48b62e0f9d7b1ebfc2d09a552e11046fb982fc52
   summary: >-
     You'll automate an Arm-based Azure Kubernetes Service (AKS) cluster deployment
-    with Terraform and then deploy a WordPress example workload. You'll start by configuring AKS to use Azure
+    with Terraform and then deploy a WordPress example workload. First, you'll configure AKS to use Azure
     Dpsv5 virtual machines based on Ampere Altra Arm processors by following Terraform-driven
     provisioning steps. After the cluster is available, you'll use a concise Kubernetes setup to run
     WordPress backed by MySQL by creating three manifests: `kustomization.yaml`, `mysql-deployment.yaml`,
diff --git a/content/learning-paths/servers-and-cloud-computing/alluxio-cobalt/_index.md b/content/learning-paths/servers-and-cloud-computing/alluxio-cobalt/_index.md
@@ -39,7 +39,7 @@ generated_summary_faq:
     VM, you'll enable the Alluxio Web UI by adding an inbound rule for TCP port 19999 in the Azure
     Network Security Group. You'll install and configure Alluxio with local storage and memory-backed
     caching, then install Apache Spark under `/opt` and configure Spark to read through Alluxio.
-    The hands-on work concludes with read workloads comparing uncached and cached access that you can use to interpret the impact of in-memory caching on analytics tasks.
+    The result is a set of read workloads comparing uncached and cached access that you can use to interpret the impact of in-memory caching on analytics tasks.
   faqs:
   - question: Which Azure VM size should I select for this setup?
     answer: >-
diff --git a/content/learning-paths/servers-and-cloud-computing/argo-cd-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/argo-cd-gcp/_index.md
@@ -37,7 +37,7 @@ generated_summary_faq:
   faq_source_hash: c6106f21859f5a8e04bbd579db47c7177bb5371d4c7f306054e56e81ed9e89a1
   summary: >-
     You'll deploy applications on Arm-based Google Kubernetes Engine using
-    GitOps with Argo CD on Google Cloud Axion C4A instances built on Arm Neoverse V2 cores. Starting
+    GitOps with Argo CD on Google Cloud C4A instances built on Arm Neoverse V2 cores. Starting
     from a SUSE Linux `arm64` VM, you'll provision an `arm64` GKE environment and install Argo CD
     using official upstream manifests. You'll configure browser and CLI access, retrieve admin credentials,
     and define a Git-backed workflow that continuously reconciles Kubernetes resources. Then, you'll deploy
@@ -53,7 +53,7 @@ generated_summary_faq:
       CD?
     answer: >-
       Confirm the current Kubernetes context points to your intended GKE cluster and namespace.
-      In the Google Cloud Console, verify the node pool uses C4A machine types to ensure you are
+      In the Google Cloud console, verify the node pool uses C4A machine types to ensure you are
       operating on Arm64 nodes.
   - question: What indicates that Argo CD installed and is accessible correctly?
     answer: >-
diff --git a/content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/_index.md b/content/learning-paths/servers-and-cloud-computing/arm-cpp-memory-model/_index.md
@@ -30,12 +30,11 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:26:18Z'
   faq_source_hash: 3a4bc8b2ab548be507b6d528844b0593b27f2dab3ab3c9649e807abdf4887ce0
   summary: >-
-    In this Learning Path, you explore the C++ memory model, see how compiler and hardware reordering
-    interact with multithreaded code, and compare Arm and x86 memory ordering. You examine atomics
+    You'll explore the C++ memory model, see how compiler and hardware reordering
+    interact with multithreaded code, and compare Arm and x86 memory ordering. First, you'll examine atomics
     and memory ordering concepts before running a small concurrent C++ example on both x86 and
-    Arm cloud instances to expose a race that can appear differently across architectures. You
-    then detect data races with ThreadSanitizer (TSan) and use its diagnostic output to guide fixes.
-    By the end, you can recognize code that relies on implicit x86 ordering and apply C++ best
+    Arm cloud instances to expose a race that can appear differently across architectures. Then, you'll detect data races with ThreadSanitizer (TSan) and use its diagnostic output to guide fixes.
+    By the end, you'll be able to recognize code that relies on implicit x86 ordering and apply C++ best
     practices to write correct, portable concurrency for Arm.
   faqs:
   - question: Do I have to use the exact instance type shown in the example?
@@ -57,7 +56,7 @@ generated_summary_faq:
       TSan builds for debugging data races, not for measuring performance.
   - question: What should I check if code that seemed correct on x86 behaves differently on Arm?
     answer: >-
-      Do not assume x86 memory ordering semantics on Arm. Revisit the code with the C++ memory
+      Don't assume x86 memory ordering semantics on Arm. Revisit the code with the C++ memory
       model in mind and use atomics and proper synchronization instead of relying on implicit
       ordering.
 # END generated_summary_faq
diff --git a/content/learning-paths/servers-and-cloud-computing/arm-mcp-server/_index.md b/content/learning-paths/servers-and-cloud-computing/arm-mcp-server/_index.md
@@ -33,12 +33,11 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:27:42Z'
   faq_source_hash: b870ac5160d35ddb51955ca8379493e172787ced8125cde8ae79f7700e653a87
   summary: >-
-    In this Learning Path, you connect an AI coding assistant to the Arm MCP Server and use its
-    Model Context Protocol capabilities to drive an x86-to-Arm migration workflow. You query Docker
-    base images with natural language to confirm `arm64` support, then configure the Arm Cloud
+    You'll connect an AI coding assistant to the Arm MCP Server and use its
+    Model Context Protocol capabilities to drive an x86-to-Arm migration workflow. First, you'll configure the Arm Cloud
     Migration Agent in GitHub Copilot to identify and refactor SIMD intrinsics from SSE/AVX to
-    Arm Neon or SVE. You review AI-generated changes and validate outcomes by building and running
-    the migrated C++ application in Docker on Arm-based systems. You also learn how to replicate
+    Arm Neon or SVE. Then, you'll review AI-generated changes and validate outcomes by building and running
+    the migrated C++ application in Docker on Arm-based systems. You'll also learn how to replicate
     the same multi-step workflow in other agentic tools using persistent, structured instructions.
   faqs:
   - question: How do I know if a Docker base image is compatible with Arm?
diff --git a/content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/_index.md b/content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/_index.md
@@ -34,12 +34,12 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:29:03Z'
   faq_source_hash: 49b3f2b1464efb20f0c8fbcff46e9f30910d856567ca01c01dc348aa1c5740d1
   summary: >-
-    In this Learning Path, you migrate a C application between Arm platforms using Kiro's Arm
-    SoC Migration Power. You install Kiro, enable the Migration Power, and run the Arm MCP server
-    as a containerized backend, then build and validate the `sensor-monitor` application on an
+    You'll migrate a C application between Arm platforms using Kiro's Arm
+    SoC Migration Power. First, you'll install Kiro, enable the Migration Power, and run the Arm MCP server
+    as a containerized backend. Then, you'll build and validate the `sensor-monitor` application on an
     AWS Graviton3 source instance. The workflow proceeds through discovery, architecture analysis,
     abstraction design, and platform-specific implementation to separate hardware-dependent code
-    behind a clear interface. You then build the migrated code for the target, such as Raspberry
+    behind a clear interface. You'll then build the migrated code for the target, such as Raspberry
     Pi 5, and validate it using the Power's testing recommendations to check functional behavior,
     platform compatibility, hardware interactions, and performance characteristics against the
     baseline.
diff --git a/content/learning-paths/servers-and-cloud-computing/arm_linux_page_size/_index.md b/content/learning-paths/servers-and-cloud-computing/arm_linux_page_size/_index.md
@@ -32,12 +32,12 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:30:49Z'
   faq_source_hash: 67004eb9a75926144eb6f75124104972b3cf20a57a22b698c9359d20db3eca02
   summary: >-
-    In this Learning Path, you evaluate and change the Linux kernel base page size on Arm, focusing
-    on installing and booting a 64K configuration. You start with page size fundamentals and a
-    quick check of the current setting using `getconf` and `uname`. OS-specific steps cover Ubuntu
+    You'll evaluate and change the Linux kernel base page size on Arm, focusing
+    on installing and booting a 64K configuration. First, you'll start with page size fundamentals and a
+    quick check of the current setting using `getconf` and `uname`. OS-specific steps include Ubuntu
     and CentOS package-based flows, while Debian requires building a 64K kernel from source using
-    the Debian source package. After reboot, you validate the change by seeing `65536` from `getconf`
-    and the expected kernel string. You also review common Arm page size options and an optional
+    the Debian source package. After reboot, you'll validate the change by seeing `65536` from `getconf`
+    and the expected kernel string. You'll also review common Arm page size options and an optional
     step to revert to the default 4K kernel after testing.
   faqs:
   - question: How do I check the current base page size and kernel in use?
@@ -51,7 +51,7 @@ generated_summary_faq:
   - question: Which distribution-specific section should I follow?
     answer: >-
       Use the Ubuntu section for Ubuntu 22.04 LTS or later, the Debian section for Debian 11 or
-      later, and the CentOS section for CentOS 9 or later. Debian does not provide a 64K kernel
+      later, and the CentOS section for CentOS 9 or later. Debian doesn't provide a 64K kernel
       package, so follow the steps to build from the Debian source package.
   - question: How do I confirm that the 64K page size is active after installation and reboot?
     answer: >-
diff --git a/content/learning-paths/servers-and-cloud-computing/arm_pmu/_index.md b/content/learning-paths/servers-and-cloud-computing/arm_pmu/_index.md
@@ -29,13 +29,13 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:33:13Z'
   faq_source_hash: 70ed68f472841d24321968188948c5c661a48445c0b07e54535d538233e048e3
   summary: >-
-    In this Learning Path, you access Arm hardware event counters and the system counter from
-    user space on Linux using the PMU. You start by distinguishing software and hardware events,
+    You'll access Arm hardware event counters and the system counter from
+    user space on Linux using the PMU. First, you'll distinguish software and hardware events,
     then use a minimal assembly approach with `MRS` and `MSR` to read the system counter and measure
-    time around a function. You then instrument event counters with PAPI, including environment
-    configuration and user-space counter access. You finish with two C examples that use
+    time around a function. You'll then instrument event counters with PAPI, including environment
+    configuration and user-space counter access. You'll finish with two C examples that use
     `perf_event_open` to read either a single counter or a group of counters without multiplexing.
-    By the end, you build and run working code that returns measurable counter values suitable
+    By the end, you'll build and run working code that returns measurable counter values suitable
     for basic performance instrumentation on Arm systems.
   faqs:
   - question: How do I know the system counter example produced a valid measurement?
diff --git a/content/learning-paths/servers-and-cloud-computing/aws-cdk/_index.md b/content/learning-paths/servers-and-cloud-computing/aws-cdk/_index.md
@@ -31,15 +31,13 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:36:00Z'
   faq_source_hash: 99f9659f6db887c7389e8cd69e67a5872d738fa72f21b9697a1abe1865808ee1
   summary: >-
-    In this Learning Path, you define and deploy a containerized application to Arm-based AWS
-    compute using the AWS Cloud Development Kit (CDK). You create a JavaScript CDK application
-    that provisions an Amazon ECS service running on Arm-based AWS Fargate. The workflow covers
-    synthesizing the application to a CloudFormation template, reviewing the generated output
-    in `cdk.out/ArmCdkAppStack.template.json`, bootstrapping the environment, and deploying the
+    You'll define and deploy a containerized application to Arm-based AWS
+    compute using the AWS Cloud Development Kit (CDK). First, you'll create a JavaScript CDK application
+    that provisions an Amazon ECS service running on Arm-based AWS Fargate. You'll then
+    synthesize the application to a CloudFormation template, review the generated output
+    in `cdk.out/ArmCdkAppStack.template.json`, bootstrap the environment, and deploy the
     stack. By following the steps, your infrastructure and service definition target Arm-based
     compute powered by AWS Graviton, using the CDK to manage application resources end-to-end.
-    The hands-on flow emphasizes building the app, translating it to infrastructure as code, and
-    deploying it with CDK conventions.
   faqs:
   - question: How do I confirm the AWS CDK CLI is installed before starting?
     answer: >-
diff --git a/content/learning-paths/servers-and-cloud-computing/aws-copilot/_index.md b/content/learning-paths/servers-and-cloud-computing/aws-copilot/_index.md
@@ -30,13 +30,12 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:37:56Z'
   faq_source_hash: ced3882cf8be11a55304d2697f450a2c862a81d87317ab42298148755e9f272c
   summary: >-
-    In this Learning Path, you package a containerized application and deploy it to AWS Fargate
-    using the AWS Copilot CLI, with a focus on targeting AWS Graviton2 processors. You containerize
-    an example app, run Copilot to initialize a Load Balanced Web Service, and see that Copilot
-    defaults to an `amd64` build. You configure Copilot for the Arm architecture so the service
-    runs on Graviton. You also use a Dockerfile to build locally or reference an
-    existing multi-architecture image and push it to Amazon ECR. By the end, you deploy the
-    service on Fargate with the architecture selection you intend to use.
+    You'll package a containerized application and deploy it to AWS Fargate
+    using the AWS Copilot CLI, with a focus on targeting AWS Graviton2 processors. First, you'll containerize
+    an example app. Then, you'll run Copilot to initialize a Load Balanced Web Service and configure Copilot for the Arm architecture so the service
+    runs on Graviton. You'll also use a Dockerfile to build locally or reference an
+    existing multi-architecture image and push it to Amazon ECR. By the end, you'll deploy the
+    service on Fargate on Arm.
   faqs:
   - question: What happens when I run the `copilot init` command shown in the steps?
     answer: >-
diff --git a/content/learning-paths/servers-and-cloud-computing/aws-terraform/_index.md b/content/learning-paths/servers-and-cloud-computing/aws-terraform/_index.md
@@ -7,7 +7,7 @@ minutes_to_complete: 60
 who_is_this_for: This is an introductory topic for software developers who are new to deploying Arm instances on AWS using Terraform.
 
 learning_objectives: 
-    - Automate AWS EC2 instance creation using Terraform
+    - Automate Amazon EC2 instance creation using Terraform
     - Deploy Arm instances on AWS and provide access via Jump Server
     - Provide infrastructure basics, code knowledge and files that could help with future learning paths
 
@@ -30,10 +30,10 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:39:51Z'
   faq_source_hash: 087a4d56914e5b53cec5ad17e8d682e72d04ba6b394237c081efe4a3f939e04e
   summary: >-
-    In this Learning Path, you define and apply Terraform automation to provision AWS Graviton
-    instances and expose secure access through a jump server, also known as a bastion host. You
+    You'll define and apply Terraform automation to provision AWS Graviton-based EC2
+    instances and expose secure access through a jump server, also known as a bastion host. First, you'll
     review the provided Terraform files, run the workflow using Terraform Cloud, and adapt the
-    configuration as needed to fit related projects. The workflow emphasizes a practical pattern:
+    configuration as needed to fit related projects. You'll learn a practical pattern:
     create Arm-based EC2 instances, place a supervised access point in front, and validate that
     the deployed nodes are reachable only through the jump server. The resulting configuration
     provides a reusable baseline for future Arm-focused work on AWS that requires one or more
diff --git a/content/learning-paths/servers-and-cloud-computing/azure-arm-template/_index.md b/content/learning-paths/servers-and-cloud-computing/azure-arm-template/_index.md
@@ -32,13 +32,13 @@ generated_summary_faq:
   faq_generated_at: '2026-06-26T17:41:45Z'
   faq_source_hash: 1682c0527bb49c417263286e2aba7c82fb9a27fa315ecc6b9ca10978b69cc236
   summary: >-
-    In this Learning Path, you build an Azure Resource Manager (ARM) template to provision a Linux
-    virtual machine on Azure Cobalt 100 Arm-based infrastructure. You define template sections
+    You'll build an Azure Resource Manager template to provision a Linux
+    virtual machine on Azure Cobalt 100 Arm-based infrastructure. First, you'll define template sections
     for parameters, variables, resources, and outputs, select an `arm64`-capable VM size from
     the Dpsv6 series in a supported region, and deploy the template with the Azure CLI into a
-    new resource group. After deployment, you retrieve the VM’s public IP, connect with SSH using
+    new resource group. After deployment, you'll retrieve the VM’s public IP, connect with SSH using
     the configured key, and validate the architecture on the instance using standard commands.
-    By the end, you have a repeatable ARM template that creates a Cobalt 100 VM and associated
+    By the end, you'll have a repeatable template that creates a Cobalt 100-based VM and associated
     networking ready for `arm64` development.
   faqs:
   - question: How do I confirm the Azure region I selected supports Cobalt 100 VM sizes?
diff --git a/content/learning-paths/servers-and-cloud-computing/azure-cobalt-cicd-aks/_index.md b/content/learning-paths/servers-and-cloud-computing/azure-cobalt-cicd-aks/_index.md
diff --git a/content/learning-paths/servers-and-cloud-computing/azure-terraform/_index.md b/content/learning-paths/servers-and-cloud-computing/azure-terraform/_index.md
diff --git a/content/learning-paths/servers-and-cloud-computing/azure-vm/_index.md b/content/learning-paths/servers-and-cloud-computing/azure-vm/_index.md
diff --git a/tools/prompts/summary_faq_system.md b/tools/prompts/summary_faq_system.md
diff --git a/tools/prompts/summary_faq_user.md b/tools/prompts/summary_faq_user.md
