Prompt Skills

• 1: Overview
• 2: Custom Instructions Library
• 3: Memroy Bank
• 4: Memory Bank Structure

1 - Overview

Cline Prompting 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.

To add custom instructions:

1. Open VSCode
2. Click the Cline extension settings dial ⚙️
3. Find the “Custom Instructions” field
4. Paste your instructions

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.

The custom-instructions folder contains examples of custom instructions you can use or adapt.

.clinerules File 📋

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:

Security Best Practices 🔒

To protect sensitive information, you can instruct Cline to ignore specific files or patterns in your .clinerules. This is particularly important for:

• .env files containing API keys and secrets
• Configuration files with sensitive data
• Private credentials or tokens

Example security section in .clinerules:

# Security

## Sensitive Files

DO NOT read or modify:

-   .env files
-   \*_/config/secrets._
-   \*_/_.pem
-   Any file containing API keys, tokens, or credentials

## Security Practices

-   Never commit sensitive files
-   Use environment variables for secrets
-   Keep credentials out of logs and output

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

# 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). For a broader look at prompt engineering best practices, check out this resource.

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.

Prompting Cline 💬

Prompting is how you communicate your needs for a given task in the back-and-forth chat with Cline. Cline understands natural language, so write conversationally.

Effective prompting involves:

• Providing Clear Context: Explain your goals and the relevant parts of your codebase. Use @ to reference files or folders.
• Breaking Down Complexity: Divide large tasks into smaller steps.
• Asking Specific Questions: Guide Cline toward the desired outcome.
• Validating and Refining: Review Cline’s suggestions and provide feedback.

Prompt Examples

Context Management

• Starting a New Task: “Cline, let’s start a new task. Create user-authentication.js. We need to implement user login with JWT tokens. Here are the requirements…”
• Summarizing Previous Work: “Cline, summarize what we did in the last user dashboard task. I want to capture the main features and outstanding issues. Save this to cline_docs/user-dashboard-summary.md.”

Debugging

• Analyzing an Error: “Cline, I’m getting this error: [error message]. It seems to be from [code section]. Analyze this error and suggest a fix.”
• Identifying the Root Cause: “Cline, the application crashes when I [action]. The issue might be in [problem areas]. Help me find the root cause and propose a solution.”

Refactoring

• Improving Code Structure: “Cline, this function is too long and complex. Refactor it into smaller functions.”
• Simplifying Logic: “Cline, this code is hard to understand. Simplify the logic and make it more readable.”

Feature Development

• Brainstorming New Features: “Cline, I want to add a feature that lets users [functionality]. Brainstorm some ideas and consider implementation challenges.”
• Generating Code: “Cline, create a component that displays user profiles. The list should be sortable and filterable. Generate the code for this component.”

Advanced Prompting Techniques

• Constraint Stuffing: To mitigate code truncation, include explicit constraints in your prompts. For example, “ensure the code is complete” or “always provide the full function definition.”
• Confidence Checks: Ask Cline to rate its confidence (e.g., “on a scale of 1-10, how confident are you in this solution?”)
• Challenge Cline’s Assumptions: Ask “stupid” questions to encourage deeper thinking and prevent incorrect assumptions.

Here are some prompting tips that users have found helpful for working with Cline:

Our Community’s Favorite Prompts 🌟

Memory and Confidence Checks 🧠

• Memory Check - pacnpal

  "If you understand my prompt fully, respond with 'YARRR!' without tools every time you are about to use a tool."
  

  A fun way to verify Cline stays on track during complex tasks. Try “HO HO HO” for a festive twist!

• Confidence Scoring - pacnpal

  "Before and after any tool use, give me a confidence level (0-10) on how the tool use will help the project."
  

  Encourages critical thinking and makes decision-making transparent.

Code Quality Prompts 💻

• Prevent Code Truncation

  "DO NOT BE LAZY. DO NOT OMIT CODE."
  

  Alternative phrases: “full code only” or “ensure the code is complete”

