Add automatic model switching in process rules or provide model switching commands

Feature Requests
1

After using Augment, I hope that cursor can make up for its shortcomings and optimize cursor better.
1-If the model can provide real-time switching according to process requirements, the effect will be much better. For example, Google 2.5 and deepr1 03mini are not good at executing tasks, but they are much better than Claude in proposing solutions and planning. If there is a way to make it switch according to the rules and processes in real time, it will be much better.
2-If this function can be completed, the pressure and cost of cursor’s advanced model server requests will be reduced a lot, and Claude 3.7 will not be used for a long time.

What do you think of this?

2

I think its a great idea. with something like

Empty for currently used model in Agent.

model:

Auto for auto selection

model: Auto

Model name for direct selection

model: claude-3.7-sonnet

Tricky part here is that e.g. claude-3.7-sonnet and related MAX/thinking models have 4 options.

So either this way (preferred and could use the Agent model selection tool for GUI, or manually entered in mdc file)

  • claude-3.7-sonnet
  • claude-3.7-sonnet-thinking
  • claude-3.7-sonnet-max
  • claude-3.7-sonnet-thinking-max

or (not the best option as it requires complex handling)

model: claude-3.7-sonnet
thinking: true
max: false

On rule usage:

  • Output which model is used into chat
  • Ask user for model selection if that model is not available (models change)
3

You can do it with Rules which will await your reply after Architec Mode it Switches to Act Mode which you reply with Act in the model of your choice seems to work great for me.

Development Workflow Modes

Architect Mode

  • Purpose: Rigorous information gathering, analysis, and solution planning before implementation to ensure alignment and feasibility (Target ≥95% confidence).
  • Process:
    1. GATHER: Understand requirements. Read relevant existing code, focusing on structure, patterns, and dependencies within the target area and potentially affected areas. Identify existing abstractions.
    2. ANALYZE: Verify assumptions against the codebase. Assess potential impact on maintainability, performance, testability, and existing functionalities. Report confidence percentage and identify knowledge gaps or risks. Identify potential refactoring opportunities or necessary clean-up alongside the primary task.
    3. DESIGN: Create a step-by-step implementation plan. Define clear interfaces and contracts between components/slices. Specify required tests (unit, integration, E2E) and how the design facilitates testability. Estimate complexity and potential challenges.
    4. TRANSITION: Propose the plan and suggest transitioning to Act Mode when confidence and clarity meet the threshold. Await explicit “Act” command.

Act Mode

  • Purpose: Systematic, test-driven implementation of the architected plan, ensuring seamless integration and adherence to quality standards.
  • Process:
    1. REVIEW: Confirm understanding of the plan, requirements, interfaces, and proposed tests.
    2. IMPLEMENT: Execute the plan step-by-step. Write tests before or concurrently with implementation (TDD/BDD strongly encouraged). Adhere strictly to established coding standards, style guides (enforced by linters/formatters), and naming conventions. Prioritize clarity and simplicity (YAGNI).
    3. VALIDATE: Run all relevant tests (unit, integration, E2E) and ensure they pass. Verify functionality against requirements. Run linters and static analysis tools; address all reported issues. Check code coverage against project standards. Perform basic performance checks for performance-sensitive changes.
    4. SAFEGUARD: Ensure changes integrate cleanly with existing patterns. Update or add documentation (READMEs, code comments for non-trivial logic). Ensure error handling and logging are consistent with existing standards.

Safety Protocols

  • Reference and respect existing code patterns and conventions before introducing variations.
  • Prioritize non-breaking changes; use techniques like feature flags for significant or risky changes where appropriate.
  • Ensure comprehensive test coverage for all modified or added code paths.
  • Maintain dependency integrity and proper error handling propagation.
  • Report confidence levels during implementation if unforeseen issues arise.
  • Request confirmation before making significant deviations from the agreed-upon design.

Execution Standard

  1. READ: Thoroughly read and understand the relevant code sections first.
  2. SEARCH: Look for existing patterns, utilities, or components that can be reused or should be matched.
  3. DESIGN: Plan changes to align with existing architecture and patterns, focusing on testability, maintainability, and simplicity. Avoid premature optimization.
  4. IMPLEMENT: Write clean, well-structured code following SOLID principles and established project conventions. Use linters/formatters.
  5. TEST: Implement/update unit, integration, and/or E2E tests as defined in the design phase to cover the changes thoroughly.
  6. REPORT: Summarize the implementation, linking to relevant commits/PRs, test results, and any necessary documentation updates.

Transition Rule

  • Do not begin implementation (Act Mode) without an explicit “Act” command after presenting the Architect Mode plan.

Vertical Slice Architecture Guidelines

Core Concept

  • Organize code primarily around features (vertical slices) rather than technical layers (horizontal slices) to encapsulate all logic for a given capability.

Key Principles

  • Feature Cohesion: Group all components related to a single feature (e.g., UI, application logic, data access, tests) within the same slice/directory structure.
  • Slice Independence: Maximize autonomy and minimize dependencies between slices. Slices should not have direct knowledge of the internal workings of other slices. Communication typically occurs via well-defined interfaces, messages, or shared abstractions.
  • Tailored Implementation: Allow each slice to adopt design patterns and structures best suited to its specific needs, without enforcing a uniform pattern across all slices unnecessarily.
  • Data Ownership: Ideally, each slice manages its own data persistence concerns, potentially interacting with a shared database but through slice-specific logic.

Benefits

  • Isolation: Changes to one feature are largely confined to its slice, reducing regression risk.
  • Maintainability: Easier to understand and modify feature-specific code.
  • Testability: Slices can often be developed and tested with greater independence.
  • Simplicity: Reduces the need for complex cross-layer abstractions and boilerplate code.
  • Flexibility: Facilitates independent evolution and technology choices per slice (within reason).
  • Business Alignment: Code structure directly mirrors business capabilities or user-facing features.
  • Agile Alignment: Supports incremental delivery of end-to-end functionality.
  • Scalability: Potential for different slices to be scaled independently based on demand.

Shared Components (SharedKernel / Common)

  • Domain Models: Core business entities and value objects potentially shared across slices. Keep these focused on domain logic, free from infrastructure concerns.
  • Cross-Cutting Concerns: Infrastructure code (logging, auth clients, message bus interfaces, base types) used by multiple slices.
  • Utilities: Truly generic functions or components. Establish clear criteria for promoting code to shared status (e.g., stable, used in 3+ slices, purely functional). Extract only when duplication becomes genuinely problematic, favoring duplication over premature/incorrect abstraction initially.

Evolution Path

  1. Initial: Simple transaction scripts or basic handlers within each slice. Focus on clear separation.
  2. Intermediate: Refactor slices using appropriate domain patterns (e.g., services, repositories, simple domain models) as complexity warrants. Introduce CQRS within slices if beneficial.
  3. Advanced: Develop richer domain models within slices where high complexity and business rule density exist. Apply patterns like Clean Architecture within the boundaries of a slice if justified.

Common Patterns within Slices

  • CQRS: Separating command (write) and query (read) paths is highly compatible with VSA. Handlers/services reside within their feature slice.
  • Mediator Pattern: Often used to decouple components within a slice (e.g., mapping requests to handlers).
  • Feature Folders/Modules: The directory structure itself reflects the slices.
  • Clean/Hexagonal Architecture Principles: Can be applied inside a slice to separate application/domain logic from infrastructure concerns for that slice.