plcode-windows-x64-baseline 2.1.0

package/.plcode/skill/experimental/polish/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: polish
+description: Final quality pass before shipping. Fixes alignment, spacing, consistency, and detail issues that separate good from great.
+category: design
+args:
+  - name: target
+    description: The feature or area to polish (optional)
+    required: false
+user-invokable: true
+---
+
+**First**: Use the frontend-design skill for design principles and anti-patterns.
+
+Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
+
+## Pre-Polish Assessment
+
+Understand the current state and goals:
+
+1. **Review completeness**:
+   - Is it functionally complete?
+   - Are there known issues to preserve (mark with TODOs)?
+   - What's the quality bar? (MVP vs flagship feature?)
+   - When does it ship? (How much time for polish?)
+
+2. **Identify polish areas**:
+   - Visual inconsistencies
+   - Spacing and alignment issues
+   - Interaction state gaps
+   - Copy inconsistencies
+   - Edge cases and error states
+   - Loading and transition smoothness
+
+**CRITICAL**: Polish is the last step, not the first. Don't polish work that's not functionally complete.
+
+## Polish Systematically
+
+Work through these dimensions methodically:
+
+### Visual Alignment & Spacing
+
+- **Pixel-perfect alignment**: Everything lines up to grid
+- **Consistent spacing**: All gaps use spacing scale (no random 13px gaps)
+- **Optical alignment**: Adjust for visual weight (icons may need offset for optical centering)
+- **Responsive consistency**: Spacing and alignment work at all breakpoints
+- **Grid adherence**: Elements snap to baseline grid
+
+**Check**:
+
+- Enable grid overlay and verify alignment
+- Check spacing with browser inspector
+- Test at multiple viewport sizes
+- Look for elements that "feel" off
+
+### Typography Refinement
+
+- **Hierarchy consistency**: Same elements use same sizes/weights throughout
+- **Line length**: 45-75 characters for body text
+- **Line height**: Appropriate for font size and context
+- **Widows & orphans**: No single words on last line
+- **Hyphenation**: Appropriate for language and column width
+- **Kerning**: Adjust letter spacing where needed (especially headlines)
+- **Font loading**: No FOUT/FOIT flashes
+
+### Color & Contrast
+
+- **Contrast ratios**: All text meets WCAG standards
+- **Consistent token usage**: No hard-coded colors, all use design tokens
+- **Theme consistency**: Works in all theme variants
+- **Color meaning**: Same colors mean same things throughout
+- **Accessible focus**: Focus indicators visible with sufficient contrast
+- **Tinted neutrals**: No pure gray or pure black—add subtle color tint (0.01 chroma)
+- **Gray on color**: Never put gray text on colored backgrounds—use a shade of that color or transparency
+
+### Interaction States
+
+Every interactive element needs all states:
+
+- **Default**: Resting state
+- **Hover**: Subtle feedback (color, scale, shadow)
+- **Focus**: Keyboard focus indicator (never remove without replacement)
+- **Active**: Click/tap feedback
+- **Disabled**: Clearly non-interactive
+- **Loading**: Async action feedback
+- **Error**: Validation or error state
+- **Success**: Successful completion
+
+**Missing states create confusion and broken experiences**.
+
+### Micro-interactions & Transitions
+
+- **Smooth transitions**: All state changes animated appropriately (150-300ms)
+- **Consistent easing**: Use ease-out-quart/quint/expo for natural deceleration. Never bounce or elastic—they feel dated.
+- **No jank**: 60fps animations, only animate transform and opacity
+- **Appropriate motion**: Motion serves purpose, not decoration
+- **Reduced motion**: Respects `prefers-reduced-motion`
+
+### Content & Copy
+
+- **Consistent terminology**: Same things called same names throughout
+- **Consistent capitalization**: Title Case vs Sentence case applied consistently
+- **Grammar & spelling**: No typos
+- **Appropriate length**: Not too wordy, not too terse
+- **Punctuation consistency**: Periods on sentences, not on labels (unless all labels have them)
+
+### Icons & Images
+
+- **Consistent style**: All icons from same family or matching style
+- **Appropriate sizing**: Icons sized consistently for context
+- **Proper alignment**: Icons align with adjacent text optically
+- **Alt text**: All images have descriptive alt text
+- **Loading states**: Images don't cause layout shift, proper aspect ratios
+- **Retina support**: 2x assets for high-DPI screens
+
+### Forms & Inputs
+
+- **Label consistency**: All inputs properly labeled
+- **Required indicators**: Clear and consistent
+- **Error messages**: Helpful and consistent
+- **Tab order**: Logical keyboard navigation
+- **Auto-focus**: Appropriate (don't overuse)
+- **Validation timing**: Consistent (on blur vs on submit)
+
+### Edge Cases & Error States
+
+- **Loading states**: All async actions have loading feedback
+- **Empty states**: Helpful empty states, not just blank space
+- **Error states**: Clear error messages with recovery paths
+- **Success states**: Confirmation of successful actions
+- **Long content**: Handles very long names, descriptions, etc.
+- **No content**: Handles missing data gracefully
+- **Offline**: Appropriate offline handling (if applicable)
+
+### Responsiveness
+
+- **All breakpoints**: Test mobile, tablet, desktop
+- **Touch targets**: 44x44px minimum on touch devices
+- **Readable text**: No text smaller than 14px on mobile
+- **No horizontal scroll**: Content fits viewport
+- **Appropriate reflow**: Content adapts logically
+
+### Performance
+
+- **Fast initial load**: Optimize critical path
+- **No layout shift**: Elements don't jump after load (CLS)
+- **Smooth interactions**: No lag or jank
+- **Optimized images**: Appropriate formats and sizes
+- **Lazy loading**: Off-screen content loads lazily
+
+### Code Quality
+
+- **Remove console logs**: No debug logging in production
+- **Remove commented code**: Clean up dead code
+- **Remove unused imports**: Clean up unused dependencies
+- **Consistent naming**: Variables and functions follow conventions
+- **Type safety**: No TypeScript `any` or ignored errors
+- **Accessibility**: Proper ARIA labels and semantic HTML
+
+## Polish Checklist
+
+Go through systematically:
+
+- [ ] Visual alignment perfect at all breakpoints
+- [ ] Spacing uses design tokens consistently
+- [ ] Typography hierarchy consistent
+- [ ] All interactive states implemented
+- [ ] All transitions smooth (60fps)
+- [ ] Copy is consistent and polished
+- [ ] Icons are consistent and properly sized
+- [ ] All forms properly labeled and validated
+- [ ] Error states are helpful
+- [ ] Loading states are clear
+- [ ] Empty states are welcoming
+- [ ] Touch targets are 44x44px minimum
+- [ ] Contrast ratios meet WCAG AA
+- [ ] Keyboard navigation works
+- [ ] Focus indicators visible
+- [ ] No console errors or warnings
+- [ ] No layout shift on load
+- [ ] Works in all supported browsers
+- [ ] Respects reduced motion preference
+- [ ] Code is clean (no TODOs, console.logs, commented code)
+
+**IMPORTANT**: Polish is about details. Zoom in. Squint at it. Use it yourself. The little things add up.
+
+**NEVER**:
+
+- Polish before it's functionally complete
+- Spend hours on polish if it ships in 30 minutes (triage)
+- Introduce bugs while polishing (test thoroughly)
+- Ignore systematic issues (if spacing is off everywhere, fix the system)
+- Perfect one thing while leaving others rough (consistent quality level)
+
+## Final Verification
+
+Before marking as done:
+
+- **Use it yourself**: Actually interact with the feature
+- **Test on real devices**: Not just browser DevTools
+- **Ask someone else to review**: Fresh eyes catch things
+- **Compare to design**: Match intended design
+- **Check all states**: Don't just test happy path
+
+Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.

package/.plcode/skill/experimental/product-management/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: product-management
+description: Assist with core product management activities including writing PRDs, analyzing features, synthesizing user research, planning roadmaps, and communicating product decisions. Use when you need help with PM documentation, analysis, or planning workflows that integrate with your codebase.
+category: meta
+---
+
+# Skill: Product management AI
+
+## Purpose
+
+Assist with core product management activities including writing product requirements documents (PRDs), analyzing feature requests, synthesizing user research, planning roadmaps, and communicating product decisions to stakeholders and engineering teams.
+
+## When to use this skill
+
+- You need to **write or update PRDs** with clear requirements, success metrics, and technical considerations.
+- You're **evaluating feature requests** and need structured analysis of impact, effort, and priority.
+- You need to **synthesize user research** findings into actionable insights.
+- You're **planning roadmaps** and need to organize, prioritize, and communicate plans.
+- You need to **communicate product decisions** clearly to engineering, design, and business stakeholders.
+- You're doing **competitive analysis** or market research synthesis.
+- You need to **track and analyze product metrics** to inform decisions.
+
+## Key capabilities
+
+Unlike point-solution PM tools:
+
+- **Integrated with codebase**: Can reference actual code, APIs, and technical constraints.
+- **Context-aware**: Understands your specific product, architecture, and technical debt.
+- **Flexible templates**: Adapt documentation to your organization's needs.
+- **Version controlled**: All artifacts live in git alongside code.
+- **Collaborative**: Works within existing dev workflows (PRs, issues, docs).
+
+## Inputs
+
+- **Product context**: Current state, key stakeholders, strategic goals.
+- **Feature requests**: User feedback, business needs, or strategic initiatives.
+- **Technical constraints**: Known limitations, dependencies, or technical debt.
+- **User research**: Interview notes, survey results, analytics data.
+- **Business goals**: Metrics, OKRs, or success criteria to optimize for.
+
+## Out of scope
+
+- Making final product decisions (this is the PM's job; the skill assists).
+- Managing stakeholder relationships and politics.
+- Detailed UI/UX design work (use design tools and collaborate with designers).
+- Project management and sprint planning (use project management tools).
+
+## Conventions and best practices
+
+### PRD structure
+
+A good PRD should include:
+
+1. **Problem statement**: What user pain point or business need are we addressing?
+2. **Goals and success metrics**: What does success look like quantitatively?
+3. **User stories and use cases**: Who will use this and how?
+4. **Requirements**: Functional and non-functional requirements, prioritized.
+5. **Technical considerations**: Architecture implications, dependencies, constraints.
+6. **Design and UX notes**: Key interaction patterns or design requirements.
+7. **Risks and mitigations**: What could go wrong and how to address it.
+8. **Launch plan**: Rollout strategy, feature flags, monitoring.
+9. **Open questions**: What still needs to be decided or researched.
+
+### Feature prioritization
+
+Use structured frameworks to evaluate features:
+
+- **RICE**: Reach × Impact × Confidence / Effort
+- **ICE**: Impact × Confidence × Ease
+- **Value vs. Effort**: 2×2 matrix plotting value against implementation cost
+- **Kano Model**: Categorize features into basic, performance, and delighters
+
+### User research synthesis
+
+When synthesizing research:
+
+1. **Identify patterns**: What themes emerge across participants?
+2. **Quote verbatim**: Include actual user quotes to illustrate points.
+3. **Quantify when possible**: "7 out of 10 participants said..."
+4. **Segment findings**: Different user types may have different needs.
+5. **Connect to metrics**: How do qualitative findings explain quantitative data?
+
+### Roadmap planning
+
+Effective roadmaps should:
+
+- **Theme-based**: Group work into strategic themes, not just feature lists.
+- **Time-horizoned**: Now / Next / Later or Quarterly structure.
+- **Outcome-focused**: Emphasize goals and outcomes, not just outputs.
+- **Flexible**: Leave room for learning and adjustment.
+- **Communicated clearly**: Different views for different audiences.
+
+## Required behavior
+
+1. **Understand context deeply**: Review existing docs, code, and prior discussions before proposing changes.
+2. **Ask clarifying questions**: Don't assume; clarify ambiguous requirements or goals.
+3. **Be specific and actionable**: Avoid vague language; provide concrete, testable requirements.
+4. **Consider tradeoffs**: Explicitly discuss pros/cons of different approaches.
+5. **Connect to strategy**: Tie features and decisions back to higher-level goals.
+6. **Involve stakeholders**: Identify who needs to review or approve.
+7. **Think through edge cases**: Don't just focus on happy paths.
+8. **Make it measurable**: Propose concrete metrics to track success.
+
+## Required artifacts
+
+Depending on the task, generate:
+
+- **PRD document**: Comprehensive product requirements in markdown format.
+- **Feature analysis**: Structured evaluation of a feature request.
+- **Research synthesis**: Summary of user research findings with insights.
+- **Roadmap document**: Organized view of planned work with themes and timelines.
+- **Decision document**: Record of key product decisions and rationale.
+- **Competitive analysis**: Comparison of competitor features and approaches.
+- **Metric definitions**: Clear definitions of success metrics and how to measure them.
+
+## Implementation checklist
+
+### Writing a PRD
+
+- [ ] Understand the problem space and strategic context
+- [ ] Review related code, APIs, and technical constraints
+- [ ] Interview key stakeholders (engineering, design, business)
+- [ ] Research user needs and competitive landscape
+- [ ] Draft problem statement and goals
+- [ ] Define user stories and use cases
+- [ ] Specify functional and non-functional requirements
+- [ ] Document technical considerations and dependencies
+- [ ] Define success metrics and measurement approach
+- [ ] Identify risks and mitigation strategies
+- [ ] Plan rollout and launch approach
+- [ ] Review with stakeholders and iterate
+
+### Analyzing a feature request
+
+- [ ] Clarify the user problem or business need
+- [ ] Identify target users and use cases
+- [ ] Estimate impact (users affected, business value)
+- [ ] Assess implementation effort and complexity
+- [ ] Identify dependencies and risks
+- [ ] Check alignment with product strategy
+- [ ] Compare against alternatives
+- [ ] Calculate prioritization score (RICE, ICE, etc.)
+- [ ] Make recommendation with clear reasoning
+
+### Synthesizing user research
+
+- [ ] Review all research materials (transcripts, notes, data)
+- [ ] Identify key themes and patterns
+- [ ] Extract representative quotes
+- [ ] Segment findings by user type if relevant
+- [ ] Connect qualitative findings to quantitative data
+- [ ] Formulate insights and implications
+- [ ] Generate actionable recommendations
+- [ ] Prioritize recommendations by impact
+
+### Planning a roadmap
+
+- [ ] Review strategic goals and OKRs
+- [ ] Collect input from stakeholders
+- [ ] Assess current state and technical debt
+- [ ] Group potential work into strategic themes
+- [ ] Prioritize themes and initiatives
+- [ ] Estimate sizing and dependencies
+- [ ] Organize into time horizons (Now/Next/Later)
+- [ ] Define success criteria for each initiative
+- [ ] Create views for different audiences
+- [ ] Review and socialize with stakeholders
+
+## Example workflows
+
+### Example 1: Writing a PRD for a new feature
+
+```markdown
+# PRD: Advanced Search Functionality
+
+## Problem Statement
+
+Users frequently report difficulty finding specific items in our catalog when they have multiple criteria (price range, location, category, features). Our current search only supports simple text queries, leading to:
+
+- High bounce rates on search results pages (65% bounce rate vs 32% site average)
+- Increased support tickets asking for search help (150/month)
+- Lost conversion opportunities (estimated $500K annual revenue impact)
+
+## Goals and Success Metrics
+
+**Primary Goal**: Enable users to find relevant items quickly using multiple filters.
+
+**Success Metrics**:
+
+- Reduce search result page bounce rate from 65% to <40%
+- Increase search-to-purchase conversion rate by 25%
+- Reduce search-related support tickets by 50%
+- 70% of users engage with at least one filter within 30 days
+
+## User Stories
+
+### Must Have
+
+1. As a buyer, I want to filter by price range so I can find items within my budget
+2. As a buyer, I want to filter by location so I can find items near me
+3. As a buyer, I want to filter by category so I can narrow down item types
+4. As a buyer, I want to combine multiple filters so I can find exactly what I need
+5. As a buyer, I want to see filter counts so I know how many items match before applying
+
+### Should Have
+
+6. As a buyer, I want to save my filter preferences so I don't have to reapply them
+7. As a buyer, I want to see suggested filters based on my search query
+8. As a buyer, I want to sort filtered results by relevance, price, or date
+
+### Nice to Have
+
+9. As a buyer, I want to create saved searches that notify me of new matches
+10. As a buyer, I want to share a filtered search URL with others
+```
+
+### Example 2: Feature request analysis
+
+```markdown
+# Feature Analysis: Dark Mode Support
+
+## Request Summary
+
+**Source**: User feedback (150+ requests in past 6 months), competitive pressure
+**Description**: Add dark mode theme option to web and mobile apps
+
+## User Need
+
+Users working in low-light environments report eye strain with current light-only theme. Power users (25% of DAU) spend 3+ hours/day in app and strongly prefer dark mode.
+
+## Prioritization Score
+
+Using RICE framework:
+
+- **Reach**: 750K users = 750
+- **Impact**: 8/10 (high for target segment) = 0.8
+- **Confidence**: 85% = 0.85
+- **Effort**: 7 weeks = 7
+
+**RICE Score**: (750 × 0.8 × 0.85) / 7 = **73.2**
+
+## Recommendation
+
+**Proceed with Option 1 (Full Dark Mode)**
+
+**Reasoning**:
+
+- High impact for large user segment (45% of base)
+- Strong user demand and competitive pressure
+- Effort is reasonable relative to value
+- RICE score above our threshold (>50)
+- Aligns with product, technical, and business strategy
+```
+
+## Common PM artifacts
+
+### PRD (Product Requirements Document)
+
+Comprehensive specification of what to build and why. Include problem statement, goals, user stories, requirements, technical considerations, risks, and launch plan.
+
+### Feature Brief
+
+Lighter-weight than PRD; quick summary of a feature idea with key details. Use for early-stage exploration before committing to full PRD.
+
+### User Research Synthesis
+
+Summary of user research findings (interviews, surveys, usability tests) with patterns, insights, and recommendations.
+
+### Roadmap
+
+Strategic plan of what to build over time. Organize by themes and time horizons; focus on outcomes not just outputs.
+
+### Decision Document
+
+Record of important product decisions, the options considered, the decision made, and the reasoning. Critical for institutional memory.
+
+### Launch Plan
+
+Detailed plan for rolling out a feature including phases, feature flags, metrics, monitoring, and rollback procedures.
+
+### Competitive Analysis
+
+Comparison of competitors' features, approaches, and positioning. Inform product strategy and feature prioritization.
+
+### One-Pager
+
+Executive summary of a product initiative. Use to communicate to leadership and get alignment.
+
+## Best practices for AI-assisted PM work
+
+### When using AI to write PRDs
+
+- Provide comprehensive context about the product, users, and technical constraints.
+- Review and edit generated content carefully; AI may miss nuances or make wrong assumptions.
+- Use AI for structure and first drafts; refine with human judgment and stakeholder input.
+- Validate technical details with engineering; don't assume AI knows your architecture.
+
+### When using AI for feature analysis
+
+- Provide quantitative data when possible (usage numbers, customer feedback counts).
+- Use structured frameworks (RICE, ICE) to make analysis consistent and defensible.
+- Don't let AI make the final decision; use it to organize thinking and surface considerations.
+- Supplement AI analysis with qualitative stakeholder input and strategic context.
+
+### When using AI for research synthesis
+
+- Provide full transcripts or detailed notes for best results.
+- Ask AI to identify patterns but validate with your own reading of the data.
+- Use AI to extract quotes and organize themes; add your own interpretation and implications.
+- Don't let AI over-summarize; sometimes important details are in the nuances.
+
+## Safety and escalation
+
+- **Strategic decisions**: AI should inform, not make, key product decisions. Involve human PMs and stakeholders.
+- **User data**: Don't feed PII or sensitive user data to AI without proper data handling procedures.
+- **Technical feasibility**: Always validate technical assumptions and effort estimates with engineering.
+- **Competitive intelligence**: Be cautious about including confidential competitive info in prompts.
+- **Tone and voice**: Review and adjust tone for your audience; AI may be too formal or informal.
+
+## Integration with other skills
+
+This skill can be combined with:
+
+- **Data querying**: To analyze product metrics and user behavior data.
+- **AI data analyst**: To perform deeper quantitative analysis for feature decisions.
+- **Frontend UI integration**: To implement features designed in PRDs.
+- **Internal tools**: To build PM tools like feature flag dashboards or metrics viewers.

package/.plcode/skill/experimental/quieter/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: quieter
+description: Tone down overly bold or visually aggressive designs. Reduces intensity while maintaining design quality and impact.
+category: design
+args:
+  - name: target
+    description: The feature or component to make quieter (optional)
+    required: false
+user-invokable: true
+---
+
+Reduce visual intensity in designs that are too bold, aggressive, or overstimulating, creating a more refined and approachable aesthetic without losing effectiveness.
+
+## 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), brand personality/tone, and everything else that a great human designer would need as well.
+
+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. Guessing leads to generic design.
+
+### 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 too intense:
+
+1. **Identify intensity sources**:
+   - **Color saturation**: Overly bright or saturated colors
+   - **Contrast extremes**: Too much high-contrast juxtaposition
+   - **Visual weight**: Too many bold, heavy elements competing
+   - **Animation excess**: Too much motion or overly dramatic effects
+   - **Complexity**: Too many visual elements, patterns, or decorations
+   - **Scale**: Everything is large and loud with no hierarchy
+
+2. **Understand the context**:
+   - What's the purpose? (Marketing vs tool vs reading experience)
+   - Who's the audience? (Some contexts need energy)
+   - What's working? (Don't throw away good ideas)
+   - What's the core message? (Preserve what matters)
+
+If any of these are unclear from the codebase, {{ask_instruction}}
+
+**CRITICAL**: "Quieter" doesn't mean boring or generic. It means refined, sophisticated, and easier on the eyes. Think luxury, not laziness.
+
+## Plan Refinement
+
+Create a strategy to reduce intensity while maintaining impact:
+
+- **Color approach**: Desaturate or shift to more sophisticated tones?
+- **Hierarchy approach**: Which elements should stay bold (very few), which should recede?
+- **Simplification approach**: What can be removed entirely?
+- **Sophistication approach**: How can we signal quality through restraint?
+
+**IMPORTANT**: Great quiet design is harder than great bold design. Subtlety requires precision.
+
+## Refine the Design
+
+Systematically reduce intensity across these dimensions:
+
+### Color Refinement
+
+- **Reduce saturation**: Shift from fully saturated to 70-85% saturation
+- **Soften palette**: Replace bright colors with muted, sophisticated tones
+- **Reduce color variety**: Use fewer colors more thoughtfully
+- **Neutral dominance**: Let neutrals do more work, use color as accent (10% rule)
+- **Gentler contrasts**: High contrast only where it matters most
+- **Tinted grays**: Use warm or cool tinted grays instead of pure gray—adds sophistication without loudness
+- **Never gray on color**: If you have gray text on a colored background, use a darker shade of that color or transparency instead
+
+### Visual Weight Reduction
+
+- **Typography**: Reduce font weights (900 → 600, 700 → 500), decrease sizes where appropriate
+- **Hierarchy through subtlety**: Use weight, size, and space instead of color and boldness
+- **White space**: Increase breathing room, reduce density
+- **Borders & lines**: Reduce thickness, decrease opacity, or remove entirely
+
+### Simplification
+
+- **Remove decorative elements**: Gradients, shadows, patterns, textures that don't serve purpose
+- **Simplify shapes**: Reduce border radius extremes, simplify custom shapes
+- **Reduce layering**: Flatten visual hierarchy where possible
+- **Clean up effects**: Reduce or remove blur effects, glows, multiple shadows
+
+### Motion Reduction
+
+- **Reduce animation intensity**: Shorter distances (10-20px instead of 40px), gentler easing
+- **Remove decorative animations**: Keep functional motion, remove flourishes
+- **Subtle micro-interactions**: Replace dramatic effects with gentle feedback
+- **Refined easing**: Use ease-out-quart for smooth, understated motion—never bounce or elastic
+- **Remove animations entirely** if they're not serving a clear purpose
+
+### Composition Refinement
+
+- **Reduce scale jumps**: Smaller contrast between sizes creates calmer feeling
+- **Align to grid**: Bring rogue elements back into systematic alignment
+- **Even out spacing**: Replace extreme spacing variations with consistent rhythm
+
+**NEVER**:
+
+- Make everything the same size/weight (hierarchy still matters)
+- Remove all color (quiet ≠ grayscale)
+- Eliminate all personality (maintain character through refinement)
+- Sacrifice usability for aesthetics (functional elements still need clear affordances)
+- Make everything small and light (some anchors needed)
+
+## Verify Quality
+
+Ensure refinement maintains quality:
+
+- **Still functional**: Can users still accomplish tasks easily?
+- **Still distinctive**: Does it have character, or is it generic now?
+- **Better reading**: Is text easier to read for extended periods?
+- **Sophistication**: Does it feel more refined and premium?
+
+Remember: Quiet design is confident design. It doesn't need to shout. Less is more, but less is also harder. Refine with precision and maintain intentionality.