mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-22 02:56:52 +03:00
Add mandatory preparation to design-transformative commands
Commands now require context gathering before proceeding: - bolder: target audience, use-cases, brand personality - quieter: purpose, audience, what's working - colorize: brand colors, audience, domain appropriateness - animate: personality, performance budget, audience - delight: brand personality, emotional context, appropriateness - simplify: what's essential vs nice-to-have Each command now: 1. Gathers context from thread/codebase first 2. MUST ask user if inference confidence is medium or lower 3. MUST use frontend-design skill before proceeding 4. Has visual separator (---) as hard gate before design work This prevents AI slop by ensuring commands have proper context before making design decisions. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.5
parent
825d936f20
commit
020ac82748
@@ -7,10 +7,27 @@ args:
|
||||
required: false
|
||||
---
|
||||
|
||||
**First**: Use the frontend-design skill for design principles and anti-patterns.
|
||||
|
||||
Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
|
||||
|
||||
## MANDATORY PREPARATION
|
||||
|
||||
### Context Gathering (Do This First)
|
||||
|
||||
You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
|
||||
|
||||
Attempt to gather these from the current thread or codebase.
|
||||
|
||||
1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and {{ask_instruction}} whether you got it right.
|
||||
2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST {{ask_instruction}} clarifying questions first to complete your context.
|
||||
|
||||
Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
|
||||
|
||||
### Use frontend-design skill
|
||||
|
||||
Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
|
||||
|
||||
---
|
||||
|
||||
## Assess Current State
|
||||
|
||||
Analyze what makes the design feel complex or cluttered:
|
||||
@@ -29,6 +46,8 @@ Analyze what makes the design feel complex or cluttered:
|
||||
- What can be removed, hidden, or combined?
|
||||
- What's the 20% that delivers 80% of value?
|
||||
|
||||
If any of these are unclear from the codebase, {{ask_instruction}}
|
||||
|
||||
**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
|
||||
|
||||
## Plan Simplification
|
||||
@@ -115,4 +134,3 @@ If you removed features or options:
|
||||
- Note any user feedback to monitor
|
||||
|
||||
Remember: You have great taste and judgment. Simplification is an act of confidence - knowing what to keep and courage to remove the rest. As Antoine de Saint-Exupéry said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."
|
||||
|
||||
|
||||
Reference in New Issue
Block a user