docs improvements (RooCodeInc#3659)

* docs improvements

* new rule slash command no screenshot

* docs

* language

---------

Co-authored-by: Cline Evaluation <[email protected]>

Author: pashpashpash

.clinerules/workflows/extension-release.md

@@ -71,6 +71,22 @@
 				"group": "Improving Your Prompting Skills",
 				"pages": ["prompting/prompt-engineering-guide", "prompting/cline-memory-bank"]
 			},
+			{
+				"group": "Features",
+				"pages": [
+					"features/cline-rules",
+					"features/slash-commands/workflows",
+					{
+						"group": "Slash Commands",
+						"pages": [
+							"features/slash-commands/new-task",
+							"features/slash-commands/new-rule",
+							"features/slash-commands/smol",
+							"features/slash-commands/report-bug"
+						]
+					}
+				]
+			},
 			{
 				"group": "Exploring Cline's Tools",
 				"pages": [

docs/docs.json

@@ -0,0 +1,162 @@
+Cline Rules allow you to provide Cline with system-level guidance. Think of them as a persistent way to include context and preferences for your projects or globally for every conversation.
+
+## Creating a Rule
+
+You can create a rule by clicking the `+` button in the Rules tab. This will open a new file in your IDE which you can use to write your rule.
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/cline-rules.png" alt="Create a Rule" />
+</Frame>
+
+Once you save the file:
+
+-   Your rule will be stored in the `.clinerules/` directory in your project (if it's a Workspace Rule)
+-   Or in the `Documents/Cline/Rules` directory (if it's a Global Rule).
+
+You can also have Cline create a rule for you by using the [`/newrule` slash command](/features/slash-commands/new-rule) in the chat.
+
+```markdown Example Cline Rule Structure [expandable]
+# Project Guidelines
+
+## Documentation Requirements
+
+-   Update relevant documentation in /docs when modifying features
+-   Keep README.md in sync with new capabilities
+-   Maintain changelog entries in CHANGELOG.md
+
+## Architecture Decision Records
+
+Create ADRs in /docs/adr for:
+
+-   Major dependency changes
+-   Architectural pattern changes
+-   New integration patterns
+-   Database schema changes
+    Follow template in /docs/adr/template.md
+
+## Code Style & Patterns
+
+-   Generate API clients using OpenAPI Generator
+-   Use TypeScript axios template
+-   Place generated code in /src/generated
+-   Prefer composition over inheritance
+-   Use repository pattern for data access
+-   Follow error handling pattern in /src/utils/errors.ts
+
+## Testing Standards
+
+-   Unit tests required for business logic
+-   Integration tests for API endpoints
+-   E2E tests for critical user flows
+```
+
+### Key Benefits
+
+1. **Version Controlled**: The `.clinerules` file becomes part of your project's source code
+2. **Team Consistency**: Ensures consistent behavior across all team members
+3. **Project-Specific**: Rules and standards tailored to each project's needs
+4. **Institutional Knowledge**: Maintains project standards and practices in code
+
+Place the `.clinerules` file in your project's root directory:
+
+```
+your-project/
+├── .clinerules
+├── src/
+├── docs/
+└── ...
+```
+
+Cline's system prompt, on the other hand, is not user-editable ([here's where you can find it](https://github.com/cline/cline/blob/main/src/core/prompts/system.ts)). For a broader look at prompt engineering best practices, check out [this resource](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview).
+
+### Tips for Writing Effective Cline Rules
+
+-   Be Clear and Concise: Use simple language and avoid ambiguity.
+-   Focus on Desired Outcomes: Describe the results you want, not the specific steps.
+-   Test and Iterate: Experiment to find what works best for your workflow.
+
+### .clinerules/ Folder System
+
+```
+your-project/
+├── .clinerules/              # Folder containing active rules
+│   ├── 01-coding.md          # Core coding standards
+│   ├── 02-documentation.md   # Documentation requirements
+│   └── current-sprint.md     # Rules specific to current work
+├── src/
+└── ...
+```
+
+Cline automatically processes **all Markdown files** inside the `.clinerules/` directory, combining them into a unified set of rules. The numeric prefixes (optional) help organize files in a logical sequence.
+
+#### Using a Rules Bank
+
+For projects with multiple contexts or teams, maintain a rules bank directory:
+
+```
+your-project/
+├── .clinerules/              # Active rules - automatically applied
+│   ├── 01-coding.md
+│   └── client-a.md
+│
+├── clinerules-bank/          # Repository of available but inactive rules
+│   ├── clients/              # Client-specific rule sets
+│   │   ├── client-a.md
+│   │   └── client-b.md
+│   ├── frameworks/           # Framework-specific rules
+│   │   ├── react.md
+│   │   └── vue.md
+│   └── project-types/        # Project type standards
+│       ├── api-service.md
+│       └── frontend-app.md
+└── ...
+```
+
+#### Benefits of the Folder Approach
+
+1. **Contextual Activation**: Copy only relevant rules from the bank to the active folder
+2. **Easier Maintenance**: Update individual rule files without affecting others
+3. **Team Flexibility**: Different team members can activate rules specific to their current task
+4. **Reduced Noise**: Keep the active ruleset focused and relevant
+
+#### Usage Examples
+
+Switch between client projects:
+
+```bash
+# Switch to Client B project
+rm .clinerules/client-a.md
+cp clinerules-bank/clients/client-b.md .clinerules/
+```
+
+Adapt to different tech stacks:
+
+```bash
+# Frontend React project
+cp clinerules-bank/frameworks/react.md .clinerules/
+```
+
+#### Implementation Tips
+
+-   Keep individual rule files focused on specific concerns
+-   Use descriptive filenames that clearly indicate the rule's purpose
+-   Consider git-ignoring the active `.clinerules/` folder while tracking the `clinerules-bank/`
+-   Create team scripts to quickly activate common rule combinations
+
+The folder system transforms your Cline rules from a static document into a dynamic knowledge system that adapts to your team's changing contexts and requirements.
+
+### Managing Rules with the Toggleable Popover
+
+To make managing both single `.clinerules` files and the folder system even easier, Cline v3.13 introduces a dedicated popover UI directly accessible from the chat interface.
+
+Located conveniently under the chat input field, this popover allows you to:
+
+-   **Instantly See Active Rules:** View which global rules (from your user settings) and workspace rules (`.clinerules` file or folder contents) are currently active.
+-   **Quickly Toggle Rules:** Enable or disable specific rule files within your workspace `.clinerules/` folder with a single click. This is perfect for activating context-specific rules (like `react-rules.md` or `memory-bank.md`) only when needed.
+-   **Easily Add/Manage Rules:** Quickly create a workspace `.clinerules` file or folder if one doesn't exist, or add new rule files to an existing folder.
+
+This UI significantly simplifies switching contexts and managing different sets of instructions without needing to manually edit files or configurations during a conversation.
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(1).png" alt="Cline Logo" />
+</Frame>

docs/features/cline-rules.mdx

@@ -0,0 +1,42 @@
+---
+title: "New Rule Command"
+sidebarTitle: "/newrule"
+---
+
+`/newrule` is a slash command that lets you teach Cline your preferred way of working. It creates a markdown file in your `.clinerules` directory that acts like persistent instructions for how Cline should behave when helping with your projects.
+
+Think of it as setting up house rules that Cline will always follow, so you don't have to repeat your preferences in every conversation.
+
+#### Using the `/newrule` Slash Command
+
+When you want Cline to consistently follow certain guidelines:
+
+-   Type `/newrule` in the chat
+-   Cline will help you create a structured rule file by asking about your preferences for:
+    -   Communication style (verbose vs. concise)
+    -   Development workflows
+    -   Coding standards
+    -   Project context
+    -   Any other specific guidelines
+-   You'll review the rule file before it's created
+-   Once approved, Cline creates a markdown file in your `.clinerules` directory that will automatically be loaded for future conversations
+
+#### Example
+
+I used `/newrule` when I was fed up with repeating the same instructions on every new task. I had specific preferences for how I wanted my React components structured, which testing library to use, and even my preferred variable naming style.
+
+Instead of typing these preferences each time, I just used `/newrule` and worked with Cline to create a detailed rule file. We built a markdown file that covered everything from code organization to my preference for functional components over class components.
+
+Now whenever I chat with Cline about my React project, it automatically follows these guidelines without me having to remind it. The best part is that I can create different rule files for different projects, so Cline adapts to whatever codebase I'm working on.
+
+#### Inspiration
+
+Here's how I use `/newrule` to make my development smoother:
+
+-   I created a rule file for each major project with specific architectural patterns and library preferences, so Cline always generates code that matches our existing codebase.
+
+-   For my team's shared projects, we have a common rule file that ensures consistent code style and documentation practices regardless of who's using Cline.
+
+-   When working with legacy code, I made a rule file that reminds Cline about the quirks and constraints of the old system, so it never suggests modern approaches that won't integrate well.
+
+-   I even have a personal rule file for my side projects with all my opinionated preferences - two-space indentation, arrow functions everywhere, and my exact folder structure requirements.

docs/features/slash-commands/new-rule.mdx

@@ -0,0 +1,41 @@
+---
+title: "New Task Command"
+sidebarTitle: "/newtask"
+---
+
+`/newtask` is a slash command that works like a perfect developer handoff. It intelligently packages what matters - the overall plan, work accomplished, relevant files, and next steps - into a fresh task with a clean context window. All while leaving behind the noise of tool calls, documentation searches, and implementation details.
+
+It's exactly what you'd do when bringing a new developer onto your project: provide the essential context they need to continue the work without overwhelming them with every keystroke that came before.
+
+#### Using the `/newtask` Slash Command
+
+When your context window is filling up but you're not done with your project:
+
+<Frame>
+	<img
+		src="https://storage.googleapis.com/cline_public_images/docs/assets/newtask.png"
+		alt="Using the /newtask slash command"
+	/>
+</Frame>
+
+-   Type `/newtask` in the chat input field
+-   Cline will analyze your conversation and propose a distilled version of the context to carry forward
+-   You can refine this proposed context through conversation before committing
+-   Once satisfied, a button appears to create the new task with your refined context
+
+#### Example
+
+I regularly use `/newtask` when working through complex implementations with multiple steps. For instance, if I've completed 3 steps of a 10-step process and my context is already 75% full with documentation snippets, file contents, and detailed discussions.
+
+Rather than losing those insights or starting from scratch, I use `/newtask` to have Cline extract what matters - the key decisions, file changes, and progress so far - without all the noise of individual tool calls and research steps.
+
+I like to think of `/newtask` as a new developer joining the project. I need to give them the full understanding of the work that has been done, awareness of the relevant files, any other context that would be helpful, and where to go next.
+
+#### Inspiration
+
+Here are some popular ways to use `/newtask`:
+
+-   I research complex APIs using the Context7 MCP server, filling my context with documentation. Once I understand the concepts, I use `/newtask` to start fresh with just the essential knowledge needed for implementation.
+-   After identifying the root cause of a tough bug through multiple debugging attempts and file explorations, I use `/newtask` to continue with a clean slate that includes the solution but discards all the failed attempts.
+-   When a client discussion explores multiple approaches and finally settles on one direction, I use `/newtask` to focus solely on implementing the chosen solution.
+-   For complex projects spanning multiple days, I use `/newtask` at logical stopping points to maintain a clean workspace while carrying forward my progress.

docs/features/slash-commands/new-task.mdx

@@ -0,0 +1,30 @@
+---
+title: "Report Bug Command"
+sidebarTitle: "/reportbug"
+---
+
+`/reportbug` is an absolute lifesaver when you hit a weird issue with Cline. Instead of having to remember all the details GitHub wants for a bug report, this command turns Cline into your personal bug reporting assistant.
+
+It walks you through collecting all the info needed for a proper bug report and then shoots it straight to our GitHub issues page with all the right formatting and system details included.
+
+#### Using the `/reportbug` Slash Command
+
+When you run into something funky that doesn't seem right:
+
+-   Just type `/reportbug` in the chat
+-   Cline will guide you through all the details we need:
+    -   A quick title describing the issue
+    -   What actually happened vs. what you expected
+    -   Steps to reproduce the bug
+    -   Any relevant output or errors you saw
+    -   Additional context that might help us fix it
+-   You'll get to review everything before it's submitted
+-   Once you approve, it opens a perfectly formatted GitHub issue with all your info plus automatic system details
+
+#### Example
+
+Last week I hit a weird bug where Cline kept timing out when reading large files. Instead of trying to remember all the GitHub template fields, I just typed `/reportbug` and Cline guided me through the whole process.
+
+It asked me about what I was trying to do, what happened instead, and the exact steps that led to the issue. The best part was that it automatically included my OS version, Cline version, and all the technical details our devs would need.
+
+A few seconds later, I had a properly formatted GitHub issue created without having to hunt down any of that info myself.

docs/features/slash-commands/report-bug.mdx

@@ -0,0 +1,47 @@
+---
+title: "Smol Command"
+sidebarTitle: "/smol"
+---
+
+`/smol` (or its alias, `/compact`) is a slash command that compresses your conversation history while preserving essential context.
+
+Unlike `/newtask` which creates a new task, `/smol` condenses your current conversation into a comprehensive summary, freeing up context window space while allowing you to continue working in the same task.
+
+Think of it like summarizing the relevant parts of a conversation while discarding the rest.
+
+#### Using the `/smol` Slash Command
+
+When your context window is getting full but you want to continue in the same task:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/smol.png" alt="Using the /smol slash command" />
+</Frame>
+
+-   Type `/smol` (or its alias `/compact`) in the chat input field
+-   Cline will analyze your conversation and create a detailed summary that preserves essential information
+-   You'll have a chance to review this summary and provide feedback if needed
+-   Once accepted, the detailed conversation history is replaced with this condensed version
+
+#### Example
+
+I use `/smol` when I'm deep into a complex debugging session and need to continue in the same task. After exploring multiple approaches and examining several files, my context window gets crowded with all the back-and-forth.
+
+By using `/smol`, I can condense all that exploration into a concise summary that captures what we've learned, which files we've examined, and what approaches we've tried. This frees up space to continue the debugging without losing the insights we've gained.
+
+The key difference from `/newtask` is that I'm staying in the same conversation flow rather than creating a separate task. This is particularly useful when I'm in the middle of something and don't want to context switch.
+
+#### Inspiration
+
+Here are powerful ways I use `/smol` in my workflow:
+
+-   During lengthy brainstorming sessions, I use `/smol` to condense our exploration before implementing the chosen solution, all within the same task.
+-   When debugging complex issues that involve multiple file checks and test runs, I use `/smol` to summarize what we've learned while continuing the debugging process.
+-   For iterative development, I use `/smol` after completing each feature to compress the implementation details while keeping the key decisions and approaches accessible.
+-   When gathering requirements from multiple sources, I use `/smol` to distill the essential needs into a concise summary before moving to the design phase.
+
+#### Smol vs Newtask
+
+People often ask me when to use `/smol` vs `/newtask`. Frankly, it's a matter of personal preference and what you're trying to achieve. Here are some guidelines:
+
+-   Use `/smol` when you're in the middle of something and want to keep going in the same task. It's perfect when you're deep in a debugging flow or brainstorming session and don't want to break your momentum. The downside? Once you compress your history, you can't get those detailed conversations back.
+-   Use `/newtask` when you're at a logical transition point and want to start fresh. It's great for moving from planning to implementation, or when you want to preserve your full conversation history (since it creates a new task rather than overwriting your current one).