@teckedd-code2save/b2dp 1.0.1 → 1.1.0

package/skills/cloud-solution-architect/references/performance-antipatterns.md

@@ -0,0 +1,242 @@
+# Performance Antipatterns
+
+Ten common performance antipatterns in cloud applications and how to resolve them.
+
+---
+
+## 1. Busy Database
+
+**Description:** Offloading too much processing to a data store. Using stored procedures for formatting, string manipulation, or complex calculations that belong in the application tier.
+
+**Why it happens:**
+- Database viewed as a service rather than a repository
+- Developers write queries that format data for direct display
+- Attempts to correct Extraneous Fetching by pushing compute to the database
+
+**Symptoms:**
+- Disproportionate decline in throughput and response times for database operations
+
+**How to detect:**
+- Performance monitoring of database activity
+- Examine work performed during slow periods
+
+**How to fix:**
+- Move processing (formatting, string manipulation, calculations) to application tiers
+- Limit the database to data access operations (aggregation is acceptable)
+- Don't move processing out if it causes the database to transfer far more data (Extraneous Fetching)
+
+**Example scenario:** A SQL query performs XML formatting, string concatenation, and locale-specific formatting in T-SQL instead of returning raw data and letting application code handle presentation.
+
+---
+
+## 2. Busy Front End
+
+**Description:** Moving resource-intensive tasks onto foreground/UI threads instead of background threads.
+
+**Why it happens:**
+- Processing done synchronously in request handlers
+
+**Symptoms:**
+- High latency on requests
+- Poor user responsiveness
+
+**How to detect:**
+- Monitor thread utilization and CPU usage on the front-end tier
+
+**How to fix:**
+- Move resource-intensive tasks to background threads or services (Azure Functions, WebJobs)
+
+**Example scenario:** A web API controller performs image resizing synchronously within the HTTP request pipeline, blocking the thread and causing timeouts for other users during peak load.
+
+---
+
+## 3. Chatty I/O
+
+**Description:** Continually sending many small network requests instead of fewer larger ones.
+
+**Why it happens:**
+- Following object-oriented patterns that make many small calls
+- Individual property gets instead of batch reads
+
+**Symptoms:**
+- High number of I/O operations
+- High latency due to network round trips
+
+**How to detect:**
+- Monitor the number of I/O requests and their sizes
+
+**How to fix:**
+- Bundle multiple smaller requests into fewer larger ones
+- Use caching to avoid repeated calls
+- Read data in bulk
+
+**Example scenario:** An application retrieves a user profile by making separate API calls for name, email, address, and preferences instead of a single call that returns the complete profile object.
+
+---
+
+## 4. Extraneous Fetching
+
+**Description:** Retrieving more data than needed, resulting in unnecessary I/O and memory consumption.
+
+**Why it happens:**
+- `SELECT *` queries
+- Fetching all columns or rows when only a subset is needed
+
+**Symptoms:**
+- High memory usage
+- Excessive bandwidth consumption
+
+**How to detect:**
+- Profile queries and check data transfer sizes
+
+**How to fix:**
+- Request only needed data columns and rows
+- Use pagination and projections
+
+**Example scenario:** An order history page runs `SELECT * FROM Orders` and filters in application code, transferring millions of rows when the user only sees the 20 most recent orders.
+
+---
+
+## 5. Improper Instantiation
+
+**Description:** Repeatedly creating and destroying objects designed to be shared and reused, such as `HttpClient`, database connections, or service clients.
+
+**Why it happens:**
+- Not understanding object lifecycle
+- Creating new instances per request
+
+**Symptoms:**
+- Port exhaustion
+- Socket exhaustion
+- Connection pool depletion
+
+**How to detect:**
+- Monitor connection counts, socket usage, and object creation rates
+
+**How to fix:**
+- Use singleton or static instances for shared clients
+- Use connection pooling
+- Use `IHttpClientFactory` for HTTP clients
+
+**Example scenario:** A web application creates a new `HttpClient` instance for every incoming request. Under load, available sockets are exhausted and requests fail with `SocketException` errors.
+
+---
+
+## 6. Monolithic Persistence
+
+**Description:** Using one data store for data with very different usage patterns.
+
+**Why it happens:**
+- Simplicity of a single database
+- Legacy design decisions
+
+**Symptoms:**
+- Performance degradation as different workloads compete for the same resources
+
+**How to detect:**
+- Monitor data store metrics and identify competing access patterns
+
+**How to fix:**
+- Separate data by usage pattern into appropriate stores (hot/warm/cold)
+- Apply polyglot persistence — use the right store for each data type
+
+**Example scenario:** A single SQL database handles both high-throughput transactional writes and complex analytical reporting queries, causing lock contention that degrades both workloads.
+
+---
+
+## 7. No Caching
+
+**Description:** Failing to cache frequently accessed data that changes infrequently.
+
+**Why it happens:**
+- Not considering a caching strategy
+- Assuming the database can handle all read traffic
+
+**Symptoms:**
+- Repeated identical queries
+- High database load
+- Slow response times
+
+**How to detect:**
+- Monitor cache hit ratios and look for repeated identical queries
+
+**How to fix:**
+- Implement the Cache-Aside pattern
+- Use Azure Cache for Redis
+- Set appropriate TTLs based on data volatility
+
+**Example scenario:** A product catalog page queries the database on every page load for data that only changes once a day, generating thousands of identical queries per hour.
+
+---
+
+## 8. Noisy Neighbor
+
+**Description:** A single tenant consumes a disproportionate amount of shared resources, starving other tenants.
+
+**Why it happens:**
+- Multi-tenant systems without resource isolation or throttling
+
+**Symptoms:**
+- Other tenants experience degraded performance
+- Resource starvation for well-behaved tenants
+
+**How to detect:**
+- Monitor per-tenant resource usage and identify outliers
+
+**How to fix:**
+- Implement tenant isolation, throttling, and quotas
+- Use the Bulkhead pattern to partition resources
+- Separate compute per tenant if needed
+
+**Example scenario:** In a shared SaaS platform, one tenant runs a bulk data import that saturates the database connection pool, causing timeout errors for all other tenants.
+
+---
+
+## 9. Retry Storm
+
+**Description:** Retrying failed requests too aggressively, amplifying failures during outages.
+
+**Why it happens:**
+- Aggressive retry policies without backoff
+- All clients retry simultaneously (thundering herd)
+
+**Symptoms:**
+- Cascading failures
+- Overwhelming services that are trying to recover
+
+**How to detect:**
+- Monitor retry rates and correlate with service recovery time
+
+**How to fix:**
+- Use exponential backoff with jitter
+- Implement the Circuit Breaker pattern
+- Cap retry attempts
+
+**Example scenario:** A downstream service goes offline for 30 seconds. Hundreds of clients immediately retry every 100ms with no backoff, generating 10x normal traffic and preventing the service from recovering for several minutes.
+
+---
+
+## 10. Synchronous I/O
+
+**Description:** Blocking the calling thread while I/O completes.
+
+**Why it happens:**
+- Using synchronous APIs for network or disk operations
+
+**Symptoms:**
+- Thread pool exhaustion
+- Poor scalability under load
+- UI freezing in client applications
+
+**How to detect:**
+- Monitor thread pool usage and identify blocking calls
+
+**How to fix:**
+- Use `async`/`await` patterns
+- Use non-blocking I/O and async APIs
+
+**Example scenario:** A web API makes synchronous HTTP calls to three downstream services sequentially. Under load, all thread pool threads are blocked waiting for responses, and the server can no longer accept new requests.
+
+---
+
+> Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/)

