docs: fix enterprise license link to point to contact sales

- Update link in enterprise onboarding prerequisites from /enterprise to /contact-sales
- Add enterprise capabilities documentation
- Add implementation plan
- Add CVE scan sample CLI workflow

docs/enterprise-solutions/Cline_Enterprise_Capabilities_Manual.md

@@ -0,0 +1,458 @@
+# Cline Enterprise: Capabilities Manual
+
+**AI-Powered Coding Agent for Regulated Industries**
+
+## Table of Contents
+
+1. [Executive Summary](#executive-summary)  
+2. [Security & Data Architecture](#security--data-architecture)  
+3. [Developer Onboarding Path](#developer-onboarding-path)  
+4. [Bring Your Own Inference](#bring-your-own-inference)  
+5. [Identity, Access & Governance](#identity-access--governance)  
+6. [Monitoring & Observability](#monitoring--observability)  
+7. [Core Agent Capabilities](#core-agent-capabilities)  
+8. [Customization & Policy Enforcement](#customization--policy-enforcement)  
+9. [Extensibility — MCP Servers](#extensibility--mcp-servers)  
+10. [CLI & CI/CD Automation](#cli--cicd-automation)  
+11. [Resources & Support](#resources--support)
+
+## Executive Summary
+
+Cline is an open-source AI coding agent that runs entirely inside your developer's editor, whether it be VS Code, JetBrains, Cursor, or the terminal. It reads files, runs commands, and builds features through natural language, with every action visible and requiring explicit developer approval.
+
+For organizations in regulated industries (financial services, healthcare, government, defense, energy, pharmaceuticals, etc) Cline Enterprise adds the governance, observability, and security controls that compliance and platform teams require:
+
+- **Zero-trust, client-side architecture** — Code never leaves your environment. No uploads. No indexing. No training.  
+- **Bring Your Own Inference** — Connect your preferred provider (AWS Bedrock, GCP Vertex AI, Azure OpenAI, or local models). Cline is the harness; you own the inference.  
+- **Enterprise SSO & RBAC** — Authenticate via your identity provider. Enforce role-based access. Manage centrally.  
+- **Full observability** — OpenTelemetry export to your existing monitoring stack for usage, cost, and audit trail integration.  
+- **Open source** — Every line of code is on [GitHub](https://github.com/cline/cline) with 50,000+ stars. Full auditability for your security review process.
+
+Cline Enterprise is designed so that your security, compliance, and infrastructure teams can approve it. Your developers will actually want to use it.
+
+## Security & Data Architecture
+
+### Zero-Trust by Design
+
+Cline operates under a zero-trust model. The agent runs entirely on the developer's workstation. There is no server-side component processing code, no cloud relay, and no intermediary between the developer and their chosen inference provider.
+
+| Security Property | Detail |
+| :---- | :---- |
+| **Code residency** | All code stays on the developer's machine. Nothing is uploaded to Cline's infrastructure. |
+| **Inference path** | API calls go directly from the developer's machine to your configured provider (e.g., AWS Bedrock in your VPC). Cline does not proxy, cache, or log these calls. |
+| **No codebase indexing** | Cline does not build vector indexes, embeddings, or caches of your repositories. Context is gathered locally on-demand, per-task. |
+| **No model training** | Your code, prompts, and outputs are never used for model training — by Cline or by the inference provider (subject to your provider agreement). |
+| **Open-source codebase** | The full source is available for security review at [github.com/cline/cline](https://github.com/cline/cline). |
+
+### Human-in-the-Loop Controls
+
+Cline proposes; the developer decides. When Cline wants to edit a file, it shows the diff and waits. When it wants to run a shell command, it shows the command and waits. Nothing executes until the developer hits approve.
+
+In practice, this means a developer reviewing a Cline session sees the same granularity they'd see in a code review: every proposed change, every command, every browser action. Auditors and team leads can look at a task's history and see exactly what was requested, what was approved, and what was executed.
+
+For teams that want to move faster on trusted operations, auto-approval policies let you selectively relax this. For example: allow file reads without prompting, but always require approval for writes and shell commands. Platform teams set these policies centrally via remote configuration, individual developers can't override them.
+
+### File Access Controls
+
+The `.clineignore` file lets organizations define files and directories that Cline cannot access similar to `.gitignore` syntax. Use this to enforce boundaries around:
+
+- Secrets and credential files  
+- Regulated data directories  
+- Legacy or sensitive code paths  
+- Third-party proprietary code
+
+### Network & Proxy Support
+
+Cline supports enterprise proxy configurations out of the box:
+
+- HTTP/HTTPS proxy via environment variables  
+- Custom certificate authorities for TLS inspection  
+- Compatibility with corporate network policies
+
+### Compliance Certifications
+
+Cline is SOC 2 certified. The full open-source codebase is available at [github.com/cline/cline](https://github.com/cline/cline) for independent security review by your team.
+
+## Developer Onboarding Path
+
+Most teams get through the essentials in one week. Here is the recommended path:
+
+### Week 1: Core Competency
+
+| Day | Focus | Module | Outcome |
+| :---- | :---- | :---- | :---- |
+| 1–2 | **Install & First Prompt** | Getting Started | Developer has Cline installed, connected to the org's provider, and has run their first successful prompt. |
+| 2–3 | **Plan & Act Mode** | Plan & Act | Developer understands when to plan vs. execute. Can use Plan mode to explore code and Act mode to implement changes. |
+| 3–4 | **Prompting Techniques** | Effective Prompts | Developer avoids common prompt mistakes. Knows zero-shot, one-shot, and chain-of-thought techniques. |
+| 5 | **Checkpoints & Context** | Context Management | Developer uses checkpoints to restore state. Understands context windows and when to use `/newtask` or `/smol`. |
+
+### Week 2–3: Advanced Skills
+
+| Focus | Module | Outcome |
+| :---- | :---- | :---- |
+| **Custom Rules** | Customization | Developer creates and uses `.clinerules` for team standards. Understands conditional rules. |
+| **Memory Bank** | Customization | Developer sets up Memory Bank for project continuity across sessions. |
+| **Tools & Features** | Tools & Features | Developer uses @-mentions, slash commands, and auto-approve effectively. |
+| **MCP Servers** | MCP | Developer can install and use MCP servers. Understands how to request custom servers. |
+
+### Key Resources for Onboarding
+
+| Resource | URL |
+| :---- | :---- |
+| Full Documentation | [docs.cline.bot](https://docs.cline.bot) |
+| Bad Prompt Examples | [cline.bot/blog/the-worst-instructions-you-can-give-an-ai-coding-agent](https://cline.bot/blog/the-worst-instructions-you-can-give-an-ai-coding-agent) |
+| Community Prompts | [github.com/cline/prompts](https://github.com/cline/prompts) |
+| Model Selection Guide | [docs.cline.bot/core-features/model-selection-guide](https://docs.cline.bot/core-features/model-selection-guide) |
+| Plan & Act Deep Dive | [cline.bot/blog/plan-smarter-code-faster-clines-plan-act-is-the-paradigm-for-agentic-coding](https://cline.bot/blog/plan-smarter-code-faster-clines-plan-act-is-the-paradigm-for-agentic-coding) |
+| Context Window Explained | [cline.bot/blog/clines-context-window-explained-maximize-performance-minimize-cost](https://cline.bot/blog/clines-context-window-explained-maximize-performance-minimize-cost) |
+| Memory Bank Guide | [cline.bot/blog/memory-bank-how-to-make-cline-an-ai-agent-that-never-forgets](https://cline.bot/blog/memory-bank-how-to-make-cline-an-ai-agent-that-never-forgets) |
+| MCP Servers Explained | [cline.bot/blog/mcp-servers-explained-what-they-are-how-they-work-and-why-cline-is-revolutionizing-ai-tools](https://cline.bot/blog/mcp-servers-explained-what-they-are-how-they-work-and-why-cline-is-revolutionizing-ai-tools) |
+| Cline CLI | [docs.cline.bot/cline-cli/overview](https://docs.cline.bot/cline-cli/overview) |
+
+## Bring Your Own Inference
+
+Cline is a harness. You bring your own inference. Connect your preferred provider, and Cline sends API calls directly from the developer's machine to that provider. There is no Cline relay, proxy, or middleware in the path.
+
+### Supported Providers
+
+Cline supports a wide range of inference providers. For enterprise deployments, these fall into three categories:
+
+**1. Online Providers (Direct API)**
+
+Direct API connections to hosted model providers. API calls go from the developer's machine to the provider's endpoint.
+
+- Anthropic (Claude), OpenAI, Google Gemini, DeepSeek, Mistral, xAI (Grok), Together, Fireworks, Groq, SambaNova, Cerebras, and others
+- Aggregators like OpenRouter and Requesty that route to multiple model providers
+
+**2. Virtual Cloud Providers (VCP): Within Your Cloud Account**
+
+For organizations that need inference to stay inside their cloud environment. Traffic stays in your account and region.
+
+- **AWS Bedrock**: IAM-based authentication. Inference stays in your VPC. Works with CloudTrail for audit logging.
+- **Google Vertex AI**: Service account authentication. Runs in your GCP project.
+- **Azure OpenAI**: AAD authentication. Managed endpoint in your Azure subscription.
+- **LiteLLM**: Self-hosted proxy that can front any provider. Deploy in your own infrastructure.
+
+**3. Local Models: No Network Egress**
+
+For air-gapped environments or teams that need to run models on-premises with zero network calls.
+
+- **Ollama**: Run open-weight models locally.
+- **LM Studio**: Local model hosting with a GUI.
+- Any **OpenAI-compatible** local endpoint.
+
+### Why This Matters for Regulated Industries
+
+- **Data residency**: With VCP or local providers, inference stays within your cloud account, region, or machine.
+- **Model governance**: Platform teams control which models developers can access via remote configuration.
+- **Air-gapped deployment**: Local models work in environments with no internet access.
+
+### Remote Provider Configuration
+
+Admins configure the organization's inference provider centrally. Developers authenticate via SSO and are automatically connected, so there are no API keys on laptops.
+
+Supported remote configuration paths:
+
+- [AWS Bedrock — Admin Configuration](https://docs.cline.bot/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration)  
+- [GCP Vertex AI — Admin Configuration](https://docs.cline.bot/enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration)  
+- [OpenAI Compatible (including Azure Foundry) — Admin Configuration](https://docs.cline.bot/enterprise-solutions/configuration/remote-configuration/openai-compatible/admin-configuration)  
+- [Anthropic — Admin Configuration](https://docs.cline.bot/enterprise-solutions/configuration/remote-configuration/anthropic/admin-configuration)  
+- [LiteLLM — Admin Configuration](https://docs.cline.bot/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration)
+
+## Identity, Access & Governance
+
+### SSO Authentication
+
+Cline Enterprise integrates with your existing identity provider via WorkOS. Supported providers include Okta, Azure AD (Entra ID), Google Workspace, and any SAML/OIDC-compatible IdP. Users are provisioned automatically on first sign-in. No manual invites or seat management required.
+
+For setup instructions, see the [SSO Setup Guide](https://docs.cline.bot/enterprise-solutions/sso-setup).
+
+### Role-Based Access Control
+
+Three-tier hierarchy with organization-scoped permissions:
+
+| Role | Capabilities |
+| :---- | :---- |
+| **Owner** | Full control. Manage billing, SSO configuration, and organization settings. |
+| **Admin** | Manage members, configure providers, set governance policies. |
+| **Member** | Use Cline with the models and features enabled by their organization. |
+
+Roles map automatically from your identity provider. Admin in IdP → Admin in Cline. Member in IdP → Member in Cline.
+
+### Centralized Governance
+
+Platform teams can enforce policies organization-wide:
+
+- **Model allow-listing** — Restrict which AI models developers can access  
+- **Feature controls** — Govern auto-approval settings, tool access, and feature flags  
+- **Remote configuration** — Push settings to all developer installations from a central dashboard  
+- **Consistent deployment** — Configure once, deploy everywhere via your existing software distribution
+
+### Access Lifecycle Management
+
+| Event | What Happens |
+| :---- | :---- |
+| User added to IdP | Access granted automatically on first SSO sign-in |
+| Role changed in IdP | Updated on next sign-in |
+| User removed from IdP | Access revoked automatically |
+
+No Cline-specific user management required. Your directory is the source of truth.
+
+## Monitoring & Observability
+
+### OpenTelemetry Integration
+
+Cline exports telemetry via OTLP (OpenTelemetry Protocol). It supports gRPC, HTTP/JSON, and HTTP/protobuf transport, so it works with any OTLP-compatible backend: Datadog, Grafana, Splunk, New Relic, or your own collector.
+
+### What You Can Track
+
+Cline emits structured metrics and log events via OpenTelemetry:
+
+- **Token usage**: Input and output tokens per request and cumulative totals, broken down by model
+- **Cost**: Per-event and cumulative cost, attributed to task and model
+- **API performance**: Time to first token, request duration, throughput (tokens/sec)
+- **Tool calls**: Count of tool invocations per task, broken down by tool name
+- **Errors**: Error counts per task and total, with error type attributes
+- **Cache efficiency**: Cache read/write token counts and hit rates
+- **Task activity**: Turn counts per task, task lifecycle events
+- **User and auth events**: Sign-in, sign-out, and identification events with organization context
+
+### Compliance Value
+
+All telemetry is exported to your infrastructure. No data is sent to Cline.
+
+- **Cost visibility**: Token and cost metrics let you track AI spend per model and set budget alerts in your monitoring stack.
+- **Usage auditing**: Token, model, and task data provide an auditable record of AI usage across the organization.
+- **Alerting**: Raw metrics in your observability platform let you build alerts for unusual patterns.
+
+## Core Agent Capabilities
+
+Cline's agent loop gives developers a structured workflow for AI-assisted development. Every capability below operates with human-in-the-loop approval by default.
+
+### Plan & Act Mode
+
+Cline's dual-mode system separates thinking from doing:
+
+- **Plan mode** — Cline explores the codebase, gathers context, and discusses strategy. It can read files and search code but cannot modify anything. Use this for architecture decisions, debugging investigations, and code review.  
+- **Act mode** — Cline implements the plan. It can edit files, run commands, and execute the strategy discussed in Plan mode. Full context from planning carries over.
+
+This separation is intentional. It prevents wasted tokens, reduces errors, and creates a natural review checkpoint before any code changes occur.
+
+**Different models for each mode** — Use a stronger reasoning model (e.g., Claude Opus) for planning and a faster model (e.g., Claude Sonnet) for implementation to optimize cost and quality.
+
+### Built-In Tools
+
+| Category | Capabilities |
+| :---- | :---- |
+| **File operations** | Read, write, search, and analyze code across the project. Targeted edits with diff-based precision. |
+| **Terminal** | Execute CLI commands with real-time output streaming. Run tests, install packages, debug errors. |
+| **Browser** | Launch a Puppeteer-controlled browser to test web apps, capture screenshots, interact with pages. |
+| **Code intelligence** | List code definitions, search with regex, understand project structure. |
+| **Task management** | Context handoff between tasks, conversation compression, follow-up questions. |
+
+### Context Management
+
+AI models have finite context windows. Cline provides multiple tools to manage this efficiently:
+
+- **Checkpoints** — Automatic snapshots of project state. Restore to any previous point instantly, rather than manually undoing changes.  
+- **`/newtask`** — Start a new task with distilled context from the current session. Like a developer handoff.  
+- **`/smol`** — Compress conversation history within the same task to free context space.  
+- **Auto-Compact** — Automatic context compression as you work.  
+- **`@`\-mentions** — Reference specific files, folders, URLs, terminal output, and git diffs to give Cline precise context without loading the entire project.
+
+### Deep Planning
+
+For complex tasks, the `/deep-planning` command triggers a structured four-step planning process before any code is written:
+
+1. **Silent investigation**: Cline reads files and runs terminal commands (project structure discovery, class/function scanning, dependency analysis, TODO identification) to build a thorough understanding of the codebase. It does this without narration so the developer is not interrupted.
+2. **Targeted questions**: Cline asks brief clarifying questions about ambiguous requirements, competing implementation approaches, or assumptions that need confirmation.
+3. **Implementation plan document**: Cline writes a structured `implementation_plan.md` covering the overview, type changes, file modifications, function and class changes, dependencies, testing strategy, and implementation order. This document is concrete enough that another developer could execute it without further investigation.
+4. **Task handoff**: Cline creates a new task from the plan with a tracked progress checklist, then switches to Act mode for execution. The plan document serves as the reference throughout implementation.
+
+This is useful for large refactors, cross-cutting changes, or any task where getting the approach wrong is expensive. The plan document is a reviewable artifact that lives in the repository.
+
+## Customization & Policy Enforcement
+
+### Cline Rules
+
+Rules are markdown files that provide persistent instructions across all conversations. For enterprise teams, this is how you enforce coding standards, architectural constraints, and compliance requirements at the tool level.
+
+```
+your-project/
+├── .clinerules/
+│   ├── coding-standards.md      # Team coding conventions
+│   ├── security-policy.md       # Security review requirements
+│   ├── testing-requirements.md  # Coverage and test type mandates
+│   ├── architecture.md          # Structural constraints
+│   └── compliance.md            # Regulatory-specific rules
+```
+
+**Key features for regulated environments:**
+
+- **Version controlled** — Rules live in your repository. Changes are tracked, reviewed, and auditable.  
+- **Conditional activation** — Rules scope to specific file paths. Security rules activate only when editing security-sensitive code. Frontend rules don't load for backend work.  
+- **Global \+ workspace rules** — Set organization-wide defaults globally, override per-project as needed.  
+- **Cross-tool compatibility** — Cline also recognizes `.cursorrules`, `.windsurfrules`, and `AGENTS.md` formats.
+
+**Example: compliance-focused rule**
+
+```
+# Security & Compliance Rules
+
+## Data Handling
+- Never log PII (names, emails, SSNs, account numbers) to console or files
+- Use parameterized queries for all database access — no string interpolation
+- Encrypt sensitive data at rest using the patterns in /src/utils/encryption.ts
+
+## Authentication
+- All new endpoints require authentication middleware
+- Use the RBAC pattern in /src/middleware/auth.ts — do not create custom auth
+- Token expiry must not exceed 15 minutes for API tokens
+
+## Audit
+- All data mutations must emit an audit event via /src/services/audit.ts
+- Include actor, action, resource, and timestamp in every audit entry
+```
+
+### .clineignore
+
+Define files and directories Cline cannot access, enforcing information barriers at the tool level:
+
+```
+# Secrets and credentials
+.env*
+secrets/
+**/credentials.json
+
+# Regulated data
+data/pii/
+data/phi/
+
+# Third-party proprietary code
+vendor/proprietary/
+```
+
+### Memory Bank
+
+Memory Bank is a structured documentation system that maintains project context across sessions. For enterprise teams, this ensures continuity when developers rotate between projects or when onboarding new team members:
+
+```
+memory-bank/
+├── projectbrief.md      # Foundation document — requirements, goals
+├── productContext.md     # Why the project exists, user experience goals
+├── activeContext.md      # Current focus, recent changes, next steps
+├── systemPatterns.md     # Architecture, design patterns, decisions
+├── techContext.md        # Tech stack, dependencies, constraints
+└── progress.md           # Status, milestones, known issues
+```
+
+## Extensibility — MCP Servers
+
+MCP (Model Context Protocol) is an open protocol that lets Cline connect to external tools and data sources. For enterprise teams, this means Cline can integrate with your internal systems without custom development.
+
+### How MCP Works
+
+MCP servers are lightweight programs that expose tools to Cline through a standardized interface. Think of it as a plugin system where each server provides a set of capabilities that Cline can invoke during a task.
+
+### Enterprise Use Cases
+
+| Category | Examples |
+| :---- | :---- |
+| **Internal APIs** | Query internal services, retrieve configuration, interact with proprietary systems |
+| **Databases** | Run read-only queries, generate reports, analyze data patterns |
+| **Project management** | Create Jira tickets, update Confluence pages, sync with ServiceNow |
+| **Documentation** | Access internal wikis, API docs, runbooks |
+| **Security scanning** | Trigger SAST/DAST scans, retrieve vulnerability reports |
+| **Compliance** | Check policy databases, validate configurations against baselines |
+
+### Getting Started
+
+- **MCP Marketplace** — Browse and install pre-built servers: [docs.cline.bot/mcp/mcp-marketplace](https://docs.cline.bot/mcp/mcp-marketplace)  
+- **Build custom servers** — Cline can help build MCP servers tailored to your internal tools using the [MCP SDK](https://github.com/modelcontextprotocol/)  
+- **Security** — Servers isolate credentials and sensitive data. All tool executions require explicit user approval.
+
+### Transport Options
+
+| Type | Use Case |
+| :---- | :---- |
+| **stdio** | Command-line servers running locally on the developer's machine |
+| **SSE** | HTTP-based servers for shared infrastructure or remote deployment |
+
+---
+
+## CLI & CI/CD Automation
+
+Cline CLI brings the full agent capabilities to your terminal and automation pipelines. It supports all the same providers, MCP servers, and rules as the editor extension.
+
+### Interactive Mode
+
+For terminal-first developers:
+
+```shell
+cline
+```
+
+Rich terminal interface with real-time conversation, syntax highlighting, @-mentions, slash commands, and keyboard shortcuts.
+
+### Headless Mode
+
+For automation, scripting, and CI/CD:
+
+```shell
+# Automated code review in CI
+gh pr diff $PR_NUMBER | cline -y "Review for security issues, PII exposure, and SQL injection"
+
+# Automated dependency audit
+cline -y "Identify dependencies with known CVEs and suggest updates"
+
+# Generate compliance documentation
+cline -y "Generate API documentation for all public endpoints in src/api/"
+
+# Release notes from commits
+git log --oneline v1.0..v1.1 | cline -y "Write release notes"
+```
+
+### CI/CD Integration Patterns
+
+| Pattern | Command | Value |
+| :---- | :---- | :---- |
+| **PR security review** | `gh pr diff N | cline -y "Review for security issues"` | Catch vulnerabilities before merge |
+| **Test failure remediation** | `cline -y "Run tests and fix failures" --timeout 600` | Automated fix-and-verify loop |
+| **Documentation drift** | `cline -y "Verify API docs match implementation"` | Keep docs in sync |
+| **Dependency scanning** | `cline -y "Audit dependencies for CVEs"` | Continuous vulnerability monitoring |
+| **Code standards** | `cline -y "Check for coding standard violations in changed files"` | Automated style enforcement |
+
+### Output Formats
+
+- **Text** — Human-readable output for logs and reviews  
+- **JSON** — Machine-parseable output for pipeline integration: `cline --json "task" | jq '.text'`
+
+## Tailoring Cline to Your Organization
+
+We work with enterprise customers to create organization-specific configurations:
+
+- **Custom `.clinerules` templates** aligned to your coding standards, security policies, and regulatory requirements  
+- **Custom MCP servers** connecting Cline to your internal tools, APIs, and documentation  
+- **Provider configuration** tuned to your cloud contracts and model governance policies  
+- **Onboarding materials** tailored to your team's languages, frameworks, and workflows
+
+To get started, share:
+
+1. Primary languages and frameworks your team uses  
+2. Coding standards or conventions documents  
+3. Common task types (bug fixes, feature development, code reviews, compliance checks)  
+4. Internal tools or systems that would benefit from Cline integration  
+5. Any regulatory or compliance requirements that should be encoded as rules
+
+## Resources & Support
+
+| Resource | Link |
+| :---- | :---- |
+| **Full Documentation** | [docs.cline.bot](https://docs.cline.bot) |
+| **Enterprise Overview** | [docs.cline.bot/enterprise-solutions/overview](https://docs.cline.bot/enterprise-solutions/overview) |
+| **GitHub (Source Code)** | [github.com/cline/cline](https://github.com/cline/cline) |
+| **Discord Community** | [discord.gg/cline](https://discord.gg/cline) |
+| **Reddit** | [reddit.com/r/cline](https://www.reddit.com/r/cline/) |
+| **Enterprise Inquiries** | [cline.bot/enterprise](https://cline.bot/enterprise) |
+
+*Cline is open-source software. Enterprise features provide governance, observability, and support on top of the same agent that millions of developers trust*  

docs/enterprise-solutions/onboarding.mdx

@@ -10,7 +10,7 @@ Cline Enterprise integrates with your existing identity provider (IdP) via WorkO
 
 ## Prerequisites
 
-- [Cline Enterprise License](https://cline.bot/enterprise)
+- [Cline Enterprise License](https://cline.bot/contact-sales)
 - Access to your identity provider (IdP) configuration (e.g., Okta, Azure AD, Google Workspace)
 - Knowledge of your organization's SSO requirements
 

implementation_plan.md

@@ -0,0 +1,201 @@
+# Implementation Plan
+
+[Overview]
+Create 6 new documentation pages (and 1 update to an existing page) to address the most significant gaps in Cline's user-facing documentation.
+
+After a comprehensive cross-reference of every feature in the Cline codebase against the existing docs site, 6 high-impact features were identified as having little to no documentation despite being fully shipped, user-facing capabilities. Each documentation page will be created as an independent unit suitable for its own PR. All pages follow the established Mintlify `.mdx` format with YAML frontmatter (`title`, `sidebarTitle`, `description`), no H1 headings (title comes from frontmatter), H2 for major sections, H3 for subsections, and Mintlify callout components (`<Tip>`, `<Warning>`, `<Note>`, `<Info>`) for admonitions. The `docs/docs.json` navigation file must be updated for each new page to wire it into the site.
+
+The 6 PRs in priority order:
+1. **Prompts Library** — Major user-facing feature with zero documentation
+2. **Commands & Keybindings Reference** — 18+ VS Code commands and 3 keybindings with no unified reference
+3. **VS Code Extension API** — Extension-to-extension `ClineAPI` interface with zero docs-site presence
+4. **Tools Reference Update** — Existing page missing 14 of 27 tools
+5. **Explain Changes Feature** — Full `/explain-changes` slash command with no dedicated page
+6. **Context Management Deep-Dive** — Only the "Auto Compact" surface is documented; underlying system invisible to users
+
+[Types]
+No new TypeScript types, interfaces, or data structures are needed — this is a documentation-only task.
+
+All referenced types already exist in the codebase:
+- `PromptItem` interface in `src/shared/prompts.ts` — fields: `promptId`, `githubUrl`, `name`, `author`, `description`, `content`, `type` (enum: `"rule"`, `"workflow"`, `"hook"`, `"skill"`), `tags`
+- `ClineAPI` interface in `src/exports/cline.d.ts` — methods: `startNewTask(task?, images?)`, `sendMessage(message?, images?)`, `pressPrimaryButton()`, `pressSecondaryButton()`
+- `ClineDefaultTool` enum in `src/shared/tools.ts` — 27 values (see Tools Reference section below for full list)
+- `ContextManager` class in `src/core/context/context-management/ContextManager.ts` — truncation strategies: `"none"`, `"lastTwo"`, `"half"`, `"quarter"`
+
+[Files]
+6 new documentation files and 1 updated existing file, plus `docs.json` navigation updates for each PR.
+
+### New Files
+
+**PR 1:** `docs/features/prompts-library.mdx`
+- Purpose: Document the Prompts Library feature — browsing, searching, applying, and removing community prompts
+- Sections: What is the Prompts Library, Accessing It, Browsing & Searching, Applying a Prompt (with per-type file destinations), Removing a Prompt, CLI Support, Submitting Your Own Prompts
+- Source of truth: `src/services/prompts/PromptsService.ts`, `src/shared/prompts.ts`, `webview-ui/src/components/prompts/PromptsLibraryView.tsx`, `src/core/controller/prompts/applyPrompt.ts`, `src/core/controller/prompts/removePrompt.ts`
+
+**PR 2:** `docs/core-workflows/commands-and-keybindings.mdx`
+- Purpose: Unified reference for all VS Code commands, keyboard shortcuts, context menu actions, and IDE integrations
+- Sections: Keyboard Shortcuts, Editor Context Menu, Terminal Context Menu, SCM Integration (Git Commit Message Generation), Code Review Integration, Command Palette Commands, Jupyter Notebook Commands
+- Source of truth: `package.json` "contributes" section (commands, keybindings, menus)
+
+**PR 3:** `docs/features/extension-api.mdx`
+- Purpose: Document the `ClineAPI` interface for extension-to-extension integration
+- Sections: What is the Extension API, Accessing the API, API Methods (with signatures and examples), Use Cases
+- Source of truth: `src/exports/cline.d.ts`, `src/exports/index.ts`, `src/exports/README.md`
+
+**PR 5:** `docs/features/explain-changes.mdx`
+- Purpose: Document the `/explain-changes` slash command and its multi-file diff view with AI-generated inline comments
+- Sections: What is Explain Changes, How to Use It, Git Reference Formats, Understanding the Output, Use Cases
+- Source of truth: `src/core/controller/task/explainChanges.ts`, `src/core/slash-commands/index.ts`
+
+**PR 6:** `docs/features/context-management.mdx`
+- Purpose: Deep-dive into how Cline manages context windows — what counts toward context, optimization strategies, truncation, and tips
+- Sections: How Context Works, What Counts Toward Your Context Window, Context Optimizations (duplicate file read detection), Truncation Strategies, Model-Specific Context Windows, Auto Compact, The Condense Tool, Tips for Staying Within Limits
+- Source of truth: `src/core/context/context-management/ContextManager.ts`, `docs/features/auto-compact.mdx` (cross-reference), `docs/model-config/context-windows.mdx` (cross-reference)
+
+### Modified Files
+
+**PR 4:** `docs/tools-reference/all-cline-tools.mdx` (UPDATE existing file)
+- Purpose: Add the 14 missing tools to the existing tools reference page
+- Missing tools to add: `apply_patch`, `web_search`, `web_fetch`, `new_task`, `condense`, `summarize_task`, `focus_chain`, `use_skill`, `use_subagents`, `generate_explanation`, `new_rule`, `report_bug`, `plan_mode_respond`, `act_mode_respond`
+- Source of truth: `src/shared/tools.ts` (ClineDefaultTool enum), tool handler files in `src/core/task/tools/handlers/`, tool definitions in `src/core/prompts/system-prompt/tools/`
+
+**ALL PRs:** `docs/docs.json` (UPDATE navigation)
+- PR 1: Add `"features/prompts-library"` to the Features group pages array
+- PR 2: Add `"core-workflows/commands-and-keybindings"` to the Core Workflows group pages array
+- PR 3: Add `"features/extension-api"` to the Features group pages array
+- PR 4: No `docs.json` change needed (page already exists)
+- PR 5: Add `"features/explain-changes"` to the Features group pages array
+- PR 6: Add `"features/context-management"` to the Features group pages array
+
+[Functions]
+No new functions are needed — this is a documentation-only task.
+
+All referenced functions already exist:
+- `PromptsService.fetchCatalog()` — fetches prompt catalog from GitHub API (`https://api.github.com/repos/cline/prompts/git/trees/main?recursive=1`)
+- `applyPrompt(controller, request)` — writes prompt content to the appropriate file path based on prompt type
+- `removePrompt(controller, request)` — deletes the prompt file from disk
+- `fetchPromptsCatalog(controller, request)` — RPC handler that calls PromptsService
+- `explainChanges(controller, request)` — generates AI explanations for git diffs between two refs
+- `ContextManager.shouldCompactContextWindow()` — checks if token usage exceeds threshold
+- `ContextManager.getNextTruncationRange()` — calculates next truncation range with strategy
+- `ContextManager.applyContextOptimizations()` — detects and replaces duplicate file reads
+
+[Classes]
+No new classes are needed — this is a documentation-only task.
+
+Referenced classes for accurate documentation:
+- `PromptsService` in `src/services/prompts/PromptsService.ts` — singleton, 1-hour cache, fetches from GitHub Git Tree API
+- `ContextManager` in `src/core/context/context-management/ContextManager.ts` — instantiated per Task, handles all context window optimization
+
+[Dependencies]
+No new dependencies are needed — this is a documentation-only task.
+
+The docs site uses Mintlify (`docs/package.json`). No additional packages are required.
+
+[Testing]
+No automated tests are needed for documentation changes.
+
+Validation strategy:
+- Each `.mdx` file must have valid YAML frontmatter with `title`, `sidebarTitle`, and `description` fields
+- Each new page must be wired into `docs.json` navigation (except PR 4 which updates an existing page)
+- Cross-reference all technical claims against source code (file paths, function names, types, behaviors)
+- Verify no broken internal links (e.g., links to other docs pages use relative paths without `.mdx` extension)
+- Run the Mintlify dev server locally (`cd docs && npx mintlify dev`) to verify pages render correctly
+
+[Implementation Order]
+Each PR is independent and can be implemented in any order. The recommended sequence below optimizes for impact and minimizes cross-dependencies.
+
+1. **PR 1 — Prompts Library** (`docs/features/prompts-library.mdx` + `docs.json` update)
+   - Highest impact: major feature with zero docs, primary discovery mechanism for customization ecosystem
+   - No dependencies on other PRs
+   - Source files to read for accuracy: `src/shared/prompts.ts`, `src/services/prompts/PromptsService.ts`, `src/core/controller/prompts/applyPrompt.ts`, `src/core/controller/prompts/removePrompt.ts`, `webview-ui/src/components/prompts/PromptsLibraryView.tsx`
+   - Prompt types and their destination paths when applied:
+     - `"rule"` → `.clinerules/{name}.md`
+     - `"workflow"` → `.clinerules/workflows/{name}.md`
+     - `"hook"` → global hooks dir (`~/Documents/Cline/Hooks/`) or workspace (`.clinerules/hooks/`)
+     - `"skill"` → `.clinerules/skills/{name}.md`
+   - Catalog source: GitHub Git Tree API on `cline/prompts` repo
+   - UI access: Book icon button (📖) in Cline toolbar → PromptsLibraryView
+   - CLI access: `/settings` → Prompts tab in settings panel
+
+2. **PR 2 — Commands & Keybindings Reference** (`docs/core-workflows/commands-and-keybindings.mdx` + `docs.json` update)
+   - High impact: users constantly ask about keyboard shortcuts and miss context menu features
+   - No dependencies on other PRs
+   - Source file: `package.json` "contributes" section
+   - Exact keybindings to document:
+     - `Cmd+.` (Mac) / `Ctrl+.` (Win/Linux) → `cline.focusChatInput` (Jump to Chat Input)
+     - `Cmd+'` (Mac) / `Ctrl+'` (Win/Linux) → Opens Cline in editor tab (condition: `!cline.isInEditorPanel`)
+     - `Cmd+Shift+'` (Mac) / `Ctrl+Shift+'` (Win/Linux) → `cline.plusButtonClicked` (New Task in tab, condition: `cline.isInEditorPanel`)
+   - Exact context menu commands:
+     - Editor context menu: `cline.addToChat` ("Add to Cline"), `cline.explainCode` ("Explain with Cline"), `cline.improveCode` ("Improve with Cline")
+     - Terminal context menu: `cline.addTerminalOutputToChat` ("Add to Cline")
+     - SCM title bar: `cline.generateGitCommitMessage` ("Generate Commit Message with Cline")
+     - Jupyter: `cline.jupyterGenerateCell`, `cline.jupyterExplainCell`, `cline.jupyterImproveCell`
+     - Code review: `cline.reviewComment.reply` ("Reply"), `cline.reviewComment.addToChat` ("Add to Cline Chat")
+
+3. **PR 3 — VS Code Extension API** (`docs/features/extension-api.mdx` + `docs.json` update)
+   - High impact for developers building on Cline
+   - No dependencies on other PRs
+   - Source files: `src/exports/cline.d.ts`, `src/exports/index.ts`, `src/exports/README.md`
+   - Exact `ClineAPI` interface:
+     ```typescript
+     interface ClineAPI {
+       startNewTask(task?: string, images?: string[]): Promise<void>
+       sendMessage(message?: string, images?: string[]): Promise<void>
+       pressPrimaryButton(): Promise<void>
+       pressSecondaryButton(): Promise<void>
+     }
+     ```
+   - Access pattern:
+     ```typescript
+     const extension = vscode.extensions.getExtension("saoudrizwan.claude-dev")
+     if (extension) {
+       const api: ClineAPI = extension.isActive ? extension.exports : await extension.activate()
+     }
+     ```
+
+4. **PR 4 — Tools Reference Update** (update `docs/tools-reference/all-cline-tools.mdx`)
+   - High impact: users see tools in action but can't look them up
+   - No dependencies on other PRs, no `docs.json` change needed
+   - Source file: `src/shared/tools.ts` (ClineDefaultTool enum — 27 total values)
+   - Currently documented tools (~13): `execute_command`, `read_file`, `write_to_file`, `replace_in_file`, `search_files`, `list_files`, `list_code_definition_names`, `browser_action`, `use_mcp_tool`, `access_mcp_resource`, `ask_followup_question`, `attempt_completion`, `load_mcp_documentation`
+   - Tools to ADD (14):
+     - `apply_patch` — Apply a unified diff patch to modify files (newer alternative to replace_in_file)
+     - `web_search` — Search the web and return results with titles and URLs
+     - `web_fetch` — Fetch and analyze content from a URL
+     - `new_task` — Create a new sub-task (used by subagents feature)
+     - `condense` — Summarize the current conversation to free context space
+     - `summarize_task` — Generate a summary of the completed task
+     - `focus_chain` — Manage a structured focus chain / TODO list for complex tasks
+     - `use_skill` — Load and activate a specialized skill by name
+     - `use_subagents` — Run up to 5 parallel in-process subagents for broad exploration
+     - `generate_explanation` — Generate AI-powered inline comments explaining git changes
+     - `new_rule` — Create a new `.clinerules` file from conversation context
+     - `report_bug` — Report a bug or issue
+     - `plan_mode_respond` — Respond in Plan mode (conversational planning without tool execution)
+     - `act_mode_respond` — Respond in Act mode (internal counterpart to plan_mode_respond)
+
+5. **PR 5 — Explain Changes Feature** (`docs/features/explain-changes.mdx` + `docs.json` update)
+   - Medium-high impact: unique differentiating feature
+   - No dependencies on other PRs (though PR 4 will also mention this tool)
+   - Source files: `src/core/controller/task/explainChanges.ts`, `src/core/slash-commands/index.ts`
+   - Invocation: Type `/explain-changes` in the chat input
+   - Parameters: `from_ref` (required), `to_ref` (optional, defaults to working directory)
+   - Supported git ref formats: commit hashes, branch names, tags, relative refs (`HEAD~1`, `HEAD^`, `origin/main`)
+   - Output: Opens a multi-file diff view in VS Code with AI-generated inline comments explaining each change
+   - The slash command is registered in `SUPPORTED_DEFAULT_COMMANDS` array in `src/core/slash-commands/index.ts` as `"explain-changes"`
+   - The handler creates a `ClineSay` message of type `generate_explanation` which renders in the chat as a status indicator
+
+6. **PR 6 — Context Management Deep-Dive** (`docs/features/context-management.mdx` + `docs.json` update)
+   - High impact: context management is the #1 source of user confusion
+   - No dependencies on other PRs
+   - Source files: `src/core/context/context-management/ContextManager.ts`, `docs/features/auto-compact.mdx`, `docs/model-config/context-windows.mdx`
+   - Key technical details to document:
+     - What counts toward context: system prompt + conversation history (user/assistant messages) + tool call results + file contents from @-mentions
+     - Duplicate file read optimization: `applyContextOptimizations()` detects when the same file is read multiple times and replaces older reads with a notice, saving tokens
+     - Truncation strategies: `"none"` (remove all), `"lastTwo"` (keep last 2 message pairs), `"half"` (keep last half), `"quarter"` (keep last quarter)
+     - `getNextTruncationRange()` is called with `"half"` for moderate pressure, `"quarter"` for severe pressure
+     - Model-specific context windows: 64K (DeepSeek), 128K (most models), 200K (Claude)
+     - Auto-compact trigger: `shouldCompactContextWindow()` checks if `totalTokens >= maxAllowedSize` where `maxAllowedSize = contextWindow - bufferTokens` (buffers: 27K-40K depending on model)
+     - The `condense` tool allows the model to proactively summarize conversation when it detects context pressure
+     - Cross-reference to existing docs: link to `features/auto-compact` and `model-config/context-windows`

src/samples/cli/cve-scan/DEMO.md

@@ -0,0 +1,195 @@
+# CVE Scanner Demo — CLI 2.0 Video Script
+
+> **Target length:** 3–4 minutes
+> **Audience:** Developers & DevSecOps teams evaluating Cline CLI for CI/CD
+> **Key message:** Cline CLI turns noisy vulnerability scans into actionable, prioritized security intelligence — automatically in your CI/CD pipeline.
+
+---
+
+## Pre-Demo Setup
+
+Before recording, prepare the environment:
+
+### 1. Have a project with known vulnerabilities
+
+Use any Node.js project, or create a quick one:
+
+```bash
+mkdir cve-demo && cd cve-demo
+npm init -y
+# Install packages with known CVEs (old versions)
+npm install lodash@4.17.20 express@4.17.1 jsonwebtoken@8.5.1 axios@0.21.1
+```
+
+### 2. Have Cline CLI installed and authenticated
+
+```bash
+cline auth -p anthropic -k sk-ant-api-xxxxx
+```
+
+### 3. Have the scan script available
+
+```bash
+cp src/samples/cli/cve-scan/scan-cves.sh ./scan-cves.sh
+chmod +x scan-cves.sh
+```
+
+### 4. Terminal settings for recording
+
+- **Font size:** 16-18pt for readability
+- **Theme:** Dark background, bright text
+- **Window size:** ~120 cols × 35 rows
+- **Tool:** [asciinema](https://asciinema.org/), OBS, or screen recording
+
+---
+
+## Scene 1: The Problem (30 seconds)
+
+**Talking point:** "Let's look at what vulnerability scanning looks like today."
+
+```bash
+# Show raw npm audit output — noisy, hard to prioritize
+npm audit
+```
+
+> **On screen:** The wall of text from `npm audit`. Scroll through it quickly.
+>
+> **Narration:** "npm audit gives you a wall of text. You get severity levels and package names, but no context about real-world exploitability, no prioritization, and definitely no explanation of what an attacker could actually do. Most teams either ignore this or spend hours triaging manually."
+
+---
+
+## Scene 2: Cline CLI to the Rescue — Local (60 seconds)
+
+**Talking point:** "Now let's pipe that same output to Cline CLI."
+
+```bash
+# Pipe npm audit to Cline for AI-powered analysis
+npm audit --json | cline -y "You are a security analyst. Analyze these vulnerability scan results. For each CVE: explain the real-world impact, assess exploitability, and give exact fix commands. Prioritize by severity. Format as a clean markdown report."
+```
+
+> **On screen:** Cline streams the analysis in real-time. The output is a beautifully formatted report with:
+> - 🔴 Critical vulnerabilities with impact explanations
+> - Exact `npm install package@version` fix commands
+> - Risk assessment of the overall project
+>
+> **Narration:** "One command. Cline reads the vulnerability data, cross-references CVE databases, and gives you a prioritized report with plain-English impact assessments and exact commands to fix each issue. No more guessing which CVEs actually matter."
+
+### Alternative: Using the scan script
+
+```bash
+# Same thing, but with the self-contained script
+./scan-cves.sh
+```
+
+> **Narration:** "We also have a self-contained script that auto-detects your package manager and handles everything. It works with npm, yarn, pnpm, and pip."
+
+---
+
+## Scene 3: CI/CD Integration — The Workflow (30 seconds)
+
+**Talking point:** "But the real power is automating this in CI/CD."
+
+> **On screen:** Open the `cline-cve-scan.yml` file in VS Code or show it on screen.
+
+```yaml
+# Highlight these key sections:
+
+on:
+  schedule:
+    - cron: "0 9 * * 1"    # Weekly Monday scan
+  pull_request:              # Scan every PR that touches dependencies
+    paths:
+      - "package.json"
+      - "package-lock.json"
+```
+
+> **Narration:** "Here's a GitHub Actions workflow that runs Cline's CVE scanner automatically. It triggers three ways: weekly scheduled scans to catch newly disclosed CVEs, on every PR that touches dependency files, and on-demand via manual trigger. Let me show you what this looks like in practice."
+
+---
+
+## Scene 4: Show the Output (30 seconds)
+
+**Talking point:** "Here's what your team sees when a scan runs."
+
+> **On screen:** Show a GitHub Issue created by the workflow (use a pre-created example or screenshot):
+
+```markdown
+# 🔒 CVE Vulnerability Report — 2026-02-11
+
+**Scanner:** npm
+**Total Vulnerabilities:** 4
+
+## 🔴 Critical Vulnerabilities (1)
+
+### CVE-2022-24999: qs
+- **Severity:** Critical
+- **Package:** `qs@6.7.0` → fix available in `qs@6.11.0`
+- **Impact:** Prototype pollution allows an attacker to inject properties into Object.prototype, potentially leading to RCE in Express.js apps that use query string parsing.
+- **Exploitability:** HIGH — actively exploited in the wild. Any Express app is vulnerable.
+- **Fix:** `npm install qs@6.11.0`
+- **Auto-fix safe:** Yes
+
+## 🟠 High Vulnerabilities (2)
+...
+
+## 📋 Summary & Recommended Actions
+1. **Immediate:** Update qs to 6.11.0 (critical, actively exploited)
+2. **This sprint:** Update jsonwebtoken to 9.0.0
+3. **Safe auto-fix:** `npm audit fix`
+```
+
+> **Narration:** "Instead of a noisy audit log buried in CI output, your team gets a GitHub Issue with every CVE explained in plain English, ranked by severity, with exact fix commands. The bot even tells you which fixes are safe to auto-apply."
+
+---
+
+## Scene 5: Extensibility & Composability (30 seconds)
+
+**Talking point:** "And it's completely extensible."
+
+```bash
+# Swap scanners — works with pip too
+./scan-cves.sh --scanner pip --output github-issue
+
+# Use a cheap model for triage, expensive model for critical CVEs
+./scan-cves.sh --config ~/.cline-haiku --severity critical
+
+# Pipe custom scanner output (Trivy, Snyk, Grype, etc.)
+trivy fs --format json . | ./scan-cves.sh --scanner custom
+
+# Post as PR comment instead of issue
+./scan-cves.sh --output pr-comment --pr 42
+```
+
+> **Narration:** "The script is scanner-agnostic — swap npm for pip, pipe in Trivy or Snyk output, or use any custom scanner. You can route to different models based on severity — use a cheap model for weekly triage, premium model for critical CVEs. And output goes wherever you need it: GitHub Issues, PR comments, Slack, or just stdout."
+
+---
+
+## Closing (15 seconds)
+
+**Talking point:** "This is the power of Cline CLI 2.0 in CI/CD."
+
+> **Narration:** "Cline CLI turns any vulnerability scanner into an intelligent security analyst. One script, any package ecosystem, automated in CI/CD. It's the difference between a wall of text your team ignores and actionable security intelligence they actually fix. Try it in your pipeline today."
+
+---
+
+## Key CLI 2.0 Features to Highlight
+
+Throughout the demo, naturally call out these Cline CLI 2.0 features:
+
+| Feature | Where it appears |
+|---------|-----------------|
+| **YOLO mode** (`-y`) | Scene 2 — fully autonomous analysis, no interaction needed |
+| **Piping** | Scene 2 — `npm audit --json \| cline -y "..."` |
+| **CI/CD integration** | Scene 3–4 — GitHub Actions workflow |
+| **Command permissions** | Scene 3 — `CLINE_COMMAND_PERMISSIONS` in workflow |
+| **`--config` flag** | Scene 5 — multi-model orchestration |
+| **Scanner-agnostic** | Scene 5 — works with npm, pip, Trivy, Snyk, etc. |
+| **Output adapters** | Scene 5 — stdout, GitHub Issue, PR comment, file |
+
+## B-Roll Suggestions
+
+- Terminal showing Cline streaming the CVE analysis in real-time
+- GitHub Issues tab showing auto-created security reports
+- Split screen: raw `npm audit` (left) vs Cline report (right)
+- GitHub Actions workflow run log showing the scan executing
+- PR with Cline's security comment posted automatically

src/samples/cli/cve-scan/cline-cve-scan.yml

@@ -0,0 +1,153 @@
+name: Cline CVE Scanner
+
+on:
+  # Weekly scheduled scan — catches new CVEs in existing dependencies
+  schedule:
+    - cron: "0 9 * * 1" # Every Monday at 9am UTC
+
+  # PR scan — catch vulnerable dependencies before they merge
+  pull_request:
+    types: [opened, synchronize, ready_for_review]
+    paths:
+      - "package.json"
+      - "package-lock.json"
+      - "yarn.lock"
+      - "pnpm-lock.yaml"
+      - "requirements.txt"
+      - "Pipfile.lock"
+      - "pyproject.toml"
+
+  # Manual trigger with options
+  workflow_dispatch:
+    inputs:
+      severity:
+        description: "Minimum severity to report"
+        required: false
+        default: "all"
+        type: choice
+        options:
+          - all
+          - low
+          - medium
+          - high
+          - critical
+      auto_fix:
+        description: "Attempt safe auto-fixes"
+        required: false
+        default: false
+        type: boolean
+
+concurrency:
+  group: cve-scan-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  cve-scan:
+    if: |
+      (github.event_name == 'pull_request' && github.event.pull_request.draft == false) ||
+      github.event_name == 'schedule' ||
+      github.event_name == 'workflow_dispatch'
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: "22"
+          cache: "npm"
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Install Cline CLI
+        run: npm install -g cline
+
+      - name: Configure Cline Authentication
+        run: |
+          cline auth --provider anthropic \
+            --apikey "${{ secrets.ANTHROPIC_API_KEY }}" \
+            --modelid claude-sonnet-4-5-20250929
+
+      - name: Determine scan parameters
+        id: params
+        run: |
+          # Set severity level
+          if [ "${{ github.event_name }}" == "workflow_dispatch" ]; then
+            echo "severity=${{ inputs.severity }}" >> $GITHUB_OUTPUT
+            echo "auto_fix=${{ inputs.auto_fix }}" >> $GITHUB_OUTPUT
+          elif [ "${{ github.event_name }}" == "pull_request" ]; then
+            echo "severity=high" >> $GITHUB_OUTPUT
+            echo "auto_fix=false" >> $GITHUB_OUTPUT
+          else
+            # Scheduled scan — report everything
+            echo "severity=all" >> $GITHUB_OUTPUT
+            echo "auto_fix=false" >> $GITHUB_OUTPUT
+          fi
+
+          # Set output target
+          if [ "${{ github.event_name }}" == "pull_request" ]; then
+            echo "output=pr-comment" >> $GITHUB_OUTPUT
+            echo "pr_number=${{ github.event.pull_request.number }}" >> $GITHUB_OUTPUT
+          else
+            echo "output=github-issue" >> $GITHUB_OUTPUT
+            echo "pr_number=" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Download CVE scan script
+        run: |
+          curl -sL https://raw.githubusercontent.com/${{ github.repository }}/main/scan-cves.sh -o scan-cves.sh \
+            || cp src/samples/cli/cve-scan/scan-cves.sh scan-cves.sh 2>/dev/null \
+            || true
+          chmod +x scan-cves.sh
+
+      - name: Run CVE scan with Cline
+        env:
+          GH_TOKEN: ${{ github.token }}
+          GITHUB_REPOSITORY: ${{ github.repository }}
+          # Restrict Cline to safe, read-only commands
+          CLINE_COMMAND_PERMISSIONS: |
+            {
+              "allow": [
+                "npm audit *",
+                "yarn audit *",
+                "pnpm audit *",
+                "pip-audit *",
+                "gh issue create *",
+                "gh issue list *",
+                "gh pr comment *",
+                "cat *",
+                "echo *"
+              ],
+              "deny": [
+                "rm *",
+                "sudo *",
+                "npm install *",
+                "npm publish *"
+              ]
+            }
+        run: |
+          PR_FLAG=""
+          if [ -n "${{ steps.params.outputs.pr_number }}" ]; then
+            PR_FLAG="--pr ${{ steps.params.outputs.pr_number }}"
+          fi
+
+          AUTO_FIX_FLAG=""
+          if [ "${{ steps.params.outputs.auto_fix }}" == "true" ]; then
+            AUTO_FIX_FLAG="--auto-fix"
+          fi
+
+          ./scan-cves.sh \
+            --scanner npm \
+            --output ${{ steps.params.outputs.output }} \
+            --severity ${{ steps.params.outputs.severity }} \
+            $PR_FLAG \
+            $AUTO_FIX_FLAG

src/samples/cli/cve-scan/scan-cves.sh

@@ -0,0 +1,308 @@
+#!/bin/bash
+# scan-cves.sh — CVE vulnerability scanner powered by Cline CLI
+#
+# Scans project dependencies for known vulnerabilities, then uses Cline CLI
+# to produce an actionable, prioritized security report.
+#
+# Usage:
+#   ./scan-cves.sh                                    # Auto-detect scanner, output to stdout
+#   ./scan-cves.sh --output github-issue              # Post results as a GitHub Issue
+#   ./scan-cves.sh --output pr-comment --pr 42        # Post as a PR comment
+#   ./scan-cves.sh --scanner npm --severity critical   # Only critical CVEs via npm
+#   cat audit.json | ./scan-cves.sh --scanner custom  # Pipe custom scanner output
+#
+# Environment variables:
+#   CLINE_CVE_MODEL    — Model to use (default: uses current cline auth config)
+#   CLINE_CVE_CONFIG   — Custom cline config directory (e.g. ~/.cline-haiku)
+#   GH_TOKEN           — GitHub token for posting issues/comments (CI/CD)
+#   GITHUB_REPOSITORY  — Owner/repo for GitHub output (auto-set in Actions)
+
+set -euo pipefail
+
+# ─── Defaults ────────────────────────────────────────────────────────────────
+
+SCANNER=""
+OUTPUT="stdout"
+SEVERITY="all"
+PR_NUMBER=""
+REPO="${GITHUB_REPOSITORY:-}"
+AUTO_FIX="false"
+CLINE_EXTRA_FLAGS=""
+
+# ─── Parse Arguments ─────────────────────────────────────────────────────────
+
+usage() {
+    cat <<EOF
+Usage: $(basename "$0") [options]
+
+Options:
+  --scanner <type>      Package manager to use: npm, yarn, pnpm, pip, custom
+                        (default: auto-detect from lockfiles)
+  --output <target>     Output target: stdout, github-issue, pr-comment, file
+                        (default: stdout)
+  --severity <level>    Minimum severity: critical, high, medium, low, all
+                        (default: all)
+  --pr <number>         PR number (required for --output pr-comment)
+  --repo <owner/repo>   GitHub repository (default: \$GITHUB_REPOSITORY)
+  --auto-fix            Let Cline attempt safe auto-fixes and report what changed
+  --config <path>       Custom Cline config directory (e.g. ~/.cline-haiku)
+  --model <id>          Model to use for analysis
+  -h, --help            Show this help message
+
+Examples:
+  # Auto-detect and print report
+  ./scan-cves.sh
+
+  # Weekly CI scan → GitHub Issue
+  ./scan-cves.sh --output github-issue --severity high
+
+  # PR check → inline comment
+  ./scan-cves.sh --output pr-comment --pr 42
+
+  # Use cheap model for triage, then escalate
+  ./scan-cves.sh --config ~/.cline-haiku --severity critical
+
+  # Pipe custom scanner output
+  cat trivy-results.json | ./scan-cves.sh --scanner custom
+EOF
+    exit 0
+}
+
+while [[ $# -gt 0 ]]; do
+    case "$1" in
+        --scanner)   SCANNER="$2";    shift 2 ;;
+        --output)    OUTPUT="$2";     shift 2 ;;
+        --severity)  SEVERITY="$2";   shift 2 ;;
+        --pr)        PR_NUMBER="$2";  shift 2 ;;
+        --repo)      REPO="$2";       shift 2 ;;
+        --auto-fix)  AUTO_FIX="true"; shift   ;;
+        --config)    CLINE_EXTRA_FLAGS="$CLINE_EXTRA_FLAGS --config $2"; shift 2 ;;
+        --model)     CLINE_EXTRA_FLAGS="$CLINE_EXTRA_FLAGS -m $2"; shift 2 ;;
+        -h|--help)   usage ;;
+        *)           echo "Unknown option: $1"; usage ;;
+    esac
+done
+
+# ─── Auto-detect Scanner ─────────────────────────────────────────────────────
+
+detect_scanner() {
+    if [[ -f "package-lock.json" ]]; then
+        echo "npm"
+    elif [[ -f "yarn.lock" ]]; then
+        echo "yarn"
+    elif [[ -f "pnpm-lock.yaml" ]]; then
+        echo "pnpm"
+    elif [[ -f "requirements.txt" ]] || [[ -f "Pipfile.lock" ]] || [[ -f "pyproject.toml" ]]; then
+        echo "pip"
+    else
+        echo ""
+    fi
+}
+
+if [[ -z "$SCANNER" ]]; then
+    SCANNER=$(detect_scanner)
+    if [[ -z "$SCANNER" ]]; then
+        echo "Error: Could not auto-detect package manager. Use --scanner to specify." >&2
+        exit 1
+    fi
+    echo "Auto-detected scanner: $SCANNER" >&2
+fi
+
+# ─── Run Vulnerability Scan ──────────────────────────────────────────────────
+
+run_scan() {
+    local scanner="$1"
+
+    case "$scanner" in
+        npm)
+            # npm audit returns non-zero when vulnerabilities exist — that's expected
+            npm audit --json 2>/dev/null || true
+            ;;
+        yarn)
+            yarn audit --json 2>/dev/null || true
+            ;;
+        pnpm)
+            pnpm audit --json 2>/dev/null || true
+            ;;
+        pip)
+            # pip-audit outputs JSON with --format json
+            if command -v pip-audit &>/dev/null; then
+                pip-audit --format json 2>/dev/null || true
+            else
+                echo '{"error": "pip-audit not installed. Run: pip install pip-audit"}' >&2
+                exit 1
+            fi
+            ;;
+        custom)
+            # Read from stdin
+            cat
+            ;;
+        *)
+            echo "Error: Unknown scanner '$scanner'. Use npm, yarn, pnpm, pip, or custom." >&2
+            exit 1
+            ;;
+    esac
+}
+
+echo "Running $SCANNER vulnerability scan..." >&2
+SCAN_OUTPUT=$(run_scan "$SCANNER")
+
+# Check if scan produced output
+if [[ -z "$SCAN_OUTPUT" ]] || [[ "$SCAN_OUTPUT" == "{}" ]] || [[ "$SCAN_OUTPUT" == "null" ]]; then
+    echo "✅ No vulnerabilities found!" >&2
+    exit 0
+fi
+
+# ─── The Security Analyst Prompt ─────────────────────────────────────────────
+#
+# This prompt is designed to be self-contained and extractable.
+# It could be published to the Cline Prompts Library as a reusable
+# "CVE Security Analyst" prompt.
+
+SEVERITY_FILTER=""
+if [[ "$SEVERITY" != "all" ]]; then
+    SEVERITY_FILTER="Focus ONLY on vulnerabilities with severity '$SEVERITY' or higher. Ignore lower-severity issues."
+fi
+
+AUTO_FIX_INSTRUCTION=""
+if [[ "$AUTO_FIX" == "true" ]]; then
+    AUTO_FIX_INSTRUCTION="
+After your analysis, attempt to auto-fix vulnerabilities that are SAFE to fix:
+- Run the appropriate package manager fix command (e.g., npm audit fix)
+- Do NOT run force-fix commands that may introduce breaking changes
+- Report what was fixed and what requires manual intervention"
+fi
+
+read -r -d '' SECURITY_PROMPT << 'PROMPT_EOF' || true
+You are a senior security analyst performing a CVE vulnerability assessment.
+
+Analyze the following vulnerability scan results from a dependency audit.
+
+For EACH vulnerability found:
+1. **CVE ID & Severity** — The CVE identifier and severity rating (Critical/High/Medium/Low)
+2. **Affected Package** — Package name, installed version, and fixed version (if available)
+3. **Impact Assessment** — Plain-English explanation of what an attacker could do. Be specific — don't just say "remote code execution," explain the attack vector.
+4. **Exploitability** — Is this exploitable in a typical web app / server / CLI context? Or is it theoretical?
+5. **Remediation** — Exact commands to fix. Be specific to the package manager.
+6. **Safe to Auto-fix?** — Yes/No. "Yes" means a simple version bump with no breaking changes.
+
+Output your report in this EXACT markdown format:
+
+# 🔒 CVE Vulnerability Report
+
+**Scan Date:** [today's date]
+**Scanner:** [package manager used]
+**Total Vulnerabilities:** [count]
+
+## 🔴 Critical Vulnerabilities ([count])
+
+### CVE-XXXX-XXXXX: [package name]
+- **Severity:** Critical
+- **Package:** `package@version` → fix available in `package@fixed-version`
+- **Impact:** [plain-English impact]
+- **Exploitability:** [assessment]
+- **Fix:** `[exact command]`
+- **Auto-fix safe:** Yes/No
+
+## 🟠 High Vulnerabilities ([count])
+[same format]
+
+## 🟡 Medium Vulnerabilities ([count])
+[same format]
+
+## 🔵 Low Vulnerabilities ([count])
+[same format]
+
+## 📋 Summary & Recommended Actions
+
+1. **Immediate action required:** [list critical items]
+2. **Schedule for next sprint:** [list high items]
+3. **Monitor:** [list medium/low items]
+4. **Safe auto-fix commands:** [consolidated list of safe fix commands]
+
+## 📊 Risk Assessment
+
+[Overall risk assessment: Is this project in good shape? Are there patterns of neglected dependencies? Specific areas of concern?]
+
+IMPORTANT:
+- If there are NO vulnerabilities in a severity category, omit that section entirely
+- If a CVE has a known exploit in the wild, flag it with ⚠️ ACTIVELY EXPLOITED
+- Be actionable — every finding should have a clear next step
+PROMPT_EOF
+
+# Combine prompt parts
+FULL_PROMPT="$SECURITY_PROMPT
+
+$SEVERITY_FILTER
+$AUTO_FIX_INSTRUCTION
+
+Here are the scan results to analyze:
+"
+
+# ─── Run Cline Analysis ──────────────────────────────────────────────────────
+
+echo "Analyzing vulnerabilities with Cline..." >&2
+
+# shellcheck disable=SC2086
+REPORT=$(echo "$SCAN_OUTPUT" | cline -y $CLINE_EXTRA_FLAGS "$FULL_PROMPT" 2>/dev/null | \
+    tail -n +1)
+
+# If using JSON mode, extract the completion result
+if echo "$REPORT" | head -1 | grep -q "^{"; then
+    REPORT=$(echo "$REPORT" | jq -r 'select(.say == "completion_result") | .text' 2>/dev/null | sed 's/\\n/\n/g')
+fi
+
+if [[ -z "$REPORT" ]]; then
+    echo "Error: Cline did not produce a report." >&2
+    exit 1
+fi
+
+# ─── Output Results ──────────────────────────────────────────────────────────
+
+case "$OUTPUT" in
+    stdout)
+        echo "$REPORT"
+        ;;
+
+    github-issue)
+        if [[ -z "$REPO" ]]; then
+            echo "Error: --repo or \$GITHUB_REPOSITORY required for github-issue output" >&2
+            exit 1
+        fi
+
+        TITLE="🔒 CVE Vulnerability Report — $(date +%Y-%m-%d)"
+        gh issue create \
+            --repo "$REPO" \
+            --title "$TITLE" \
+            --body "$REPORT" \
+            --label "security,automated"
+        echo "✅ GitHub Issue created in $REPO" >&2
+        ;;
+
+    pr-comment)
+        if [[ -z "$PR_NUMBER" ]]; then
+            echo "Error: --pr <number> required for pr-comment output" >&2
+            exit 1
+        fi
+        if [[ -z "$REPO" ]]; then
+            echo "Error: --repo or \$GITHUB_REPOSITORY required for pr-comment output" >&2
+            exit 1
+        fi
+
+        gh pr comment "$PR_NUMBER" \
+            --repo "$REPO" \
+            --body "$REPORT"
+        echo "✅ Comment posted on PR #$PR_NUMBER in $REPO" >&2
+        ;;
+
+    file)
+        FILENAME="cve-report-$(date +%Y%m%d-%H%M%S).md"
+        echo "$REPORT" > "$FILENAME"
+        echo "✅ Report saved to $FILENAME" >&2
+        ;;
+
+    *)
+        echo "Error: Unknown output target '$OUTPUT'. Use stdout, github-issue, pr-comment, or file." >&2
+        exit 1
+        ;;
+esac