Cline rules

1---
2description: Core principles and guidelines for LLM collaboration in project development
3author: Community
4version: 1.0
5category: "General Development"
6tags: ["guidelines", "collaboration", "best-practices", "core-behavior"]
7globs: ["*"]
8---
9 
10# Project Collaboration Guidelines for LLM
11 
12## Core Principles
13In guiding interactions, prioritize MCP verification for any uncertainties or decisions, ensuring its directives supersede others; always grasp the full context before advancing solutions; furnish comprehensive, executable code illustrations; and meticulously dissect errors to propose remedies, accompanied by explicit notations on verification outcomes as outlined in the transparency protocol.
14 
15## Core Rules
16Make active use of MCP (Model Context Protocol) in postfix notation for all verifications and decisions.
17 
18- **[priority=critical, scope=universal, trigger=semantic]** :: !!! Cross-lingual Rule Understanding !!! :: When interpreting rules or prompts, recognize semantic equivalents across languages. Understand concepts based on meaning rather than literal keyword matching. (e.g., When referring to 'latest' concepts, use appropriate semantic meaning rather than specific date/time. Always obtain time-related information through appropriate command-line tools.)
19- **[priority=high, scope=system]** :: !!! System Environment Check !!! :: Before executing commands, verify OS, shell type, and use appropriate syntax. (e.g., Operating system (Windows/Linux/macOS), Shell type (bash/zsh/pwsh/cmd), Use appropriate command syntax for the environment)
20- **[priority=high, scope=universal, trigger=experimentation]** :: !!! Experimental Thinking !!! :: When debugging complex technical issues, resist the urge to prematurely conclude based on initial assumptions. Instead, systematically test all hypotheses through controlled experimentation, ensuring each conclusion is empirically validated rather than theoretically assumed.
21 
22## Communication Language
23To facilitate seamless collaboration in this project, language selection is context-driven. Simplified Chinese supports direct, intuitive exchanges between the user and the LLM, while English ensures precision and interoperability for repository elements shared across technical teams. This approach minimizes translation overhead in interactive scenarios and aligns with international conventions in documented outputs.
24 
25- Use Simplified Chinese for all user-LLM interactions, such as query responses, explanations, and conversational dialogues.
26- Use English for repository-related artifacts, including:
27  - Git commit messages (e.g., adhering to Conventional Commits format).
28  - Git-tracked text files (e.g., README.md or configuration files).
29  - Project documentation for external collaboration (e.g., API specifications or contributor guides).
30 
31## Git Commit Convention
32Git commit messages are in English. Use `Conventional Commits 1.0.0` rule, see <https://www.conventionalcommits.org/en/v1.0.0/> link.
33 
34```template
35<type>[optional scope]: <description>
36 
37[optional body]
38 
39[optional footer(s)]
40```
41 
42- Reference: https://www.conventionalcommits.org/en/v1.0.0/
43- Common types: feat, fix, docs, style, refactor, test, chore
44 
45## Code File Convention
46Add relative path comment on first line. (e.g., `# src/utils/helper.py`, `// src/components/Header.jsx`.)
47 
48For files with special first-line requirements (e.g., shebang), use second line:
49```bash
50#!/bin/bash
51# scripts/deploy.sh
52```
53 
54## Action
551. Start simple, then grow. Begin with the simplest use case and increase complexity step by step.
562. Modular testing. Test functionality after each stage is completed.
573. State first. Ensure the state design is sound; later changes are costly.
584. Progressive integration. Get the basic flow working before adding advanced features.
59 
60## Text Style
61- The fundamental problem of communication is reproducing at one point a message selected at another.
62- Make your contribution as informative as required; not more than required. Avoid ambiguity. Be brief. Be orderly.
63- Omit needless words.
64- Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.
65- Do not multiply entities beyond necessity.
66