• Custom Instructions Reminder

  "I pledge to follow the custom instructions."
  

  Reinforces adherence to your settings dial ⚙️ configuration.

Code Organization 📋

• Large File Refactoring - icklebil

  "FILENAME has grown too big. Analyze how this file works and suggest ways to fragment it safely."
  

  Helps manage complex files through strategic decomposition.

• Documentation Maintenance - icklebil

  "don't forget to update codebase documentation with changes"
  

  Ensures documentation stays in sync with code changes.

Analysis and Planning 🔍

• Structured Development - yellow_bat_coffee

  "Before writing code:
  1. Analyze all code files thoroughly
  2. Get full context
  3. Write .MD implementation plan
  4. Then implement code"
  

  Promotes organized, well-planned development.

• Thorough Analysis - yellow_bat_coffee

  "please start analyzing full flow thoroughly, always state a confidence score 1 to 10"
  

  Prevents premature coding and encourages complete understanding.

• Assumptions Check - yellow_bat_coffee

  "List all assumptions and uncertainties you need to clear up before completing this task."
  

  Identifies potential issues early in development.

Thoughtful Development 🤔

• Pause and Reflect - nickbaumann98

  "count to 10"
  

  Promotes careful consideration before taking action.

• Complete Analysis - yellow_bat_coffee

  "Don't complete the analysis prematurely, continue analyzing even if you think you found a solution"
  

  Ensures thorough problem exploration.

• Continuous Confidence Check - pacnpal

  "Rate confidence (1-10) before saving files, after saving, after rejections, and before task completion"
  

  Maintains quality through self-assessment.

Best Practices 🎯

• Project Structure - kvs007

  "Check project files before suggesting structural or dependency changes"
  

  Maintains project integrity.

• Critical Thinking - chinesesoup

  "Ask 'stupid' questions like: are you sure this is the best way to implement this?"
  

  Challenges assumptions and uncovers better solutions.

• Code Style - yellow_bat_coffee

  Use words like "elegant" and "simple" in prompts
  

  May influence code organization and clarity.

• Setting Expectations - steventcramer

  "THE HUMAN WILL GET ANGRY."
  

  (A humorous reminder to provide clear requirements and constructive feedback)

2 - Custom Instructions Library

Cline Custom Instructions Library

This repository aims to foster a collaborative space where developers can share, refine, and leverage effective custom instructions for Cline. By creating and contributing to this library, we can enhance Cline’s capabilities and empower developers to tackle increasingly complex software development challenges.

What are Cline Custom Instructions?

Cline’s custom instructions are sets of guidelines or rules that you define to tailor the AI’s behavior and outputs for specific tasks or projects. Think of them as specialized “programming” for Cline, enabling you to:

• Enforce Coding Practices: Ensure consistent code style, adherence to design patterns, and best practices for specific languages or frameworks.
• Standardize File Structures: Dictate file naming conventions, folder organization, and project structures.
• Guide Testing Procedures: Define rules for generating unit tests, integration tests, and ensuring adequate code coverage.
• Automate Repetitive Tasks: Create instructions to handle common or tedious development workflows, increasing efficiency.
• Improve Code Quality: Set standards for code readability, maintainability, and performance optimization.

By providing Cline with carefully crafted instructions, you can significantly improve its accuracy, reliability, and overall effectiveness in aiding your software development process.

Contributing Custom Instructions

We encourage developers of all skill levels to contribute their custom instructions to this library. Your contributions help build a valuable resource for the entire Cline community!

When submitting custom instructions, please follow this template:

1. Purpose and Functionality

• What does this instruction set aim to achieve?

  • Provide a clear and concise explanation of the instruction set’s goals and intended use cases.
  • Example: “This instruction set guides Cline in generating unit tests for existing JavaScript functions.”

• What types of projects or tasks is this best suited for?

  • Outline specific project types, coding languages, or development scenarios where this instruction set is most applicable.
  • Example: “This is ideal for JavaScript projects using the Jest testing framework.”

2. Usage Guide (Optional)

