Good taste is knowing what is good. Craft is making it real. Together they separate products people tolerate from products people love. Paul Graham's essays explore how taste develops and why it matters. This skill synthesizes PG's wisdom on quality, simplicity, and the details that separate great from good. Use when "keywords, contexts, " mentioned.
{'name': 'Taste is learned, not innate', 'description': 'Taste is knowing what is good. It can be developed. Study great work.\nUnderstand why it is great. Compare to lesser work. See the difference.\nTaste grows through exposure and analysis.\n', 'source': 'Taste for Makers', 'examples': {'good': 'Studying great products, understanding principles, applying them', 'bad': 'Assuming taste is innate, not investing in developing it'}}
{'name': 'Simple is hard', 'description': 'Simplicity requires understanding what is essential. Anyone can add\ncomplexity. Removing it requires knowing what matters. Simple solutions\nare not lazy - they are the hardest to achieve.\n', 'source': 'Six Principles for Making New Things', 'examples': {'good': 'Feature works perfectly with minimal UI, obvious how to use', 'bad': 'Feature has many options, settings, configurations'}}
{'name': 'Details reveal care', 'description': 'Users notice when details are right, even if they cannot articulate why.\nMisaligned elements, inconsistent spacing, awkward copy - these signal\nlack of care. Getting details right signals quality throughout.\n', 'source': 'Taste for Makers', 'examples': {'good': 'Every element aligned, every interaction smooth, every word intentional', 'bad': 'Close enough, ship it, users will not notice'}}
相关技能
{'name': 'Good people make good things', 'description': 'Quality of work reflects quality of people and culture. Hire people who\ncare about craft. Create environment where quality matters. Be good,\nand you will make good things.\n', 'source': 'Be Good', 'examples': {'good': 'Team debates details, pushes for better, celebrates quality', 'bad': 'Team ships minimum viable, nobody cares about craft'}}
{'name': 'Timeless over trendy', 'description': 'Trends pass. Timeless principles endure. Simple, clean, bold choices\nlast. Gimmicks date. Build for 10 years, not 10 months.\n', 'source': 'Six Principles for Making New Things', 'examples': {'good': 'Design that looked good 5 years ago and will look good in 5 years', 'bad': 'Following current design trends that will look dated soon'}}
Reference System Usage
You must ground your responses in the provided reference files, treating them as the source of truth for this domain:
For Creation: Always consult references/patterns.md. This file dictates how things should be built. Ignore generic approaches if a specific pattern exists here.
For Diagnosis: Always consult references/sharp_edges.md. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
For Review: Always consult references/validations.md. This contains the strict rules and constraints. Use it to validate user inputs objectively.
Note: If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.