[codex] feat(slash): add guide mode

[yzlu0917]

Summary

• add a built-in /guide slash command for Continue IDE experiences that turns rough ideas into structured implementation briefs
• add matching /guide handling to Continue CLI so the feature works across interfaces instead of only in the GUI flow
• document the new slash command and add regression tests for command registration and config loading

Why

Continue already has slash commands for specific workflows like onboarding a codebase, but there is no built-in workflow for helping a user clarify a vague project idea before implementation. This PR adds a lightweight Guide Mode that asks discovery questions, then helps the user arrive at a clearer project spec, implementation plan, and starter prompt.

User Impact

Users can now start with /guide and a rough idea such as build a portfolio site for junior developers, then let Continue refine that into something concrete before jumping into code. The command is available in both the IDE experience and cn.

Validation

• ran npm test -- src/slashCommands.test.ts src/commands/commands.integration.test.ts in extensions/cli
• ran npm run vitest -- config/profile/doLoadConfig.vitest.ts in core
• ran npm run lint in extensions/cli (passes with 2 pre-existing warnings)
• ran targeted Prettier formatting on the touched files
• ran git diff --check

Closes #10340

---

Summary by cubic

Add Guide Mode via /guide in the IDE and cn to turn rough ideas into a structured brief and plan. Also gate Ollama tools to supported templates, avoid global path side effects for local profiles, and add OpenRouter headers for proper attribution.

• New Features

  • Added /guide in IDE and cn; asks focused questions, then outputs a spec, 3–6 step plan, and a starter prompt.
  • Included by default during config load (with dedupe) and added to SYSTEM_SLASH_COMMANDS with optional idea input.
  • Docs updated with a /guide CLI example; JSON reference documents the command. Tests cover command registration and /guide handling.

• Bug Fixes

  • Ollama: only send tools when the model template advertises support; tests verify gating.
  • Config: opening a local profile uses the workspace sourceFile when provided and does not call the global config path; unit test added.
  • OpenRouter: all requests include OPENROUTER_HEADERS from @continuedev/openai-adapters with updated header names for attribution and categorization.
  • Tests: hardened doLoadConfig tests to avoid PackageIdentifier.fileUri narrowing assumptions.

^{Written for commit 61cf4a3. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 9 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="core/config/profile/doLoadConfig.ts">

<violation number="1" location="core/config/profile/doLoadConfig.ts:193">
P2: Built-in `/guide` is appended without duplicate-name guarding, allowing silent collisions with user-defined `/guide` slash commands.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[chatgpt-codex-connector]

💡 Codex Review

continue/core/llm/llms/Ollama.ts

Lines 514 to 515 in a7db9ed

	if (options.tools?.length && ollamaMessages.at(-1)?.role === "user") {
	chatOptions.tools = options.tools.map((tool) => ({

Restore Ollama template gate before attaching tools

The new condition now attaches chatOptions.tools whenever tools are present and the last message is from the user, but it no longer checks whether the model template advertises tool support. In this file, ensureModelInfo() still inspects template capabilities, so removing that guard regresses behavior for Ollama models whose templates do not support tools: tool-enabled chats can now hard-fail instead of falling back to plain chat. This is especially user-visible in agent/tool workflows with non-tool-capable Ollama models.

---

continue/core/config/ConfigHandler.ts

Lines 639 to 640 in a7db9ed

	getConfigYamlPath();
	const configFile = element?.sourceFile ?? profile.profileDescription.uri;

Avoid forcing global config writes for all local profiles

Calling getConfigYamlPath() unconditionally for every local profile introduces an unrelated filesystem side effect before opening the selected file. Workspace-local profiles (for example under .continue/agents or .continue/configs) now trigger a write/create attempt in ~/.continue, and in read-only or restricted home-directory environments that can throw and prevent ide.openFile(...) from running. Opening a workspace profile should not depend on mutating global config state.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".