Is your feature request related to a problem? Please describe.
I'm frustrated when subjective prompt engineering rules are hardcoded into the plugin's system instructions, making it impossible for users to control or disable them without forking the entire project.
Recently, rules were changed that force the AI to:
Minimize output tokens as much as possible
ALWAYS group multiple changes together
NOT be methodical or cautious
Avoid making one change at a time on the same file
These rules fundamentally altered how the plugin works, causing it to make massive batch changes without incremental verification. This isn't a bug in the algorithmic sense—the code works as designed—but it's a subjective workflow choice that significantly impacts how developers use the tool.
Describe the solution you'd like
Move all subjective prompt engineering rules from hardcoded system instructions to user-accessible preference pages/settings. Users should be able to:
View what rules are currently active
Enable/disable individual rules based on their workflow preferences
Customize parameters (e.g., how aggressive batching should be)
This would allow the plugin to serve different working styles without requiring forks for every workflow preference.
Describe alternatives you've considered
Fork the plugin: Too heavy-handed for simple workflow preferences
Document the rules: Doesn't solve the problem—users still can't change them
Ignore the issue: Results in damaged output and frustrated users who don't understand why behavior changed
Additional context
Here's a concrete example of the damage these hardcoded rules cause:
[User's chat excerpt demonstrating the issue]
System identified problematic rules in <tool_calling>:
- IMPORTANT: You should minimize output tokens as much as possible
- ALWAYS group as many changes as you can... DO NOT be overly
cautious and methodical by making one change at a time
Effect: System pushed to make massive changes without step-by-step verification
The core issue: These aren't technical bugs—they're subjective opinions about "best practices" that don't apply universally. Different developers have different needs:
Some need aggressive batching for speed
Others need methodical, verified changes for safety-critical code
Some want minimal output; others need detailed explanations
By hardcoding these preferences, you're forcing one workflow philosophy on all users. This creates a situation where users must either accept suboptimal behavior or maintain their own fork—neither is sustainable.
Question: Would a PR implementing this feature be accepted, or is the current hardcoded approach a fundamental design decision that would require a fork to change?
Is your feature request related to a problem? Please describe.
I'm frustrated when subjective prompt engineering rules are hardcoded into the plugin's system instructions, making it impossible for users to control or disable them without forking the entire project.
Recently, rules were changed that force the AI to:
Minimize output tokens as much as possible
ALWAYS group multiple changes together
NOT be methodical or cautious
Avoid making one change at a time on the same file
These rules fundamentally altered how the plugin works, causing it to make massive batch changes without incremental verification. This isn't a bug in the algorithmic sense—the code works as designed—but it's a subjective workflow choice that significantly impacts how developers use the tool.
Describe the solution you'd like
Move all subjective prompt engineering rules from hardcoded system instructions to user-accessible preference pages/settings. Users should be able to:
View what rules are currently active
Enable/disable individual rules based on their workflow preferences
Customize parameters (e.g., how aggressive batching should be)
This would allow the plugin to serve different working styles without requiring forks for every workflow preference.
Describe alternatives you've considered
Fork the plugin: Too heavy-handed for simple workflow preferences
Document the rules: Doesn't solve the problem—users still can't change them
Ignore the issue: Results in damaged output and frustrated users who don't understand why behavior changed
Additional context
Here's a concrete example of the damage these hardcoded rules cause:
[User's chat excerpt demonstrating the issue]
System identified problematic rules in <tool_calling>:
cautious and methodical by making one change at a time
Effect: System pushed to make massive changes without step-by-step verification
The core issue: These aren't technical bugs—they're subjective opinions about "best practices" that don't apply universally. Different developers have different needs:
Some need aggressive batching for speed
Others need methodical, verified changes for safety-critical code
Some want minimal output; others need detailed explanations
By hardcoding these preferences, you're forcing one workflow philosophy on all users. This creates a situation where users must either accept suboptimal behavior or maintain their own fork—neither is sustainable.
Question: Would a PR implementing this feature be accepted, or is the current hardcoded approach a fundamental design decision that would require a fork to change?