chore: prettier formatting

Author: RomneyDa

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

@@ -10,17 +10,20 @@ Analyze this pull request for breaking changes that may leave stale references e
 ## 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

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

@@ -12,12 +12,14 @@ Review this pull request for changes to dependencies. A significant portion of P
 ### 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?
 

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

@@ -12,6 +12,7 @@ Review this pull request for error handling quality. The most common user-facing
 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"

.continue/agents/input-validation.md

@@ -10,17 +10,20 @@ Review this pull request for input validation quality. The most common user issu
 ## 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

.continue/agents/test-coverage.md

@@ -10,16 +10,19 @@ Review this pull request to determine if new functionality has adequate test cov
 ## 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