feat: add 5 agent checks derived from codebase history

.continue/agents/breaking-change-detector.md

@@ -0,0 +1,43 @@
+---
+name: Breaking Change Detector
+description: Flag renamed commands, APIs, or config options with stale references
+---
+
+# Breaking Change Detector
+
+Analyze this pull request for breaking changes that may leave stale references elsewhere in the codebase.
+
+## What Constitutes a Breaking Change
+
+1. **CLI command renames or removals** - If a command registered in `extensions/cli/src/commands/` is renamed, removed, or has its flags changed, check that:
+
+   - Documentation in `docs/` reflects the new name
+   - Agent definitions in `.continue/agents/` don't reference the old command
+   - Skills in `skills/` are updated
+   - README and CONTRIBUTING.md are current
+   - GitHub Actions workflows don't invoke the old command
+
+2. **Public API changes** - If exported functions, interfaces, or types in `core/` or `packages/` are renamed or have signature changes, check that:
+
+   - All callers in `gui/`, `extensions/`, and `binary/` are updated
+   - Type definitions in `packages/config-types/` are consistent
+
+3. **Configuration schema changes** - If config file formats (YAML or JSON) are modified, check that:
+
+   - Validation logic handles both old and new formats (or migration is provided)
+   - Documentation examples use the new format
+   - Default configs are updated
+
+4. **URL changes** - If any hardcoded URLs (e.g., `hub.continue.dev`, `api.continue.dev`) are changed, scan for stale references across the repo.
+
+## What to Do
+
+- If you find stale references, fix them directly.
+- If a breaking change has no migration path and could affect users, add a comment noting the concern but do not block.
+- Focus only on changes introduced in this PR. Do not flag pre-existing issues.
+
+## What NOT to Flag
+
+- Internal refactors where all references are updated in the same PR
+- Changes to test-only code
+- Changes to development tooling that don't affect users

.continue/agents/dependency-security-review.md

@@ -0,0 +1,48 @@
+---
+name: Dependency Security Review
+description: Review dependency changes for security implications and breaking changes
+---
+
+# Dependency Security Review
+
+Review this pull request for changes to dependencies. A significant portion of PRs in this repo are automated dependency bumps (Dependabot, Snyk). This check ensures dependency changes get meaningful review.
+
+## What to Check
+
+### For Any `package.json` Changes
+
+1. **New dependencies** - For each newly added dependency:
+
+   - Is it well-maintained (not abandoned)?
+   - Does it have known vulnerabilities?
+   - Is it the right choice, or does an existing dependency already cover this use case?
+   - Is the version pinned appropriately (exact vs range)?
+
+2. **Major version bumps** - For major version upgrades:
+
+   - Are there breaking changes that affect our usage?
+   - Have the callers been updated to match the new API?
+
+3. **Removed dependencies** - For each removed dependency:
+   - Are all imports/requires of this dependency also removed?
+   - Is there a replacement, or was the functionality dropped?
+
+### For `package-lock.json` Changes
+
+1. **Large lockfile diffs** (>500 lines changed) - Flag for human review, as they may indicate a transitive dependency shift that warrants attention.
+
+2. **New transitive dependencies** - Check if the total dependency count increased significantly.
+
+### Security-Specific Concerns
+
+1. **Packages with filesystem/network access** - New dependencies that read/write files or make network requests deserve extra scrutiny since this tool runs locally on user machines.
+
+2. **Native/binary dependencies** - New native modules (`node-gyp`, `.node` binaries) increase the attack surface and build complexity.
+
+3. **Post-install scripts** - Dependencies with `postinstall` scripts can execute arbitrary code during `npm install`.
+
+## What to Do
+
+- If you find concerning dependency changes, add a comment explaining the concern.
+- Do NOT modify `package.json` or `package-lock.json` files directly.
+- If no dependency files were changed in this PR, do nothing.

.continue/agents/error-message-quality.md

@@ -0,0 +1,35 @@
+---
+name: Error Message Quality
+description: Ensure error handling surfaces actionable messages to users
+---
+
+# Error Message Quality Check
+
+Review this pull request for error handling quality. The most common user-facing issues in this codebase are generic "Unknown error" messages and swallowed error details that prevent users from diagnosing problems themselves.
+
+## What to Check
+
+1. **Catch blocks that discard error details** - Look for `catch` blocks that re-throw or return a generic message without including the original error's message, status code, or context.
+
+2. **HTTP status codes without user-friendly mapping** - When making API calls (especially to LLM providers), ensure that common HTTP errors produce distinct, actionable messages:
+
+   - `401` → "Invalid API key" (not "Unknown error")
+   - `402` → "Insufficient funds or quota exceeded"
+   - `403` → "Access denied - check your API key permissions"
+   - `429` → "Rate limited - please wait and retry"
+   - `5xx` → "Provider service error - try again later"
+
+3. **Silent failures** - Look for empty catch blocks, caught errors that are only logged but not surfaced, or promise rejections that are swallowed.
+
+4. **Error messages that lack context** - Error messages should include what operation failed and what the user can do about it, not just the raw error string.
+
+## What NOT to Flag
+
+- Internal error handling between modules where errors are properly propagated up
+- Test files
+- Debug/development-only error logging
+- Errors that are intentionally caught and handled silently (with a clear code comment explaining why)
+
+## Scope
+
+Only review files changed in this PR. Do not audit the entire codebase. If you find issues, make targeted fixes to improve the error messages in the changed code. If no error handling issues exist in the changed files, do nothing.

