docs: align checks + index with positioning and messaging

docs/checks/best-practices.mdx

@@ -58,7 +58,7 @@ When a check runs, the system automatically prepends a meta prompt that handles
 - Prevents the agent from touching pre-existing issues in unchanged code
 - Restricts edits to changed files only
 
-You **don't** need to include instructions like "review the changed files" or "only look at the diff" — that's already handled. Focus your check on **what to look for and how to fix it**, not on scoping or diff mechanics.
+You **don't** need to include instructions like "review the changed files" or "only look at the diff." That's already handled. Focus your check on **what to look for and how to fix it**, not on scoping or diff mechanics.
 
 ## What checks can do
 
@@ -85,13 +85,13 @@ This means a check can do things like verify a new page renders correctly in a b
 - "Are there security issues in this auth flow that a linter wouldn't catch?"
 - "Does this error handling follow the patterns established elsewhere in the codebase?"
 
-Checks fill the gap between mechanical linting and human review. They are most valuable for questions that require reading multiple files, understanding intent, or applying project-specific conventions that aren't codified in a linter rule.
+Checks fill the gap between mechanical linting and human review. They handle questions that require reading multiple files, understanding intent, or applying project-specific conventions no linter rule can express.
 
 ---
 
 ## Examples
 
-Complete check files you can drop into `.continue/checks/` directly. These are generic starting points — checks [generated by your coding agent](/checks/generating-checks) will be more specific to your project.
+Complete check files you can drop into `.continue/checks/` directly. These are generic starting points. Checks [generated by your coding agent](/checks/generating-checks) will be more specific to your project.
 
 ### Security review
 
@@ -103,12 +103,12 @@ description: Catch hardcoded secrets, injection vectors, and missing input valid
 
 Look for these security issues and fix them:
 
-- Hardcoded API keys, tokens, passwords, or connection strings — move them to environment variables
-- New API endpoints or request handlers without input validation — add appropriate validation
-- SQL queries built with string concatenation or template literals — convert to parameterized queries
-- Sensitive data (passwords, tokens, PII) written to logs or stdout — remove or redact the sensitive fields
-- New cryptographic code using weak algorithms (MD5, SHA1 for security purposes, ECB mode) — replace with stronger alternatives
-- Secrets added to files that are not in `.gitignore` — remove them and add the files to `.gitignore`
+- Hardcoded API keys, tokens, passwords, or connection strings: move them to environment variables
+- New API endpoints or request handlers without input validation: add appropriate validation
+- SQL queries built with string concatenation or template literals: convert to parameterized queries
+- Sensitive data (passwords, tokens, PII) written to logs or stdout: remove or redact the sensitive fields
+- New cryptographic code using weak algorithms (MD5, SHA1 for security purposes, ECB mode): replace with stronger alternatives
+- Secrets added to files that are not in `.gitignore`: remove them and add the files to `.gitignore`
 ````
 
 ### Test coverage
@@ -121,9 +121,9 @@ description: Ensure new code has corresponding tests
 
 Look for new code that's missing tests:
 
-- A new source file was added without a corresponding test file (e.g., `utils.ts` added but no `utils.test.ts`) — create a test file with basic coverage for the exported functions
-- New exported functions or public methods with no tests exercising them — add tests covering the main code paths
-- An existing test file was deleted without the corresponding source file also being deleted — flag this for review
+- A new source file was added without a corresponding test file (e.g., `utils.ts` added but no `utils.test.ts`): create a test file with basic coverage for the exported functions
+- New exported functions or public methods with no tests exercising them: add tests covering the main code paths
+- An existing test file was deleted without the corresponding source file also being deleted: flag this for review
 
 No changes needed if:
 
@@ -142,9 +142,9 @@ description: Keep docs in sync when public APIs or configuration changes
 
 Look for changes to public-facing APIs or configuration where the documentation wasn't updated:
 
