Merge pull request #13 from harker-c/patch-15

Update pakman.md

src/content/docs/build/pakman.md

@@ -5,10 +5,10 @@ description: PAKman is a build system for building packages for your application
 
 PAKman is a build system for building packages for your application. It's a simple way to build packages for your application and deploy them to your infrastructure.
 
-We recommend using the build pack selection from the UI to generate the bulk of the configuration but having an understanding of the generated file is also important.
+We recommend using the build pack selection from the UI to generate the bulk of the configuration, but having an understanding of the generated file is also important.
 
 :::note[PAKman is Open Sourced]
-PAKman is open sourced and available on [GitHub](https://github.com/upmaru/pakman). Feel free to let us know if you have any suggestions.
+PAKman is open sourced and available on [GitHub](https://github.com/upmaru/pakman). Feel free to let us know if you have any feedback or suggestions.
 
 There is also a [blog post](https://zacksiri.dev/posts/why-i-created-pakman) by the author (who also happens to be one of the founders of OpsMaru) about how all this works.
 :::
@@ -50,13 +50,13 @@ dependencies:
 
 ### Stack
 
-The stack is where you choose which version of alpine you use. Stacks are similar to heroku's stack. The only difference is heroku's stack is based on ubuntu. 
+The stack is where you choose which version of alpine you use. Stacks are similar to Heroku's stack. The only difference is Heroku's stack is based on ubuntu. 
 
 ```yaml title="instellar.yml"
 stack: alpine/3.18
 ```
 
-Each stack has different version of dependencies. You can choose which stack to use depending on which version of your dependency you wish to use.
+Each stack has a different version of dependencies. You can choose which stack to use depending on which version of your dependency you wish to use.
 
 ![setup repository](../../../assets/build/runtime-versions.png)
 
@@ -86,11 +86,11 @@ The destinations directive tells the build system that the files in the destinat
 
 Hooks are commands that are run at different stages of the installation process. There are 4 main stages in the lifecycle.
 
-+ post-install - These commands run after the package is installed, in the example below we add the app `devspace` to the default application to run when the OS starts. That way if we restart the container the application automatically starts. We also run `rc-service devspace migrate`. This basically runs database migration.
++ post-install - These commands run after the package is installed. In the example below, we add the app `devspace` to the default application to run when the OS starts. That way if we restart the container the application automatically starts. We also run `rc-service devspace migrate`. This basically runs database migration.
 
 + pre-upgrade - These commands run before upgrade. In this case we stop the application before the upgrade.
 
-+ post-upgrade - These commands run after the package is upgraded. In this case we want to run migrations and then start the new upgraded version of the app.
++ post-upgrade - These commands run after the package is upgraded. In this case we want to run migrations and then start the new, upgraded version of the app.
 
 + post-deinstall - These commands run after the package is removed. Generally it is not used since we just delete the container and provision a new one if something goes wrong.
 
@@ -112,11 +112,11 @@ hook:
 
 ### Run
 
-The `run` section describes how the application runs. It provides commands that tell the system how to run the application. In the example below you will see the `commands` sectiona nd the `services` section.
+The `run` section describes how the application runs. It provides commands that tell the system how to run the application. In the example below, you will see the `commands` section and the `services` section.
 
 + services - These are commands that start the service of your application. In the example below we're starting a rails application by calling the `rails` binary followed with the `server` which essentially becomes `rails server`. In this case we also have a background worker called `good-job`. The below configuration essentially runs `bundle exec good_job start`
 
-+ commands - These are commands that run as one time and are not long lived processes. For example you can access the rails console by running `rc-service devspace console` or access the logs by using `rc-service devspace logs`.
++ commands - These are commands that run one time and are not long lived processes. For example you can access the rails console by running `rc-service devspace console` or access the logs by using `rc-service devspace logs`.
 
 Doing things this way enables us to `normalize` the experience. No matter what language or framework you use, you can use `rc-service [app-name] [command]` to run the commands you need.
 
@@ -151,14 +151,14 @@ run:
 
 ### Kits
 
-Kits are something specific to `instellar` our core engine that orchestrates deployments. Kits provide a way to configure things specific to your application and answers the following questions:
+Kits are something specific to `instellar`, our core engine that orchestrates deployments. Kits provide a way to configure things specific to your application. Kits answer the following questions:
 
 + Which port of my service to expose?
 + What are the environment variables my app depends on?
 + Which environment variables are automatically provisioned?
 + Which environment variables should be exposed to the application?
 + Which environment variables are required / options?
-+ What are the application specific configuration required for resources?
++ What are the application specific configurations required for resources?
 
 In the example below we have a `web` kit, which is the main kit. We also have a `fork` which is the `good-job` process.