package/skills/cloud-solution-architect/references/technology-choices.md

@@ -0,0 +1,159 @@
+# Azure Technology Choice Decision Frameworks
+
+Decision frameworks for selecting the right Azure service in each category. Use these tables to compare options based on scale, cost, complexity, and use case fit.
+
+## Decision Approach
+
+1. **Start with requirements** — workload type, scale needs, team expertise
+2. **Use the comparison tables** — narrow to 2-3 candidates
+3. **Follow the decision trees** — Azure Architecture Center provides flowcharts for compute, data store, load balancing, and messaging
+4. **Validate with constraints** — budget, compliance, regional availability, existing infrastructure
+
+---
+
+## 1. Compute
+
+Choose a compute service based on control needs, scaling model, and operational complexity.
+
+| Service | Best For | Scale | Complexity | Cost Model |
+|---|---|---|---|---|
+| Azure VMs | Full control, lift-and-shift, custom OS | Manual/VMSS | High | Per-hour |
+| App Service | Web apps, APIs, mobile backends | Built-in autoscale | Low | Per App Service plan |
+| Azure Functions | Event-driven, short-lived processes | Consumption-based auto | Very Low | Per execution |
+| AKS | Microservices, complex orchestration | Node/pod autoscaling | High | Per node VM |
+| Container Apps | Serverless containers, microservices | KEDA-based autoscale | Medium | Per vCPU/memory/s |
+| Container Instances | Simple containers, batch jobs | Per-instance | Very Low | Per second |
+
+**Quick decision:**
+- Need full OS control? → **VMs**
+- Web app or API with minimal ops? → **App Service**
+- Short-lived event-driven code? → **Functions**
+- Complex microservices with K8s expertise? → **AKS**
+- Microservices without K8s management? → **Container Apps**
+- Run a container quickly, no orchestration? → **Container Instances**
+
+---
+
+## 2. Storage
+
+Choose a storage service based on data structure, access patterns, and scale.
+
+| Service | Best For | Access Pattern | Scale | Cost |
+|---|---|---|---|---|
+| Blob Storage | Unstructured data, media, backups | REST API, SDK | Massive | Per GB + operations |
+| Azure Files | SMB/NFS file shares, lift-and-shift | File system mount | TB-scale | Per GB provisioned |
+| Queue Storage | Simple message queuing | Pull-based | High throughput | Very low per message |
+| Table Storage | NoSQL key-value data | REST API | TB-scale | Per GB + operations |
+| Data Lake Storage | Big data analytics, hierarchical namespace | ABFS, REST | Massive | Per GB, tiered |
+
+**Quick decision:**
+- Blobs, images, videos, backups? → **Blob Storage**
+- Need a mounted file share (SMB/NFS)? → **Azure Files**
+- Simple async message queue? → **Queue Storage**
+- Key-value NoSQL without Cosmos DB cost? → **Table Storage**
+- Big data analytics with hierarchical namespace? → **Data Lake Storage**
+
+---
+
+## 3. Database
+
+Choose a database based on data model, consistency needs, and scale requirements.
+
+| Service | Best For | Consistency | Scale | Cost Model |
+|---|---|---|---|---|
+| Azure SQL | Relational, OLTP, enterprise apps | Strong (ACID) | Up to Hyperscale | DTU or vCore-based |
+| Cosmos DB | Global distribution, multi-model, low latency | Tunable (5 levels) | Unlimited horizontal | RU/s + storage |
+| Azure Database for PostgreSQL | Open-source relational, PostGIS, JSON | Strong (ACID) | Flexible Server auto | vCore-based |
+| Azure Database for MySQL | Open-source relational, web apps | Strong (ACID) | Flexible Server auto | vCore-based |
+
+**Quick decision:**
+- Enterprise SQL Server workloads? → **Azure SQL**
+- Global distribution or single-digit-ms latency? → **Cosmos DB**
+- Open-source relational with spatial/JSON? → **PostgreSQL**
+- Open-source relational for web apps? → **MySQL**
+
+---
+
+## 4. Messaging
+
+Choose a messaging service based on delivery guarantees, throughput, and integration pattern.
+
+| Service | Best For | Delivery | Throughput | Cost |
+|---|---|---|---|---|
+| Service Bus | Enterprise messaging, ordered delivery, transactions | At-least-once, at-most-once | Moderate-high | Per operation + unit |
+| Event Hubs | Event streaming, telemetry, big data ingestion | At-least-once, partitioned | Very high (millions/s) | Per TU/PU + ingress |
+| Event Grid | Event-driven reactive programming, webhooks | At-least-once | High | Per operation |
+| Queue Storage | Simple async messaging, decoupling | At-least-once | Moderate | Very low per message |
+
+**Quick decision:**
+- Enterprise messaging with ordering/transactions? → **Service Bus**
+- High-volume event streaming or telemetry? → **Event Hubs**
+- Reactive event routing (resource events, webhooks)? → **Event Grid**
+- Simple, cheap async decoupling? → **Queue Storage**
+
+---
+
+## 5. Networking
+
+Choose a load balancing service based on traffic scope, protocol layer, and feature needs.
+
+| Service | Best For | Scope | Layer | Features |
+|---|---|---|---|---|
+| Azure Front Door | Global HTTP(S) load balancing, CDN, WAF | Global | Layer 7 | CDN, WAF, SSL offload, caching |
+| Application Gateway | Regional HTTP(S) load balancing, WAF | Regional | Layer 7 | WAF, URL routing, SSL termination |
+| Azure Load Balancer | TCP/UDP traffic distribution | Regional | Layer 4 | High perf, zone redundant |
+| Traffic Manager | DNS-based global traffic routing | Global | DNS | Failover, performance, geographic routing |
+
+**Quick decision:**
+- Global HTTP(S) with CDN and WAF? → **Front Door**
+- Regional HTTP(S) with WAF? → **Application Gateway**
+- Regional TCP/UDP load balancing? → **Load Balancer**
+- DNS-based global failover? → **Traffic Manager**
+
+---
+
+## 6. AI Services
+
+Choose an AI service based on customization needs and model type.
+
+| Service | Best For | Complexity | Scale |
+|---|---|---|---|
+| Azure OpenAI | LLMs, GPT models, generative AI | Medium | API-based, token pricing |
+| Azure AI Services | Pre-built AI (vision, speech, language) | Low | API-based, per transaction |
+| Azure Machine Learning | Custom ML models, MLOps, training | High | Compute cluster-based |
+
+**Quick decision:**
+- Need GPT/LLM capabilities? → **Azure OpenAI**
+- Pre-built vision, speech, or language? → **AI Services**
+- Custom model training and MLOps? → **Azure Machine Learning**
+
+---
+
+## 7. Containers
+
+Choose a container service based on orchestration needs and operational complexity.
+
+| Service | Best For | Orchestration | Complexity | Cost |
+|---|---|---|---|---|
+| AKS | Full Kubernetes, complex workloads | Full K8s control plane | High | Per node VM |
+| Container Apps | Serverless containers, microservices, event-driven | Managed (built on K8s) | Medium | Per vCPU/memory/s |
+| Container Instances | Simple containers, sidecar groups, batch | None (per-instance) | Very Low | Per second |
+
+**Quick decision:**
+- Need full Kubernetes API and control? → **AKS**
+- Serverless containers with event-driven scaling? → **Container Apps**
+- Run a single container or batch job quickly? → **Container Instances**
+
+---
+
+## Related Decision Trees
+
+The Azure Architecture Center provides detailed flowcharts for these decisions:
+
+- [Choose a compute service](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree)
+- [Compare Container Apps with other options](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree#compare-container-options)
+- [Choose a data store](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-overview)
+- [Load balancing decision tree](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview)
+- [Compare messaging services](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging)
+
+> Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/)

