From a787164940dc1727d817cd3b935b733d60df4374 Mon Sep 17 00:00:00 2001 From: sarthakNITT Date: Thu, 26 Mar 2026 02:01:28 +0530 Subject: [PATCH 1/4] npm i --- binary/package-lock.json | 1 + core/package-lock.json | 1 + extensions/vscode/package-lock.json | 4 ++-- packages/openai-adapters/package-lock.json | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/binary/package-lock.json b/binary/package-lock.json index b2c7b0b5f5..7be0100f7a 100644 --- a/binary/package-lock.json +++ b/binary/package-lock.json @@ -42096,6 +42096,7 @@ "dependencies": { "@ai-sdk/anthropic": "^3.0.44", "@ai-sdk/deepseek": "^2.0.20", + "@ai-sdk/google": "^3.0.30", "@ai-sdk/openai": "^3.0.29", "@ai-sdk/xai": "^3.0.57", "@anthropic-ai/sdk": "^0.67.0", diff --git a/core/package-lock.json b/core/package-lock.json index 4fac30298e..007e91c4ff 100644 --- a/core/package-lock.json +++ b/core/package-lock.json @@ -223,6 +223,7 @@ "dependencies": { "@ai-sdk/anthropic": "^3.0.44", "@ai-sdk/deepseek": "^2.0.20", + "@ai-sdk/google": "^3.0.30", "@ai-sdk/openai": "^3.0.29", "@ai-sdk/xai": "^3.0.57", "@anthropic-ai/sdk": "^0.67.0", diff --git a/extensions/vscode/package-lock.json b/extensions/vscode/package-lock.json index caf51b31c6..e685658148 100644 --- a/extensions/vscode/package-lock.json +++ b/extensions/vscode/package-lock.json @@ -1,12 +1,12 @@ { "name": "continue", - "version": "1.3.33", + "version": "1.3.34", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "continue", - "version": "1.3.33", + "version": "1.3.34", "license": "Apache-2.0", "dependencies": { "@continuedev/config-types": "file:../../packages/config-types", diff --git a/packages/openai-adapters/package-lock.json b/packages/openai-adapters/package-lock.json index a30fb82b04..a1276bd731 100644 --- a/packages/openai-adapters/package-lock.json +++ b/packages/openai-adapters/package-lock.json @@ -10,8 +10,8 @@ "license": "Apache-2.0", "dependencies": { "@ai-sdk/anthropic": "^3.0.44", - "@ai-sdk/google": "^3.0.30", "@ai-sdk/deepseek": "^2.0.20", + "@ai-sdk/google": "^3.0.30", "@ai-sdk/openai": "^3.0.29", "@ai-sdk/xai": "^3.0.57", "@anthropic-ai/sdk": "^0.67.0", From 1aaef81d7f29202ca36aeb3c1b2cf1afaae906f7 Mon Sep 17 00:00:00 2001 From: sarthakNITT Date: Sat, 23 May 2026 01:19:33 +0530 Subject: [PATCH 2/4] fixed issue #12469 --- .agents/skills/docs-style/SKILL.md | 41 +++++++++++++++++++++ docs/customize/deep-dives/configuration.mdx | 31 ++++++++++++++++ 2 files changed, 72 insertions(+) create mode 100644 .agents/skills/docs-style/SKILL.md diff --git a/.agents/skills/docs-style/SKILL.md b/.agents/skills/docs-style/SKILL.md new file mode 100644 index 0000000000..d65086856c --- /dev/null +++ b/.agents/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/docs/customize/deep-dives/configuration.mdx b/docs/customize/deep-dives/configuration.mdx index 6acb9409ea..7edb18288d 100644 --- a/docs/customize/deep-dives/configuration.mdx +++ b/docs/customize/deep-dives/configuration.mdx @@ -28,6 +28,37 @@ When editing this file, you can see the available options suggested as you type, See the full reference for `config.yaml` [here](/reference). +### Local Config Profiles + +In addition to the main `config.yaml`, you can create multiple local config profiles by adding YAML files to a `.continue/configs/` directory: + +- `~/.continue/configs/` for profiles available across all workspaces +- `/.continue/configs/` for profiles available only in that workspace + +Each `.yaml` or `.yml` file is loaded as a separate local profile and appears in the config selector. Creating, editing, or deleting a file in `.continue/configs/` automatically reloads Continue. + +Local profile files use the same YAML schema as `config.yaml`. + +```text +.continue/ +|-- config.yaml +|-- configs/ +| |-- default.yaml +| `-- code-review.yaml +|-- agents/ +| `-- local-agent.yaml +`-- assistants/ + `-- local-assistant.yaml +``` + +Continue also discovers YAML profiles from these local directories: + +- `.continue/configs/` +- `.continue/agents/` +- `.continue/assistants/` + +Use `.continue/configs/` for general local config profiles. The `.continue/agents/` and `.continue/assistants/` directories are supported alongside it for existing local agent and assistant profiles. These directories can be placed in your workspace or in your global Continue directory. On Windows, use `%USERPROFILE%\.continue\configs\`, `%USERPROFILE%\.continue\agents\`, or `%USERPROFILE%\.continue\assistants\` for global profiles. + ## Legacy Configuration Methods (Deprecated) From 5ddf1deada0848ebf47130a3c72309f297c3a63e Mon Sep 17 00:00:00 2001 From: sarthakNITT Date: Sat, 23 May 2026 01:23:23 +0530 Subject: [PATCH 3/4] . --- .agents/skills/docs-style/SKILL.md | 41 ------------------------------ 1 file changed, 41 deletions(-) delete mode 100644 .agents/skills/docs-style/SKILL.md diff --git a/.agents/skills/docs-style/SKILL.md b/.agents/skills/docs-style/SKILL.md deleted file mode 100644 index d65086856c..0000000000 --- a/.agents/skills/docs-style/SKILL.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -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. From caffa8ca6747efa53002a332b4f05259e6e14e9d Mon Sep 17 00:00:00 2001 From: sarthakNITT Date: Sat, 23 May 2026 01:30:17 +0530 Subject: [PATCH 4/4] copilot suggestion 2 --- docs/customize/deep-dives/configuration.mdx | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/customize/deep-dives/configuration.mdx b/docs/customize/deep-dives/configuration.mdx index 7edb18288d..4a27116efe 100644 --- a/docs/customize/deep-dives/configuration.mdx +++ b/docs/customize/deep-dives/configuration.mdx @@ -39,6 +39,8 @@ Each `.yaml` or `.yml` file is loaded as a separate local profile and appears in Local profile files use the same YAML schema as `config.yaml`. +Example (global/user-level `~/.continue/` directory): + ```text .continue/ |-- config.yaml @@ -53,11 +55,11 @@ Local profile files use the same YAML schema as `config.yaml`. Continue also discovers YAML profiles from these local directories: -- `.continue/configs/` -- `.continue/agents/` -- `.continue/assistants/` + - `/.continue/configs/` or `~/.continue/configs/` (`%USERPROFILE%\.continue\configs\` on Windows for global profiles) + - `/.continue/agents/` or `~/.continue/agents/` (`%USERPROFILE%\.continue\agents\` on Windows for global profiles) + - `/.continue/assistants/` or `~/.continue/assistants/` (`%USERPROFILE%\.continue\assistants\` on Windows for global profiles) -Use `.continue/configs/` for general local config profiles. The `.continue/agents/` and `.continue/assistants/` directories are supported alongside it for existing local agent and assistant profiles. These directories can be placed in your workspace or in your global Continue directory. On Windows, use `%USERPROFILE%\.continue\configs\`, `%USERPROFILE%\.continue\agents\`, or `%USERPROFILE%\.continue\assistants\` for global profiles. +Use `.continue/configs/` for general local config profiles. The `.continue/agents/` and `.continue/assistants/` directories are supported alongside it for existing local agent and assistant profiles in either workspace-local or global Continue directories. ## Legacy Configuration Methods (Deprecated)