summaries and faqs tuning

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md

@@ -33,10 +33,10 @@ generated_summary_faq:
   faq_source_hash: 39f9323dac9bd7f5480e501ad8fd93d2d9999c420ed1c2eb45eba2ccb3be63ad
   summary: >-
     You'll learn how to tune NGINX on Arm-based platforms using a measurement-first
-    workflow. First, you'll establish a baseline, then iteratively adjust Linux network stack parameters and
+    workflow. Using a baseline, you'll iteratively adjust Linux network stack parameters and
     evaluate compiler and library choices such as OpenSSL, PCRE, and zlib. You'll review tuned configuration examples and guidance for sizing directives to refine configurations
-    for static file serving, reverse proxy, and API gateway scenarios. You're also introduced to `wrk`
-    as an option for generating traffic and reporting throughput and latency on NGINX. By the end, you'll use `wrk` to compare before-and-after results and verify the impact of each change.
+    for static file serving, reverse proxy, and API gateway scenarios. You'll also learn about `wrk`
+    as an option for generating traffic and reporting throughput and latency on NGINX. By the end, you'll use `wrk` to compare before-and-after results and verify the impact of each tuning change.
   faqs:
   - question: How do I know whether a tuning change improved performance?
     answer: >-
@@ -51,7 +51,7 @@ generated_summary_faq:
   - question: Do I need to use wrk if I already have a load test?
     answer: >-
       No. If you already have a repeatable HTTP workload, use that. wrk is provided as a starting point
-      only when you do not already have an established test method.
+      only when you don't already have an established test method.
   - question: When tuning the reverse proxy or API gateway, what should I reuse from the static
       file server configuration?
     answer: >-

tools/prompts/summary_faq_system.md

@@ -6,7 +6,7 @@ Authoring rules:
 - Use only the supplied context. Do not invent products, prerequisites, tools, claims, performance numbers, compatibility details, or outcomes.
 - Treat the supplied Learning Path as the source of truth. If a detail is not present, either omit it or state that it is not explicitly listed.
 - Preserve the intent of the Learning Path author. Do not rewrite the path into a different task, audience, platform, toolchain, or level of difficulty.
-- Follow the supplied authoring guidance from `.github/skills/writing-style-review` and `content/learning-paths/cross-platform/_example-learning-path/`.
+- Follow the supplied authoring guidance from `.github/skills/writing-style-review/SKILL.md` and `content/learning-paths/cross-platform/_example-learning-path/`.
 - Treat existing page fields and sections as already visible to the learner. Do not repeat information that is already covered by the title, description, objectives, "What will you learn?", prerequisites, tool/install lists, or setup sections.
 - Use prerequisites, objectives, tags, and metadata only to understand the path and avoid contradictions. Do not restate prerequisites in the summary or FAQ unless the question addresses a specific action or blocker that occurs while following the steps.
 - Prefer concrete verbs such as install, configure, build, deploy, benchmark, profile, debug, validate, or compare when those actions are supported by the context.

tools/prompts/summary_faq_user.md

@@ -6,7 +6,7 @@ Important: the generated block appears on the same page as the existing Learning
 
 Assume these rules while writing:
 - Use only the Learning Path context below. Do not add facts, tools, commands, prerequisites, performance claims, compatibility claims, or outcomes that are not present.
-- Write as an Arm Learning Path author by following the supplied guidance from `.github/skills/writing-style-review` and `content/learning-paths/cross-platform/_example-learning-path/`.
+- Write as an Arm Learning Path author by following the supplied guidance from `.github/skills/writing-style-review/SKILL.md` and `content/learning-paths/cross-platform/_example-learning-path/`.
 - Keep the content useful for human review. The draft should be specific enough to evaluate, but not so detailed that it replaces the Learning Path steps.
 - If the context is thin, be honest and stay high-level rather than filling gaps.
 - Match the complexity of the Learning Path. Introductory paths should stay approachable; advanced paths can use more precise technical language from the context.