skill-based updates

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/2-environment-setup.md

@@ -79,4 +79,4 @@ The `docker exec` command should print `CREATE EXTENSION`. If it prints `NOTICE:
 
 You've set up an Arm-based environment by creating a Microsoft Azure VM powered by Cobalt 100 and installing the toolchain necessary for migration. 
 
-Next, you'll create a reproducable baseline to use for benchmarking.
+Next, you'll create a reproducible baseline to use for benchmarking.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/3-checkout-build-baseline.md

@@ -1,12 +1,12 @@
 ---
-title: Create an Arm baseline before optimization
+title: Create a nopCommerce endpoint benchmark baseline on Arm
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Build and baseline
+## Build nopCommerce and create an endpoint baseline
 
 Create a reproducible Arm baseline before optimization work. 
 
@@ -80,7 +80,7 @@ curl -s -o /dev/null -w 'install=%{http_code}\n' http://127.0.0.1:5000/install
 
 The outputs after a successful install should be: `root=200`, `install=302`.
 
-### Run the baseline
+### Run the endpoint baseline benchmark
 
 Don't benchmark `/install`. Baseline stable storefront paths first, then add cart and attribute-change routes only after you know the valid product IDs, attribute IDs, request method, and anti-forgery token behavior for your installed store.
 
@@ -235,6 +235,6 @@ This baseline process becomes the control for every later tuning or code-change
 
 You've now created a baseline before migrating the application. 
 
-Next, you'll make note of dependencies before migration. 
+Next, you'll audit dependencies before migration. 
 
 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/4-dependency-mapping-manifests.md

@@ -1,5 +1,5 @@
 ---
-title: Run dependency discovery before migration
+title: Generate an SBOM and run .NET dependency discovery before migration
 weight: 4
 
 ### FIXED, DO NOT MODIFY
@@ -28,7 +28,7 @@ dotnet list src/Presentation/Nop.Web/Nop.Web.csproj package --include-transitive
 
 ### Generate an SBOM
 
-Generate an SBOM so you can track all components, versions, and exposure surface as a first-class migration artifact. While not strictly necessary for migration purposes, this is a best practice that will save your team time down the road. You can also give this SBOM to an LLM to extract insights about your codebase for you.
+Generate an SBOM so you can track all components, versions, and exposure surface as a first-class migration artifact. While not strictly necessary for migration purposes, this is a best practice that'll save time. You can also give this SBOM to an LLM to extract insights about your codebase.
 
 The CycloneDX tool is installed as a .NET global tool. Add `~/.dotnet/tools` to `PATH` in the current shell so the `dotnet-CycloneDX` command is available immediately after installation.
 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/5-containerization.md

@@ -1,12 +1,12 @@
 ---
-title: Choose between options to containerize the application
+title: Choose a containerization path for the nopCommerce application
 weight: 5
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Containerize the application
+## Containerize and migrate the application
 
 Containerization should preserve reproducibility across architectures. The following are practical paths for Dockerfile-based builds and .NET SDK container publish, with guardrails for multi-architecture delivery.
 
@@ -16,7 +16,7 @@ Use the Dockerfile workflow as the default migration path for nopCommerce until
 
 Run a Dockerfile build with `buildx` from the repository root when you want to preserve the upstream nopCommerce Dockerfile behavior. This is the safest first containerization path because the Dockerfile installs runtime packages used by nopCommerce on Linux, including globalization and image-processing dependencies.
 
-Before you push a multi-architecture image, make sure `buildx` is available, you are logged in to your registry, and your builder can build both requested platforms. If `docker buildx version` fails, install the Docker Buildx plugin for your Docker package before continuing. On an Arm-only VM, the `linux/amd64` build requires emulation or an additional x64 builder node.
+Before you push a multi-architecture image, make sure `buildx` is available, you're logged in to your registry, and your builder can build both requested platforms. If `docker buildx version` fails, install the Docker Buildx plugin for your Docker package before continuing. On an Arm-only VM, the `linux/amd64` build requires emulation or an additional x64 builder node.
 
 ```bash
 docker buildx version
@@ -36,9 +36,9 @@ docker buildx imagetools inspect "$IMAGE"
 
 ### Single architecture .NET SDK publish path
 
-Use SDK publish when you want tighter integration with .NET build settings and fewer custom Docker steps. For nopCommerce, treat this as a validation path until you have confirmed that the generated image includes the Linux native packages your store needs. SDK publish creates the container image, but it does not run `apk add` or `apt-get install` steps like a Dockerfile does.
+Use SDK publish when you want tighter integration with .NET build settings and fewer custom Docker steps. For nopCommerce, treat this as a validation path until you have confirmed that the generated image includes the Linux native packages your store needs. SDK publish creates the container image, but it doesn't run `apk add` or `apt-get install` steps the way a Dockerfile does.
 
