Workflow Rules

Language

• •By default always write documentation, comments, code, commit messages, and pull request titles/descriptions in English
• •Use English for all technical communication including:
  • •Code comments and documentation
  • •Commit messages and commit descriptions
  • •Pull request titles and descriptions
  • •Technical documentation and README files
  • •API documentation and code examples

Integrated Terminal

• •Prefer terminal commands over GUI operations when possible

Temporary Files Management

• •When creating temporary files, use temporary directories (./tmp or system tmp)
• •Never commit temporary files to version control

Workspace & Multi-Repository Rules

Workspace Structure Awareness

• •Always check current working directory and understand repository boundaries
• •Never assume single git repository when working in multi-repo workspace
• •Always verify which repository operations are targeting before execution

Multi-Repository Handling

• •When working with staged changes, identify which specific repository they belong to
• •Navigate to correct repository directory before running git operations
• •Treat each repository as separate entity with its own git state

Branch Management

• •Create feature branches from main/master
• •Use descriptive branch names
• •Keep branches focused on single features
• •Delete merged branches

Commit Workflow

• •Only commit when explicitly requested
• •Never commit unstaged changes without explicit request
• •Never commit directly to main/master branch
• •Make small, focused commits
• •Use conventional commit format
• •Include meaningful commit messages
• •Reference Linear issues when applicable
• •Do not add Co-authored-by: Cursor <cursoragent@cursor.com> (or any Cursor agent co-author trailer) to commit messages

PR Workflow

• •Create PRs for all main branch changes
• •Use descriptive PR titles
• •Include comprehensive descriptions
• •Request appropriate reviewers

Planning Workflow

Plan Creation Guidelines

• •Create plans in .cursor/plans/ directory
• •Use clear, actionable task breakdown
• •Include dependencies and prerequisites
• •Format as markdown with clear sections
• •NEVER include timelines or schedules
• •NEVER generate cronograms or time estimates
• •Focus on what needs to be done, not when

Plan Structure

• •

  Objective

• •

  Tasks

• •

  Dependencies

• •

  Acceptance Criteria

• •

  Notes

Plan Files

• •Save in .cursor/plans/ with .plan.md extension so plans match the standard format (e.g. descriptive-name.plan.md).
• •Use the same task/todo structure as native Cursor plans so plans stay consistent whether created in plan mode or in chat.

Documentation Standards

Content Guidelines

• •Clear and concise explanations
• •Practical examples and use cases
• •Consistent formatting and structure
• •Regular updates and maintenance
• •Avoid redundant information
• •Avoid overly complex explanations