docs: fix typos and grammar errors across documentation

erkamyaman · atscott · commit 4739bde9fb6c · 2026-04-08T09:40:47.000-07:00
Fix various typos, misspellings, and grammar issues across contributing
docs, adev content guides, and agent skills documentation.

- "an minimum" → "a minimum" (CONTRIBUTING.md)
- "GitHub accounts" → "GitHub account" (CONTRIBUTING.md)
- "decendants" → "descendants" (components/styling.md)
- "templates are using" → "templates is using" (hydration.md)
- "A automated" → "An automated" (branches-and-versioning.md)
- "Github" → "GitHub" (branches-and-versioning.md, commit-message-guidelines.md)
- "practices makes" → "practice makes" (caretaking.md)
- "corresponds" → "correspond" (triage-and-labelling.md)
- "one a line" → "a line" (documentation-authoring.md)
- "straight forward" → "straightforward" (using-fixup-commits.md)
- "or you decide" → "or you can decide" (anatomy-of-components.md)
- "whenver" → "whenever" (angular-new-app/SKILL.md)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -71,7 +71,7 @@ You can file new issues by selecting from our [new issue templates](https://gith
 
 ### <a name="pr-quality"></a> Contribution Quality
 
-We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have an minimum set of expectations that are required of any community contribution pull request that is opened.
+We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have a minimum set of expectations that are required of any community contribution pull request that is opened.
 
 1. Search [GitHub](https://github.com/angular/angular/pulls) for an open or closed PR that relates to your submission.
    - You don't want to duplicate existing efforts.
@@ -238,7 +238,7 @@ changes to be accepted, the CLA must be signed. It's a quick process, we promise
 - For corporations, we'll need you to
   [print, sign and one of scan+email, fax or mail the form][corporate-cla].
 
-If you have more than one GitHub accounts, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
+If you have more than one GitHub account, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
 
 The following documents can help you sort out issues with GitHub accounts and multiple email addresses:
 
diff --git a/adev/src/content/guide/components/anatomy-of-components.md b/adev/src/content/guide/components/anatomy-of-components.md
@@ -51,7 +51,7 @@ You can alternatively choose to write your template and styles in separate files
 export class ProfilePhoto {}
 ```
 
-This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you decide which to use for each component.
+This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you can decide which to use for each component.
 
 Both `templateUrl` and `styleUrl` are relative to the directory in which the component resides.
 
diff --git a/adev/src/content/guide/components/styling.md b/adev/src/content/guide/components/styling.md
@@ -94,7 +94,7 @@ For example:
 
   So, in effect, the `<a>` element may be in the component's template, or in any of its projected or child content.
 
-- With `:host ::ng-deep p a`, both the `<a>` and `<p>` elements must be decendants of the component's host element.
+- With `:host ::ng-deep p a`, both the `<a>` and `<p>` elements must be descendants of the component's host element.
 
   They can come from the component's template or the views of its child components, but not elsewhere in the app.
 
diff --git a/adev/src/content/guide/hydration.md b/adev/src/content/guide/hydration.md
@@ -142,7 +142,7 @@ Providing a custom or a "noop" Zone.js implementation may lead to a different ti
 
 ## Errors
 
-There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates are using valid structure, and you'll avoid that error case.
+There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates is using valid structure, and you'll avoid that error case.
 
 For a full reference on hydration related errors, visit the [Errors Reference Guide](/errors).
 
diff --git a/contributing-docs/branches-and-versioning.md b/contributing-docs/branches-and-versioning.md
@@ -102,14 +102,14 @@ major version.
 
 Two additional target labels do not map to specific versions while still defining which branch to merge into.
 
-| Label              | Description                                           |
-| ------------------ | ----------------------------------------------------- |
-| target: automation | A automated change made by the angular-robot account. |
-| target: feature    | A change to be made in a feature branch.              |
+| Label              | Description                                            |
+| ------------------ | ------------------------------------------------------ |
+| target: automation | An automated change made by the angular-robot account. |
+| target: feature    | A change to be made in a feature branch.               |
 
 Changes made to a feature branch, outside of our typical branching and merging process utilize the
 `target: feature` branch. Additionally, the `target: automation` label, which is only able to be
-utilized by the `angular-robot` account targets only the branch defined within the Github UI.
+utilized by the `angular-robot` account targets only the branch defined within the GitHub UI.
 
 ### Pull request examples
 
diff --git a/contributing-docs/caretaking.md b/contributing-docs/caretaking.md
@@ -26,7 +26,7 @@ pnpm ng-dev pr merge <pr number>
 Some directories in the Angular codebase have additional protections or rules. For example, code
 under `//packages/core/primitives` must be merged and synced into Google separately from other
 changes. Attempting to combine changes in `primitives` with other changes results in an error. This
-practices makes it significantly easier to rollback or revert changes in the event of a breakage or
+practice makes it significantly easier to rollback or revert changes in the event of a breakage or
 outage.
 
 ## PRs that require global presubmits
diff --git a/contributing-docs/commit-message-guidelines.md b/contributing-docs/commit-message-guidelines.md
@@ -45,7 +45,7 @@ Must be one of the following:
 | Type         | Description                                                                                         |
 | ------------ | --------------------------------------------------------------------------------------------------- |
 | **build**    | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
-| **ci**       | Changes to our CI configuration files and scripts (examples: Github Actions, SauceLabs)             |
+| **ci**       | Changes to our CI configuration files and scripts (examples: GitHub Actions, SauceLabs)             |
 | **docs**     | Documentation only changes                                                                          |
 | **feat**     | A new feature                                                                                       |
 | **fix**      | A bug fix                                                                                           |
diff --git a/contributing-docs/documentation-authoring.md b/contributing-docs/documentation-authoring.md
@@ -94,7 +94,7 @@ because they are _very_ common.
   - Use callouts for a brief aside that offers more context on a topic that's not strictly
     necessary to understanding the main content
   - Never put multiple callouts next to each other or in proximity (such as separated
-    by one a line or two of text)
+    by a line or two of text)
   - Never put a callout inside another element, such as a card or table cell
 - **Alerts**
   - Use sparingly to call attention to a very brief but relevant point
diff --git a/contributing-docs/triage-and-labelling.md b/contributing-docs/triage-and-labelling.md
@@ -9,7 +9,7 @@ The owner of the component is then responsible for the detailed / component-leve
 ### Areas
 
 The caretaker should be able to determine the _area_ for incoming issues.
-Most areas generally corresponds to a specific directory or set of directories in this repo. Some
+Most areas generally correspond to a specific directory or set of directories in this repo. Some
 areas are more cross-cutting (e.g. for performance or security). Apply all labels that make sense
 for an issue. Each `area: ` label on GitHub should have a description of what it's for.
 
diff --git a/contributing-docs/using-fixup-commits.md b/contributing-docs/using-fixup-commits.md
@@ -51,7 +51,7 @@ However, amending an existing commit with the changes makes it difficult for the
 exactly what has changed since the last time they reviewed the Pull Request.
 
 Here is where fixup commits come in handy.
-By addressing review feedback in fixup commits, you make it very straight forward for the reviewer
+By addressing review feedback in fixup commits, you make it very straightforward for the reviewer
 to see what are the new changes that need to be reviewed and verify that their earlier feedback has
 been addressed.
 This can save a lot of effort, especially on larger Pull Requests (where having to re-review _all_
