Apply docs suggestions from code review

Co-authored-by: MGatner <[email protected]>

Author: lonnieezell

docs/0 - install.md

@@ -1,7 +1,6 @@
 # Installation
 
-These instructions assume that you have already [installed the CodeIgniter 4 app starter](https://codeigniter.com/user_guide/installation/installing_composer.html) as the basis for your new project, that you have setup your `.env` file and created a database, and can access
-it via the Spark CLI script.
+These instructions assume that you have already [installed the CodeIgniter 4 app starter](https://codeigniter.com/user_guide/installation/installing_composer.html) as the basis for your new project, set up your `.env` file, and created a database that you can access via the Spark CLI script.
 
 Installation is done through [Composer](https://getcomposer.org). The example assumes you have it installed globally.
 If you have it installed as a phar, or othewise you will need to adjust the way you call composer itself.

docs/1 - concepts.md

@@ -17,7 +17,7 @@ on the standard Config class if nothing is found in the database.
 
 ## User Providers
 
-You can use your own models to handle user persistence. Shield calls this class the `User Provider` class. A default model
+You can use your own models to handle user persistence. Shield calls this the "User Provider" class. A default model
 is provided for you at `CodeIgniter\Shield\Models\UserModel`. You can change this in the `Config\Auth->userProvider` setting.
 The only requirement is that your new class MUST extend the provided `UserModel`.
 
@@ -31,11 +31,10 @@ User accounts are stored separately from the information needed to identify that
 called User Identities. By default, the library has two types of identities: one for standard email/password information,
 and one for access tokens.
 
-By keeping the identity information loosely coupled from the user account itself, it frees the system up to more easily
-integrate third-party sign-in systems, JWT systems, and more, all on a single user.
+Keeping these identities loosely coupled from the user account itself facilitates integrations with third-party sign-in systems, JWT systems, and more - all on a single user.
 
 While this has the potential to make the system more complex, the `email` and `password` fields are automatically
-looked up for you when attempting to access from the User entity. Caution should be used to craft queries that will pull
+looked up for you when attempting to access them from the User entity. Caution should be used to craft queries that will pull
 in the `email` field when you need to display it to the user, as you could easily run into some n+1 slow queries otherwise.
 
 When you `save($user)` a `User` instance in the `UserModel`, the email/password identity will automatically be updated.

docs/2 - authentication.md

@@ -2,7 +2,7 @@
 
 Authentication is the process of determining that a visitor actually belongs to your website,
 and identifying them. Shield provides a flexible and secure authentication system for your
-web apps and API's.
+web apps and APIs.
 
 ## Available Authenticators
 

docs/3 - auth_actions.md

@@ -73,4 +73,4 @@ and provides feedback. In the `Email2FA` class, it verifies the code against wha
 database and either sends them back to the previous form to try again or redirects the user to the
 page that a `login` task would have redirected them to anyway.
 
-All methods should return either a `RedirectResponse` or string of a view, like through the `view()` method.
+All methods should return either a `RedirectResponse` or a view string (e.g. using the `view()` function).

docs/4 - authorization.md

@@ -74,7 +74,7 @@ public $matrix = [
 
 ## Authorizing Users
 
-When the `Authorizable` trait on the `User` entity provides the following methods to authorize your users.
+The `Authorizable` trait on the `User` entity provides the following methods to authorize your users.
 
 #### can()
 

docs/7 - customization.md

@@ -53,17 +53,17 @@ public function loginRedirect(): string
 Shield has the following controllers that can be extended to handle
 various parts of the authentication process:
 
-- **ActionController** handles the after login and after-registration actions that can be ran, like Two Factor Authentication and Email Verification.
+- **ActionController** handles the after-login and after-registration actions, like Two Factor Authentication and Email Verification.
 
 - **LoginController** handles the login process.
 
 - **RegisterController** handles the registration process. Overriding this class allows you to customize the User Provider, the User Entity, and the validation rules.
 
-- **MagicLinkController** handles the "lost password" process that allows a user to login with a link sent to their email. Allows you to
+- **MagicLinkController** handles the "lost password" process that allows a user to login with a link sent to their email. This allows you to
 override the message that is displayed to a user to describe what is happening, if you'd like to provide more information than simply swapping out the view used.
 
-It is not recommended to copy the entire controller into app and change it's namespace. Instead, you should create a new controller that extends
-the existing controller and then only override the methods needed. This allows the other methods to always stay up to date with any security
+It is not recommended to copy the entire controller into **app/Controllers** and change its namespace. Instead, you should create a new controller that extends
+the existing controller and then only override the methods needed. This allows the other methods to stay up to date with any security
 updates that might happen in the controllers.
 
 ```php