Entry pages and workflow examples use direct prose

README.md

@@ -1,6 +1,6 @@
 # Process-PSModule
 
-Process-PSModule is the corner-stone of the PSModule framework — an end-to-end GitHub Actions workflow that builds, tests, versions, documents, and publishes PowerShell modules to the PowerShell Gallery.
+Process-PSModule is the core workflow of the PSModule framework. This end-to-end GitHub Actions workflow builds, tests, versions, documents, and publishes PowerShell modules to the PowerShell Gallery.
 
 Documentation site generation is powered by Zensical. Repositories define site configuration in `zensical.toml`.
 

docs/content/guides/configuring-the-pipeline.md

@@ -14,7 +14,7 @@ This page shows the common changes. For the complete list of settings and their
 
 ## Example 1 - Defaults with Code Coverage target
 
-This example runs all steps and will require that code coverage is 80% before passing.
+This example runs all steps and requires at least 80% code coverage to pass.
 
 ```yaml
 Test:

docs/content/guides/versioning-and-releases.md

@@ -19,7 +19,7 @@ the configured default branch.
 
 Test and lint stages run before the publish gates, and publish is blocked when required checks fail.
 
-An open labelled pull request can publish a prerelease. A closed pull request only cleans up its prereleases. When a
+An open labeled pull request can publish a prerelease. A closed pull request only cleans up its prereleases. When a
 pull request merges, the resulting push to the default branch resolves that pull request's labels and creates the
 stable release from the exact pushed commit.
 
@@ -55,7 +55,7 @@ short-lived pull requests targeting `main`.
 
 ## Prereleases
 
-A pull request labelled `Prerelease` publishes a prerelease version (for example `v1.2.3-pr.1.5`) that is installable
+A pull request labeled `Prerelease` publishes a prerelease version (for example `v1.2.3-pr.1.5`) that is installable
 but not promoted as latest. When that pull request is merged with a version label, the stable version is computed from
 the label and the current version on `main`.
 

docs/content/index.md

@@ -15,7 +15,7 @@ default-branch push is the sole authority for a stable release. When that push i
 request, its labels and release notes supply the release metadata. See the
 [scenario matrix](reference/scenario-matrix.md) for the resulting job execution.
 
-Everything is packaged into a single reusable workflow so that a module repository only needs a small caller workflow and one settings file. A user configures the behaviour by editing `.github/PSModule.yml`.
+Everything is packaged into a single reusable workflow so that a module repository only needs a small caller workflow and one settings file. A user configures the behavior by editing `.github/PSModule.yml`.
 
 ![Process diagram](media/Process-PSModule.png)
 
@@ -77,16 +77,16 @@ The requirements and architecture behind the pipeline. Primarily for those maint
 
 ## A GitHub & PowerShell development framework
 
-PSModule **infuses GitHub with PowerShell** and brings more to the PowerShell ecosystem by using the GitHub platform to its fullest extent.
-The framework is two things in one: a collection of reusable PowerShell modules, and a set of GitHub Actions workflows that automate the full PowerShell module (software) delivery lifecycle — the DevOps functionality that the ecosystem is missing.
+The PSModule framework has reusable PowerShell modules and GitHub Actions workflows.
+The workflows automate the PowerShell module delivery lifecycle.
 
-We empower PowerShell-savvy developers to effortlessly transform their ideas into impactful solutions, automating the repetitive tasks so developers — whether consumers or contributors — can concentrate on coding without distractions.
+The framework automates repeated tasks so developers can write code for their PowerShell solutions. This applies to both consumers and contributors.
 
-Where we are headed is tracked as [objectives and initiatives](https://msx.no/docs/Ways-of-Working/Goal-Setting/).
+See [objectives and initiatives](https://msx.no/docs/Ways-of-Working/Goal-Setting/) for the goal-setting model.
 
 ## Cross-org guidance
 
-Cross-org standards and reusable solution documentation are now canonical in [MSXOrg/docs](https://msx.no/docs/):
+Cross-org standards and reusable solution documentation are canonical in [MSXOrg/docs](https://msx.no/docs/):
 
 - [Coding Standards](https://msx.no/docs/Coding-Standards/)
 - [Capabilities](https://msx.no/docs/Capabilities/)