docs: fix typos across contributing, product, and skill docs (#3153)

Fix spelling and grammar errors found in a full sweep of the
repo's English markdown files.

- CONTRIBUTING.md: "contributing to to it", "accpeted", "wil"
- .github/PULL_REQUEST_TEMPLATE.md: "value provider to" instead
  of "value provided to"
- docs/product.md: "vendor-lock in" instead of "vendor lock-in"
- packages/expo-two-way-audio/CONTRIBUTING.md: "prescreptive"
- packages/expo-two-way-audio/README.md: "can bee added"
- skills/paseo-committee/SKILL.md: "considered and reject"

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

.github/PULL_REQUEST_TEMPLATE.md

@@ -18,7 +18,7 @@ Closes #
 
 ### Reasoning
 
-<!-- A short description of the reasoning of this change in your own words. What was wrong, and how do you hope this PR fixes it. If you can't explain this briefly, the PR is probably too big. This description must be grounded in real user flows and framed as value provider to Paseo users. -->
+<!-- A short description of the reasoning of this change in your own words. What was wrong, and how do you hope this PR fixes it. If you can't explain this briefly, the PR is probably too big. This description must be grounded in real user flows and framed as value provided to Paseo users. -->
 
 ### Goals
 

CONTRIBUTING.md

@@ -6,7 +6,7 @@ Thank you for taking the time to contribute to Paseo.
 
 Paseo is an opinionated product, built on freedom and flexibility: any agent provider, any device, running on your own machine. It is meant to be composable, so you can build the workflow you want. Read more about the product vision [here](docs/product.md).
 
-Given Paseo's scope, contributing to to it takes a lot of context that is very hard to transfer. That's why product, design, architecture, and workflow decisions are currently all made by the maintainer.
+Given Paseo's scope, contributing to it takes a lot of context that is very hard to transfer. That's why product, design, architecture, and workflow decisions are currently all made by the maintainer.
 
 I pick what to build based on whether it fits the product, how many workflows it improves, whether it keeps things composable, whether we can hold the quality bar, and whether I want to build it.
 
@@ -72,8 +72,8 @@ Here is the criteria I use to decide:
 - PRs that were explicitly approved in a discussion are preferred.
 - Unsolicited PR can be closed without a detailed review.
 - Your PR can be narrowed, refactored, or redesigned.
-- Your PR might be accpeted but not merged immediately.
+- Your PR might be accepted but not merged immediately.
-- You wil be attributed for your work in the changelog, even if I redesign your PR
+- You will be attributed for your work in the changelog, even if I redesign your PR
 
 ## QA evidence
 

docs/product.md

@@ -12,7 +12,7 @@ The development workflow is shifting from manually editing files to orchestratin
 
 Freedom and flexibility. Every design decision follows from this:
 
-- **Multi-provider** — Use any coding agent harness. Pick the right model for each job, switch freely as the landscape shifts. No vendor-lock in.
+- **Multi-provider** — Use any coding agent harness. Pick the right model for each job, switch freely as the landscape shifts. No vendor lock-in.
 - **Cross-device** — Desktop, mobile, web, CLI. Start work at your desk, check progress from your phone, script from the terminal.
 - **Self-hosted** — The daemon runs on your machine. Your code, your keys, your environment. No inference markup, no cloud dependency.
 - **Respectful** - No telemetry, no forced cloud, no forced accounts

packages/expo-two-way-audio/CONTRIBUTING.md

@@ -26,7 +26,7 @@ npm i
 
 ## How to Submit Changes
 
-We try not to be too prescreptive about how people work, but we also believe in helping make things easier by following a couple of basic steps. If you follow these recommendations, it should make the review process simpler and quicker:
+We try not to be too prescriptive about how people work, but we also believe in helping make things easier by following a couple of basic steps. If you follow these recommendations, it should make the review process simpler and quicker:
 
 1. If your change is large, consider reaching out to us beforehand and discussing the issue. This could save you a lot of time if there are good reasons why we haven't done something.
 2. Fork the repo and work on a branch on your fork. Try to give your branches short, descriptive names in the format {type}/{description} e.g. bugfix/missing-try-catch.

packages/expo-two-way-audio/README.md

@@ -88,7 +88,7 @@ npx expo run:ios --device --configuration Release
 npx expo run:android --device --variant release
 ```
 
-For Android, the following permissions are needed: `RECORD_AUDIO`, `MODIFY_AUDIO_SETTINGS`. In Expo apps they can bee added in your `app.json` file:
+For Android, the following permissions are needed: `RECORD_AUDIO`, `MODIFY_AUDIO_SETTINGS`. In Expo apps they can be added in your `app.json` file:
 
 ```javascript
 expo.android.permissions: ["RECORD_AUDIO", "MODIFY_AUDIO_SETTINGS"]

skills/paseo-committee/SKILL.md

@@ -55,7 +55,7 @@ Read both responses. Challenge them — do not accept at face value:
 
 - "Why does <underlying thing> happen? Symptom or cause?"
 - Verify any assumption the plan makes about the code.
-- "What did you considered and reject?"
+- "What did you consider and reject?"
 
 Send follow-ups until the plan addresses root cause.