package/skills/context7-mcp/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: context7-mcp
+description: This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.
+---
+
+When the user asks about libraries, frameworks, or needs code examples, use Context7 to fetch current documentation instead of relying on training data.
+
+## When to Use This Skill
+
+Activate this skill when the user:
+
+- Asks setup or configuration questions ("How do I configure Next.js middleware?")
+- Requests code involving libraries ("Write a Prisma query for...")
+- Needs API references ("What are the Supabase auth methods?")
+- Mentions specific frameworks (React, Vue, Svelte, Express, Tailwind, etc.)
+
+## How to Fetch Documentation
+
+### Step 1: Resolve the Library ID
+
+Call `resolve-library-id` with:
+
+- `libraryName`: The library name extracted from the user's question
+- `query`: The user's full question (improves relevance ranking)
+
+### Step 2: Select the Best Match
+
+From the resolution results, choose based on:
+
+- Exact or closest name match to what the user asked for
+- Higher benchmark scores indicate better documentation quality
+- If the user mentioned a version (e.g., "React 19"), prefer version-specific IDs
+
+### Step 3: Fetch the Documentation
+
+Call `query-docs` with:
+
+- `libraryId`: The selected Context7 library ID (e.g., `/vercel/next.js`)
+- `query`: The user's specific question
+
+### Step 4: Use the Documentation
+
+Incorporate the fetched documentation into your response:
+
+- Answer the user's question using current, accurate information
+- Include relevant code examples from the docs
+- Cite the library version when relevant
+
+## Guidelines
+
+- **Be specific**: Pass the user's full question as the query for better results
+- **Version awareness**: When users mention versions ("Next.js 15", "React 19"), use version-specific library IDs if available from the resolution step
+- **Prefer official sources**: When multiple matches exist, prefer official/primary packages over community forks

