Apply suggestions from code review

config/hero.yaml

@@ -21,9 +21,8 @@ shortcuts:
       text: Contribute to the project
   - title: Want to adopt AEPs in your organization?
     description: |
-      AEPs were adapted from [Google's AIP project](https://google.aip.dev/), but also extend it with
-      tooling to easily generate and validate that result in better designed APIs, as well as provide clients to 
-      consume them.
+      AEPs were adapted from [Google's AIP project](https://google.aip.dev/), but also enhanced with improved
+      guidance for APIs, tooling to generate and validate them, and clients to interact with them. The result is better designed and consumable APIs.
     button:
       href: /adopting
       text: Learn more

pages/general/adopting.md

@@ -1,16 +1,25 @@
 # Adopting AEPs for your company
 
-By adopting the guidelines from the API Enhancement Proposals, you establish a much 
-tighter and efficient possibility space. APIs that follow the 
+By adopting the guidelines from the API Enhancement Proposals, you establish a
+much tighter and efficient possibility space. APIs that follow the
 [AEP guidance](https://aep.dev) from the design stage:
 
-- are more consistent  within and across teams, reducing cognitive load for API consumers
-- reduce arguments  about API design decisions, thanks to the AEP specification, tools, and exemplar design patterns
+- are more consistent within and across teams, reducing cognitive load for API
+  consumers
+- reduce arguments about API design decisions, thanks to the AEP specification,
+  tools, and exemplar design patterns
 
-Having an AEP-compliant API also means benefitting from the AEP ecosystem of tooling, such as:
+Having an AEP-compliant API also means benefitting from the AEP ecosystem of
+tooling, such as:
 
-- Linters and validators to ensure adherence to the AEP design specification [proto]()/[openapi]()
-- A command line tool interface genreator that make it easier to work with APIs ([aepcli](https://github.com/aep-dev/aepcli))
-- Client-side and server-side code generators ([aepc](https://github.com/aep-dev/aepc))
-- A Terraform provider ([terraform-provider-aep](https://github.com/aep-dev/terraform-provider-aep))
-- ... and more! Please start a [discussion](https://github.com/aep-dev/aep.dev/discussions) if there is something you wish to see, validate, or prioritize.
+- Linters and validators to ensure adherence to the AEP design specification
+  [proto]()/[openapi]()
+- A dynamic command line interface generator that make it easier to work with
+  APIs ([aepcli](https://github.com/aep-dev/aepcli))
+- Client-side and server-side code generators
+  ([aepc](https://github.com/aep-dev/aepc))
+- A Terraform provider
+  ([terraform-provider-aep](https://github.com/aep-dev/terraform-provider-aep))
+- ... and more! Please start a
+  [discussion](https://github.com/aep-dev/aep.dev/discussions) if there is
+  something you wish to see, validate, or prioritize.

pages/general/faq.md

@@ -2,21 +2,21 @@
 
 ## What are the differences between AEPs and AIPs?
 
-If you are familiar with Google's API Improvement Proposals 
-[google.aip.dev](https://google.aip.dev), then much of the 
+If you are familiar with Google's API Improvement Proposals
+[google.aip.dev](https://google.aip.dev), then much of the
 [API Enhancement Proposals](https://aep.dev) content will be familiar.
 
 However, AEPs have notable philosophical differences, including:
 
-- AEPs prioritize broadly applicable design guidance for any company, while AIPs
-  prioritized design guidance specifically for Google (e.g., providing
+- AEPs prioritize broadly applicable design guidance for any company, while
+  AIPs prioritized design guidance specifically for Google (e.g., providing
   backwards-compatibility with prior decisions to meet Google-specific needs).
 - AEPs are protocol-agonistic and consider both gRPC and HTTP+JSON as
   first-class protocols for which examples and other content are necessary.
-- AEPs focuses on a core specification that is not intended to be forked, paired with a 
-  mechanism for optional organization-specific guidance to extend the
-  specification. AIPs encourage forking its guidance outright.
+- AEPs focuses on a core specification that is not intended to be forked,
+  paired with a mechanism for optional organization-specific guidance to extend
+  the specification. AIPs encourage forking its guidance outright.
 
 AEPs also have the advantage of hindsight, which makes it possible in some
-cases to provide better guidance. (One small example:
-renaming `page_size` to `max_page_size` for requests to paginated API methods.)
+cases to provide better guidance. (One small example: renaming `page_size` to
+`max_page_size` for requests to paginated API methods.)