-- A public function, class, or type signature was added or changed — update the corresponding docs (README, docs/, or inline JSDoc/docstrings)
-- Configuration options were added or renamed (config files, environment variables, CLI flags) — update the relevant documentation to reflect the new options
-- API route paths or request/response shapes changed — update the API documentation
+- A public function, class, or type signature was added or changed: update the corresponding docs (README, docs/, or inline JSDoc/docstrings)
+- Configuration options were added or renamed (config files, environment variables, CLI flags): update the relevant documentation to reflect the new options
+- API route paths or request/response shapes changed: update the API documentation
 
 No changes needed if the PR doesn't touch public APIs or configuration, or if docs were already updated.
 ````
@@ -161,11 +161,11 @@ If no dependency files (`package.json`, `requirements.txt`, `pyproject.toml`, `g
 
 When dependencies were added or updated, look for these issues:
 
-- A new dependency that appears unmaintained (no commits in the last 12 months) — flag for review and suggest well-maintained alternatives
-- A dependency was bumped by more than one major version (e.g., v2.x to v4.x) without a note in the PR description — add a comment explaining the jump
-- A known deprecated or security-flagged package was added — replace with the recommended alternative
-- A dependency that duplicates functionality from an existing dependency — remove and use the existing one instead
-- Dev dependencies in production dependency sections (e.g., a test framework in `dependencies` instead of `devDependencies`) — move to the correct section
+- A new dependency that appears unmaintained (no commits in the last 12 months): flag for review and suggest well-maintained alternatives
+- A dependency was bumped by more than one major version (e.g., v2.x to v4.x) without a note in the PR description: add a comment explaining the jump
+- A known deprecated or security-flagged package was added: replace with the recommended alternative
+- A dependency that duplicates functionality from an existing dependency: remove and use the existing one instead
+- Dev dependencies in production dependency sections (e.g., a test framework in `dependencies` instead of `devDependencies`): move to the correct section
 ````
 
 ### Migration safety
@@ -180,9 +180,9 @@ If no migration files were added or changed, no action is needed.
 
 When migrations are present, look for these issues:
 
-- `DROP TABLE` or `DROP COLUMN` without a preceding migration that backs up or migrates the data — add a data migration step or split into separate migrations
-- Column type narrowing (e.g., `TEXT` to `VARCHAR(50)`, `BIGINT` to `INT`) without a backfill step — add a backfill or guard against data truncation
-- `NOT NULL` constraint added to an existing column without a `DEFAULT` value — add a default or a data backfill migration
-- Renaming a column or table that is referenced by application code without updating that code in the same PR — update the references
-- A destructive and a constructive change in the same migration file — split into separate migrations for safe rollback
+- `DROP TABLE` or `DROP COLUMN` without a preceding migration that backs up or migrates the data: add a data migration step or split into separate migrations
+- Column type narrowing (e.g., `TEXT` to `VARCHAR(50)`, `BIGINT` to `INT`) without a backfill step: add a backfill or guard against data truncation
+- `NOT NULL` constraint added to an existing column without a `DEFAULT` value: add a default or a data backfill migration
+- Renaming a column or table that is referenced by application code without updating that code in the same PR: update the references
+- A destructive and a constructive change in the same migration file: split into separate migrations for safe rollback
 ````

docs/checks/generating-checks.mdx

@@ -12,10 +12,10 @@ Then describe what you want to enforce and the agent writes the check file, tail
 
 ## Security
 
-Catch vulnerabilities specific to your stack — auth gaps, injection vectors, leaked secrets.
+Catch vulnerabilities specific to your stack: auth gaps, injection vectors, leaked secrets.
 
 ```
-Look at our codebase and write checks for the most likely security issues — think auth bypasses, injection vectors, secrets in source, and missing input validation. Tailor the checks to the frameworks and patterns we actually use.
+Look at our codebase and write checks for the most likely security issues: auth bypasses, injection vectors, secrets in source, and missing input validation. Tailor the checks to the frameworks and patterns we actually use.
 ```
 
 ## Code review patterns
@@ -36,10 +36,10 @@ Write a check that uses a browser to verify any new or changed pages render with
 
 ## Best practices
 
-Enforce the conventions your team already follows — error handling, naming, migration safety.
+Enforce the conventions your team already follows: error handling, naming, migration safety.
 
 ```
-Analyze our codebase and write checks for the patterns that matter most — error handling conventions, logging standards, naming conventions, or whatever you see us being inconsistent about
+Analyze our codebase and write checks for the patterns that matter most: error handling conventions, logging standards, naming conventions, or whatever you see us being inconsistent about
 ```
 
 ## Test coverage

docs/checks/iterating.mdx

@@ -37,8 +37,8 @@ The more precise your feedback, the faster the check improves.
 
 The rejection dialog also lets you set a sensitivity level for the check:
 
-- **Conservative** — only flag critical issues (high confidence required)
-- **Balanced** — default behavior
-- **Thorough** — flag all potential improvements, even when not fully certain
+- **Conservative**: only flag critical issues (high confidence required)
+- **Balanced**: default behavior
+- **Thorough**: flag all potential improvements, even when not fully certain
 
 If a check is producing too many low-value suggestions, try lowering the sensitivity to **Conservative**. If it's missing real issues, raise it to **Thorough**.

docs/checks/running-in-ci.mdx

@@ -20,7 +20,7 @@ Once connected, Continue will start running checks on new pull requests in the s
 
 ## How checks are discovered
 
-Continue reads the `.continue/checks/` directory from your repository's default branch. Every `.md` file in that directory becomes a check that runs on every PR. No additional configuration is needed — commit a check file and it is active.
+Continue reads the `.continue/checks/` directory from your repository's default branch. Every `.md` file in that directory becomes a check that runs on every PR. No additional configuration is needed. Commit a check file and it is active.
 
 ## The PR workflow
 

docs/checks/running-locally.mdx

@@ -34,14 +34,14 @@ The migration safety check is flagging additive-only migrations as failures. Upd
 
 ## Run checks automatically
 
-You can add `/check` to your `AGENTS.md` so your coding agent runs checks automatically as part of its workflow — for example, after creating a PR:
+You can add `/check` to your `AGENTS.md` so your coding agent runs checks automatically as part of its workflow. For example, after creating a PR:
 
 ```markdown AGENTS.md
 After creating or updating a pull request, run /check and fix any failures before requesting review.
 ```
 
 ## Why local?
 
-Running checks locally uses your existing coding agent and credits (Claude Max, API key, etc.). There's nothing extra to install or configure — if your agent can read your repo, it can run your checks.
+Running checks locally uses your existing coding agent and credits (Claude Max, API key, etc.). There's nothing extra to install or configure. If your agent can read your repo, it can run your checks.
 
 For running checks automatically on every PR in CI, see [Run Checks in CI](/checks/running-in-ci).

docs/index.mdx

@@ -2,7 +2,11 @@
 title: "What is Continue?"
 ---
 
-Continue runs AI checks on every pull request. Each check is a markdown file in your repo that shows up as a GitHub status check — green if the code looks good, red with a suggested fix if not.
+Your tests pass. But standards slip.
+
+Linters catch syntax. Tests verify behavior. But nobody's checking whether that migration is safe, the API docs got updated, or the auth flow follows your team's conventions. Reviewers repeat the same feedback on every PR, and things still slip through.
+
+**Continue runs source-controlled AI checks on every pull request.** Standards as checks, enforced by AI, decided by humans.
 
 <video autoPlay muted loop playsInline className="rounded-xl" src="https://continue.dev/videos/demo.mp4" />
 
@@ -12,7 +16,7 @@ Continue runs AI checks on every pull request. Each check is a markdown file in
 
 ## How it works
 
-You define checks as markdown files in `.continue/checks/`. Each file has a name, a description, and a prompt that tells the AI what to look for.
+You define checks as markdown files in `.continue/checks/`, version-controlled and reviewable alongside your code. You specify what to look for. The AI enforces it on every PR. Results show up as GitHub status checks: green if the code looks good, red with a suggested fix if not.
 
 ```markdown .continue/checks/security-review.md
 ---