package/skills/frontend-data-consumer/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: frontend-data-consumer
+description: Ingests backend API contracts and scaffolds high-quality, typed React/Vue components (Data Tables, Detail Cards, Forms) using a specific design system (like Tailwind or Shadcn/UI). Use when a user wants to build a UI for their backend API or data platform.
+---
+
+# Frontend Data Consumer
+
+Automatically convert backend API contracts, database schemas, or ORM models into fully functional, strongly-typed frontend components. This skill is the perfect companion to the `business-to-data-platform` backend generator.
+
+## 🎯 When to Use
+- When the backend has been scaffolded and the user wants to start building the frontend features.
+- When you need to generate a React or Vue component that reads or writes to a specific API endpoint.
+- When generating admin dashboards, data tables, or forms based on database tables.
+- Works perfectly alongside the `frontend-design-review` skill to refine the generated UI.
+
+## 🛠️ Step-by-Step Workflow
+
+### 1. Analyze the Backend Contracts
+1. Locate the backend API routers/controllers, DTOs, or ORM schemas (e.g., Prisma schema, SQLAlchemy models).
+2. Understand the exact shape of the data returned by the `GET` endpoints.
+3. Understand the required payloads for the `POST`/`PUT`/`PATCH` endpoints.
+
+### 2. Scaffold Frontend API Hooks/Services
+Once the data shape is known, generate the data-fetching layer in the frontend using modern libraries (e.g., React Query, SWR, or RTK Query for React; Vue Query for Vue).
+
+#### Example (React Query):
+```typescript
+// hooks/useUsers.ts
+import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
+import { User, CreateUserDto } from '../types/api';
+
+export const useUsers = () => {
+  return useQuery<User[], Error>({
+    queryKey: ['users'],
+    queryFn: async () => {
+      const response = await fetch('/api/users');
+      if (!response.ok) throw new Error('Failed to fetch users');
+      return response.json();
+    },
+  });
+};
+
+export const useCreateUser = () => {
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: async (newUser: CreateUserDto) => {
+      const response = await fetch('/api/users', {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(newUser),
+      });
+      if (!response.ok) throw new Error('Failed to create user');
+      return response.json();
+    },
+    onSuccess: () => {
+      queryClient.invalidateQueries({ queryKey: ['users'] });
+    },
+  });
+};
+```
+
+### 3. Generate UI Components
+Based on the API contracts, scaffold the necessary UI components. Always use the project's preferred styling solution (TailwindCSS, CSS Modules, Styled Components, Shadcn/UI, Material UI).
+
+- **Data Tables:** Map array responses to robust data tables (with pagination and sorting if supported by the backend).
+- **Forms:** Generate creation/edit forms using a library like `react-hook-form` paired with `zod` validation that matches the backend rules exactly.
+- **Detail Views:** Generate read-only detail cards for individual records.
+
+### 4. Implement Loading & Error States
+Never return a component that crashes when data is fetching or fails.
+- Always handle the `isLoading` or `isPending` state with skeletons or spinners.
+- Always handle the `isError` state with a friendly error message or fallback UI.
+
+### 5. Finalize UI Contracts (No Hardcoding)
+Adhere strictly to this rule: **Never hardcode static arrays representing business entities.** The components must *always* consume the generated API hooks. If the backend endpoint doesn't exist yet, the hook should query a real endpoint path even if it currently 404s, so the wiring is ready to go.