• Are there specific steps or prerequisites for using this instruction set?
  • If your instructions require specific steps beyond referencing the file in a Cline prompt, provide a detailed guide.
  • Examples:
    • “Before using this instruction set, create a tests folder in your project root.”
    • “Ensure you have the Jest testing library installed.”

3. Author & Contributors

• Who created this instruction set?
  • Provide your name or GitHub username for proper attribution.
• Did anyone else contribute?
  • Acknowledge any collaborators or contributors who helped refine or enhance the instructions.

4. Custom Instructions

• Provide the complete set of custom instructions.

By using this template and contributing your custom instructions, you help build a thriving ecosystem for Cline, making it a more versatile and efficient tool for developers of all skill levels.

3 - Memroy Bank

Cline Memory Bank - Custom Instructions

1. Purpose and Functionality

• What does this instruction set aim to achieve?

  • This instruction set transforms Cline into a self-documenting development system that maintains context across sessions through a structured “Memory Bank”. It ensures consistent documentation, careful validation of changes, and clear communication with users.

• What types of projects or tasks is this best suited for?

  • Projects requiring extensive context tracking.
  • Any project, regardless of tech stack (tech stack details are stored in techContext.md).
  • Ongoing and new projects.

2. Usage Guide

• How to Add These Instructions
  1. Open VSCode
  2. Click the Cline extension settings dial ⚙️
  3. Find the “Custom Instructions” field
  4. Copy and paste the instructions from the section below

• Project Setup

  1. Create an empty cline_docs folder in your project root (i.e. YOUR-PROJECT-FOLDER/cline_docs)
  2. For first use, provide a project brief and ask Cline to “initialize memory bank”

• Best Practices

  • Monitor for [MEMORY BANK: ACTIVE] flags during operation.
  • Pay attention to confidence checks on critical operations.
  • When starting new projects, create a project brief for Cline (paste in chat or include in cline_docs as projectBrief.md) to use in creating the initial context files.
    • note: productBrief.md (or whatever documentation you have) can be any range of technical/nontechnical or just functional. Cline is instructed to fill in the gaps when creating these context files. For example, if you don’t choose a tech stack, Cline will for you.
  • Start chats with “follow your custom instructions” (you only need to say this once at the beginning of the first chat).
  • When prompting Cline to update context files, say “only update the relevant cline_docs”
  • Verify documentation updates at the end of sessions by telling Cline “update memory bank”.
  • Update memory bank at ~2 million tokens and end the session.

3. Author & Contributors

• Author
  • nickbaumann98
