plcode-windows-x64-baseline 2.1.0

package/.plcode/skill/core/code-refactoring/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: code-refactoring
+description: Code refactoring patterns and techniques for improving code quality without changing behavior. Use for cleaning up legacy code, reducing complexity, or improving maintainability.
+category: workflow
+source: wshobson/agents
+license: MIT
+---
+
+# Code Refactoring
+
+## Refactoring Principles
+
+### When to Refactor
+
+- Before adding new features (make change easy, then make easy change)
+- After getting tests passing (red-green-refactor)
+- When you see code smells
+- During code review feedback
+
+### When NOT to Refactor
+
+- Without tests covering the code
+- Under tight deadlines with no safety net
+- Code that will be replaced soon
+- When you don't understand what the code does
+
+## Common Code Smells
+
+### Long Methods
+
+```typescript
+// BEFORE: Method doing too much
+function processOrder(order: Order) {
+  // 100 lines of validation, calculation, notification, logging...
+}
+
+// AFTER: Extract into focused methods
+function processOrder(order: Order) {
+  validateOrder(order)
+  const total = calculateTotal(order)
+  saveOrder(order, total)
+  notifyCustomer(order)
+}
+```
+
+### Deeply Nested Conditionals
+
+```typescript
+// BEFORE: Arrow code
+function getDiscount(user: User, order: Order) {
+  if (user) {
+    if (user.isPremium) {
+      if (order.total > 100) {
+        if (order.items.length > 5) {
+          return 0.2
+        }
+      }
+    }
+  }
+  return 0
+}
+
+// AFTER: Early returns (guard clauses)
+function getDiscount(user: User, order: Order) {
+  if (!user) return 0
+  if (!user.isPremium) return 0
+  if (order.total <= 100) return 0
+  if (order.items.length <= 5) return 0
+  return 0.2
+}
+```
+
+### Primitive Obsession
+
+```typescript
+// BEFORE: Primitives everywhere
+function createUser(name: string, email: string, phone: string) {
+  if (!email.includes("@")) throw new Error("Invalid email")
+  // more validation...
+}
+
+// AFTER: Value objects
+class Email {
+  constructor(private value: string) {
+    if (!value.includes("@")) throw new Error("Invalid email")
+  }
+  toString() {
+    return this.value
+  }
+}
+
+function createUser(name: string, email: Email, phone: Phone) {
+  // Email is already validated
+}
+```
+
+### Feature Envy
+
+```typescript
+// BEFORE: Method uses another object's data extensively
+function calculateShipping(order: Order) {
+  const address = order.customer.address
+  const weight = order.items.reduce((sum, i) => sum + i.weight, 0)
+  const distance = calculateDistance(address.zip)
+  return weight * distance * 0.01
+}
+
+// AFTER: Move method to where the data is
+class Order {
+  calculateShipping() {
+    return this.totalWeight * this.customer.shippingDistance * 0.01
+  }
+}
+```
+
+## Refactoring Techniques
+
+### Extract Method
+
+```typescript
+// Identify a code block that does one thing
+// Move it to a new method with a descriptive name
+// Replace original code with method call
+
+function printReport(data: ReportData) {
+  // Extract this block...
+  const header = `Report: ${data.title}\nDate: ${data.date}\n${"=".repeat(40)}`
+  console.log(header)
+
+  // ...into a method
+  printHeader(data)
+}
+```
+
+### Replace Conditional with Polymorphism
+
+```typescript
+// BEFORE: Switch on type
+function getArea(shape: Shape) {
+  switch (shape.type) {
+    case "circle":
+      return Math.PI * shape.radius ** 2
+    case "rectangle":
+      return shape.width * shape.height
+    case "triangle":
+      return (shape.base * shape.height) / 2
+  }
+}
+
+// AFTER: Polymorphic classes
+interface Shape {
+  getArea(): number
+}
+
+class Circle implements Shape {
+  constructor(private radius: number) {}
+  getArea() {
+    return Math.PI * this.radius ** 2
+  }
+}
+
+class Rectangle implements Shape {
+  constructor(
+    private width: number,
+    private height: number,
+  ) {}
+  getArea() {
+    return this.width * this.height
+  }
+}
+```
+
+### Introduce Parameter Object
+
+```typescript
+// BEFORE: Too many parameters
+function searchProducts(
+  query: string,
+  minPrice: number,
+  maxPrice: number,
+  category: string,
+  inStock: boolean,
+  sortBy: string,
+  sortOrder: string
+) { ... }
+
+// AFTER: Parameter object
+interface SearchParams {
+  query: string;
+  priceRange: { min: number; max: number };
+  category?: string;
+  inStock?: boolean;
+  sort?: { by: string; order: 'asc' | 'desc' };
+}
+
+function searchProducts(params: SearchParams) { ... }
+```
+
+### Replace Magic Numbers with Constants
+
+```typescript
+// BEFORE
+if (user.age >= 18 && order.total >= 50) {
+  applyDiscount(order, 0.1)
+}
+
+// AFTER
+const MINIMUM_AGE = 18
+const DISCOUNT_THRESHOLD = 50
+const STANDARD_DISCOUNT = 0.1
+
+if (user.age >= MINIMUM_AGE && order.total >= DISCOUNT_THRESHOLD) {
+  applyDiscount(order, STANDARD_DISCOUNT)
+}
+```
+
+## Safe Refactoring Process
+
+1. **Ensure tests exist** - Write tests if they don't
+2. **Make small changes** - One refactoring at a time
+3. **Run tests after each change** - Catch regressions immediately
+4. **Commit frequently** - Easy to revert if something breaks
+5. **Review the diff** - Make sure behavior hasn't changed
+
+## Refactoring Checklist
+
+- [ ] Tests pass before starting
+- [ ] Each change is small and focused
+- [ ] Tests pass after each change
+- [ ] No behavior changes (only structure)
+- [ ] Code is more readable than before
+- [ ] Commit message explains the refactoring

