codingbuddy-rules 1.0.1 → 1.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -115,3 +115,53 @@ Claude can directly read and reference:
115
115
  1. Update `.ai-rules/rules/*.md` for universal changes
116
116
  2. Update `.claude/rules/custom-instructions.md` for Claude-specific features
117
117
  3. Sync Claude Project instructions when rules change significantly
118
+
119
+ ## Skills
120
+
121
+ CodingBuddy skills are accessible via MCP tools:
122
+
123
+ ### List Available Skills
124
+
125
+ Use `list_skills` MCP tool to see all available skills.
126
+
127
+ ### Use a Skill
128
+
129
+ Use `get_skill` MCP tool with skill name:
130
+
131
+ - `get_skill("brainstorming")` - Explore requirements before implementation
132
+ - `get_skill("test-driven-development")` - TDD workflow
133
+ - `get_skill("systematic-debugging")` - Debug methodically
134
+ - `get_skill("writing-plans")` - Create implementation plans
135
+ - `get_skill("executing-plans")` - Execute plans with checkpoints
136
+ - `get_skill("subagent-driven-development")` - In-session plan execution
137
+ - `get_skill("dispatching-parallel-agents")` - Handle parallel tasks
138
+ - `get_skill("frontend-design")` - Build production-grade UI
139
+
140
+ ### When to Use Skills
141
+
142
+ - **brainstorming**: Before any creative work or new features
143
+ - **test-driven-development**: Before implementing features or bugfixes
144
+ - **systematic-debugging**: When encountering bugs or test failures
145
+ - **writing-plans**: For multi-step tasks with specs
146
+ - **executing-plans**: Following written implementation plans
147
+ - **frontend-design**: Building web components or pages
148
+
149
+ ### Auto-Recommend Skills
150
+
151
+ Use `recommend_skills` MCP tool to get skill recommendations based on user prompt:
152
+
153
+ ```typescript
154
+ // AI can call this to get skill recommendations
155
+ recommend_skills({ prompt: "There is a bug in the login" })
156
+ // => recommends: systematic-debugging
157
+
158
+ recommend_skills({ prompt: "로그인에 버그가 있어" })
159
+ // => recommends: systematic-debugging (Korean support)
160
+
161
+ recommend_skills({ prompt: "Build a dashboard component" })
162
+ // => recommends: frontend-design
163
+ ```
164
+
165
+ **Supported Languages:** English, Korean, Japanese, Chinese, Spanish
166
+
167
+ The tool returns skill recommendations with confidence levels (high/medium) and matched patterns for transparency.
@@ -122,3 +122,28 @@ When using Copilot Workspace:
122
122
  1. Update `.ai-rules/rules/*.md` for universal rule changes