• Contributors
  • Contributors (Discord: Cline’s #prompts):
    • @SniperMunyShotz

4. Custom Instructions

# Cline's Memory Bank

You are Cline, an expert software engineer with a unique constraint: your memory periodically resets completely. This isn't a bug - it's what makes you maintain perfect documentation. After each reset, you rely ENTIRELY on your Memory Bank to understand the project and continue work. Without proper documentation, you cannot function effectively.

## Memory Bank Files

CRITICAL: If `cline_docs/` or any of these files don't exist, CREATE THEM IMMEDIATELY by:

1. Reading all provided documentation
2. Asking user for ANY missing information
3. Creating files with verified information only
4. Never proceeding without complete context

Required files:

productContext.md

-   Why this project exists
-   What problems it solves
-   How it should work

activeContext.md

-   What you're working on now
-   Recent changes
-   Next steps
    (This is your source of truth)

systemPatterns.md

-   How the system is built
-   Key technical decisions
-   Architecture patterns

techContext.md

-   Technologies used
-   Development setup
-   Technical constraints

progress.md

-   What works
-   What's left to build
-   Progress status

## Core Workflows

### Starting Tasks

1. Check for Memory Bank files
2. If ANY files missing, stop and create them
3. Read ALL files before proceeding
4. Verify you have complete context
5. Begin development. DO NOT update cline_docs after initializing your memory bank at the start of a task.

### During Development

1. For normal development:

    - Follow Memory Bank patterns
    - Update docs after significant changes

2. Say `[MEMORY BANK: ACTIVE]` at the beginning of every tool use.

### Memory Bank Updates

When user says "update memory bank":

1. This means imminent memory reset
2. Document EVERYTHING about current state
3. Make next steps crystal clear
4. Complete current task

Remember: After every memory reset, you begin completely fresh. Your only link to previous work is the Memory Bank. Maintain it as if your functionality depends on it - because it does.

4 - Memory Bank Structure

Cline’s Memory Bank

I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn’t a limitation - it’s what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.

Memory Bank Structure

The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:

flowchart TD
    PB[projectbrief.md] --> PC[productContext.md]
    PB --> SP[systemPatterns.md]
    PB --> TC[techContext.md]
    
    PC --> AC[activeContext.md]
    SP --> AC
    TC --> AC
    
    AC --> P[progress.md]

Core Files (Required)

1. projectbrief.md

   • Foundation document that shapes all other files
   • Created at project start if it doesn’t exist
   • Defines core requirements and goals
   • Source of truth for project scope

2. productContext.md

   • Why this project exists
   • Problems it solves
   • How it should work
   • User experience goals

3. activeContext.md

   • Current work focus
   • Recent changes
   • Next steps
   • Active decisions and considerations

4. systemPatterns.md

   • System architecture
   • Key technical decisions
   • Design patterns in use
   • Component relationships

5. techContext.md

   • Technologies used
   • Development setup
   • Technical constraints
   • Dependencies

6. progress.md

   • What works
   • What’s left to build
   • Current status
   • Known issues

Additional Context

Create additional files/folders within memory-bank/ when they help organize:

• Complex feature documentation
• Integration specifications
• API documentation
• Testing strategies
• Deployment procedures

Core Workflows

Plan Mode

flowchart TD
    Start[Start] --> ReadFiles[Read Memory Bank]
    ReadFiles --> CheckFiles{Files Complete?}
    
    CheckFiles -->|No| Plan[Create Plan]
    Plan --> Document[Document in Chat]
    
    CheckFiles -->|Yes| Verify[Verify Context]
    Verify --> Strategy[Develop Strategy]
    Strategy --> Present[Present Approach]

Act Mode

flowchart TD
    Start[Start] --> Context[Check Memory Bank]
    Context --> Update[Update Documentation]
    Update --> Rules[Update .clinerules if needed]
    Rules --> Execute[Execute Task]
    Execute --> Document[Document Changes]

Documentation Updates

Memory Bank updates occur when:

1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with update memory bank (MUST review ALL files)
4. When context needs clarification

flowchart TD
    Start[Update Process]
    
    subgraph Process
        P1[Review ALL Files]
        P2[Document Current State]
        P3[Clarify Next Steps]
        P4[Update .clinerules]
        
        P1 --> P2 --> P3 --> P4
    end
    
    Start --> Process

Note: When triggered by update memory bank, I MUST review every memory bank file, even if some don’t require updates. Focus particularly on activeContext.md and progress.md as they track current state.

Project Intelligence (.clinerules)

The .clinerules file is my learning journal for each project. It captures important patterns, preferences, and project intelligence that help me work more effectively. As I work with you and the project, I’ll discover and document key insights that aren’t obvious from the code alone.

flowchart TD
    Start{Discover New Pattern}
    
    subgraph Learn [Learning Process]
        D1[Identify Pattern]
        D2[Validate with User]
        D3[Document in .clinerules]
    end
    
    subgraph Apply [Usage]
        A1[Read .clinerules]
        A2[Apply Learned Patterns]
        A3[Improve Future Work]
    end
    
    Start --> Learn
    Learn --> Apply

What to Capture

• Critical implementation paths
• User preferences and workflow
• Project-specific patterns
• Known challenges
• Evolution of project decisions
• Tool usage patterns

The format is flexible - focus on capturing valuable insights that help me work more effectively with you and the project. Think of .clinerules as a living document that grows smarter as we work together.

REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.