package/.plcode/skill/core/code-review/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: code-review
+description: Automated code review for pull requests using specialized review patterns. Analyzes code for quality, security, performance, and best practices. Use when reviewing code changes, PRs, or doing code audits.
+compatibility: All TypeScript/JavaScript projects
+license: MIT
+metadata:
+  category: development
+  priority: high
+---
+
+# Code Review Skill
+
+This skill provides comprehensive code review capabilities following industry best practices.
+
+## When to Use
+
+- Reviewing pull requests
+- Analyzing code changes
+- Performing security audits
+- Checking for performance issues
+- Ensuring code quality standards
+
+## Review Checklist
+
+### Quality
+
+- [ ] Code follows project conventions
+- [ ] Functions are small and focused
+- [ ] Variable names are descriptive
+- [ ] No unnecessary complexity
+
+### Security
+
+- [ ] No hardcoded secrets
+- [ ] Input validation present
+- [ ] No SQL injection risks
+- [ ] Proper error handling
+
+### Performance
+
+- [ ] No unnecessary computations
+- [ ] Efficient data structures
+- [ ] Proper async/await usage
+- [ ] No memory leaks
+
+### Testing
+
+- [ ] Tests cover new code
+- [ ] Edge cases handled
+- [ ] Integration tests updated
+
+## Output Format
+
+Provide structured feedback with:
+
+1. Summary of changes
+2. Critical issues (blocking)
+3. Warnings (non-blocking)
+4. Suggestions for improvement
+5. Positive findings