.continue/agents/input-validation.md

@@ -0,0 +1,45 @@
+---
+name: Input Validation
+description: Ensure user-facing inputs have proper validation and error feedback
+---
+
+# Input Validation Check
+
+Review this pull request for input validation quality. The most common user issues in this codebase stem from malformed API keys, blank inputs, and missing configuration values that produce confusing downstream errors.
+
+## What to Check
+
+1. **API keys and secrets** - Any code that accepts API keys, tokens, or credentials should:
+
+   - Reject obviously invalid values (empty strings, whitespace-only, placeholder text like "your-api-key-here")
+   - Validate format where possible (e.g., OpenAI keys start with `sk-`, Anthropic keys start with `sk-ant-`)
+   - Provide a clear error message before making a network request with a bad key
+
+2. **Configuration values** - New or modified config parsing should:
+
+   - Validate required fields are present and non-empty
+   - Validate types (e.g., numbers are actually numbers, URLs are valid URLs)
+   - Provide clear error messages that name the specific field and expected format
+   - Not crash the entire config loading process for a single invalid value
+
+3. **User text inputs** - New or modified UI inputs should:
+
+   - Handle empty/whitespace-only submissions gracefully
+   - Sanitize inputs that will be used in file paths, URLs, or shell commands
+   - Not allow submission of invalid data that will fail silently later
+
+4. **URL and endpoint validation** - When users provide custom URLs (e.g., for self-hosted LLM endpoints):
+   - Validate URL format
+   - Handle missing protocol (add `https://` if missing)
+   - Provide feedback before attempting connection
+
+## What NOT to Flag
+
+- Internal function parameters (trust internal callers)
+- Test inputs
+- Validation that already exists and is working correctly
+- Configuration values with sensible defaults that don't require user input
+
+## Scope
+
+Only review files changed in this PR. If you find missing validation, add it directly. Keep fixes minimal and focused. If no user-facing input handling was changed, do nothing.

.continue/agents/test-coverage.md

@@ -0,0 +1,56 @@
+---
+name: Test Coverage
+description: Ensure new functionality includes corresponding tests
+---
+
+# Test Coverage Check
+
+Review this pull request to determine if new functionality has adequate test coverage.
+
+## When Tests Are Expected
+
+1. **New exported functions or classes** - Any new public function, class, or module that is exported and used by other parts of the codebase should have at least basic unit tests covering:
+
+   - The happy path (expected inputs produce expected outputs)
+   - Edge cases (empty inputs, null/undefined, boundary values)
+   - Error cases (invalid inputs throw or return appropriate errors)
+
+2. **New CLI commands or subcommands** - Should have:
+
+   - Smoke tests verifying the command registers and runs
+   - Tests for flag parsing and validation
+   - Tests for expected output format
+
+3. **Bug fixes** - If a PR fixes a bug, there should be a regression test that:
+
+   - Reproduces the original bug condition
+   - Verifies the fix resolves it
+
+4. **New API endpoints or handlers** - Should have integration tests covering:
+   - Successful request/response
+   - Error responses for invalid inputs
+   - Authentication/authorization (if applicable)
+
+## When Tests Are NOT Expected
+
+- Documentation-only changes
+- Configuration file changes (YAML, JSON, Markdown)
+- CSS/styling changes
+- Dependency updates (unless they change behavior)
+- Agent definition files (`.continue/agents/*.md`)
+- Refactors that don't change behavior (existing tests should still pass)
+- Internal implementation changes fully covered by existing tests
+
+## What to Do
+
+- If new functionality lacks tests, add a PR comment noting what should be tested and why.
+- Do NOT write tests yourself. The author knows the intended behavior best.
+- If the PR includes tests but they seem incomplete (missing edge cases, no error cases), note the gaps.
+- If the PR is clearly a test-exempt category (docs, config, styling), do nothing.
+
+## Test Infrastructure Reference
+
+- **Core**: Jest (`*.test.ts`) + Vitest (`*.vitest.ts`) in `core/`
+- **GUI**: Vitest (`*.test.ts`) in `gui/src/`
+- **CLI**: Vitest (`*.test.ts`, `*.e2e.test.ts`) in `extensions/cli/`
+- **Packages**: Vitest in each `packages/*/` directory