diff --git a/content/ci/actions.md b/content/ci/actions.md
index 30fc6ba..c5c12c6 100644
--- a/content/ci/actions.md
+++ b/content/ci/actions.md
@@ -78,7 +78,7 @@ Forgejo Runner is released in both binary and container image (OCI) forms:
 
 Before you deploy the Runner, you need to generate its configuration files and modify as suited.
 
-You can generate them to your current directory by either running the binary on host or in a Docker container.
+You can generate them in your current directory by either running the binary on host or in a Docker container.
 
 Make sure to replace `{TOKEN}` with the registration token you copied, and `{NAME}` with any identifier to monitor it
 on Codeberg.
diff --git a/content/ci/agents.md b/content/ci/agents.md
index a12ad4b..5c600f9 100644
--- a/content/ci/agents.md
+++ b/content/ci/agents.md
@@ -7,7 +7,7 @@ eleventyNavigation:
 
 Codeberg's CI resources are run by volunteers, and as such have some limitations in terms of shared resources. However, it is not necessary to self-host and administer your own full CI instance as you can add your own Woodpecker agents to your user or organization.
 
-Some example use-cases where a self-hosted agent are recommended include: when you want faster feedback from CI, to handle long-running or resource-intensive jobs, creating specialized environments for specific architectures, hardware-in-the-loop testing, or setting up larger networked integration tests.
+Some example use-cases where a self-hosted agent is recommended include: when you want faster feedback from CI, to handle long-running or resource-intensive jobs, creating specialized environments for specific architectures, hardware-in-the-loop testing, or setting up larger networked integration tests.
 
 This guide will walk you through [setting up your own Woodpecker agent](https://woodpecker-ci.org/docs/administration/configuration/agent) to communicate with Codeberg's CI infrastructure and configuring your workflows to use it.
 
@@ -145,7 +145,7 @@ steps:
 
 You can also add labels to the agent's configuration that can be used in workflows. Labels are key-value maps assigned to specific agents by using the `WOODPECKER_AGENT_LABELS` variable.
 
-For example, say you're creating an IoT project that needs a machine with a specific peripheral, such as a LoRa radio, for testing. You have an agent that has the module attached and you need a way to tell Woodpecker to use that particular machine. [Radio hardware often depends on what part of the world you're in,](https://en.wikipedia.org/wiki/ITU_Region) you also want specify where your agent is located.
+For example, say you're creating an IoT project that needs a machine with a specific peripheral, such as a LoRa radio, for testing. You have an agent that has the module attached and you need a way to tell Woodpecker to use that particular machine. [Radio hardware often depends on what part of the world you're in,](https://en.wikipedia.org/wiki/ITU_Region) you also want to specify where your agent is located.
 
 Here is how to add the necessary environment variable to [an agent's docker compose script](#creating-an-agent-with-docker-compose) to label it in ITU Region 1 (Europe is in Region 1) with a lora module attached:
 
diff --git a/content/ci/index.md b/content/ci/index.md
index 8a5ef32..723e849 100644
--- a/content/ci/index.md
+++ b/content/ci/index.md
@@ -35,12 +35,11 @@ Repositories owned by your codeberg account should automatically be available as
 For the usage of our Woodpecker instance, keep the following in mind:
 
 - **CI access is provided as-is and might break at any time** and for an undefined period of time, due to server issues,
-  for testing and maintenance purpose or human error.
+  for testing and maintenance purposes or human error.
 - **Resource usage must be reasonable** for the intended use-case. CI requires substantial computing resources
   (cloning the repo and pulling the image, installing required tools, building and throwing everything away).
-  Please try to ensure a good balance between code quality/automation and resource usage.
   Therefore, please consider twice how to create a good balance between ensuring code quality for your project and
-  resource usage therefore.
+  resource usage.
 - The CI service requires manual onboarding and Woodpecker has limited Role-Based Access Control (RBAC) capabilities,
   which will be a problem for projects with a team-based permission structure or many individual collaborators.
 - `linux/amd64` is the sole build target on the Woodpecker CI deployment.