language

.clinerules/workflows/extension-release.md

@@ -0,0 +1,549 @@
+The goal of this workflow is to take a changeset for a release of Cline, an autonomous coding agent extension that plugs right into your IDE, and write the updated announcement component, and the updated changelog. 
+
+
+For reference, here are some examples of how we converted previous changesets to announcement components / changelogs. 
+
+
+- 3.14
+<changeset>
+This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
+
+Releases
+claude-dev@3.14.0
+Minor Changes
+77c9863: create clinerules folder if its currently a file and creating new rule
+0ffb7dd: disabling shift hint for now & improving tooltip behavior
+79b76fd: Add support for custom model ID in AWS Bedrock provider, enabling use of Application Inference Profile.
+eb6e481: Full support for LaTeX rendering
+df37f29: Add support for custom API request timeout. Previously, timeouts were hardcoded to 30 seconds for providers like Ollama or 15 seconds for OpenRouter and Cline. Now users can set a custom timeout value in milliseconds through the settings interface.
+e4d26be: allow cursorrules and windsurfrules
+c5de50f: Fix Handle @withRetry() SyntaxError when running extension locally issue
+61d2f42: enabled pricing calculation for gemini and vertex + more robust caching & cache tracking for gemini & vertex
+aed152b: add truncation notice when truncating manually
+2fe2405: Migrate Cline Tools Section to new docs
+19cc8bc: Add a timeout setting for the terminal connection, allowing users to adjust this if they are having timeout issues
+03d4410: Added copy button to code blocks.
+c78fe23: addressed race condition in terminal command usage
+91e222f: add checkpoints after more messages
+14230e7: add newrule slash command
+1c7d33a: Add remote config with posthog allowing for disabling new features until they're reading, making for a better developer experience.
+4196c14: add cache ui for open router and cline provider
+d97424f: showing expanded task by default
+5294e78: Refactor to not pass a message for showing the MCP View from the servers modal
+70cc437: Fix Windows path issue: Correct handling of import.meta.url to avoid leading slash in pathname
+4b697d8: Migrate the addRemoteServer to protobus
+Patch Changes
+c63d9a1: updated drag and drop text to say "drop" instead of "drag"
+459adf0: Add markdown copy to chat
+74ec823: Minor UX improvement to drag and drop ux
+b0961f4: Remove linear pull request action
+e9ce384: searchCommits protobus migration
+5802b68: createRuleFile protobus migration
+df7f9fc: Add dependsOn to more blocks in the tasks.json
+41ae732: Fix for git commit mentions in repos with no git commits
+7e78445: Adding args to allow Cursor to open workspaces (for checkpoint testing/development)
+bdfda6f: feat(bedrock): Introduce Amazon Nova Premier
+65243ad: Introduce UI library for future UI development
+4565e06: checkIsImageURL migrated to protobus
+5a8e9d8: protobus migration for openImage
+deeda6e: Lowering Gemini cache TTL time
+db0b022: Adding UI to show openrouter balance next to provider
+4650ffa: deleteRuleFile protobus migration
+d4bd755: fix cost calculation
+</changeset>
+
+<changelog>
+## [3.14.0]
+
+-   Add UI to show openrouter balance next to provider
+-   Add support for custom model ID in AWS Bedrock provider, enabling use of Application Inference Profile (Thanks @clicube!)
+-   Add more robust caching & cache tracking for gemini & vertex providers
+-   Add support for LaTeX rendering
+-   Add support for custom API request timeout. Timeouts were 15-30s, but can now be configured via settings for OpenRouter/Cline & Ollama (Thanks @WingsDrafterwork!)
+-   Add truncation notice when truncating manually
+-   Add a timeout setting for the terminal connection, allowing users to set a time to wait for terminal startup
+-   Add copy button to code blocks
+-   Add copy button to markdown blocks (Thanks @weshoke!)
+-   Add checkpoints to more messages
+-   Add slash command to create a new rules file (/newrule)
+-   Add cache ui for open router and cline provider
+-   Add Amazon Nova Premier model to Bedrock (Thanks @watany!)
+-   Add support for cursorrules and windsurfrules
+-   Add support for batch history deletion (Thanks @danix800!)
+-   Improve Drag & Drop experience
+-   Create clinerules folder creating new rule if it's needed
+-   Enable pricing calculation for gemini and vertex providers
+-   Refactor message handling to not show the MCP View of the server modal
+-   Migrate the addRemoteServer to protobus (Thanks @DaveFres!)
+-   Update task header to be expanded by default
+-   Update Gemini cache TTL time to 15 minutes
+-   Fix race condition in terminal command usage
+-   Fix to correctly handle `import.meta.url`, avoiding leading slash in pathname for Windows (Thanks @DaveFres!)
+-   Fix @withRetry() decoration syntax error when running extension locally (Thanks @DaveFres!)
+-   Fix for git commit mentions in repos with no git commits
+-   Fix cost calculation (Thanks @BarreiroT!)
+</changelog>
+
+
+<announcement-component>
+const Announcement = ({ version, hideAnnouncement }: AnnouncementProps) => {
+	const minorVersion = version.split(".").slice(0, 2).join(".") // 2.0.0 -> 2.0
+	return (
+		<div style={containerStyle}>
+			<VSCodeButton appearance="icon" onClick={hideAnnouncement} style={closeIconStyle}>
+				<span className="codicon codicon-close"></span>
+			</VSCodeButton>
+			<h3 style={h3TitleStyle}>
+				🎉{"  "}New in v{minorVersion}
+			</h3>
+			<ul style={ulStyle}>
+				<li>
+					<b>Gemini prompt caching:</b> Gemini and Vertex providers now support prompt caching and price tracking for
+					Gemini models.
+				</li>
+				<li>
+					<b>Copy Buttons:</b> Buttons were added to Markdown and Code blocks that allow you to copy their contents
+					easily.
+				</li>
+				<li>
+					<b>/newrule command:</b> New slash command to have cline write your .clinerules for you based on your
+					workflow.
+				</li>
+				<li>
+					<b>Drag and drop improvements:</b> Don't forget to hold shift while dragging files!
+				</li>
+				<li>Added more checkpoints across the task, allowing you to restore from more than just file changes.</li>
+				<li>Added support for rendering LaTeX in message responses. (Try asking Cline to show the quadratic formula)</li>
+			</ul>
+			<Accordion isCompact className="pl-0">
+				<AccordionItem
+					key="1"
+					aria-label="Previous Updates"
+					title="Previous Updates:"
+					classNames={{
+						trigger: "bg-transparent border-0 pl-0 pb-0 w-fit",
+						title: "font-bold text-[var(--vscode-foreground)]",
+						indicator:
+							"text-[var(--vscode-foreground)] mb-0.5 -rotate-180 data-[open=true]:-rotate-90 rtl:rotate-0 rtl:data-[open=true]:-rotate-90",
+					}}>
+					<ul style={ulStyle}>
+						<li>
+							<b>Global Cline Rules:</b> store multiple rules files in Documents/Cline/Rules to share between
+							projects.
+						</li>
+						<li>
+							<b>Cline Rules Popup:</b> New button in the chat area to view workspace and global cline rules files
+							to plug and play specific rules for the task
+						</li>
+						<li>
+							<b>Slash Commands:</b> Type <code>/</code> in chat to see the list of quick actions, like starting a
+							new task (more coming soon!)
+						</li>
+						<li>
+							<b>Edit Messages:</b> You can now edit a message you sent previously by clicking on it. Optionally
+							restore your project when the message was sent!
+						</li>
+					</ul>
+				</AccordionItem>
+			</Accordion>
+
+			{/*
+			// Leave this here for an example of how to structure the announcement
+			<ul style={{ margin: "0 0 8px", paddingLeft: "12px" }}>
+				 <li>
+					OpenRouter now supports prompt caching! They also have much higher rate limits than other providers,
+					so I recommend trying them out.
+					<br />
+					{!apiConfiguration?.openRouterApiKey && (
+						<VSCodeButtonLink
+							href={getOpenRouterAuthUrl(vscodeUriScheme)}
+							style={{
+								transform: "scale(0.85)",
+								transformOrigin: "left center",
+								margin: "4px -30px 2px 0",
+							}}>
+							Get OpenRouter API Key
+						</VSCodeButtonLink>
+					)}
+					{apiConfiguration?.openRouterApiKey && apiConfiguration?.apiProvider !== "openrouter" && (
+						<VSCodeButton
+							onClick={() => {
+								vscode.postMessage({
+									type: "apiConfiguration",
+									apiConfiguration: { ...apiConfiguration, apiProvider: "openrouter" },
+								})
+							}}
+							style={{
+								transform: "scale(0.85)",
+								transformOrigin: "left center",
+								margin: "4px -30px 2px 0",
+							}}>
+							Switch to OpenRouter
+						</VSCodeButton>
+					)}
+				</li>
+				<li>
+					<b>Edit Cline's changes before accepting!</b> When he creates or edits a file, you can modify his
+					changes directly in the right side of the diff view (+ hover over the 'Revert Block' arrow button in
+					the center to undo "<code>{"// rest of code here"}</code>" shenanigans)
+				</li>
+				<li>
+					New <code>search_files</code> tool that lets Cline perform regex searches in your project, letting
+					him refactor code, address TODOs and FIXMEs, remove dead code, and more!
+				</li>
+				<li>
+					When Cline runs commands, you can now type directly in the terminal (+ support for Python
+					environments)
+				</li>
+			</ul>*/}
+			<div style={hrStyle} />
+			<p style={linkContainerStyle}>
+				Join us on{" "}
+				<VSCodeLink style={linkStyle} href="https://x.com/cline">
+					X,
+				</VSCodeLink>{" "}
+				<VSCodeLink style={linkStyle} href="https://discord.gg/cline">
+					discord,
+				</VSCodeLink>{" "}
+				or{" "}
+				<VSCodeLink style={linkStyle} href="https://www.reddit.com/r/cline/">
+					r/cline
+				</VSCodeLink>
+				for more updates!
+			</p>
+		</div>
+	)
+}
+</announcement-component>
+
+- 3.13
+
+<changeset>
+Minor Changes
+2964388: Added copy button to MermaidBlock component
+75143a7: Add the ability to fetch from global cline rules files
+Patch Changes
+a0252e7: convert inline style to tailwind css of file SettingsView.tsx
+ab59bd9: Add stream options back to xai provider
+7276f50: Icons to indicate an action is occuring outside of the users workspace
+0b19ba6: update to NEW model
+</changeset>
+
+<changelog>
+## [3.13.0]
+
+-   Add Cline rules popover under the chat field, allowing you to easily add, enable & disable workspace level or global rule files
+-   Add new slash command menu letting you type “/“ to do quick actions like creating new tasks
+-   Add ability to edit past messages, with options to restore your workspace back to that point
+-   Allow sending a message when selecting an option provided by the question or plan tool
+-   Add command to jump to Cline's chat input
+-   Add support for OpenAI o3 & 4o-mini (Thanks @PeterDaveHello and @arafatkatze!)
+-   Add baseURL option for Google Gemini provider (Thanks @owengo and @olivierhub!)
+-   Add support for Azure's DeepSeek model. (Thanks @yt3trees!)
+-   Add ability for models that support it to receive image responses from MCP servers (Thanks @rikaaa0928!)
+-   Improve search and replace diff editing by making it more flexible with models that fail to follow structured output instructions. (Thanks @chi-cat!)
+-   Add detection of Ctrl+C termination in terminal, improving output reading issues
+-   Fix issue where some commands with large output would cause UI to freeze
+-   Fix token usage tracking issues with vertex provider (Thanks @mzsima!)
+-   Fix issue with xAI reasoning content not being parsed (Thanks @mrubens!)
+</changelog>
+
+<announcement-component>
+const Announcement = ({ version, hideAnnouncement }: AnnouncementProps) => {
+	const minorVersion = version.split(".").slice(0, 2).join(".") // 2.0.0 -> 2.0
+	return (
+		<div style={containerStyle}>
+			<VSCodeButton appearance="icon" onClick={hideAnnouncement} style={closeIconStyle}>
+				<span className="codicon codicon-close"></span>
+			</VSCodeButton>
+			<h3 style={h3TitleStyle}>
+				🎉{"  "}New in v{minorVersion}
+			</h3>
+			<ul style={ulStyle}>
+				<li>
+					<b>Global Cline Rules:</b> store multiple rules files in Documents/Cline/Rules to share between projects.
+				</li>
+				<li>
+					<b>Cline Rules Popup:</b> New button in the chat area to view workspace and global cline rules files to plug
+					and play specific rules for the task
+				</li>
+				<li>
+					<b>Slash Commands:</b> Type <code>/</code> in chat to see the list of quick actions, like starting a new task
+					(more coming soon!)
+				</li>
+				<li>
+					<b>Edit Messages:</b> You can now edit a message you sent previously by clicking on it. Optionally restore
+					your project when the message was sent!
+				</li>
+			</ul>
+			<h4 style={{ margin: "5px 0 5px" }}>Previous Updates:</h4>
+			<ul style={ulStyle}>
+				<li>
+					<b>Model Favorites:</b> You can now mark your favorite models when using Cline & OpenRouter providers for
+					quick access!
+				</li>
+				<li>
+					<b>Faster Diff Editing:</b> Improved animation performance for large files, plus a new indicator in chat
+					showing the number of edits Cline makes.
+				</li>
+				<li>
+					<b>New Auto-Approve Options:</b> Turn off Cline's ability to read and edit files outside your workspace.
+				</li>
+			</ul>
+			{/*
+			// Leave this here for an example of how to structure the announcement
+			<ul style={{ margin: "0 0 8px", paddingLeft: "12px" }}>
+				 <li>
+					OpenRouter now supports prompt caching! They also have much higher rate limits than other providers,
+					so I recommend trying them out.
+					<br />
+					{!apiConfiguration?.openRouterApiKey && (
+						<VSCodeButtonLink
+							href={getOpenRouterAuthUrl(vscodeUriScheme)}
+							style={{
+								transform: "scale(0.85)",
+								transformOrigin: "left center",
+								margin: "4px -30px 2px 0",
+							}}>
+							Get OpenRouter API Key
+						</VSCodeButtonLink>
+					)}
+					{apiConfiguration?.openRouterApiKey && apiConfiguration?.apiProvider !== "openrouter" && (
+						<VSCodeButton
+							onClick={() => {
+								vscode.postMessage({
+									type: "apiConfiguration",
+									apiConfiguration: { ...apiConfiguration, apiProvider: "openrouter" },
+								})
+							}}
+							style={{
+								transform: "scale(0.85)",
+								transformOrigin: "left center",
+								margin: "4px -30px 2px 0",
+							}}>
+							Switch to OpenRouter
+						</VSCodeButton>
+					)}
+				</li>
+				<li>
+					<b>Edit Cline's changes before accepting!</b> When he creates or edits a file, you can modify his
+					changes directly in the right side of the diff view (+ hover over the 'Revert Block' arrow button in
+					the center to undo "<code>{"// rest of code here"}</code>" shenanigans)
+				</li>
+				<li>
+					New <code>search_files</code> tool that lets Cline perform regex searches in your project, letting
+					him refactor code, address TODOs and FIXMEs, remove dead code, and more!
+				</li>
+				<li>
+					When Cline runs commands, you can now type directly in the terminal (+ support for Python
+					environments)
+				</li>
+			</ul>*/}
+			<div style={hrStyle} />
+			<p style={linkContainerStyle}>
+				Join us on{" "}
+				<VSCodeLink style={linkStyle} href="https://x.com/cline">
+					X,
+				</VSCodeLink>{" "}
+				<VSCodeLink style={linkStyle} href="https://discord.gg/cline">
+					discord,
+				</VSCodeLink>{" "}
+				or{" "}
+				<VSCodeLink style={linkStyle} href="https://www.reddit.com/r/cline/">
+					r/cline
+				</VSCodeLink>
+				for more updates!
+			</p>
+		</div>
+	)
+}
+</announcement-component>
+
+
+We have a changeset PR that automatically generated as new unreleased PRs are merged into main, the PR is always called "Changeset version bump" and the author is github-actions. 
+
+The Changeset PR description looks something like this:
+
+<changeset-pr-description>
+This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
+
+
+# Releases
+## claude-dev@3.16.0
+
+### Minor Changes
+
+-   c6e8b04: Recent task list is now collapsible, allowing users to hide their recent tasks (e.g. when sharing their screen).
+-   aabe4ae: Add detection for new users to display special components
+-   6c18d51: adds global endpoint for vertex ai users
+-   080ed7c: Add Tailwind CSS IntelliSense to the the recommended extensions list
+-   5147e28: new workflow feature
+
+### Patch Changes
+
+-   c0b3c69: fix eternal loading states when the last message is a checkpoint
+-   570ece3: selectImages protos migration
+-   8d8452e: askResponse protobus migration
+-   cd1ff2a: Finishing the migration of Vscode Advanced settings to Settings Webview
+</changeset-pr-description>
+
+The changeset pr is ALWAYS on the following branch: `changeset-release/main`.
+
+I have the `gh` command line tool set up and authenticated, so you have everything you need.
+
+The first step is to get the full diff from the changeset PR to look at the changes that were automatically made to the `CHANGELOG.md` file. By default it will automatically add a new section to the changelog.md file with the new version. The problem with the automatically generated section is that it just takes the text that the developers threw into their changeset files for each corresponding PR, and they can be pretty vague and bad. Additionally there's some stuff that is totally irrelevant for the end user, like minor refactoring changes. So I manually typically go in and update this section to be a proper changelog that will show up in our patchnotes. You can look at how the rest of the file is done because those are all good examples of us updating this to use good language for the end user. We usually put new features up top (and the most exciting flagship features at the very top), and then bug fixes/improvements at the bottom. Having some basic organization to the ordering of the bullet points by content is nice. But use common sense. 
+
+To handle this process effectively, do the following:
+
+For each of the automatically generated bullet points in the Changelog.md, you should
+1. Take the commit hash at the start of the bullet point, and use the `gh` command line tool find the PR that it was associated with. 
+2. Use the `gh` command to get the PR title/description/discussion to understand the context surrounding the PR.
+3. Use the `gh` command line tool to get the full PR diff to fully understand the changes made in the code.
+4. Synthesize that knowledge to determine (a) whether or not this change is relevant to end users and (b) what the text & ordering of the line should be.  
+5. Update the `CHANGELOG.md` accordingly 
+
+Do this for every single item in the list from the autogenerated bullet points. We want to be diligent and have a full understanding of every feature so we can make the best changelog ever!
+
+Here are some principles for good changelogs from keepchangelog.com, a handy guide:
+
+<keepachangelog-pinciples-for-good-changelogs>
+### Guiding Principles
+- Changelogs are for humans, not machines.
+- There should be an entry for every single version.
+- The same types of changes should be grouped.
+- The latest version comes first.
+
+### Bullet points in the changelog should follow these principles:
+- Types of changes
+- Added for new features.
+- Changed for changes in existing functionality.
+- Deprecated for soon-to-be removed features.
+- Removed for now removed features.
+- Fixed for any bug fixes.
+- Security in case of vulnerabilities.
+</keepachangelog-pinciples-for-good-changelogs>
+
+Lastly, when developers make a PR, they typically make a changeset. And they have 3 options when making the changeset:
+
+1. Patch
+2. Minor
+3. Major
+
+Sometimes they label something as minor when really it should just be a patch. Or vice versa. Because of this, the automatic version bump may be incorrect. So when starting out this workflow, you should use the <ask_followup_question> tool to confirm with me whether or not this should be a patch bump (show the old version number and what the proposed new version number would be) or a minor bump. Part of the release process is making sure the version in package.json that is automatically changed actually corresponds with what we decided the bump should actually be based on the features. ALL these modifications happen in the `changeset-release/main` branch btw. 
+
+<important_note>
+Before doing any of this, make sure you check out the `changeset-release/main` and pull the most recent up to date changes. Then perform all this work in that branch. 
+
+New announcement banners should ONLY be made for minor version bumps or higher. That's another reason why double checking if the changelog warrants the bump is important.
+
+Also, SUPER important: For any external contributors that aren't part of the cline github organization, we always want to add a (Thanks @username!) at the end of the changelog to attribute them properly. We're an open source project and it's ethical to do this.
+</important_note>
+
+Once the changelog looks good, and the version number looks good, we gotta double check that the version number in the changelog has the brackets around it. And as a final step, double check the package.json version number matches the latest number in the changelog. And as the ultimate final step we run `npm run install:all` to make sure the package version number permiates through the lock file. 
+
+
+<detailed_sequence_of_steps>
+# Cline Release Process - Detailed Sequence of Steps
+
+## Before Starting
+1. First, examine the changeset PR without checking it out:
+   ```bash
+   gh pr view changeset-release/main
+   ```
+
+2. View the PR diff to see the auto-generated CHANGELOG.md changes:
+   ```bash
+   gh pr diff changeset-release/main > changeset-diff.txt
+   cat changeset-diff.txt | grep -A 50 "CHANGELOG.md"
+   ```
+
+## Initial Setup
+3. Once you're ready to start, checkout and update the changeset release branch:
+   ```bash
+   git checkout changeset-release/main
+   git pull origin changeset-release/main
+   ```
+
+## Analyzing Each Change
+4. For each commit hash in the auto-generated changelog entries:
+
+   a. Find the PR number associated with a commit hash:
+      ```bash
+      gh pr list --search "<commit-hash>" --state merged
+      ```
+   
+   b. Get PR details for better context:
+      ```bash
+      gh pr view <PR-number>
+      ```
+   
+   c. Check if the contributor is external to determine if attribution is needed:
+      ```bash
+      # Extract username from PR
+      USERNAME=$(gh pr view <PR-number> --json author --jq .author.login)
+      
+      # Check if user is a member of the Cline organization
+	  # this command is a bit finnicky, but it 100% works. 
+	  # if you see a `Error executing command: The command ran successfully, but we couldn't capture its output. Please proceed accordingly.` error, just retry it until you actually get the output
+	  # don't make any assumptions, just retry the command to actually get the output and determine if they're external or not.
+	  # no output means they are an external contributor, otherwise if there is output they are an internal contributor (part of our github org)
+      gh api "orgs/cline/members" --jq "map(.login)" | grep -i "pashpashpash"
+      ```
+   
+   d. View the full PR diff to understand code changes:
+      ```bash
+      gh pr diff <PR-number> > pr-diff-<PR-number>.txt
+      cat pr-diff-<PR-number>.txt
+      ```
+
+## Updating the Changelog
+5. Based on PR analysis, update the CHANGELOG.md with user-friendly descriptions:
+   - Use the `<replace_in_file>` tool to edit the CHANGELOG.md file
+   - Group by feature type (Added, Changed, Fixed)
+   - Put most exciting features at the top
+   - Move bug fixes and small improvements to the bottom
+   - Use clear, end-user focused language
+   - For external contributors, add attribution at the end of the relevant entry: `(Thanks @username!)`
+
+## Version Number Verification
+6. Confirm the version bump is appropriate:
+   - Check package.json to verify the auto-generated version number:
+     ```bash
+     cat package.json | grep "\"version\""
+     ```
+   - If the feature set doesn't warrant a minor bump, use the `<replace_in_file>` tool to modify package.json
+
+7. Ensure the version in CHANGELOG.md has brackets around it:
+   ```
+   ## [3.16.0]
+   ```
+
+## Creating the Announcement (for minor/major versions only)
+8. If this is a minor version bump, create/update the announcement component:
+   - Use the `<replace_in_file>` tool to edit the src/views/components/announcement.tsx file
+   - Update the highlights based on key features
+   - Move previous version highlights to the "Previous Updates" section
+   - Use the previous announcement components as reference for structure
+
+## Finalizing the Release
+9. Update dependencies with the new version number:
+   ```bash
+   npm run install:all
+   ```
+
+10. Commit your changes:
+    ```bash
+    git add CHANGELOG.md package.json package-lock.json src/views/components/announcement.tsx
+    git commit -m "Update CHANGELOG.md and announcement for version 3.16.0"
+    ```
+
+11. Push your changes to the changeset branch:
+    ```bash
+    git push origin changeset-release/main
+    ```
+
+12. Check that your changes pushed successfully:
+    ```bash
+    git status
+    ```
+</detailed_sequence_of_steps>

docs/docs.json

@@ -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/features/cline-rules.mdx

@@ -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/slash-commands/new-rule.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-task.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/report-bug.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/smol.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).

docs/features/slash-commands/workflows.mdx

@@ -0,0 +1,323 @@
+---
+title: "Workflows"
+sidebarTitle: "Workflows"
+---
+
+Workflows allow you to define a series of steps to guide Cline through a repetitive set of tasks, such as deploying a service or submitting a PR.
+
+To invoke a workflow, type `/[workflow-name.md]` in the chat.
+
+## How to Create and Use Workflows
+
+Workflows live alongside Cline Rules. Creating one is straightforward:
+
+<Frame>
+	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/workflows.png" alt="Workflows tab in Cline" />
+</Frame>
+
+1. Create a markdown file with clear instructions for the steps Cline should take
+2. Save it with a `.md` extension in your workflows directory
+3. To trigger a workflow, just type `/` followed by the workflow filename
+4. Provide any required parameters when prompted
+
+The real power comes from how you structure your workflow files. You can:
+
+-   Leverage Cline's built-in tools like `ask_followup_question`, `read_file`, and `search_files`
+-   Use command-line tools you already have installed like `gh` or `docker`
+-   Reference external MCP tool calls like Slack or Whatsapp
+-   Chain multiple actions together in a specific sequence
+
+## Real-world Example
+
+I created a PR Review workflow that's already saving me tons of time.
+
+````md pr-review.md [expandable]
+You have access to the `gh` terminal command. I already authenticated it for you. Please review it to use the PR that I asked you to review. You're already in the `cline` repo.
+
+<detailed_sequence_of_steps>
+
+# GitHub PR Review Process - Detailed Sequence of Steps
+
+## 1. Gather PR Information
+
+1. Get the PR title, description, and comments:
+
+    ```bash
+    gh pr view <PR-number> --json title,body,comments
+    ```
+
+2. Get the full diff of the PR:
+    ```bash
+    gh pr diff <PR-number>
+    ```
+
+## 2. Understand the Context
+
+1. Identify which files were modified in the PR:
+
+    ```bash
+    gh pr view <PR-number> --json files
+    ```
+
+2. Examine the original files in the main branch to understand the context:
+
+    ```xml
+    <read_file>
+    <path>path/to/file</path>
+    </read_file>
+    ```
+
+3. For specific sections of a file, you can use search_files:
+    ```xml
+    <search_files>
+    <path>path/to/directory</path>
+    <regex>search term</regex>
+    <file_pattern>*.ts</file_pattern>
+    </search_files>
+    ```
+
+## 3. Analyze the Changes
+
+1. For each modified file, understand:
+
+    - What was changed
+    - Why it was changed (based on PR description)
+    - How it affects the codebase
+    - Potential side effects
+
+2. Look for:
+    - Code quality issues
+    - Potential bugs
+    - Performance implications
+    - Security concerns
+    - Test coverage
+
+## 4. Ask for User Confirmation
+
+1. Before making a decision, ask the user if you should approve the PR, providing your assessment and justification:
+
+    ```xml
+    <ask_followup_question>
+    <question>Based on my review of PR #<PR-number>, I recommend [approving/requesting changes]. Here's my justification:
+
+    [Detailed justification with key points about the PR quality, implementation, and any concerns]
+
+    Would you like me to proceed with this recommendation?</question>
+    <options>["Yes, approve the PR", "Yes, request changes", "No, I'd like to discuss further"]</options>
+    </ask_followup_question>
+    ```
+
+## 5. Ask if User Wants a Comment Drafted
+
+1. After the user decides on approval/rejection, ask if they would like a comment drafted:
+
+    ```xml
+    <ask_followup_question>
+    <question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
+    <options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
+    </ask_followup_question>
+    ```
+
+2. If the user wants a comment drafted, provide a well-structured comment they can copy:
+
+    ```
+    Thank you for this PR! Here's my assessment:
+
+    [Detailed assessment with key points about the PR quality, implementation, and any suggestions]
+
+    [Include specific feedback on code quality, functionality, and testing]
+    ```
+
+## 6. Make a Decision
+
+1. Approve the PR if it meets quality standards:
+
+    ```bash
+    gh pr review <PR-number> --approve --body "Your approval message"
+    ```
+
+2. Request changes if improvements are needed:
+    ```bash
+    gh pr review <PR-number> --request-changes --body "Your feedback message"
+    ```
+    </detailed_sequence_of_steps>
+
+<example_review_process>
+
+# Example PR Review Process
+
+Let's walk through a real example of reviewing PR #3627 which fixes the thinking mode calculation for Claude 3.7 models.
+
+## Step 1: Gather PR Information
+
+```bash
+# Get PR details
+gh pr view 3627 --json title,body,comments
+
+# Get the full diff
+gh pr diff 3627
+```
+
+## Step 2: Understand the Context
+
+```xml
+# Examine the original files to understand what's being changed
+<read_file>
+<path>src/shared/api.ts</path>
+</read_file>
+
+# Look at the ThinkingBudgetSlider component implementation
+<read_file>
+<path>webview-ui/src/components/settings/ThinkingBudgetSlider.tsx</path>
+</read_file>
+
+# Check how thinking mode is currently handled in API providers
+<search_files>
+<path>src/api/providers</path>
+<regex>reasoningOn</regex>
+<file_pattern>*.ts</file_pattern>
+</search_files>
+```
+
+## Step 3: Analyze the Changes
+
+From the PR information and code examination, we can see that:
+
+1. The PR fixes an issue with the thinking mode budget calculation for Claude 3.7 models
+2. Currently, the thinking budget is incorrectly calculated as 80% of maxTokens (8192), resulting in 6553 tokens
+3. Claude 3.7 actually supports a much larger thinking budget (up to 64000 tokens)
+4. The PR adds a `thinkingConfig` property with `maxBudget: 64000` to model definitions
+5. It updates API handlers to use this value when reasoning mode is enabled
+6. It enhances the slider component to calculate max values based on model-specific percentages
+7. Comprehensive tests were added to verify the calculations
+
+## Step 4: Ask for User Confirmation
+
+```xml
+<ask_followup_question>
+<question>Based on my review of PR #3627, I recommend approving this PR. Here's my justification:
+
+1. The PR correctly fixes the thinking mode budget calculation for Claude 3.7 models
+2. It properly implements the thinkingConfig.maxBudget property (64000) for Claude 3.7 models
+3. It applies the appropriate percentage (50%) for the slider calculation
+4. The changes are well-tested with comprehensive unit tests
+5. The implementation is clean and follows the project's coding standards
+6. The PR includes helpful screenshots demonstrating the fix
+
+Would you like me to proceed with approving this PR?</question>
+<options>["Yes, approve the PR", "No, I'd like to discuss further", "Let me review it myself first"]</options>
+</ask_followup_question>
+```
+
+## Step 5: Ask if User Wants a Comment Drafted
+
+```xml
+<ask_followup_question>
+<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
+<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
+</ask_followup_question>
+```
+
+## Step 6: Make a Decision
+
+```bash
+gh pr review 3627 --approve --body "This PR looks good! It correctly fixes the thinking mode budget calculation for Claude 3.7 models by using the appropriate maxBudget value (64000) and applying the right percentage (50%) for the slider. The changes are well-tested and the implementation is clean."
+```
+
+</example_review_process>
+
+<common_gh_commands>
+
+# Common GitHub CLI Commands for PR Review
+
+## Basic PR Commands
+
+```bash
+# List open PRs
+gh pr list
+
+# View a specific PR
+gh pr view <PR-number>
+
+# View PR with specific fields
+gh pr view <PR-number> --json title,body,comments,files,commits
+
+# Check PR status
+gh pr status
+```
+
+## Diff and File Commands
+
+```bash
+# Get the full diff of a PR
+gh pr diff <PR-number>
+
+# List files changed in a PR
+gh pr view <PR-number> --json files
+
+# Check out a PR locally
+gh pr checkout <PR-number>
+```
+
+## Review Commands
+
+```bash
+# Approve a PR
+gh pr review <PR-number> --approve --body "Your approval message"
+
+# Request changes on a PR
+gh pr review <PR-number> --request-changes --body "Your feedback message"
+
+# Add a comment review (without approval/rejection)
+gh pr review <PR-number> --comment --body "Your comment message"
+```
+
+## Additional Commands
+
+```bash
+# View PR checks status
+gh pr checks <PR-number>
+
+# View PR commits
+gh pr view <PR-number> --json commits
+
+# Merge a PR (if you have permission)
+gh pr merge <PR-number> --merge
+```
+
+</common_gh_commands>
+````
+
+When I get a new PR to review, I used to manually gather context: checking the PR description, examining the diff, looking at surrounding files, and finally forming an opinion. Now I just:
+
+1. Type `/pr-review.md` in chat
+2. Paste in the PR number
+3. Let Cline handle everything else
+
+My workflow uses the `gh` command-line tool to:
+
+-   Pull the PR description and comments
+-   Examine the diff
+-   Check surrounding files for context
+-   Analyze potential issues
+-   Asks me if it's cool approve it if everything looks good, with justification for why it should be approved
+-   If I say "yes," Cline automatically approves the PR with the `gh` command
+
+This has taken my PR review process from a manual, multi-step operation to a single command that gives me everything I need to make an informed decision.
+
+> This is just one example of a workflow file. You can find more in our [prompts repository](https://github.com/cline/prompts) for inspiration.
+
+## Building Your Own Workflows
+
+The beauty of workflows is they're completely customizable to your needs. You might create workflows for all kinds of repetitive tasks:
+
+-   For releases, you could have a workflow that grabs all merged PRs, builds a changelog, and handles version bumps.
+-   Setting up new projects is perfect for workflows. Just run one command to create your folder structure, install dependencies, and set up configs.
+-   Need to create a report? Create a workflow that grabs stats from different sources and formats them exactly how you like. You can even visualize them with a charting library and then make a presentation out of it with a library like [slidev](https://sli.dev/).
+-   You can even use workflows to draft messages to your team using an MCP server like Slack or Whatsapp after you submit a PR.
+
+With Workflows, your imagination is the limit. The true potential comes from spotting those annoying repetitive tasks you do all the time.
+
+If you can describe something as "first I do X, then Y, then Z" - that's a perfect workflow candidate.
+
+Start with something small that bugs you, turn it into a workflow, and keep refining it. You'll be shocked how much of your day can be automated this way.

docs/package.json

@@ -0,0 +1,16 @@
+{
+	"name": "docs",
+	"version": "1.0.0",
+	"main": "index.js",
+	"scripts": {
+		"test": "echo \"Error: no test specified\" && exit 1",
+		"dev": "mintlify dev"
+	},
+	"keywords": [],
+	"author": "",
+	"license": "ISC",
+	"description": "",
+	"dependencies": {
+		"mintlify": "^4.0.538"
+	}
+}

docs/prompting/prompt-engineering-guide.mdx

@@ -4,212 +4,6 @@ title: "Prompt Engineering Guide"
 
 Welcome to the Cline Prompting Guide! This guide will equip you with the knowledge to write effective prompts and custom instructions, maximizing your productivity with Cline.
 
-## Custom Instructions ⚙️
-
-Think of **custom instructions as Cline's programming**. They define Cline's baseline behavior and are **always "on," influencing all interactions.** Instructions can be broad and abstract, or specific and explicit. You might want Cline to have a unique personality, or produce output in a particular file format, or adhere to certain architectural principles. Custom instructions can standardize Cline's output in ways you define, which is especially valuable when working with others. See the [Enterprise section](../enterprise-solutions/custom-instructions.md) for using Custom Instructions in a team context.\
-\
-
-<mark style="color:yellow;">
-	NOTE: Modifying the Custom Instructions field updates Cline's prompt cache, discarding accumulated context. This causes a
-	temporary increase in cost while that context is replaced. Update Custom Instructions between conversations whenever possible.
-</mark>
-
-To add custom instructions:
-
-1. Open VSCode
-2. Click the Cline extension settings dial ⚙️
-3. Find the "Custom Instructions" field
-4. Paste your instructions
-
-<Frame>
-	<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(1).png" alt="Cline Logo" />
-</Frame>
-
-Custom instructions are powerful for:
-
--   Enforcing Coding Style and Best Practices: Ensure Cline always adheres to your team's coding conventions, naming conventions, and best practices.
--   Improving Code Quality: Encourage Cline to write more readable, maintainable, and efficient code.
--   Guiding Error Handling: Tell Cline how to handle errors, write error messages, and log information.
-
----
-
-## .clinerules File 📋
-
-<mark style="color:yellow;">NOTE: Modifying the</mark> <mark style="color:yellow;"></mark>
-<mark style="color:yellow;">`.clinerules`</mark>
-<mark style="color:yellow;">
-	file updates Cline's prompt cache, discarding accumulated context. This causes a temporary increase in cost while that context
-	is replaced. Update the
-</mark> <mark style="color:yellow;"></mark>
-<mark style="color:yellow;">`.clinerules`</mark> <mark style="color:yellow;"></mark>
-<mark style="color:yellow;">file between conversations whenever possible.</mark>
-
-While custom instructions are user-specific and global (applying across all projects), the `.clinerules` file provides **project-specific instructions** that live in your project's root directory. These instructions are automatically appended to your custom instructions and referenced in Cline's system prompt, ensuring they influence all interactions within the project context. This makes it an excellent tool for:
-
-### General Use Cases
-
-The `.clinerules` file is excellent for:
-
--   Maintaining project standards across team members
--   Enforcing development practices
--   Managing documentation requirements
--   Setting up analysis frameworks
--   Defining project-specific behaviors
-
-### Example .clinerules Structure
-
-```markdown
-# 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 Custom Instructions
-
--   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 📂
-
-While a single `.clinerules` file works well for simpler projects, Cline now supports a `.clinerules` folder for more sophisticated rule organization. This modular approach brings several advantages:
-
-#### How It Works
-
-Instead of a single file, create a `.clinerules/` directory in your project root:
-
-```
-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>
-
 ## .clineignore File Guide
 
 ### Overview