package/skills/frontend-design-review/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: frontend-design-review
+description: >
+  Review and create distinctive, production-grade frontend interfaces with high design quality and design system compliance.
+  Evaluates using three pillars: frictionless insight-to-action, quality craft, and trustworthy building.
+  USE FOR: PR reviews, design reviews, accessibility audits, design system compliance checks, creative frontend design,
+  UI code review, component reviews, responsive design checks, theme testing, and creating memorable UI.
+  DO NOT USE FOR: Backend API reviews, database schema reviews, infrastructure or DevOps work, pure business logic
+  without UI, or non-frontend code.
+acknowledgments: |
+  Design review principles and quality pillar framework created by @Quirinevwm (https://github.com/Quirinevwm).
+  Creative frontend guidance inspired by Anthropic's frontend-design skill
+  (https://github.com/anthropics/skills/tree/main/skills/frontend-design). Licensed under respective terms.
+---
+
+# Frontend Design Review
+
+Review UI implementations against design quality standards and your design system **OR** create distinctive, production-grade frontend interfaces from scratch.
+
+## Two Modes
+
+### Mode 1: Design Review
+Evaluate existing UI for design system compliance, three quality pillars (Frictionless, Quality Craft, Trustworthy), accessibility, and code quality.
+
+### Mode 2: Creative Frontend Design
+Create distinctive interfaces that avoid generic "AI slop" aesthetics, have clear conceptual direction, and execute with precision.
+
+---
+
+## Creative Frontend Design
+
+Before coding, commit to an aesthetic direction:
+- **Purpose**: What problem does this solve? Who uses it?
+- **Tone**: minimal, maximalist, retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco, soft/pastel, industrial, etc.
+- **Constraints**: Framework, performance, accessibility requirements.
+- **Differentiation**: What makes this distinctive and context-appropriate?
+
+### Aesthetics Guidelines
+
+- **Typography**: Distinctive fonts that elevate aesthetics. Pair a display font with a refined body font. Avoid Inter, Roboto, Arial, Space Grotesk.
+- **Color & Theme**: Cohesive palette with CSS variables. Dominant colors + sharp accents > timid, evenly-distributed palettes.
+- **Motion**: CSS-only preferred. One well-orchestrated page load with staggered reveals > scattered micro-interactions.
+- **Spatial Composition**: Asymmetry, overlap, diagonal flow, grid-breaking elements, generous negative space OR controlled density.
+- **Backgrounds**: Gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, grain overlays.
+
+**AVOID**: Overused fonts, cliched color schemes, predictable layouts, cookie-cutter design without context-specific character.
+
+Match implementation complexity to vision. Maximalist = elaborate code. Minimalist = restraint and precision.
+
+---
+
+## Design Review
+
+### Design System Workflow
+
+**Before implementing:**
+1. Review component in your Storybook / component library for API and usage
+2. Use Figma Dev Mode to get exact specs (spacing, tokens, properties)
+3. Implement using design system components + design tokens
+
+**During review:**
+1. Compare implementation to Figma design
+2. Verify design tokens are used (not hardcoded values)
+3. Check all variants/states are implemented correctly
+4. Flag deviations (needs design approval)
+
+**If component doesn't exist:**
+1. Check if existing component can be adapted
+2. Reach out to design for new component creation
+3. Document exception and rationale in code
+
+### Review Process
+
+1. Identify user task
+2. Check design system for matching patterns
+3. Evaluate aesthetic direction
+4. Identify scope (component, feature, or flow)
+5. Evaluate each pillar
+6. Score and prioritize issues (blocking/major/minor)
+7. Provide recommendations with design system examples
+
+### Core Principles
+
+- **Task completion**: Minimum clicks. Every screen answers "What can I do?" and "What happens next?"
+- **Action hierarchy**: 1-2 primary actions per view. Progressive disclosure for secondary.
+- **Onboarding**: Explain features on introduction. Smart defaults over configuration.
+- **Navigation**: Clear entry/exit points. Back/cancel always available. Breadcrumbs for deep flows.
+
+---
+
+## Quality Pillars
+
+### 1. Frictionless Insight to Action
+
+**Evaluate:** Task completable in ≤3 interactions? Primary action obvious and singular?
+
+**Red flags:** Excessive clicks, multiple competing primary buttons, buried actions, dead ends.
+
+### 2. Quality is Craft
+
+**Evaluate:**
+- Design system compliance: matches Figma specs, uses design tokens
+- Aesthetic direction: distinctive typography, cohesive colors, intentional motion
+- Accessibility: Grade C minimum (WCAG 2.1 A), Grade B ideal (WCAG 2.1 AA)
+
+**Red flags:** Generic AI aesthetics, hardcoded values, implementation doesn't match Figma, broken reflow, missing focus indicators.
+
+### 3. Trustworthy Building
+
+**Evaluate:**
+- AI transparency: disclaimer on AI-generated content
+- Error transparency: actionable error messages
+
+**Red flags:** Missing AI disclaimers, opaque errors without guidance.
+
+---
+
+## Review Output Format
+
+See [references/review-output-format.md](references/review-output-format.md) for the full review template.
+
+## Review Type Modifiers
+
+See [references/review-type-modifiers.md](references/review-type-modifiers.md) for context-specific review focus areas (PR, Creative, Design, Accessibility).
+
+## Quick Checklist
+
+See [references/quick-checklist.md](references/quick-checklist.md) for the pre-approval checklist covering design system compliance, aesthetic quality, frictionless, quality craft, and trustworthy pillars.
+
+## Pattern Examples
+
+See [references/pattern-examples.md](references/pattern-examples.md) for good/bad examples of creative frontend and design system review work.
+
+---
+
+## Acknowledgments
+
+Creative frontend principles inspired by [Anthropic's frontend-design skill](https://github.com/anthropics/skills/tree/main/skills/frontend-design). Design review principles and quality pillar framework created by [@Quirinevwm](https://github.com/Quirinevwm) for systematic UI evaluation.

package/skills/frontend-design-review/references/pattern-examples.md

@@ -0,0 +1,21 @@
+# Pattern Examples
+
+## Creative Frontend (New Interfaces)
+
+### Good: Clear Aesthetic Direction
+- Landing page with brutalist aesthetic: Raw typography (Neue Haas Grotesk), stark black and white, asymmetric layouts
+- Dashboard with organic theme: Rounded forms, earth tones, flowing animations, textured backgrounds
+
+### Bad: Generic AI Aesthetic
+- Overused fonts, cliched color schemes, centered content, generic card layouts
+
+## Design System Review (Existing Work)
+
+### Good: Frictionless
+- Single primary button, clear task completion path
+
+### Good: Quality Craft
+- Uses design system with tokens, distinctive typography, keyboard accessible, tested in themes
+
+### Bad: Quality Craft
+- Hardcoded values, generic overused fonts, poor contrast in dark mode