package/.plcode/skill/core/critique/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: critique
+description: Evaluate design effectiveness from a UX perspective. Assesses visual hierarchy, information architecture, emotional resonance, and overall design quality with actionable feedback.
+category: design
+args:
+  - name: area
+    description: The feature or area to critique (optional)
+    required: false
+user-invokable: true
+---
+
+Conduct a holistic design critique, evaluating whether the interface actually works—not just technically, but as a designed experience. Think like a design director giving feedback.
+
+**First**: Use the frontend-design skill for design principles and anti-patterns.
+
+## Design Critique
+
+Evaluate the interface across these dimensions:
+
+### 1. AI Slop Detection (CRITICAL)
+
+**This is the most important check.** Does this look like every other AI-generated interface from 2024-2025?
+
+Review the design against ALL the **DON'T** guidelines in the frontend-design skill—they are the fingerprints of AI-generated work. Check for the AI color palette, gradient text, dark mode with glowing accents, glassmorphism, hero metric layouts, identical card grids, generic fonts, and all other tells.
+
+**The test**: If you showed this to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.
+
+### 2. Visual Hierarchy
+
+- Does the eye flow to the most important element first?
+- Is there a clear primary action? Can you spot it in 2 seconds?
+- Do size, color, and position communicate importance correctly?
+- Is there visual competition between elements that should have different weights?
+
+### 3. Information Architecture
+
+- Is the structure intuitive? Would a new user understand the organization?
+- Is related content grouped logically?
+- Are there too many choices at once? (cognitive overload)
+- Is the navigation clear and predictable?
+
+### 4. Emotional Resonance
+
+- What emotion does this interface evoke? Is that intentional?
+- Does it match the brand personality?
+- Does it feel trustworthy, approachable, premium, playful—whatever it should feel?
+- Would the target user feel "this is for me"?
+
+### 5. Discoverability & Affordance
+
+- Are interactive elements obviously interactive?
+- Would a user know what to do without instructions?
+- Are hover/focus states providing useful feedback?
+- Are there hidden features that should be more visible?
+
+### 6. Composition & Balance
+
+- Does the layout feel balanced or uncomfortably weighted?
+- Is whitespace used intentionally or just leftover?
+- Is there visual rhythm in spacing and repetition?
+- Does asymmetry feel designed or accidental?
+
+### 7. Typography as Communication
+
+- Does the type hierarchy clearly signal what to read first, second, third?
+- Is body text comfortable to read? (line length, spacing, size)
+- Do font choices reinforce the brand/tone?
+- Is there enough contrast between heading levels?
+
+### 8. Color with Purpose
+
+- Is color used to communicate, not just decorate?
+- Does the palette feel cohesive?
+- Are accent colors drawing attention to the right things?
+- Does it work for colorblind users? (not just technically—does meaning still come through?)
+
+### 9. States & Edge Cases
+
+- Empty states: Do they guide users toward action, or just say "nothing here"?
+- Loading states: Do they reduce perceived wait time?
+- Error states: Are they helpful and non-blaming?
+- Success states: Do they confirm and guide next steps?
+
+### 10. Microcopy & Voice
+
+- Is the writing clear and concise?
+- Does it sound like a human (the right human for this brand)?
+- Are labels and buttons unambiguous?
+- Does error copy help users fix the problem?
+
+## Generate Critique Report
+
+Structure your feedback as a design director would:
+
+### Anti-Patterns Verdict
+
+**Start here.** Pass/fail: Does this look AI-generated? List specific tells from the skill's Anti-Patterns section. Be brutally honest.
+
+### Overall Impression
+
+A brief gut reaction—what works, what doesn't, and the single biggest opportunity.
+
+### What's Working
+
+Highlight 2-3 things done well. Be specific about why they work.
+
+### Priority Issues
+
+The 3-5 most impactful design problems, ordered by importance:
+
+For each issue:
+
+- **What**: Name the problem clearly
+- **Why it matters**: How this hurts users or undermines goals
+- **Fix**: What to do about it (be concrete)
+- **Command**: Which command to use (prefer: {{available_commands}} — or other installed skills you're sure exist)
+
+### Minor Observations
+
+Quick notes on smaller issues worth addressing.
+
+### Questions to Consider
+
+Provocative questions that might unlock better solutions:
+
+- "What if the primary action were more prominent?"
+- "Does this need to feel this complex?"
+- "What would a confident version of this look like?"
+
+**Remember**:
+
+- Be direct—vague feedback wastes everyone's time
+- Be specific—"the submit button" not "some elements"
+- Say what's wrong AND why it matters to users
+- Give concrete suggestions, not just "consider exploring..."
+- Prioritize ruthlessly—if everything is important, nothing is
+- Don't soften criticism—developers need honest feedback to ship great design

package/.plcode/skill/core/database-design/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: database-design
+description: Database schema design, optimization, and migration patterns for PostgreSQL, MySQL, and NoSQL databases. Use for designing schemas, writing migrations, or optimizing queries.
+category: backend
+source: wshobson/agents
+license: MIT
+---
+
+# Database Design
+
+## Schema Design Principles
+
+### Normalization Guidelines
+
+```sql
+-- 1NF: Atomic values, no repeating groups
+-- 2NF: No partial dependencies on composite keys
+-- 3NF: No transitive dependencies
+
+-- Users table (normalized)
+CREATE TABLE users (
+  id SERIAL PRIMARY KEY,
+  email VARCHAR(255) UNIQUE NOT NULL,
+  created_at TIMESTAMPTZ DEFAULT NOW()
+);
+
+-- Addresses table (separate entity)
+CREATE TABLE addresses (
+  id SERIAL PRIMARY KEY,
+  user_id INTEGER REFERENCES users(id) ON DELETE CASCADE,
+  street VARCHAR(255),
+  city VARCHAR(100),
+  country VARCHAR(100),
+  is_primary BOOLEAN DEFAULT false
+);
+```
+
+### Denormalization for Performance
+
+```sql
+-- When read performance matters more than write consistency
+CREATE TABLE order_summaries (
+  id SERIAL PRIMARY KEY,
+  order_id INTEGER REFERENCES orders(id),
+  customer_name VARCHAR(255),  -- Denormalized from customers
+  total_amount DECIMAL(10,2),
+  item_count INTEGER,
+  last_updated TIMESTAMPTZ DEFAULT NOW()
+);
+```
+
+## Index Design
+
+### Common Index Patterns
+
+```sql
+-- B-tree (default) for equality and range queries
+CREATE INDEX idx_users_email ON users(email);
+
+-- Composite index (order matters!)
+CREATE INDEX idx_orders_user_date ON orders(user_id, created_at DESC);
+
+-- Partial index for specific conditions
+CREATE INDEX idx_active_users ON users(email) WHERE deleted_at IS NULL;
+
+-- GIN index for array/JSONB columns
+CREATE INDEX idx_posts_tags ON posts USING GIN(tags);
+
+-- Covering index (includes additional columns)
+CREATE INDEX idx_orders_covering ON orders(user_id) INCLUDE (total, status);
+```
+
+### Index Analysis
+
+```sql
+-- Check index usage
+SELECT
+  schemaname, tablename, indexname,
+  idx_scan, idx_tup_read, idx_tup_fetch
+FROM pg_stat_user_indexes
+ORDER BY idx_scan DESC;
+
+-- Find missing indexes
+SELECT
+  relname, seq_scan, seq_tup_read,
+  idx_scan, idx_tup_fetch
+FROM pg_stat_user_tables
+WHERE seq_scan > idx_scan
+ORDER BY seq_tup_read DESC;
+```
+
+## Migration Patterns
+
+### Safe Migration Template
+
+```sql
+-- Always use transactions
+BEGIN;
+
+-- Add column with default (non-blocking in PG 11+)
+ALTER TABLE users ADD COLUMN status VARCHAR(20) DEFAULT 'active';
+
+-- Create index concurrently (doesn't lock table)
+CREATE INDEX CONCURRENTLY idx_users_status ON users(status);
+
+-- Backfill data in batches
+UPDATE users SET status = 'active' WHERE status IS NULL AND id BETWEEN 1 AND 10000;
+
+COMMIT;
+```
+
+### Zero-Downtime Migrations
+
+```
+1. Add new column (nullable)
+2. Deploy code that writes to both columns
+3. Backfill old data
+4. Deploy code that reads from new column
+5. Remove old column
+```
+
+## Query Optimization
+
+### EXPLAIN Analysis
+
+```sql
+-- Always use EXPLAIN ANALYZE
+EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
+SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';
+
+-- Key metrics to watch:
+-- - Seq Scan vs Index Scan
+-- - Actual rows vs Estimated rows
+-- - Buffers: shared hit vs read
+```
+
+### Common Optimizations
+
+```sql
+-- Use EXISTS instead of IN for large sets
+SELECT * FROM users u
+WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
+
+-- Pagination with keyset (cursor) instead of OFFSET
+SELECT * FROM posts
+WHERE created_at < '2024-01-01'
+ORDER BY created_at DESC
+LIMIT 20;
+
+-- Use CTEs for complex queries
+WITH active_users AS (
+  SELECT id FROM users WHERE last_login > NOW() - INTERVAL '30 days'
+)
+SELECT * FROM orders WHERE user_id IN (SELECT id FROM active_users);
+```
+
+## Constraints & Data Integrity
+
+```sql
+-- Primary key
+ALTER TABLE users ADD PRIMARY KEY (id);
+
+-- Foreign key with cascade
+ALTER TABLE orders ADD CONSTRAINT fk_orders_user
+  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
+
+-- Check constraint
+ALTER TABLE products ADD CONSTRAINT chk_price_positive
+  CHECK (price >= 0);
+
+-- Unique constraint
+ALTER TABLE users ADD CONSTRAINT uniq_users_email UNIQUE (email);
+
+-- Exclusion constraint (no overlapping ranges)
+ALTER TABLE reservations ADD CONSTRAINT excl_no_overlap
+  EXCLUDE USING gist (room_id WITH =, tsrange(start_time, end_time) WITH &&);
+```
+
+## Best Practices
+
+- Use UUIDs for public-facing IDs, SERIAL/BIGSERIAL for internal
+- Always add `created_at` and `updated_at` timestamps
+- Use soft deletes (`deleted_at`) for important data
+- Design for eventual consistency in distributed systems
+- Document schema decisions in migration files
+- Test migrations on production-size data before deploying