Share your favorite prompt rules & guidelines!

[Juice10]

Have any good Clean Architecture, DDD, SOLID, DRY, KISS or any other well defined guidelines. Share them here!

[Juice10]

I'm currently using the following mode specific instructions for the Code mode.

Its a modified variation on this prompt from continue.dev which adds DRY:

Use the following principles:

# SOLID and DRY Design Principles - Coding Assistant Guidelines

When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID and DRY principles:

## 1. Single Responsibility Principle (SRP)

- Each class must have only one reason to change.
- Limit class scope to a single functional area or abstraction level.
- When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) from business logic.
- Create dedicated classes for distinct operations like data access, business rules, and UI.
- Method names should clearly indicate their singular purpose.
- If a method description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance when combining behaviors.

## 2. Open/Closed Principle (OCP)

- Design classes to be extended without modification.
- Use abstract classes and interfaces to define stable contracts.
- Implement extension points for anticipated variations.
- Favor strategy patterns over conditional logic.
- Use configuration and dependency injection to support behavior changes.
- Avoid switch/if-else chains based on type checking.
- Provide hooks for customization in frameworks and libraries.
- Design with polymorphism as the primary mechanism for extending functionality.

## 3. Liskov Substitution Principle (LSP)

- Ensure derived classes are fully substitutable for their base classes.
- Maintain all invariants of the base class in derived classes.
- Never throw exceptions from methods that don't specify them in base classes.
- Don't strengthen preconditions in subclasses.
- Don't weaken postconditions in subclasses.
- Never override methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition over inheritance when complete substitutability can't be achieved.

## 4. Interface Segregation Principle (ISP)

- Create focused, minimal interfaces with cohesive methods.
- Split large interfaces into smaller, more specific ones.
- Design interfaces around client needs, not implementation convenience.
- Avoid "fat" interfaces that force clients to depend on methods they don't use.
- Use role interfaces that represent behaviors rather than object types.
- Implement multiple small interfaces rather than a single general-purpose one.
- Consider interface composition to build up complex behaviors.
- Remove any methods from interfaces that are only used by a subset of implementing classes.

## 5. Dependency Inversion Principle (DIP)

- High-level modules should depend on abstractions, not details.
- Make all dependencies explicit, ideally through constructor parameters.
- Use dependency injection to provide implementations.
- Program to interfaces, not concrete classes.
- Place abstractions in a separate package/namespace from implementations.
- Avoid direct instantiation of service classes with 'new' in business logic.
- Create abstraction boundaries at architectural layer transitions.
- Define interfaces owned by the client, not the implementation.

## 6. Don't Repeat Yourself (DRY)

- Eliminate duplication in code, data, and logic.
- Extract repeated code into reusable methods, classes, or modules.
- Create shared utility functions for common operations.
- Use inheritance and composition to share behavior without duplication.
- Establish a single source of truth for business rules and constants.
- Leverage code generation tools for repetitive boilerplate when appropriate.
- Apply template methods and patterns to standardize common processes.
- Centralize configuration values rather than scattering them throughout code.
- Use shared data models across application layers to avoid translation duplication.
- Consider parameterization to handle slight variations instead of duplicating code.
- Maintain knowledge in a single, unambiguous, authoritative representation.
- Recognize that excessive abstraction to achieve DRY can sometimes harm readability.

## Implementation Guidelines

- When starting a new class, explicitly identify its single responsibility.
- Document extension points and expected subclassing behavior.
- Write interface contracts with clear expectations and invariants.
- Question any class that depends on many concrete implementations.
- Use factories, dependency injection, or service locators to manage dependencies.
- Review inheritance hierarchies to ensure LSP compliance.
- Regularly refactor toward SOLID, especially when extending functionality.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.
- Review code for duplication during code reviews and refactoring sessions.
- Establish shared libraries or modules for cross-cutting functionality.
- Create consistent patterns and templates for common operations.

## Warning Signs

- God classes that do "everything"
- Methods with boolean parameters that radically change behavior
- Deep inheritance hierarchies
- Classes that need to know about implementation details of their dependencies
- Circular dependencies between modules
- High coupling between unrelated components
- Classes that grow rapidly in size with new features
- Methods with many parameters
- Copy-pasted code blocks with minor variations
- Similar algorithms implemented in multiple places
- Identical validation logic repeated across different layers
- Duplicated string literals, magic numbers, or business rules
- Multiple data structures representing the same information
- Related constants defined in multiple locations
- Repeated conditional expressions that make the same decisions

[joaompinto]

I do not have data to support my view, but from experimenting system-prompt-to-user-prompt-to-code mostly with Claude Sonnet 3.5 and more recently GPT4.1 (my own agent). Adding such a long context for "writing code" is inefficient and ineffective, on my lay man understanding, it will drive too much attention to all those constrains and correlated patterns, at cost of attention to match the functional requirement "it should do this".

What I am experimenting now, and I believe it will provider better results, is to apply such rules post code generation, in a nutshell I am splitting generation/validation, even if that comes with the cost of a longer loop.

I am following this approach supported by:
https://arxiv.org/abs/2502.18600