-This command publishes an Arm64 image into the local Docker daemon with an explicit repository, tag, and container runtime identifier:
+This command publishes an arm64 image into the local Docker daemon with an explicit repository, tag, and container runtime identifier:
 
 ```bash
 dotnet publish src/Presentation/Nop.Web/Nop.Web.csproj \
@@ -88,13 +88,13 @@ Before choosing the SDK publish path for multi-architecture images, check the SD
 dotnet --version
 ```
 
-If you can't use a .NET SDK version that supports multi-RID container publishing, or if SDK publish does not produce the multi-architecture image index you need, use the `docker buildx build --platform linux/amd64,linux/arm64` workflow instead. 
+If you can't use a .NET SDK version that supports multi-RID container publishing, or if SDK publish doesn't produce the multi-architecture image index you need, use the `docker buildx build --platform linux/amd64,linux/arm64` workflow instead. 
 
 Multi-RID container publishing starts with .NET SDK versions `8.0.405`, `9.0.102`, and `9.0.2xx`. The nopCommerce `release-4.90.3` source pins SDK `9.0.100` in `global.json` with feature-band roll-forward, so confirm the actual SDK selected by CI is new enough before relying on SDK multi-arch publish.
 
 
 ## What you've accomplished and what's next
 
-You've learned about different containerization paths for the .NET application and containerized the app. 
+You've learned about different containerization paths for the .NET application. 
 
 Next, you'll tune application performance. 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/6-deploy-verify-cobalt.md

@@ -14,7 +14,9 @@ Treat tuning as an experiment pipeline, not a one-shot tweak. On Arm, apply chan
 
 Start with a conservative runtime profile that is commonly effective for server workloads. Keep these settings outside the application code at first so you can switch profiles without rebuilding.
 
-Runtime environment variables are read when the .NET process starts. Stop the baseline `dotnet run` process, set the variables in the same terminal, and then restart nopCommerce. The thread-pool minimum below matches the 2-vCPU validation VM; treat it as a starting point, not a universal value for every Cobalt size.
+Runtime environment variables are read when the .NET process starts. Stop the baseline `dotnet run` process, set the variables in the same terminal, and then restart nopCommerce. 
+
+The following thread-pool minimum matches the 2-vCPU validation VM. Treat it as a starting point, not a universal value for every Cobalt size:
 
 ```bash
 export DOTNET_TieredCompilation=1
@@ -86,7 +88,7 @@ Use these rules before adopting a tuning profile:
 
 ### Considerations for interpreting metric improvements
 
-When interpeting metric improvements, consider the following:
+When interpreting metric improvements, consider the following:
 
 - If only one metric improves while p95 or error rate regresses, don't treat the change as a win.
 - If run-to-run variation is near the observed delta, treat it as noise.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/7-arm-mcp-server.md

@@ -80,8 +80,8 @@ Implement the following guardrails when using the Arm MCP Server for optimizatio
 - Ask the agent to separate observed facts from inferred explanations.
 - Re-run on production-like traffic before release.
 
-## What you've accomplished
+## What you've learned
 
-You've used the Arm MCP Server to optimize a .NET nopCommerce application migrated to Arm. 
+You've learned how to use the Arm MCP Server to optimize a .NET nopCommerce application migrated to Arm. 
 
 You can use the workflows in this Learning Path as a template for your own applications, then validate with your production-like traffic profile before rollout.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/_index.md

@@ -1,9 +1,9 @@
 ---
-title: Migrate a .NET nopCommerce application to Azure Cobalt 100
+title: Migrate and optimize a .NET nopCommerce application on Microsoft Azure
 
 minutes_to_complete: 75
 
-who_is_this_for: This Learning Path is for .NET and platform engineers migrating a production .NET application to Arm on Azure.
+who_is_this_for: This Learning Path is for .NET and platform engineers migrating a production .NET application to Arm-based infrastructure on Azure.
 
 learning_objectives:
     - Build a pinned nopCommerce release and baseline on Arm with the same .NET toolchain
@@ -13,7 +13,7 @@ learning_objectives:
     - Use the Arm MCP Server to automate endpoint selection, test generation, and optimization planning
 
 prerequisites:
-    - Azure account with permissions to create VMs
+    - Azure account with permissions to create virtual machines
     - Azure CLI (`az`) installed locally
     - Docker and .NET 9 SDK familiarity
     - Basic Linux command-line knowledge