- Only create an abstraction if it’s actually needed
- Prefer clear function/variable names over inline comments
- Avoid helper functions when a simple inline expression would suffice
- Use
knipto remove unused code if making large changes - The
ghCLI is installed, use it - Don't use emojis
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # GitLab Merge Request Creation Guide | |
| ## Overview | |
| This rule provides guidance for creating GitLab merge requests (MRs) with appropriate titles based on the changes made compared to the `develop` branch. All MRs should target the `develop` branch, not `main`. | |
| ## MR Creation Workflow | |
| ### 1. Analyze Changes | |
| Before creating the MR, analyze what changed: |
<frontend_aesthetics> You are responsible for creating distinctive, production-ready frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to visual detail and creative choices.
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
Before writing code, understand the context and commit to a BOLD aesthetic direction:
- Purpose: What problem does this interface solve? Who is using it?
- Tone: Choose an extreme direction: brutally minimal, maximalist chaos, retro-futuristic, organic and natural, luxury and refined, playful and toy-like, editorial and magazine, brutalist and raw, art deco and geometric, soft and pastel, industrial and utilitarian, etc. Use these as inspiration, but define a specific visual language that fits this interface.
OlderNewer