123
123
  2. Keep `.github/copilot-instructions.md` concise (Copilot's context limit)
124
124
  3. Link to detailed rules in `.ai-rules/` rather than duplicating
125
+
126
+ ## Skills
127
+
128
+ ### Using Skills in Codex
129
+
130
+ Skills are located in `.ai-rules/skills/`. To use a skill:
131
+
132
+ 1. Read the skill file:
133
+
134
+ ```bash
135
+ cat .ai-rules/skills/<skill-name>/SKILL.md
136
+ ```
137
+
138
+ 2. Follow the skill's checklist and process.
139
+
140
+ ### Available Skills
141
+
142
+ - `brainstorming` - Explore requirements before implementation
143
+ - `test-driven-development` - TDD workflow
144
+ - `systematic-debugging` - Debug methodically
145
+ - `writing-plans` - Create implementation plans
146
+ - `executing-plans` - Execute plans with checkpoints
147
+ - `subagent-driven-development` - In-session plan execution
148
+ - `dispatching-parallel-agents` - Handle parallel tasks
149
+ - `frontend-design` - Build production-grade UI
@@ -126,3 +126,26 @@ When updating rules:
126
126
  1. Update `.ai-rules/rules/*.md` for changes affecting all AI tools
127
127
  2. Update `.cursor/rules/*.mdc` only for Cursor-specific changes
128
128
  3. Keep both in sync for best experience
129
+
130
+ ## Skills
131
+
132
+ ### Using Skills in Cursor
133
+
134
+ Reference skills in your prompts using file inclusion:
135
+
136
+ ```
137
+ @.ai-rules/skills/test-driven-development/SKILL.md
138
+ ```
139
+
140
+ Or manually include skill content in `.cursorrules`.
141
+
142
+ ### Available Skills
143
+
144
+ - `.ai-rules/skills/brainstorming/SKILL.md`
145
+ - `.ai-rules/skills/test-driven-development/SKILL.md`
146
+ - `.ai-rules/skills/systematic-debugging/SKILL.md`
147
+ - `.ai-rules/skills/writing-plans/SKILL.md`
148
+ - `.ai-rules/skills/executing-plans/SKILL.md`
149
+ - `.ai-rules/skills/subagent-driven-development/SKILL.md`
150
+ - `.ai-rules/skills/dispatching-parallel-agents/SKILL.md`
151
+ - `.ai-rules/skills/frontend-design/SKILL.md`
@@ -0,0 +1,112 @@
1
+ # CodingBuddy Skills
2
+
3
+ Reusable workflows for consistent development practices.
4
+
5
+ ## Available Skills
6
+
7
+ | Skill | Description | When to Use |
8
+ |-------|-------------|-------------|
9
+ | brainstorming | Explores user intent, requirements and design before implementation | Before any creative work |
10
+ | dispatching-parallel-agents | Handle 2+ independent tasks without shared state | Parallel task execution |
11
+ | executing-plans | Execute implementation plans with review checkpoints | Following written plans |
12
+ | frontend-design | Create distinctive, production-grade frontend interfaces | Building web components/pages |
13
+ | subagent-driven-development | Execute plans with independent tasks in current session | In-session plan execution |
14
+ | systematic-debugging | Systematic approach before proposing fixes | Encountering bugs or failures |
15
+ | test-driven-development | Write tests first, then minimal code to pass | Before implementing features |
16
+ | writing-plans | Create implementation plans before coding | Multi-step tasks with specs |
17
+
18
+ ## Skill Format
19
+
20
+ Skills use YAML frontmatter + Markdown:
21
+
22
+ ```markdown
23
+ ---
24
+ name: skill-name
25
+ description: "Brief description (max 500 chars)"
26
+ ---
27
+
28
+ # Skill Title
29
+
30
+ ## When to Use
31
+ ...
32
+
33
+ ## Process/Checklist
34
+ ...
35
+ ```
36
+
37
+ ### Frontmatter Requirements
38
+
39
+ - `name`: lowercase alphanumeric with hyphens only (`^[a-z0-9-]+$`)
40
+ - `description`: 1-500 characters
41
+
42
+ ## Usage by Platform
43
+
44
+ ### Claude Code (MCP)
45
+
46
+ ```
47
+ list_skills # List all available skills
48
+ get_skill("test-driven-development") # Get specific skill content
49
+ ```
50
+
51
+ ### Codex / GitHub Copilot
52
+
53
+ ```bash
54
+ cat .ai-rules/skills/<skill-name>/SKILL.md
55
+ ```
56
+
57
+ ### Cursor
58
+
59
+ ```
60
+ @.ai-rules/skills/test-driven-development/SKILL.md
61
+ ```
62
+
63
+ ## Creating Custom Skills
64
+
65
+ 1. Create directory: `skills/<name>/`
66
+ 2. Create `SKILL.md` with YAML frontmatter
67
+ 3. Follow the format specification above
68
+
69
+ ### Example
70
+
71
+ ```bash
72
+ mkdir -p .ai-rules/skills/my-skill
73
+ cat > .ai-rules/skills/my-skill/SKILL.md << 'EOF'
74
+ ---
75
+ name: my-skill
76
+ description: My custom skill for specific workflow
77
+ ---
78
+
79
+ # My Skill
80
+
81
+ ## When to Use
82
+ - Specific scenario 1
83
+ - Specific scenario 2
84
+
85
+ ## Checklist
86
+ - [ ] Step 1
87
+ - [ ] Step 2
88
+ EOF
89
+ ```
90
+
91
+ ## Directory Structure
92
+
93
+ ```
94
+ .ai-rules/skills/
95
+ ├── README.md # This file
96
+ ├── brainstorming/
97
+ │ └── SKILL.md
98
+ ├── dispatching-parallel-agents/
99
+ │ └── SKILL.md
100
+ ├── executing-plans/
101
+ │ └── SKILL.md
102
+ ├── frontend-design/
103
+ │ └── SKILL.md
104
+ ├── subagent-driven-development/
105
+ │ └── SKILL.md
106
+ ├── systematic-debugging/
107
+ │ └── SKILL.md
108
+ ├── test-driven-development/
109
+ │ └── SKILL.md
110
+ └── writing-plans/
111
+ └── SKILL.md
112
+ ```
@@ -0,0 +1,54 @@
1
+ ---
2
+ name: brainstorming
3
+ description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
4
+ ---
5
+
6
+ # Brainstorming Ideas Into Designs
7
+
8
+ ## Overview
9
+
10
+ Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
11
+
12
+ Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
13
+
14
+ ## The Process
15
+
16
+ **Understanding the idea:**
17
+ - Check out the current project state first (files, docs, recent commits)
18
+ - Ask questions one at a time to refine the idea
19
+ - Prefer multiple choice questions when possible, but open-ended is fine too
20
+ - Only one question per message - if a topic needs more exploration, break it into multiple questions
21
+ - Focus on understanding: purpose, constraints, success criteria
22
+
23
+ **Exploring approaches:**
24
+ - Propose 2-3 different approaches with trade-offs
25
+ - Present options conversationally with your recommendation and reasoning
26
+ - Lead with your recommended option and explain why
27
+
28
+ **Presenting the design:**
29
+ - Once you believe you understand what you're building, present the design
30
+ - Break it into sections of 200-300 words
31
+ - Ask after each section whether it looks right so far
32
+ - Cover: architecture, components, data flow, error handling, testing
33
+ - Be ready to go back and clarify if something doesn't make sense
34
+
35
+ ## After the Design
36
+
37
+ **Documentation:**
38
+ - Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
39
+ - Use elements-of-style:writing-clearly-and-concisely skill if available
40
+ - Commit the design document to git
41
+
42
+ **Implementation (if continuing):**
43
+ - Ask: "Ready to set up for implementation?"
44
+ - Use superpowers:using-git-worktrees to create isolated workspace
45
+ - Use superpowers:writing-plans to create detailed implementation plan
46
+
47
+ ## Key Principles
48
+
49
+ - **One question at a time** - Don't overwhelm with multiple questions
50
+ - **Multiple choice preferred** - Easier to answer than open-ended when possible
51
+ - **YAGNI ruthlessly** - Remove unnecessary features from all designs
52
+ - **Explore alternatives** - Always propose 2-3 approaches before settling
53
+ - **Incremental validation** - Present design in sections, validate each
54
+ - **Be flexible** - Go back and clarify when something doesn't make sense
@@ -0,0 +1,180 @@
1
+ ---
2
+ name: dispatching-parallel-agents
3
+ description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
4
+ ---
5
+
6
+ # Dispatching Parallel Agents
7
+
8
+ ## Overview
9
+
10
+ When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
11
+
12
+ **Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
13
+
14
+ ## When to Use
15
+
16
+ ```dot
17
+ digraph when_to_use {
18
+ "Multiple failures?" [shape=diamond];
19
+ "Are they independent?" [shape=diamond];
20
+ "Single agent investigates all" [shape=box];
21
+ "One agent per problem domain" [shape=box];
22
+ "Can they work in parallel?" [shape=diamond];
23
+ "Sequential agents" [shape=box];
24
+ "Parallel dispatch" [shape=box];
25
+
26
+ "Multiple failures?" -> "Are they independent?" [label="yes"];
27
+ "Are they independent?" -> "Single agent investigates all" [label="no - related"];
28
+ "Are they independent?" -> "Can they work in parallel?" [label="yes"];
29
+ "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
30
+ "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
31
+ }
32
+ ```
33
+
34
+ **Use when:**
35
+ - 3+ test files failing with different root causes
36
+ - Multiple subsystems broken independently
37
+ - Each problem can be understood without context from others
38
+ - No shared state between investigations
39
+
40
+ **Don't use when:**
41
+ - Failures are related (fix one might fix others)
42
+ - Need to understand full system state
43
+ - Agents would interfere with each other
44
+
45
+ ## The Pattern
46
+
47
+ ### 1. Identify Independent Domains
48
+
49
+ Group failures by what's broken:
50
+ - File A tests: Tool approval flow
51
+ - File B tests: Batch completion behavior
52
+ - File C tests: Abort functionality
53
+
54
+ Each domain is independent - fixing tool approval doesn't affect abort tests.
55
+
56
+ ### 2. Create Focused Agent Tasks
57
+
58
+ Each agent gets:
59
+ - **Specific scope:** One test file or subsystem
60
+ - **Clear goal:** Make these tests pass
61
+ - **Constraints:** Don't change other code
62
+ - **Expected output:** Summary of what you found and fixed
63
+
64
+ ### 3. Dispatch in Parallel
65
+
66
+ ```typescript
67
+ // In Claude Code / AI environment
68
+ Task("Fix agent-tool-abort.test.ts failures")
69
+ Task("Fix batch-completion-behavior.test.ts failures")
70
+ Task("Fix tool-approval-race-conditions.test.ts failures")
71
+ // All three run concurrently
72
+ ```
73
+
74
+ ### 4. Review and Integrate
75
+
76
+ When agents return:
77
+ - Read each summary
78
+ - Verify fixes don't conflict
79
+ - Run full test suite
80
+ - Integrate all changes
81
+
82
+ ## Agent Prompt Structure
83
+
84
+ Good agent prompts are:
85
+ 1. **Focused** - One clear problem domain
86
+ 2. **Self-contained** - All context needed to understand the problem
87
+ 3. **Specific about output** - What should the agent return?
88
+
89
+ ```markdown
90
+ Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
91
+
92
+ 1. "should abort tool with partial output capture" - expects 'interrupted at' in message
93
+ 2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
94
+ 3. "should properly track pendingToolCount" - expects 3 results but gets 0
95
+
96
+ These are timing/race condition issues. Your task:
97
+
98
+ 1. Read the test file and understand what each test verifies
99
+ 2. Identify root cause - timing issues or actual bugs?
100
+ 3. Fix by:
101
+ - Replacing arbitrary timeouts with event-based waiting
102
+ - Fixing bugs in abort implementation if found
103
+ - Adjusting test expectations if testing changed behavior
104
+
105
+ Do NOT just increase timeouts - find the real issue.
106
+
107
+ Return: Summary of what you found and what you fixed.
108
+ ```
109
+
110
+ ## Common Mistakes
111
+
112
+ **❌ Too broad:** "Fix all the tests" - agent gets lost
113
+ **✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
114
+
115
+ **❌ No context:** "Fix the race condition" - agent doesn't know where
116
+ **✅ Context:** Paste the error messages and test names
117
+
118
+ **❌ No constraints:** Agent might refactor everything
119
+ **✅ Constraints:** "Do NOT change production code" or "Fix tests only"
120
+
121
+ **❌ Vague output:** "Fix it" - you don't know what changed
122
+ **✅ Specific:** "Return summary of root cause and changes"
123
+
124
+ ## When NOT to Use
125
+
126
+ **Related failures:** Fixing one might fix others - investigate together first
127
+ **Need full context:** Understanding requires seeing entire system
128
+ **Exploratory debugging:** You don't know what's broken yet
129
+ **Shared state:** Agents would interfere (editing same files, using same resources)
130
+
131
+ ## Real Example from Session
132
+
133
+ **Scenario:** 6 test failures across 3 files after major refactoring
134
+
135
+ **Failures:**
136
+ - agent-tool-abort.test.ts: 3 failures (timing issues)
137
+ - batch-completion-behavior.test.ts: 2 failures (tools not executing)
138
+ - tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
139
+
140
+ **Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
141
+
142
+ **Dispatch:**
143
+ ```
144
+ Agent 1 → Fix agent-tool-abort.test.ts
145
+ Agent 2 → Fix batch-completion-behavior.test.ts
146
+ Agent 3 → Fix tool-approval-race-conditions.test.ts
147
+ ```
148
+
149
+ **Results:**
150
+ - Agent 1: Replaced timeouts with event-based waiting
151
+ - Agent 2: Fixed event structure bug (threadId in wrong place)
152
+ - Agent 3: Added wait for async tool execution to complete
153
+
154
+ **Integration:** All fixes independent, no conflicts, full suite green
155
+
156
+ **Time saved:** 3 problems solved in parallel vs sequentially
157
+
158
+ ## Key Benefits
159
+
160
+ 1. **Parallelization** - Multiple investigations happen simultaneously
161
+ 2. **Focus** - Each agent has narrow scope, less context to track
162
+ 3. **Independence** - Agents don't interfere with each other
163
+ 4. **Speed** - 3 problems solved in time of 1
164
+
165
+ ## Verification
166
+
167
+ After agents return:
168
+ 1. **Review each summary** - Understand what changed
169
+ 2. **Check for conflicts** - Did agents edit same code?
170
+ 3. **Run full suite** - Verify all fixes work together
171
+ 4. **Spot check** - Agents can make systematic errors
172
+
173
+ ## Real-World Impact
174
+
175
+ From debugging session (2025-10-03):
176
+ - 6 failures across 3 files
177
+ - 3 agents dispatched in parallel
178
+ - All investigations completed concurrently
179
+ - All fixes integrated successfully
180
+ - Zero conflicts between agent changes
@@ -0,0 +1,76 @@
1
+ ---
2
+ name: executing-plans
3
+ description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
4
+ ---
5
+
6
+ # Executing Plans
7
+
8
+ ## Overview
9
+
10
+ Load plan, review critically, execute tasks in batches, report for review between batches.
11
+
12
+ **Core principle:** Batch execution with checkpoints for architect review.
13
+
14
+ **Announce at start:** "I'm using the executing-plans skill to implement this plan."
15
+
16
+ ## The Process
17
+
18
+ ### Step 1: Load and Review Plan
19
+ 1. Read plan file
20
+ 2. Review critically - identify any questions or concerns about the plan
21
+ 3. If concerns: Raise them with your human partner before starting
22
+ 4. If no concerns: Create TodoWrite and proceed
23
+
24
+ ### Step 2: Execute Batch
25
+ **Default: First 3 tasks**
26
+
27
+ For each task:
28
+ 1. Mark as in_progress
29
+ 2. Follow each step exactly (plan has bite-sized steps)
30
+ 3. Run verifications as specified
31
+ 4. Mark as completed
32
+
33
+ ### Step 3: Report
34
+ When batch complete:
35
+ - Show what was implemented
36
+ - Show verification output
37
+ - Say: "Ready for feedback."
38
+
39
+ ### Step 4: Continue
40
+ Based on feedback:
41
+ - Apply changes if needed
42
+ - Execute next batch
43
+ - Repeat until complete
44
+
45
+ ### Step 5: Complete Development
46
+
47
+ After all tasks complete and verified:
48
+ - Announce: "I'm using the finishing-a-development-branch skill to complete this work."
49
+ - **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
50
+ - Follow that skill to verify tests, present options, execute choice
51
+
52
+ ## When to Stop and Ask for Help
53
+
54
+ **STOP executing immediately when:**
55
+ - Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
56
+ - Plan has critical gaps preventing starting
57
+ - You don't understand an instruction
58
+ - Verification fails repeatedly
59
+
60
+ **Ask for clarification rather than guessing.**
61
+
62
+ ## When to Revisit Earlier Steps
63
+
64
+ **Return to Review (Step 1) when:**
65
+ - Partner updates the plan based on your feedback
66
+ - Fundamental approach needs rethinking
67
+
68
+ **Don't force through blockers** - stop and ask.
69
+
70
+ ## Remember
71
+ - Review plan critically first
72
+ - Follow plan steps exactly
73
+ - Don't skip verifications
74
+ - Reference skills when plan says to
75
+ - Between batches: just report and wait
76
+ - Stop when blocked, don't guess
@@ -0,0 +1,42 @@
1
+ ---
2
+ name: frontend-design
3
+ description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
4
+ license: Complete terms in LICENSE.txt
5
+ ---
6
+
7
+ This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
8
+
9
+ The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
10
+
11
+ ## Design Thinking
12
+
13
+ Before coding, understand the context and commit to a BOLD aesthetic direction:
14
+ - **Purpose**: What problem does this interface solve? Who uses it?
15
+ - **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
16
+ - **Constraints**: Technical requirements (framework, performance, accessibility).
17
+ - **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
18
+
19
+ **CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
20
+
21
+ Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
22
+ - Production-grade and functional
23
+ - Visually striking and memorable
24
+ - Cohesive with a clear aesthetic point-of-view
25
+ - Meticulously refined in every detail
26
+
27
+ ## Frontend Aesthetics Guidelines
28
+
29
+ Focus on:
30
+ - **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
31
+ - **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
32
+ - **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
33
+ - **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
34
+ - **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
35
+
36
+ NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
37
+
38
+ Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
39
+
40
+ **IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
41
+
42
+ Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.