diff --git a/.claude/skills/docs-style/SKILL.md b/.claude/skills/docs-style/SKILL.md new file mode 100644 index 00000000000..d65086856cd --- /dev/null +++ b/.claude/skills/docs-style/SKILL.md @@ -0,0 +1,41 @@ +--- +name: docs-style +description: Style guidelines for writing and updating documentation. Use when writing new docs, updating existing docs, or reviewing docs for quality. +--- + +# Docs Style Guide + +## Principles + +- **Be concise** — no filler. Make it easy to find what you're looking for +- **Task-oriented** — frame around what the user is trying to do, not what the product can do +- **Progressive disclosure** — guide from introduction to advanced use-cases. Don't throw users into the deep end +- **Real examples over abstract explanations** — show, don't describe +- **Code snippets must be copy-pasteable** — no placeholder values that silently break, no missing imports +- **Prerequisites up front** — don't surprise the user halfway through +- **One topic per page** — if you're covering two things, split it +- **Link, don't repeat** — reference other docs instead of duplicating content +- **Scannable headings** — skimming the TOC should reveal the page structure +- **Show expected output** — after a step, tell the user what they should see +- **Consistent terminology** — pick one term for a concept, use it everywhere +- **Screenshots/GIFs for key product features** — use visuals when they teach faster than text +- **Know which type of doc you're writing** — a tutorial (learning), a how-to (completing a task), a reference (looking something up), or an explanation (understanding why). Don't mix them in one page +- **Tutorials should be completable** — a user following every step should end up with a working result, every time +- **Reference docs should be exhaustive and consistent** — cover everything, use the same structure for every entry + +## Tone + +- **Don't be patronizing** — the reader is a developer. Don't tell them when to use something in a "when to use X vs Y" comparison table. If the distinction matters, state it plainly at the top of the relevant section in a sentence, then move on. +- **Respect the reader's time** — open with the command or code, not a paragraph explaining what they're about to see. Lead with the thing, then explain. +- **No personality** — the docs aren't a character. Don't try to be warm, clever, or endearing. No "Let's dive in!", no "The Magic of...", no "Pro Tip:", no emoji in headings. Developers see through it instantly and it reads like marketing copy wearing a docs costume. Just be direct and clinical. The docs serve information, they don't have a relationship with the reader. +- **Inline guidance over callout boxes** — prefer weaving tips into the prose rather than using ``, ``, ``, etc. These components break reading flow and look heavy when overused. Reserve them for truly critical warnings (e.g. data loss, security). One per page is a good ceiling; zero is often fine. +- **Examples should feel real** — use realistic file paths, realistic prompts, realistic tasks. Not `> Tell me about the CLI` but `> @tests/auth.test.ts This test started failing after the last migration`. +- **Examples earn their place** — don't add "Example: Doing X" sections that are just English prompts in a code block. Examples are valuable when they demonstrate non-obvious syntax, flags, piping, or configuration. If the reader could figure it out from the rest of the page, skip the example. +- **No "Next Steps" sections** — don't end pages with a "Next Steps" or "What's Next?" section with CardGroups linking to other pages. The sidebar navigation already does this. If a link to another page is relevant, put it inline where the context is, not in a generic footer. +- **Page title = sidebar title** — the `title` in frontmatter should match the sidebar label. Drop `sidebarTitle` unless there's a genuine reason for them to differ. Don't stuff extra context into the page title (e.g., "Continue CLI (cn) Overview" → "Overview"). +- **No subtitle/description in frontmatter** — don't use the `description` field. The opening paragraph of the page should provide whatever context is needed. Metadata subtitles add clutter and duplicate what the prose already says. + +## Headings + +- **Direct and plain, not clever or engaging** — headings should just say what the section is about. Verbs are fine when they're direct ("Resume previous sessions"). Gerund phrases that sound like tutorial chapter titles are not ("Giving Context with @" → "`@` Context"). The test isn't grammatical — it's tonal. If it sounds like a friendly narrator is walking you through something, rewrite it. If it just plainly states what the section covers, it's good. +- **Scannable over descriptive** — skimming the TOC should reveal the page structure at a glance. Keep headings short and plain. diff --git a/.continue/checks/stale-comments.md b/.continue/checks/stale-comments.md new file mode 100644 index 00000000000..0a06e617f74 --- /dev/null +++ b/.continue/checks/stale-comments.md @@ -0,0 +1,92 @@ +--- +name: Stale & Misleading Comments +description: Flag comments that no longer match the code they describe. +--- + +# Stale & Misleading Comments + +## Context + +In a fast-moving TypeScript monorepo with many contributors, comments frequently fall out of sync with the code they describe. A misleading comment is worse than no comment — it actively misdirects developers and causes bugs. This check catches comments that contradict, no longer match, or misrepresent adjacent code. + +## What to Check + +### 1. Comments That Contradict the Code + +Look for inline comments (`//`) and block comments (`/* */`) where the description no longer matches what the code actually does. + +**BAD — comment says "retry" but code doesn't retry:** + +```typescript +// Retry the request on failure +const result = await fetch(url); +``` + +**BAD — comment describes old parameter list:** + +```typescript +// Takes a model name and returns the provider +function getProvider(config: ModelConfig, context: ContextManager) { +``` + +**GOOD — comment matches behavior:** + +```typescript +// Resolve provider from full model configuration and context +function getProvider(config: ModelConfig, context: ContextManager) { +``` + +### 2. TODO/FIXME/HACK Comments for Completed Work + +Flag TODO, FIXME, and HACK comments where the described work appears to already be done in the surrounding code. + +**BAD — TODO says to add validation, but validation exists below:** + +```typescript +// TODO: add input validation +if (!input || typeof input !== "string") { + throw new Error("Invalid input"); +} +``` + +### 3. Commented-Out Code With Misleading Annotations + +Flag blocks of commented-out code that have an annotation suggesting they're still needed, when the functionality has been replaced or removed. + +**BAD:** + +```typescript +// Keep this for fallback support +// const oldProvider = new LegacyProvider(config); +// oldProvider.initialize(); +const provider = new ModernProvider(config); +``` + +### 4. JSDoc / Docstrings That Mismatch Signatures + +Check that `@param`, `@returns`, and `@throws` tags in JSDoc comments match the actual function signature — correct parameter names, types, and return type. + +**BAD — documents a param that doesn't exist:** + +```typescript +/** + * @param modelName - The model to use + * @returns The completion text + */ +async function complete(config: AutocompleteConfig): Promise { +``` + +## Key Files to Check + +- `core/` — shared logic across all extensions +- `extensions/vscode/src/` — VS Code extension source +- `extensions/cli/src/` — CLI extension source +- `gui/src/` — React GUI components +- `packages/` — shared npm packages + +## Exclusions + +- License headers and copyright notices +- Comments in generated files, vendored code, or `node_modules` +- Comments in test files that describe expected (intentionally wrong) behavior +- Commented-out code in test fixtures used as test data diff --git a/README.md b/README.md index 0c6d7fc0344..ccfc303c8d8 100644 --- a/README.md +++ b/README.md @@ -41,12 +41,10 @@ Continue runs agents on every pull request as GitHub status checks. Each agent i name: Security Review description: Review PR for basic security vulnerabilities --- - Review this PR and check that: - -- No secrets or API keys are hardcoded -- All new API endpoints have input validation -- Error responses use the standard error format + - No secrets or API keys are hardcoded + - All new API endpoints have input validation + - Error responses use the standard error format ``` ## Install CLI diff --git a/docs/agents/overview.mdx b/docs/agents/overview.mdx index 5499428f260..5497cd5d6b9 100644 --- a/docs/agents/overview.mdx +++ b/docs/agents/overview.mdx @@ -1,268 +1,104 @@ --- -title: "Cloud Agents & Continuous AI" -description: "Standardized Cloud Agent workflows that combine prompts, rules, and tools to complete specific, repeatable tasks" -sidebarTitle: "Overview" +title: "Agents" --- -## What are Cloud Agents? -Cloud Agents are AI workflows that execute on remote infrastructure (Continue Mission Control) rather than your local machine. Because they live in the cloud, they maintain persistent, secure connections to your development tools and can be triggered in two ways: +Agents use the same markdown file format as checks. The difference: agents can be triggered by events beyond PR open — cron schedules, GitHub issues, Sentry alerts, Slack messages, webhooks. Triggers are configured in Mission Control. -- On-Demand: Manually triggered via Chat, Tasks, or the CLI for complex, human-guided work. +## Local agents vs. cloud agents -- Automated: Automatically triggered by schedules (Cron) or events (Webhooks) for background maintenance. +There are two ways to define agents: -Unlike local assistants, Cloud Agents provide a centralized "Mission Control" where teams can collaborate on tasks, review shared logs, and standardize automation across repositories. +- **Local**: Place agent files in `.continue/agents/` in your repository. Version-controlled and shared with your team. +- **Cloud**: Created and managed on [continue.dev/agents](https://continue.dev/agents). Web UI for configuration, no file to commit. +Both run on Continue's cloud infrastructure. - - Agents are custom AI workflows that combine a prompt, rules, and tools (MCPs and more) to complete specific, repeatable tasks. - They live in the Continue Mission Control and can be executed from Mission Control (web interface), TUI mode, or headless automation. - +## Triggers +Triggers determine when an agent runs. They are configured in [Mission Control](/mission-control/workflows). +Supported trigger types: -## Ways to Run Cloud Agents +| Trigger | Description | +|---|---| +| **Cron** | Run on a schedule (daily, weekly, hourly, custom) | +| **Webhook** | Run when an external system sends a request | +| **GitHub event** | Run when specific GitHub events occur (PR opened, issue created, label added, etc.) | -These execution modes allow Continue agents to function as cloud agents, running continuously, headlessly, or on schedules without requiring a developer in the loop: + +Version-controlled trigger configuration (defined in the agent file itself) is on the roadmap. Today, all triggers are managed through Mission Control. + - - - **Interactive web interface** - - Trigger from the Continue Mission Control and review results in real-time. - - ```bash - # Navigate to continue.dev/agents - # Click "Run Agent" on any agent - # Monitor progress and review outputs - ``` - - Perfect for: Interactive debugging, reviewing agent outputs, team collaboration - - - - **Interactive terminal mode** +## Running agents - Launch from terminal for live interaction and testing. - - ```bash - cn --agent my-org/github-pr-agent - # Interactive chat interface opens - # Type your specific request - # Review and approve actions - ``` - - Perfect for: Local development, testing prompts, quick one-off tasks + + + Trigger agents from the web interface at [continue.dev](https://continue.dev) and review results in real-time. - - **Automated execution** - - Run one-off or scheduled tasks automatically without interaction. - + ```bash - cn -p --agent my-org/snyk-agent "Run weekly security scan" + cn --agent my-org/my-agent ``` - Perfect for: CI/CD pipelines, scheduled tasks, webhook integrations + Opens an interactive chat session with the agent. - - **Version-controlled agents in your repository** - - Define agents in `.continue/agents/` and run them with the CLI or GitHub Actions. - + ```bash - # Run a local agent file - cn --agent .continue/agents/my-agent.md + cn -p --agent my-org/my-agent "Run weekly security scan" ``` - Perfect for: Team-shared workflows, CI/CD automation, version-controlled agent definitions - - [Learn more about local agents →](/guides/run-agents-locally) + Runs the agent non-interactively. Useful for CI/CD pipelines and scheduled automation. -## Local vs. Cloud Agents +## Checks vs. agents -| Feature | Local Agents (IDE / TUI) | Cloud Agents (Mission Control) | -|---------|--------------------------|--------------------------------| -| Compute Location | Your Local Machine | Remote Cloud Infrastructure | -| Primary Use Case | fast, private iteration and "single-player" coding | Collaborative tasks, heavy processing, and reliable automation | -| Context Access | Limited to open files and local git state | Full repository access + integrated tools (Sentry, Snyk, etc.) | -| Triggers | Manual Tasks / CLI | Hybrid: Manual Chat, Cron Schedules, or Event Webhooks | -| Availability | Stops when you close your laptop | Always On: Runs asynchronously in the background | +| | Checks | Agents | +|---|---|---| +| File location | `.continue/checks/` | `.continue/agents/` or continue.dev | +| Trigger | Always on PR open | Configurable in [Mission Control](/mission-control/workflows) | +| Purpose | Pass/fail review of PRs | Any automated task | -## Pre-configured Cloud Agents +## Cloud agent gallery -Skip the setup and use battle-tested agents from our cookbook collection: +Pre-configured agents you can use immediately: - - + `continuedev/snyk-continuous-ai-agent` - -A cloud agent that monitors vulnerabilities and automatically opens PRs with fixes. - - - - - `continuedev/github-project-manager-agent` - - A cloud agent that triages issues and manages project workflows - - - - - - `continuedev/posthog-continuous-ai-agent` - - A cloud agent that analyzes user data and creates actionable tasks - - - - - - `continuedev/netlify-continuous-ai-agent` - - A cloud agent that monitors Core Web Vitals and optimizes deployments - - - - - - `continuedev/supabase-agent` - - A cloud agent that audits RLS security and generates migrations - - - - - - `continuedev/dlt-agent` - - A cloud agent that inspects pipelines and debugs load errors - - - - - - **Explore More Cloud Agents**: Browse the complete collection of pre-configured agents and MCP integration cookbooks in our [Guides Overview](/guides/overview#mcp-integration-cookbooks). - - -{/* ## Webhook Integrations -Trigger Agents automatically through secure webhooks for CI/CD integration: - -```bash -POST /webhooks/ingest/:webhookId -{ - "payload": { "trigger": "nightly-security-scan" } -} -``` - -Perfect for connecting with: -- GitHub Actions workflows -- Monitoring alerts (Sentry, DataDog) -- Deployment pipelines -- Scheduled maintenance tasks */} - -## Collaboration - -Agents are organizational assets — once created, everyone in your org can use them: - -| Role | Permissions | -|------|-------------| -| **Public** | Use, create, remix, and delete Agents | -| **Organization** | Share agents with your team | -| **Private** | Create, edit, and delete Agents for your personal use | - -## Getting Started - - - - Start with a cookbook agent like `continuedev/github-project-manager-agent`: - - ```bash - cn --agent continuedev/github-project-manager-agent "List open issues labeled bug" - ``` - - - - Test agents locally before automation: - - ```bash - cn --agent continuedev/snyk-continuous-ai-agent - # Interactive mode - perfect for learning how to use the agent for your use case - ``` - - - - Ready to build custom workflows? Learn how in our [Create and Edit guide](/agents/create-and-edit). - - - - Integrate with CI/CD using headless mode and webhooks for continuous workflows. - - - -## Monitoring - -You can monitor all activity for your Agents directly in **Mission Control**. - - - - - The **Inbox** shows every Task or Workflow run, and you can filter by Agent. - - - - Click any session in the Inbox to open the Detail page. - - Each session includes: - - **Summary** — what the agent did and why - - **Diff** — generated code changes - - **Logs** — full execution trace, tool calls, and reasoning - - This is the best way to review output, debug issues, or confirm correctness. - - - + Monitors vulnerabilities and automatically opens PRs with fixes. + - -All monitoring is scoped to your current workspace. - + + `continuedev/github-project-manager-agent` -## Best Practices + Triages issues and manages project workflows. + -The practice of using cloud agents, which we call Continuous AI, requires forethought to set up the right guardrails: + + `continuedev/posthog-continuous-ai-agent` -- **Start Small**: Begin with tasks you're confident Continue can accomplish -- **Use Thorough Prompts**: Agents can run for extended periods, so invest in detailed instructions -- **Test Locally First**: Practice with TUI mode before deploying to production -- **Team Alignment**: Discuss agent usage and adjust code review habits for higher PR volume -- **Iterate and Improve**: Be willing to refine prompts based on results + Analyzes user data and creates actionable tasks. + -## Next Steps + + `continuedev/netlify-continuous-ai-agent` - - - Build your first custom agent with prompts, rules, and tools + Monitors Core Web Vitals and optimizes deployments. - - Set up version-controlled agents in your repository - + + `continuedev/supabase-agent` - - Browse pre-built agents for security, analytics, and more + Audits RLS security and generates migrations. - - Learn to run agents from the command line - + + `continuedev/dlt-agent` - - Access the web interface to manage agents + Inspects pipelines and debugs load errors. - \ No newline at end of file + diff --git a/docs/checks/best-practices.mdx b/docs/checks/best-practices.mdx new file mode 100644 index 00000000000..5609b75cbc2 --- /dev/null +++ b/docs/checks/best-practices.mdx @@ -0,0 +1,205 @@ +--- +title: "Best Practices" +--- + +These principles apply whether you're writing a check yourself or reviewing one your coding agent generated. A well-structured check tells the agent exactly what to look for and how to fix it; a vague one produces noise. + +## Scope narrowly + +Write one check per concern. A single check that tries to cover security, test coverage, and documentation will produce muddled results. Split it into three checks instead. + +```markdown .continue/checks/input-validation.md +--- +name: Input Validation +description: Verify new API endpoints validate their inputs +--- + +Look for new API endpoints that accept user input without validation +(missing type checks, no schema validation, no length limits). +If found, add appropriate input validation. +``` + +A "review everything" check will spread itself thin and miss things. A focused check does one job well. + +## Be specific about what to look for + +The prompt must describe exactly what the agent should look for and what it should do about it. Vague instructions produce vague results. + +**Good:** + +``` +Look for new API endpoints that don't validate their inputs. Add schema validation using zod where missing. +``` + +**Bad:** + +``` +Check that the code is secure. +``` + +Structure criteria as a concrete list: + +```markdown +Look for these issues in the changed code and fix them: + +- New REST endpoints missing request body validation +- Database queries using string interpolation instead of parameterized queries +- Error responses that expose stack traces or internal paths +``` + +The more specific you are about what to look for, the more reliable the check. + +## What you don't need to write + +When a check runs, the system automatically prepends a meta prompt that handles diff scoping for you. Specifically, it: + +- Provides the full diff and a list of changed files +- Instructs the agent to only review changed lines +- 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. + +## What checks can do + +Checks are not limited to reading the diff. The agent running a check can: + +- **Read files** in the repository beyond the diff, to understand surrounding context +- **Run bash commands** like `grep`, `find`, or custom scripts +- **Use a browser** to visit URLs, take screenshots, and verify rendered output +- **Access the PR diff** including file names, additions, and deletions +- **Use the GitHub CLI** (`gh`) to read PR metadata, comments, or linked issues + +This means a check can do things like verify a new page renders correctly in a browser, or cross-reference the diff against your database schema. + +## Checks vs. tests vs. linting + +**Linting** handles formatting, style, and static patterns. Use ESLint, Prettier, Ruff, or equivalent. If a rule can be expressed as a pattern match on syntax, it belongs in a linter. + +**Tests** verify correctness, behavior, and regressions. Use your test framework. If the question is "does this function return the right output for these inputs," write a test. + +**Checks** handle judgment calls that require understanding context: + +- "Is this database migration safe to run on a 500M-row table?" +- "Does this PR update the API docs to reflect the endpoint changes it makes?" +- "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. + +--- + +## 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. + +### Security review + +````markdown security-review.md +--- +name: Security Review +description: Catch hardcoded secrets, injection vectors, and missing input validation +--- + +Look for these security issues in the changed code 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` +```` + +### Test coverage + +````markdown test-coverage.md +--- +name: Test Coverage +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 + +No changes needed if: + +- All new source files have corresponding test files +- New functions/methods are already covered by tests +- Only test files, docs, or config files were changed +```` + +### Documentation freshness + +````markdown docs-freshness.md +--- +name: Documentation Freshness +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 + +No changes needed if the PR doesn't touch public APIs or configuration, or if docs were already updated. +```` + +### Conventional commits + +````markdown conventional-commits.md +--- +name: Conventional Commits +description: Ensure the PR title follows conventional commit format +--- + +Check that the pull request title follows the Conventional Commits specification. + +The title must match this format: `type(optional scope): description` + +Valid types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert` + +If the PR title doesn't match the format, suggest a corrected title based on the content of the changes. +```` + +### Dependency audit + +````markdown dependency-audit.md +--- +name: Dependency Audit +description: Review new or updated dependencies for risk +--- + +If no dependency files (`package.json`, `requirements.txt`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Gemfile`, or similar) were changed, no action is needed. + +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 +```` + +### Migration safety + +````markdown migration-safety.md +--- +name: Migration Safety +description: Catch destructive database migrations +--- + +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 +```` diff --git a/docs/checks/generating-checks.mdx b/docs/checks/generating-checks.mdx new file mode 100644 index 00000000000..4f0b79d0242 --- /dev/null +++ b/docs/checks/generating-checks.mdx @@ -0,0 +1,69 @@ +--- +title: "Generating Checks" +--- + +The best way to create checks is to have your coding agent write them. Install the writing-checks skill to teach your agent the check file format and best practices: + +```bash +npx skills add continuedev/skills --skill writing-checks +``` + +Then describe what you want to enforce and the agent writes the check file, tailored to your actual frameworks, file structure, and conventions. Here are some prompts to try: + +## Security + +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. +``` + +## Code review patterns + +Turn recurring PR feedback into automated checks so reviewers don't have to repeat themselves. + +``` +Look through our recent PR review comments and identify things reviewers say repeatedly. Write checks that automate those recurring review comments. +``` + +## QA and browser testing + +Verify that UI changes render correctly and don't break links or layouts. + +``` +Write a check that uses a browser to verify any new or changed pages render without errors and match our design system +``` + +## Best practices + +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 +``` + +## Test coverage + +Make sure new code ships with tests that match your project's existing patterns. + +``` +Write a check that verifies new code has corresponding tests, following the test file naming and structure conventions already in our project +``` + +## Documentation + +Flag PRs where public APIs or config changed but the docs didn't. + +``` +Write a check that flags PRs where public API or configuration changes aren't reflected in documentation +``` + +## Iterate locally + +Write the check (or have your agent write it), run it against a real PR branch, read the output, refine. Run `/checks` in your coding agent to test: + +``` +/checks .continue/checks/migration-safety.md +``` + +See [Run Checks Locally](/checks/running-locally) for the full local testing workflow. diff --git a/docs/checks/quickstart.mdx b/docs/checks/quickstart.mdx new file mode 100644 index 00000000000..8154ef24537 --- /dev/null +++ b/docs/checks/quickstart.mdx @@ -0,0 +1,50 @@ +--- +title: "Write Your First Check" +--- + +## Generating checks (recommended) + +Paste this into Claude Code or any coding agent: + +``` +Help me write checks for this codebase: https://continue.dev/walkthrough +``` + +The walkthrough reads your codebase, helps you write your first checks, connects you to Continue, and gets them running on your next PR. It takes a few minutes. + +If you'd rather set things up manually, keep reading. + +## Writing checks manually + +A check file has two parts: **frontmatter** (YAML between `---` delimiters) with a required `name` and `description`, and a **body** prompt that tells the AI what to look for. Create a `.md` file in `.continue/checks/`: + +```markdown .continue/checks/security-review.md +--- +name: Security Review +description: Flag hardcoded secrets and missing input validation +--- + +Review this pull request for security issues. + +Flag as failing if any of these are true: + +- Hardcoded API keys, tokens, or passwords in source files +- New API endpoints without input validation +- SQL queries built with string concatenation +- Sensitive data logged to stdout + +If none of these issues are found, pass the check. +``` + +Write concrete pass/fail criteria so the check produces consistent results. See the [reference](/checks/reference) for all available fields. + +## Next steps + + + + Verify your checks before pushing by running `/check` in your coding agent. + + + Set up GitHub integration so checks run on every pull request. + + diff --git a/docs/checks/reference.mdx b/docs/checks/reference.mdx new file mode 100644 index 00000000000..df460b290d7 --- /dev/null +++ b/docs/checks/reference.mdx @@ -0,0 +1,71 @@ +--- +title: "Check File Reference" +--- + +A check is a markdown file with YAML frontmatter and a markdown body. The frontmatter configures metadata and tooling. The body is the prompt the agent follows when reviewing a pull request. + +## File format + +```markdown +--- +name: Migration Safety +description: Flag destructive database migrations +--- + +Your prompt here. This is the system prompt the agent uses +when evaluating the pull request. +``` + +Check files live in `.continue/checks/` or `.agents/checks/` at the repository root. + +## Frontmatter fields + +| Field | Required | Type | Description | +|-------|----------|------|-------------| +| `name` | Yes | string | Display name shown in GitHub status checks and on continue.dev | +| `description` | Yes | string | Short description of what the check verifies | +| `model` | No | string | Model to use. Defaults to Claude Sonnet. Example: `anthropic/claude-sonnet-4-5-20250514` | + +## Body + +The markdown body after the frontmatter is the agent's system prompt. It runs in the context of the PR being reviewed. The agent reads the prompt, examines the pull request diff, and produces a pass or fail verdict with reasoning. + +Write concrete pass/fail criteria. See [Best Practices](/checks/best-practices) for guidance on prompt structure. + +## Complete example + +A fully-specced check file using all available fields: + +```markdown .continue/checks/migration-safety.md +--- +name: Migration Safety +description: Flag destructive database migrations +model: anthropic/claude-sonnet-4-5-20250514 +--- + +Review database migration files in this pull request. + +Flag as failing if any migration contains: +- DROP TABLE or DROP COLUMN without a corresponding backfill migration +- Data type changes that narrow the column (e.g., VARCHAR(255) → VARCHAR(100)) +- Removing NOT NULL constraints without a default value + +Pass if the migration is additive only (new tables, new columns, new indexes). +``` + +## File discovery + +Continue locates checks by scanning specific directories at the repository root: + +- Reads all `.md` files in `.continue/checks/` +- Reads all `.md` files in `.agents/checks/` +- Subdirectories are not scanned +- Files without valid `name` and `description` frontmatter are skipped + +Checks always run when a PR is opened. For event-triggered automation, use [agents](/mission-control/beyond-checks#agents). + +## Supported directory paths + +`.continue/checks/` and `.agents/checks/` are equivalent. Both are scanned and merged into a single list of checks. + +`.agents/` is an emerging cross-tool standard for AI agent configuration. `.continue/` is Continue-specific. Use whichever fits your project. If both directories contain a check with the same `name`, the `.continue/checks/` version takes precedence. diff --git a/docs/checks/running-in-ci.mdx b/docs/checks/running-in-ci.mdx new file mode 100644 index 00000000000..9a5921774c6 --- /dev/null +++ b/docs/checks/running-in-ci.mdx @@ -0,0 +1,43 @@ +--- +title: "Run Checks in CI" +--- + +Continue watches your repository for pull requests, runs each check defined in `.continue/checks/`, and reports results as GitHub status checks. A green check means the code passed; a red check means the code failed, with a suggested fix. + +## Prerequisites + +- A [Continue](https://continue.dev) account +- A GitHub repository with at least one check file in `.continue/checks/` (see [Write Your First Check](/checks/quickstart)) + +## Connect GitHub + +1. Go to [continue.dev](https://continue.dev/) and sign in (or create an account). +2. Navigate to the [GitHub integration page](https://continue.dev/integrations/github). +3. Click **Connect GitHub** and authorize Continue. +4. Select the repositories you want Continue to monitor. + +Once connected, Continue will start running checks on new pull requests in the selected repositories. + +## 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. + +## The PR workflow + +When a pull request is opened, reopened, or updated: + +1. Each check file runs independently against the PR diff. +2. Results appear as GitHub status checks on the PR. +3. If a check passes, it shows a green checkmark. +4. If a check fails, it shows a red X with a suggested diff. +5. Click the check details link in GitHub to see the full reasoning on continue.dev. + +## Accept or reject suggestions + +When a check fails and suggests changes: + +1. Click the check's **Details** link on the PR in GitHub. This opens the result on continue.dev. +2. Review the suggested diff. +3. **Accept** to apply the changes as a commit to the PR branch. +4. **Reject** to dismiss the suggestion. The check will re-run on the next push. + diff --git a/docs/checks/running-locally.mdx b/docs/checks/running-locally.mdx new file mode 100644 index 00000000000..b78ca373746 --- /dev/null +++ b/docs/checks/running-locally.mdx @@ -0,0 +1,41 @@ +--- +title: "Run Checks Locally" +--- + +Run your checks locally before pushing to CI using the `/check` command in your coding agent (Claude Code, Cursor, or any agent that supports skills). + +## Install + +```bash +npx skills add continuedev/skills --skill check +``` + +## Run checks + +Type `/check` in your coding agent. It discovers every check file in `.continue/checks/`, runs each one as a subagent against your current branch, and reports the results. To run a single check, pass the file path: `/check .continue/checks/security-review.md`. + +``` +/check +``` + +## Iterate on a check + +The local feedback loop is: edit the check file, run `/check`, read the output, refine. Because checks run inside your coding agent, you can ask it to fix issues in the same session: + +``` +The migration safety check is flagging additive-only migrations as failures. Update the check to only flag destructive operations. +``` + +## 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: + +```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. + +For running checks automatically on every PR in CI, see [Run Checks in CI](/checks/running-in-ci). diff --git a/docs/cli/configuration.mdx b/docs/cli/configuration.mdx new file mode 100644 index 00000000000..851dec6bab4 --- /dev/null +++ b/docs/cli/configuration.mdx @@ -0,0 +1,77 @@ +--- +title: "Configuration" +--- + +`cn` resolves its configuration (models, MCP servers, rules, etc.) from several sources, in this order: + +1. **`--config` flag** — a file path or hub assistant slug passed at launch +2. **Saved config** — the last-used configuration, persisted across sessions +3. **Default** — your first assistant from [Continue](https://continue.dev), or `~/.continue/config.yaml` if you're not logged in + +## `--config` flag + +Point `cn` at a local YAML file or a hub assistant: + +```bash +# Local file +cn --config ./my-config.yaml + +# Hub assistant +cn --config my-org/my-assistant +``` + +This overrides any saved preference for the current session. + +## Switching at runtime + +Use `/config` inside a TUI session to switch between available configurations: + +``` +> /config +``` + +This shows your available assistants and local configs. The selection is saved for next time. + +## `config.yaml` + +If you're not logged in to Continue, `cn` looks for `~/.continue/config.yaml`. This file uses the same format as the IDE extensions — see [config.yaml reference](/customize/deep-dives/configuration) for the full schema. + +## CLI-specific flags + +Several flags inject configuration at launch without editing a file: + +```bash +# Add models from the hub +cn --model my-org/claude-sonnet + +# Add MCP servers from the hub +cn --mcp my-org/github-mcp + +# Add rules (file path, hub slug, or inline string) +cn --rule ./rules/style.md +cn --rule my-org/code-review-rules +cn --rule "Always use TypeScript strict mode" + +# Load an agent file from the hub +cn --agent my-org/pr-reviewer +``` + +All of these are repeatable — pass them multiple times to add multiple items. + +## Organization + +If you belong to multiple organizations on Continue, use `--org` to specify which one: + +```bash +cn --org my-team -p "Review this PR" +``` + +In TUI mode, `/config` lets you switch organizations interactively. + +## Secrets + +Store sensitive values (API keys, tokens) in [Continue → Settings → Secrets](https://continue.dev/settings/secrets). Reference them in config with: + +```yaml +${{ secrets.MY_API_KEY }} +``` diff --git a/docs/cli/guides.mdx b/docs/cli/guides.mdx deleted file mode 100644 index 89e96b56650..00000000000 --- a/docs/cli/guides.mdx +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "Guides" -url: "/guides/overview#mcp-integration-cookbooks" ---- \ No newline at end of file diff --git a/docs/cli/headless-mode.mdx b/docs/cli/headless-mode.mdx new file mode 100644 index 00000000000..f493869ff6f --- /dev/null +++ b/docs/cli/headless-mode.mdx @@ -0,0 +1,86 @@ +--- +title: "Headless Mode" +--- + +Run `cn -p "your prompt"` to execute a single task without an interactive session. The agent runs to completion and prints its response to stdout. + +```bash +cn -p "Generate a conventional commit message for the staged changes" +``` + +## Piping + +Pipe data into `cn` to include it as context: + +```bash +git diff --staged | cn -p "Write a commit message for this diff" +cat error.log | cn -p "Explain what went wrong" +curl -s https://api.example.com/health | cn -p "Is this healthy?" +``` + +Pipe the output into other tools: + +```bash +cn -p "Generate a commit message" | git commit -F - +cn -p "List all TODO comments in src/" --silent > todos.txt +``` + +## Output options + +| Flag | Effect | +|------|--------| +| `--silent` | Strip `` tags and excess whitespace from output | +| `--format json` | Output structured JSON | + +`--silent` is useful when piping output into another program. `--format json` is useful for parsing results programmatically. + +## Tool permissions + +In headless mode, tools that would normally prompt for approval (`ask` permission) are automatically excluded — there's no one to approve them. To enable write operations, explicitly allow them: + +```bash +# Allow the agent to write files +cn -p "Fix the type errors in src/" --allow Write --allow Edit + +# Allow everything +cn -p "Set up the project" --allow "*" +``` + +See [tool permissions](/cli/tool-permissions) for the full policy system. + +## Authentication in CI + +Set `CONTINUE_API_KEY` instead of running `cn login`: + +```bash +export CONTINUE_API_KEY=your-key-here +cn -p "Review the PR for security issues" +``` + +Get an API key from [Continue → Settings → API Keys](https://continue.dev/settings/api-keys). Store it as a secret in your CI provider. + +## Resume in headless mode + +Resume a previous session without interactive input: + +```bash +cn -p --resume +``` + +This replays the previous session's history, which can be useful for inspecting past results in automation. + +## Examples + +```bash +# Git hooks +cn -p "Review staged changes for obvious bugs" --silent + +# CI pipeline — allow file writes for auto-fix +cn -p "Fix all ESLint errors in src/" --allow Write --allow Edit --allow Bash + +# Generate docs from code +cn -p "@src/api/ Generate OpenAPI documentation for these endpoints" --silent > api-docs.yaml + +# Use a specific assistant +cn -p "Triage this error log" --config my-org/error-triage-assistant +``` diff --git a/docs/cli/install.mdx b/docs/cli/install.mdx deleted file mode 100644 index 07bd47b56c9..00000000000 --- a/docs/cli/install.mdx +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: "Install Continue CLI" -description: "Get Continue CLI installed and configured for command-line AI coding assistance and automation" -sidebarTitle: "Install" ---- - -import { OSAutoDetect } from '/snippets/OSAutoDetect.jsx' -import CLIInstall from '/snippets/cli-install.mdx' - - - - - -## Installation - - - -## Two Ways to Use Continue CLI - - - **Quick Overview**: Continue CLI works in two modes - TUI for interactive - conversations or headless for automated commands. - - - - -**Interactive development sessions** - -Start a conversation with AI in your terminal: - -```bash -cn -> @src/app.js Generate unit tests for this component -``` - -Perfect for exploration, debugging, and iterative development. - - - - -**Automation and scripting** - -Single commands that return results: - -```bash -cn -p "Generate a commit message for current changes" -cn -p "Review the last 5 commits for issues" -``` - -Perfect for CI/CD, git hooks, and automated workflows. - - - - -## Setup - - - - -For interactive development and exploration: - - - -```bash -cn login -``` -This will open your browser to authenticate with Continue Mission Control. - - - -Start an interactive session: -```bash -cn -``` - -Try asking a question: - -``` -> Tell me about the CLI -``` - - - - - - -For automation workflows and scripting: - - - -For automation workflows, get an API key: -1. Visit [Continue Mission Control API Keys](https://continue.dev/settings/api-keys) -2. Click **"+ New API Key"** -3. Copy the API key immediately (you won't see it again!) -4. Login using your Continue account - - - -Store secure credentials for CLI workflows: -1. Visit [Continue Mission Control Secrets](https://continue.dev/settings/secrets) -2. Add your API keys and sensitive data -3. Reference in configurations with `${{ secrets.SECRET_NAME }}` - - - -Try headless mode for automation: -```bash -cn -p "Generate a conventional commit message for the current git changes" -``` - - - - - -## What's Next? - - - - Learn basic usage with practical examples - - - - Build automated workflows with Continue CLI - - - -## Getting Help - -If you encounter issues: - -- Ask for help in [our discussions](https://github.com/continuedev/continue/discussions) -- Report bugs on [GitHub](https://github.com/continuedev/continue) diff --git a/docs/cli/overview.mdx b/docs/cli/overview.mdx deleted file mode 100644 index 9c0e9c51cab..00000000000 --- a/docs/cli/overview.mdx +++ /dev/null @@ -1,242 +0,0 @@ ---- -title: "Continue CLI (cn) Overview" -description: "Command-line interface for automated coding tasks, scripting, and headless development workflows with Continue's AI coding capabilities" -sidebarTitle: "Overview" ---- - -import { OSAutoDetect } from '/snippets/OSAutoDetect.jsx' -import CLIInstall from '/snippets/cli-install.mdx' - - - - - - - -**Continue enables developers to ship faster with Continuous AI.** - - - Build features from descriptions. Debug and fix issues. Navigate any codebase. - Automate tedious tasks. - - -## Get Started in 30 Seconds - -Prerequisites: - -- [Node.js 18 or newer](https://nodejs.org/en/download/) -- A [Continue Mission Control](https://continue.dev) account (recommended) or local configuration - - - -Then navigate to your project and start coding: - -```bash -cd your-awesome-project -cn -# You'll be prompted to set up on first use -``` - -That's it! You're ready to start automating with Continue CLI. - -[Continue with CLI Quickstart →](/cli/quick-start) - -## Two Ways to Use Continue CLI - -Continue CLI offers two distinct modes designed for different workflows: - -### TUI Mode: Interactive Development - -**Perfect for exploration, debugging, and iterating on AI workflows** - -```bash -cn -> @src/components/UserProfile.js Review this component for security issues -> Generate comprehensive unit tests -> Suggest performance improvements -``` - -- **Interactive conversations** with your codebase -- **Iterate and refine** prompts and approaches -- **Explore and understand** complex codebases -- **Perfect for experimentation** and learning - -### Headless Mode: Production Automation - -**Perfect for CI/CD, automation, and reliable workflows** - -```bash -cn -p "Generate a conventional commit message for staged changes" -cn -p "Review pull request changes for security vulnerabilities" -cn -p "Update documentation based on recent code changes" -``` - -- **Single-command execution** for automation -- **Reliable, repeatable results** for production use -- **CI/CD and pipeline integration** -- **Git hooks and automated workflows** - - - **Tool Permissions in TUI vs Headless Mode** - - Continue CLI tools have three permission levels: - - **allow**: Executes automatically without confirmation - - **ask**: Prompts for user confirmation before execution (e.g., `writeFile`, `runTerminalCommand`) - - **exclude**: Tool is not available to the AI - - **In headless mode**, tools with "ask" permission are automatically excluded to prevent the AI from seeing tools it cannot call. This ensures reliable automation without user intervention. - - **In TUI mode**, tools with "ask" permission are available and will prompt for confirmation when the AI attempts to use them. - - 💡 **Tip**: If your workflow requires tools that need confirmation (like file writes or terminal commands), use TUI mode. For fully automated workflows with read-only operations, use headless mode. - - -### Development Workflow: TUI → Headless - - - **Pro Tip**: Start in TUI mode to iterate on your AI agent. Once - you have a workflow that works reliably, deploy it as a Continuous AI - automation. - - -1. **Experiment in TUI mode** to perfect your agent -2. **Test different approaches** interactively until you get consistent results -3. **Convert successful workflows** to automated Continuous AI commands -4. **Deploy in production** with confidence in your proven approach - -## Why developers love Continue CLI - -- **Works in your terminal**: Not another chat window. Not another IDE. Continue CLI meets you where you already work, with the tools you already love. -- **Takes action**: Continue CLI can directly edit files, run commands, and create commits. Need more? Check out our [MCPs](/customize/deep-dives/mcp). -- **Automate tasks**: Create issues from PostHog data, automatically assign labels to issues, and more. Do all this in a single command from your developer machines, or automatically in CI. -- **Flexible development flow**: Start interactive, then automate proven workflows. - -## Key Capabilities - -### Context Engineering - -- Use `@` to reference files and provide context -- Use `/` to run slash commands for specific tasks -- Access the same context providers as IDE extensions - -### Tool Integration - -- File editing and creation -- Terminal command execution -- Codebase understanding and analysis -- Git integration -- Web search and documentation access - -### Model Flexibility - -- Switch between models with `/model` command -- Use any model configured in your `config.yaml` -- Access Continue Mission Control models and configurations - -## Continue Mission Control Integration - -Continue CLI integrates seamlessly with [Continue Mission Control](https://continue.dev) for: - -### API Access - -Get an API key for automation workflows: - -1. Visit [Continue Mission Control API Keys](https://continue.dev/settings/api-keys) -2. Create a new API key -3. Use with `cn login` or in your automation scripts - -### Secrets Management - -Store secure credentials for CLI workflows: - -1. Visit [Continue Mission Control Secrets](https://continue.dev/settings/secrets) -2. Add your API keys and sensitive data -3. Reference in configurations with `${{ secrets.SECRET_NAME }}` - -### Configuration Sync - -- Cloud-managed configurations automatically sync -- Share configurations across team members -- Version control for your AI workflows - -## Common Use Cases - -### TUI Mode Examples - -**Interactive development and exploration:** - - -```bash Codebase Exploration -# Start interactive session -cn -> @src/components Find all unused React components -> /explain How does authentication work in this codebase? -> @auth/ What security patterns are used here? -``` - -```bash Iterative Debugging -# Debug issues interactively -cn -> @tests/auth.test.js This test is failing, help me understand why -> @src/auth/middleware.js Let's examine this middleware -> /debug What could be causing the timeout error? -``` - -```bash Workflow Development -# Develop and test automation workflows -cn -> @package.json @CHANGELOG.md Generate a release notes template -> # Test and refine the approach -> # Once working, convert to: cn -p "Generate release notes" -``` - - - -### Headless Mode Examples - -**Production automation and scripting:** - - -```bash Git Automation -# Generate commit messages -cn -p "Generate a conventional commit message for the current changes" - -# Code review automation - -cn -p "Review the current git changes for bugs and suggest improvements" - -```` - -```bash CI/CD Integration -# In your pipeline scripts -cn -p "Analyze test failures and suggest fixes" - -# Automated documentation updates -cn -p "@README.md Update this documentation based on recent changes" -```` - -```bash Issue Management -# Create GitHub issues from PostHog data -cn -p "@posthog-data.json Create GitHub issues for UX problems found in this session data" - -# Automated security audits -cn -p "Scan the codebase for potential security vulnerabilities" -``` - - - -## Next Steps - - - - Learn basic commands and common workflows - - - - Install Continue CLI and set up your environment - - - - Task-specific tutorials and examples - - diff --git a/docs/cli/quick-start.mdx b/docs/cli/quick-start.mdx deleted file mode 100644 index dbda8ec50a6..00000000000 --- a/docs/cli/quick-start.mdx +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: "Continue CLI Quick Start" -description: "Get hands-on experience with Continue CLI through practical examples and common use cases" -sidebarTitle: "Quick Start" ---- - -Get hands-on experience with Continue CLI through practical development workflows. - - - - TUI Mode (`cn` command) is for **large development tasks** that require - agentic workflows with human oversight. Perfect for complex refactors, - feature implementation, or one-off automation tasks that need monitoring and - iteration. - - - Headless Mode (`-p` flag) is for **reliable, repeatable tasks** that no - longer need constant supervision. Perfect for CI/CD pipelines, git hooks, - and automated workflows you've already tested and refined. - - - -## TUI Mode: Large Development Tasks - -Make sure you have [Continue CLI installed](/cli/install) and are in a project directory. - -### Example: Implementing a New Feature - -```bash -# Navigate to your project directory -cd your-awesome-project - -# Start TUI Mode for complex development work -cn -``` - -**Example workflow for adding authentication:** - -``` -> I need to add JWT authentication to this Express app. Let me start by showing you the current structure. - -> @src/app.js @package.json Here's my current setup. Can you implement JWT auth with middleware, login/register routes, and user model? - -> [Agent analyzes codebase and implements auth system] -> [You review changes, test, and provide feedback] -> [Agent iterates based on your input until the feature is complete] -``` - -### Example: Complex Refactoring - -```bash -cn -``` - -**Refactoring a monolithic component:** - -``` -> @src/components/Dashboard.jsx This component is 800 lines and does too much. Help me break it into smaller, reusable components. - -> [Agent analyzes component structure] -> [Proposes component breakdown strategy] -> [You approve approach] -> [Agent implements the refactor with proper props and state management] -> [You test and request adjustments] -``` - -### When to Use TUI Mode - -✅ **Large development tasks** that need oversight -✅ **Complex refactors** requiring multiple steps -✅ **New feature implementation** with unknowns -✅ **One-off automation tasks** you haven't done before -✅ **Debugging complex issues** that need exploration - -## Headless Mode: Automated Workflows - -Once you've refined a workflow in TUI Mode, convert it to Continuous AI for automation. - -### Example: From REPL → Continuous AI - -**Step 1: Develop in TUI Mode** - -```bash -cn -> @package.json @CHANGELOG.md Generate release notes for version 2.1.0 -> [Test and refine the prompt until it works perfectly] -``` - -**Step 2: Convert to Continuous AI** - -```bash -# Now use the refined workflow in automation -cn -p "Generate release notes for the current version based on package.json and recent commits" -``` - -### Common Continuous AI Workflows - -```bash -# Git automation -cn -p "Generate a conventional commit message for staged changes" -cn -p "Review the last 3 commits for potential issues" - -# Code quality -cn -p "Fix all TypeScript errors in the src/ directory" -cn -p "Update outdated dependencies and fix breaking changes" - -# Documentation -cn -p "@README.md Update documentation based on recent changes" -cn -p "Generate API documentation from JSDoc comments" - -# CI/CD integration -cn -p "Analyze test failures and create GitHub issue with findings" -cn -p "Update version numbers and create release branch" -``` - -### When to Use Headless Mode - -✅ **Proven workflows** you've tested in TUI Mode -✅ **Repetitive tasks** that no longer need oversight -✅ **CI/CD automation** in pipelines -✅ **Git hooks** for automated checks -✅ **Scheduled tasks** that run unattended - - - **Tool Permission Differences Between Modes** - - Tools requiring user confirmation ("ask" permission) like `writeFile` and `runTerminalCommand` are: - - **Available in TUI mode** - AI can use them with your approval - - **Excluded in headless mode** - AI cannot see or call them - - This prevents the AI from attempting operations that require user interaction when running in automated environments. Choose TUI mode if your workflow needs tools that modify files or run commands. - - -### Available Slash Commands - -Common slash commands available in CLI: - -- `/clear` - Clear the chat history -- `/compact` - Summarize chat history into a compact form -- `/config` - Switch configuration or organization -- `/exit` - Exit the chat -- `/fork` - Start a forked chat session from the current history -- `/help` - Show help message -- `/info` - Show session information including usage statistics (cost, tokens, cache usage) -- `/init` - Create an AGENTS.md file -- `/login` - Authenticate with your account -- `/logout` - Sign out of your current session -- `/mcp` - Manage MCP server connections -- `/model` - Switch between available chat models -- `/resume` - Resume a previous chat session -- `/whoami` - Check who you're currently logged in as - -Use `/help` to see all available commands. - -## The Development Workflow - - - **Recommended Approach**: Start complex tasks in TUI Mode to iterate and - refine your approach. Once you have a reliable workflow, convert it to - Headless Mode for automation. - - -### Workflow Pattern - -1. **🔬 Experiment in TUI Mode** - - - Try complex development tasks with human oversight - - Iterate on prompts and approaches until they work reliably - - Test edge cases and refine the agent's behavior - -2. **⚡ Automate with Continuous AI** - - Convert proven REPL workflows to single commands - - Deploy in CI/CD, git hooks, or scheduled tasks - - Run with confidence knowing the approach is tested - -## Next Steps - - - - Build an automated PostHog to GitHub issues workflow - - - - Learn to build and deploy AI-powered development workflows - - diff --git a/docs/cli/quickstart.mdx b/docs/cli/quickstart.mdx new file mode 100644 index 00000000000..eb50da8c9aa --- /dev/null +++ b/docs/cli/quickstart.mdx @@ -0,0 +1,88 @@ +--- +title: "Quickstart" +--- + +import { OSAutoDetect } from '/snippets/OSAutoDetect.jsx' +import CLIInstall from '/snippets/cli-install.mdx' + + + +Continue CLI (`cn`) is a terminal-based coding agent. It can edit files, run commands, and work through multi-step tasks — the same agent that powers the Continue IDE extensions, running in your terminal. + + + + + +## Install + + + +Verify the installation: + +```bash +cn --version +``` + +### Requirements + +- **Node.js 20+** — needed for the npm install path. The shell installer bundles its own runtime. +- A [Continue](https://continue.dev) account, or an Anthropic API key. + +## First run + +```bash +cd your-project +cn +``` + +On first launch you'll be asked to log in with [Continue](https://continue.dev) or enter an Anthropic API key. After that, you're in a session and can start typing. + +## Authentication + +### Log in with Continue + +```bash +cn login +``` + +This opens your browser to authenticate with [Continue](https://continue.dev). Once authenticated, `cn` can use your configured assistants, models, and MCP servers from the platform. + +### API key (headless / CI) + +For automation environments where there's no browser, set the `CONTINUE_API_KEY` environment variable: + +```bash +export CONTINUE_API_KEY=your-key-here +cn -p "your prompt" +``` + +Get an API key from [Continue → Settings → API Keys](https://continue.dev/settings/api-keys). + +### Local API key + +If you don't want to use Continue, you can use an Anthropic API key directly. On first launch, `cn` will prompt you to choose between logging in with Continue or entering an Anthropic API key. + +## Two modes + +**[TUI mode](/cli/tui-mode)** — run `cn` to start an interactive session. You type messages, reference files with `@`, approve tool calls, and iterate with the agent. This is the default. + +**[Headless mode](/cli/headless-mode)** — run `cn -p "your prompt"` for single-shot automation. The agent runs to completion and prints its response to stdout. Use this in scripts, CI/CD, and git hooks. + +## Common flags + +| Flag | Effect | +|------|--------| +| `-p "prompt"` | Headless mode — run prompt and exit | +| `--config ` | Use a specific config file or assistant | +| `--resume` | Resume the most recent session | +| `--auto` | Allow all tools without prompting | +| `--readonly` | Plan mode — read-only tools only | +| `--allow ` | Allow a specific tool (repeatable) | +| `--exclude ` | Exclude a specific tool (repeatable) | +| `--rule ` | Add a rule — file path, hub slug, or string (repeatable) | +| `--mcp ` | Add an MCP server from the hub (repeatable) | +| `--model ` | Add a model from the hub (repeatable) | +| `--agent ` | Load an agent file from the hub | +| `--verbose` | Enable verbose logging | + +Run `cn --help` for the full list. diff --git a/docs/cli/tool-permissions.mdx b/docs/cli/tool-permissions.mdx new file mode 100644 index 00000000000..5273a116dd4 --- /dev/null +++ b/docs/cli/tool-permissions.mdx @@ -0,0 +1,92 @@ +--- +title: "Tool Permissions" +--- + +Every tool has one of three permission levels: + +| Permission | Behavior | +|------------|----------| +| `allow` | Runs automatically, no prompt | +| `ask` | Prompts for approval before running (TUI only) | +| `exclude` | Hidden from the agent entirely | + +## Defaults + +Read-only tools (`Read`, `List`, `Search`, `Fetch`, `Diff`) default to `allow`. Write tools (`Edit`, `MultiEdit`, `Write`) and `Bash` default to `ask`. In [headless mode](/cli/headless-mode), `ask` tools are excluded since there's no one to approve them. + +## Overriding with flags + +Use `--allow`, `--ask`, and `--exclude` to override defaults at launch: + +```bash +# Allow file writes without prompting +cn --allow Write --allow Edit + +# Exclude terminal commands +cn --exclude Bash + +# Allow everything (headless automation) +cn -p "Set up the project" --allow "*" +``` + +Flags take precedence over all other permission sources. + +## Tool matching patterns + +Flags accept tool matching patterns: + +- `Write` — matches any call to the `Write` tool +- `Write(*)` — same as above +- `Write(**/*.ts)` — matches `Write` calls where the primary argument matches the glob `**/*.ts` + +```bash +# Allow writing only to TypeScript files +cn --allow "Write(**/*.ts)" + +# Allow bash but not for install commands +cn --allow Bash --exclude "Bash(npm install*)" +``` + +## `permissions.yaml` + +Persistent permissions are stored in `~/.continue/permissions.yaml`. This file is updated when you choose "Continue + don't ask again" in the TUI approval prompt. + +```yaml +# ~/.continue/permissions.yaml +allow: + - Read(*) + - Write(**/*.ts) + +ask: + - Bash + +exclude: [] +``` + +You can edit this file directly, but it's primarily managed by the TUI. Changes take effect on the next session. + +## Precedence + +When multiple sources define a permission for the same tool, the highest-priority source wins: + +1. **Mode policies** — `--auto` and `--readonly` override everything (see below) +2. **CLI flags** — `--allow`, `--ask`, `--exclude` +3. **`permissions.yaml`** — persistent personal settings +4. **Defaults** — built-in policies + +## Modes + +Modes are a shorthand for common permission sets. Switch modes with `Shift+Tab` during a TUI session, or set them at launch: + +```bash +cn --auto # Allow all tools without prompting +cn --readonly # Plan mode — read-only tools only, no file writes +``` + +| Mode | Effect | +|------|--------| +| **normal** (default) | Uses configured permissions | +| **plan** (`--readonly`) | Excludes all write tools, allows reads and `Bash` | +| **auto** (`--auto`) | Allows everything — `*: allow` | + +Plan and auto modes are absolute overrides. They ignore `--allow`, `--exclude`, and `permissions.yaml` entirely. diff --git a/docs/cli/tui-mode.mdx b/docs/cli/tui-mode.mdx new file mode 100644 index 00000000000..44999ed6073 --- /dev/null +++ b/docs/cli/tui-mode.mdx @@ -0,0 +1,60 @@ +--- +title: "TUI Mode" +--- + +Run `cn` to start an interactive session. You get a prompt where you can type messages, reference files with `@`, and use slash commands. `cn` uses the same underlying agent as the Continue IDE extensions. + + + + + +## `@` Context + +Use `@` to point the agent at specific files or directories: + +``` +> @src/auth/middleware.ts Why is this middleware rejecting valid tokens? +> @tests/ Write missing test cases for the auth module +> @package.json @tsconfig.json Help me set up path aliases +``` + +The agent reads the referenced files and uses them as context for its response. + +## Slash Commands + +Type `/` to see available commands. Run `/help` for the full list. + +| Command | What it does | +|---------|-------------| +| `/model` | Switch between configured chat models | +| `/config` | Switch configuration or organization | +| `/compact` | Summarize chat history to free up context | +| `/fork` | Branch the conversation from the current point | +| `/resume` | Pick up a previous session | +| `/info` | Show token usage and cost for this session | +| `/init` | Create an `AGENTS.md` file for the current project | +| `/mcp` | Manage MCP server connections | + +## Resume previous sessions + +Pick up where you left off: + +```bash +# Resume the most recent session +cn --resume + +# Or use the slash command inside a session +> /resume +``` + +This restores the full conversation history, so the agent remembers prior context. + +## Tool Permissions + +Tools that can modify your system (file writes, terminal commands) prompt for approval before executing. You get three options: + +- **Continue** — approve this call +- **Continue + don't ask again** — approve and save a policy rule to `~/.continue/permissions.yaml` +- **No** — reject the call and give the agent new instructions + +Read-only tools (`Read`, `List`, `Search`, `Fetch`) run automatically. See [tool permissions](/cli/tool-permissions) for the full policy system. diff --git a/docs/customize/model-providers/more/asksage.mdx b/docs/customize/model-providers/more/asksage.mdx index b7ef3a8aed7..2dee198997f 100644 --- a/docs/customize/model-providers/more/asksage.mdx +++ b/docs/customize/model-providers/more/asksage.mdx @@ -132,7 +132,7 @@ Supported features: ## Setting up Continue CLI 1. Install Continue CLI -Follow the steps from the [official Continue docs](https://docs.continue.dev/cli/install). +Follow the steps from the [official Continue docs](https://docs.continue.dev/cli/quickstart). 2. Setting up a custom config for Ask Sage Follow the steps in step 2 of the Overview above 👆. diff --git a/docs/docs.json b/docs/docs.json index 2674ab96165..3a37a56d267 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -11,24 +11,36 @@ "navigation": { "tabs": [ { - "tab": "Documentation", + "tab": "Checks", "groups": [ { "group": "Getting Started", "icon": "rocket-launch", - "pages": ["index", "overview"] + "pages": [ + "index", + "checks/quickstart", + "checks/running-locally", + "checks/running-in-ci" + ] + }, + { + "group": "Writing Checks", + "icon": "pencil", + "pages": [ + "checks/generating-checks", + "checks/best-practices", + "checks/reference" + ] }, { "group": "Mission Control", "icon": "globe", + "expanded": false, "pages": [ - "mission-control/index", - "mission-control/tasks", - "mission-control/workflows", + "mission-control/beyond-checks", { "group": "Integrations", "pages": [ - "mission-control/integrations", "mission-control/integrations/github", "mission-control/integrations/sentry", "mission-control/integrations/snyk", @@ -39,59 +51,24 @@ "mission-control/integrations/supabase" ] }, - "mission-control/metrics", - "mission-control/sharing", - { - "group": "Governance", - "pages": [ - "mission-control/governance/creating-an-org", - "mission-control/governance/org-permissions", - "mission-control/governance/pricing" - ] - }, - { - "group": "Secrets", - "pages": [ - "mission-control/secrets/secret-types", - "mission-control/secrets/secret-resolution" - ] - }, - { - "group": "Configs", - "pages": [ - "mission-control/configs/intro", - "mission-control/configs/use-a-config", - "mission-control/configs/create-a-config", - "mission-control/configs/edit-a-config" - ] - } - ] - }, - { - "group": "Agents", - "icon": "robot", - "pages": [ - "agents/intro", - "agents/overview", - "agents/create-and-edit" + "mission-control/metrics" ] - }, + } + ] + }, + { + "tab": "CLI", + "groups": [ { "group": "CLI", "icon": "terminal", "pages": [ - "cli/overview", - "cli/install", - "cli/quick-start", - "cli/guides", - "cli/configuration" + "cli/quickstart", + "cli/tui-mode", + "cli/headless-mode", + "cli/configuration", + "cli/tool-permissions" ] - }, - { - "group": "Help", - "icon": "book-open", - "expanded": false, - "pages": ["faqs", "troubleshooting", "CONTRIBUTING"] } ] }, @@ -247,85 +224,48 @@ "reference/deprecated-codebase", "reference/deprecated-docs" ] - } - ] - }, - { - "tab": "Guides", - "groups": [ - { - "group": "Getting Started", - "icon": "rocket-launch", - "pages": ["guides/overview"] }, { - "group": "Cloud Agents", - "icon": "cloud", + "group": "Guides", + "expanded": false, + "icon": "compass", "pages": [ - "guides/cloud-agents/cloud-agents-taxonomy", - "guides/cloud-agents/guide-to-cloud-agents", - "guides/cloud-agents/when-to-use-cloud-agents", - "guides/cloud-agents/from-task-to-automation", - "guides/cloud-agents/cloud-agents-vs-ci", - "guides/cloud-agents/operating-cloud-agents-safely", - "guides/cloud-agents/automated-security-remediation-with-snyk" + "guides/understanding-configs", + "guides/configuring-models-rules-tools", + "guides/codebase-documentation-awareness", + "guides/plan-mode-guide", + "guides/ollama-guide", + "guides/instinct", + "guides/running-continue-without-internet", + "guides/custom-code-rag", + "guides/how-to-self-host-a-model" ] }, { - "group": "Guides", - "icon": "compass", + "group": "Help", + "icon": "book-open", + "expanded": false, + "pages": ["faqs", "troubleshooting", "CONTRIBUTING"] + }, + { + "group": "Continue Hub (deprecated)", + "expanded": false, + "icon": "box-archive", "pages": [ { - "group": "Understanding Continue", - "pages": [ - "guides/understanding-configs", - "guides/configuring-models-rules-tools", - "guides/codebase-documentation-awareness", - "guides/plan-mode-guide", - "guides/ollama-guide", - "guides/instinct", - "guides/running-continue-without-internet", - "guides/custom-code-rag", - "guides/how-to-self-host-a-model" - ] - }, - { - "group": "CLI Guides", - "pages": [ - "guides/cli", - "guides/run-agents-locally", - "guides/doc-writing-agent-cli" - ] - }, - { - "group": "Continuous AI Guides", - "pages": [ - "guides/continuous-ai", - "guides/continuous-ai-readiness-assessment" - ] - }, - { - "group": "Integration Guides", + "group": "Secrets", "pages": [ - "guides/notion-continue-guide", - "guides/github-pr-review-bot" + "mission-control/secrets/secret-types", + "mission-control/secrets/secret-resolution" ] }, { - "group": "Cookbooks", + "group": "Configs", "pages": [ - "guides/posthog-github-continuous-ai", - "guides/continue-docs-mcp-cookbook", - "guides/github-mcp-continue-cookbook", - "guides/atlassian-mcp-continue-cookbook", - "guides/sanity-mcp-continue-cookbook", - "guides/sentry-mcp-error-monitoring", - "guides/snyk-mcp-continue-cookbook", - "guides/supabase-mcp-database-workflow", - "guides/dlt-mcp-continue-cookbook", - "guides/netlify-mcp-continuous-deployment", - "guides/chrome-devtools-mcp-performance", - "guides/klavis-mcp-continue-cookbook" + "mission-control/configs/intro", + "mission-control/configs/use-a-config", + "mission-control/configs/create-a-config", + "mission-control/configs/edit-a-config" ] } ] @@ -404,6 +344,14 @@ "js": ["reo-tracking.js"] }, "redirects": [ + { + "source": "/cli/overview", + "destination": "/cli/quickstart" + }, + { + "source": "/cli/install", + "destination": "/cli/quickstart" + }, { "source": "/changelog", "destination": "https://changelog.continue.dev" @@ -486,7 +434,7 @@ }, { "source": "/hub/workflows/intro", - "destination": "/agents/intro" + "destination": "/mission-control/beyond-checks" }, { "source": "/hub/blocks/create-a-block", @@ -1480,7 +1428,7 @@ }, { "source": "/hub/agents/overview", - "destination": "/agents/overview" + "destination": "/mission-control/beyond-checks" }, { "source": "/hub/agents/create-and-edit", @@ -1505,6 +1453,50 @@ { "source": "/hub/integrations/sentry", "destination": "/mission-control/integrations/sentry" + }, + { + "source": "/mission-control/workflows", + "destination": "/mission-control" + }, + { + "source": "/mission-control/sharing", + "destination": "/mission-control" + }, + { + "source": "/mission-control/governance/creating-an-org", + "destination": "/mission-control" + }, + { + "source": "/mission-control/governance/org-permissions", + "destination": "/mission-control" + }, + { + "source": "/mission-control/governance/pricing", + "destination": "/mission-control" + }, + { + "source": "/agents/overview", + "destination": "/mission-control/beyond-checks" + }, + { + "source": "/agents/intro", + "destination": "/mission-control/beyond-checks" + }, + { + "source": "/agents/create-and-edit", + "destination": "/mission-control/beyond-checks" + }, + { + "source": "/mission-control/tasks", + "destination": "/mission-control/beyond-checks" + }, + { + "source": "/guides/run-agents-locally", + "destination": "/checks/running-locally" + }, + { + "source": "/overview", + "destination": "/" } ] } diff --git a/docs/guides/cloud-agents/guide-to-cloud-agents.mdx b/docs/guides/cloud-agents/guide-to-cloud-agents.mdx index aacf8aefa7b..3c263ef3074 100644 --- a/docs/guides/cloud-agents/guide-to-cloud-agents.mdx +++ b/docs/guides/cloud-agents/guide-to-cloud-agents.mdx @@ -70,7 +70,7 @@ The defining feature of a Cloud Agent isn't just *automation*; it is **availabil ### Human-in-the-Loop Approach - You can trigger agents manually (with Continue, use the [Continue CLI](../../cli/overview) or [Mission Control](../../mission-control)) when you need a one-off task that you want to review. + You can trigger agents manually (with Continue, use the [Continue CLI](../../cli/quickstart) or [Mission Control](../../mission-control)) when you need a one-off task that you want to review. diff --git a/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx b/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx index 6c8fabcda62..65f755e0fc0 100644 --- a/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx +++ b/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx @@ -74,7 +74,7 @@ Use cloud agents if you can say “yes” to most of these: - [ ] We can start in a manual or assisted mode -If you’re unsure, start with a one-off [task](../../mission-control/tasks) and treat it like an experiment. +If you're unsure, start with an agent and treat it like an experiment. ## Where to Go Next diff --git a/docs/guides/dlt-mcp-continue-cookbook.mdx b/docs/guides/dlt-mcp-continue-cookbook.mdx index 5fed1f5c585..a0e62d7c020 100644 --- a/docs/guides/dlt-mcp-continue-cookbook.mdx +++ b/docs/guides/dlt-mcp-continue-cookbook.mdx @@ -273,7 +273,7 @@ Navigate to **Repository Settings → Secrets and variables → Actions** and ad ### Create Workflow File -This workflow automatically validates your dlt data pipelines on pull requests using the Continue CLI in [headless mode](/cli/overview#headless-mode%3A-production-automation). It inspects pipeline schemas, checks for errors, and posts a summary report as a PR comment. The workflow can also be triggered manually via `workflow_dispatch`. +This workflow automatically validates your dlt data pipelines on pull requests using the Continue CLI in [headless mode](/cli/headless-mode). It inspects pipeline schemas, checks for errors, and posts a summary report as a PR comment. The workflow can also be triggered manually via `workflow_dispatch`. Create `.github/workflows/dlt-pipeline-validation.yml` in your repository: diff --git a/docs/guides/notion-continue-guide.mdx b/docs/guides/notion-continue-guide.mdx index cc5eec951db..2e742112552 100644 --- a/docs/guides/notion-continue-guide.mdx +++ b/docs/guides/notion-continue-guide.mdx @@ -30,7 +30,7 @@ This guide teaches you to: Before starting, ensure you have: -- [Continue CLI](https://docs.continue.dev/cli/overview) installed +- [Continue CLI](https://docs.continue.dev/cli/quickstart) installed - A [Notion workspace](https://notion.so) with Editor (or higher) access - Node.js 18+ installed locally - [Continue account](https://continue.dev) with **Hub access** diff --git a/docs/guides/run-agents-locally.mdx b/docs/guides/run-agents-locally.mdx index b5ae2f534d8..f59340bc9b2 100644 --- a/docs/guides/run-agents-locally.mdx +++ b/docs/guides/run-agents-locally.mdx @@ -5,7 +5,7 @@ description: "Set up version-controlled agents in your repository and run them w --- - Looking for the easiest way to create and manage agents? [Cloud Agents in Mission Control](/agents/overview#pre-configured-agents) are recommended for most teams. This guide covers **local agents**—agent files stored in your repository—for open source users or teams needing version-controlled definitions. + Looking for the easiest way to create and manage agents? [Cloud Agents in Mission Control](/mission-control/beyond-checks#cloud-agent-gallery) are recommended for most teams. This guide covers **local agents**—agent files stored in your repository—for open source users or teams needing version-controlled definitions. @@ -20,7 +20,7 @@ description: "Set up version-controlled agents in your repository and run them w Before starting, ensure you have: -- [Continue CLI installed](/cli/install) +- [Continue CLI installed](/cli/quickstart) - `ANTHROPIC_API_KEY` environment variable set - [GitHub CLI](https://cli.github.com/) installed locally if your agents interact with GitHub (pre-installed on GitHub-hosted runners) @@ -226,7 +226,7 @@ When running agents in CI/CD, follow the principle of least privilege: --agent .continue/agents/analysis-only.md ``` - Learn more in the [CLI documentation](/cli/overview#how-to-set-tool-permissions). + Learn more in the [CLI documentation](/cli/tool-permissions). @@ -355,11 +355,11 @@ your-repo/ ## Next Steps - - Learn about agent components and capabilities + + Learn about agents, triggers, and automation - + Full Continue CLI documentation diff --git a/docs/guides/sanity-mcp-continue-cookbook.mdx b/docs/guides/sanity-mcp-continue-cookbook.mdx index 8a82b2f81fa..291b8c2291f 100644 --- a/docs/guides/sanity-mcp-continue-cookbook.mdx +++ b/docs/guides/sanity-mcp-continue-cookbook.mdx @@ -369,7 +369,7 @@ Navigate to **Repository Settings → Secrets and variables → Actions** and ad ### Create Workflow File -This workflow automatically validates your Sanity schemas and content on pull requests using the Continue CLI in [headless mode](/cli/overview#headless-mode%3A-production-automation). It checks schema integrity, validates content relationships, and posts a summary report as a PR comment. +This workflow automatically validates your Sanity schemas and content on pull requests using the Continue CLI in [headless mode](/cli/headless-mode). It checks schema integrity, validates content relationships, and posts a summary report as a PR comment. Create `.github/workflows/sanity-content-validation.yml` in your repository: diff --git a/docs/index.mdx b/docs/index.mdx index bb0a6e4f7ae..bd745252b98 100644 --- a/docs/index.mdx +++ b/docs/index.mdx @@ -1,49 +1,41 @@ --- title: "What is Continue?" -description: "Run agents as CI checks on every PR" --- +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. +