@nerdev/skillset 0.2.1

package/skills/engineering/coding-standards/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: coding-standards
+category: engineering
+source: ECC (adapted)
+description: "Cross-project coding conventions for TypeScript/JavaScript. Load when establishing code standards or reviewing code style."
+
+# Coding Standards
+
+When to use: new project setup, onboarding team members, establishing code conventions, resolving style debates.
+
+## Naming Conventions
+
+| Element | Convention | Example |
+|---------|------------|---------|
+| Files | camelCase | `userService.ts`, `roomController.ts` |
+| Directories | camelCase | `src/routes`, `src/components` |
+| Functions | camelCase | `getUserById`, `createRoom` |
+| Variables | camelCase | `currentUser`, `roomId` |
+| Types/Interfaces | PascalCase | `User`, `RoomState` |
+| Enums | PascalCase | `ToolType`, `UserRole` |
+| Constants | UPPER_SNAKE_CASE | `MAX_RETRY_ATTEMPTS`, `DEFAULT_TIMEOUT` |
+| React Components | PascalCase | `CanvasToolbar`, `RoomHeader` |
+| CSS Classes | kebab-case | `canvas-container`, `tool-button` |
+
+## Code Structure
+
+### Functions
+
+- Max length: 30 lines (ideal), 50 lines (acceptable), 80 lines (split required)
+- Max parameters: 3 (use options object for more)
+- Single responsibility: one function, one job
+- Early returns: guard clauses over nested if/else
+
+```typescript
+// Good: Early return, single responsibility
+function processOrder(order: Order): Result {
+  if (!order) return { error: 'Order is required' }
+  if (order.status !== 'pending') return { error: 'Order already processed' }
+
+  const total = calculateTotal(order.items)
+  if (total <= 0) return { error: 'Invalid order total' }
+
+  return { data: { orderId: order.id, total } }
+}
+
+// Bad: Nested if/else, multiple responsibilities
+function processOrder(order: Order): Result {
+  if (order) {
+    if (order.status === 'pending') {
+      const total = calculateTotal(order.items)
+      if (total > 0) {
+        return { data: { orderId: order.id, total } }
+      } else {
+        return { error: 'Invalid order total' }
+      }
+    } else {
+      return { error: 'Order already processed' }
+    }
+  } else {
+    return { error: 'Order is required' }
+  }
+}
+```
+
+### Files
+
+- One export per file (preferred) or closely related exports
+- Barrel exports via `index.ts` only at package root
+- Order: types, constants, functions, classes, exports
+
+## Type Safety
+
+- No `any`. Use `unknown` and narrow with type guards.
+- No type assertions (`as`) unless absolutely necessary.
+- Prefer interfaces over type aliases for object shapes.
+- Use discriminated unions for variant types.
+
+```typescript
+// Good: Discriminated union
+type Result<T> =
+  | { success: true; data: T }
+  | { success: false; error: string }
+
+function processResult(result: Result<User>) {
+  if (result.success) {
+    console.log(result.data.name)
+  } else {
+    console.error(result.error)
+  }
+}
+
+// Bad: Type assertion
+const user = data as User  // Dangerous!
+```
+
+## Error Handling
+
+- Custom error classes for domain errors.
+- Never swallow errors. Always log or rethrow.
+- Error boundaries for React components.
+- Try/catch only when you can recover.
+
+```typescript
+// Good: Custom error class
+class NotFoundError extends Error {
+  constructor(resource: string, id: string) {
+    super(`${resource} with id ${id} not found`)
+    this.name = 'NotFoundError'
+  }
+}
+
+// Good: Explicit error handling
+async function getUser(id: string): Promise<User> {
+  const user = await db.user.findUnique({ where: { id } })
+  if (!user) throw new NotFoundError('User', id)
+  return user
+}
+
+// Bad: Swallowed error
+async function getUser(id: string): Promise<User | null> {
+  try {
+    return await db.user.findUnique({ where: { id } })
+  } catch {
+    return null  // What went wrong? Who knows!
+  }
+}
+```
+
+## Immutability
+
+- Prevent mutation with `readonly`, `as const`, `Object.freeze`.
+- Use spread over push/pop/splice.
+- Pure functions: same input, same output, no side effects.
+
+```typescript
+// Good: Immutable operations
+const addItem = (items: readonly Item[], item: Item): Item[] => [...items, item]
+const removeItem = (items: readonly Item[], id: string): Item[] => items.filter(i => i.id !== id)
+
+// Bad: Mutation
+const addItem = (items: Item[], item: Item): void => { items.push(item) }
+const removeItem = (items: Item[], id: string): void => {
+  const index = items.findIndex(i => i.id === id)
+  if (index >= 0) items.splice(index, 1)
+}
+```
+
+## Async Patterns
+
+- Always handle promises. No floating promises.
+- Use async/await over .then() chains.
+- Parallel when possible: Promise.all for independent operations.
+- Timeouts on external calls. Never wait forever.
+
+```typescript
+// Good: Parallel execution with timeout
+async function loadDashboard(userId: string): Promise<Dashboard> {
+  const [user, orders, notifications] = await Promise.all([
+    getUser(userId),
+    getOrders(userId),
+    getNotifications(userId),
+  ])
+
+  return { user, orders, notifications }
+}
+
+// Bad: Sequential when parallel is possible
+async function loadDashboard(userId: string): Promise<Dashboard> {
+  const user = await getUser(userId)        // 100ms
+  const orders = await getOrders(userId)    // 200ms
+  const notifications = await getNotifications(userId)  // 150ms
+  // Total: 450ms (could be 200ms with parallel)
+  return { user, orders, notifications }
+}
+```
+
+## Code Smells
+
+| Smell | Detection | Fix |
+|-------|-----------|-----|
+| Long function | > 30 lines | Extract smaller functions |
+| Deep nesting | > 3 levels | Use early returns |
+| Magic numbers | Hardcoded values | Extract to constants |
+| Duplicated code | Same logic 3+ times | Extract shared function |
+| God class | Does too many things | Split into focused classes |
+| Feature envy | Uses another class's data | Move function to that class |
+| Primitive obsession | Using primitives for complex concepts | Create value objects |
+
+## Comments
+
+- No comments for obvious code. Code should be self-documenting.
+- Document why, not what. Explain reasoning, not mechanics.
+- JSDoc on all exports: parameters, return values, throws.
+- TODO format: `// TODO(username): description - ticket-ref`
+
+```typescript
+/**
+ * Calculates the discounted price for an item.
+ *
+ * @param price - Original price in cents
+ * @param discount - Discount percentage (0-1)
+ * @returns Discounted price in cents
+ * @throws {ValidationError} When discount is out of range
+ *
+ * @example
+ * calculatePrice(1000, 0.15) // 850
+ */
+function calculatePrice(price: number, discount: number): number {
+  if (discount < 0 || discount > 1) {
+    throw new ValidationError('Discount must be between 0 and 1')
+  }
+  return Math.round(price * (1 - discount))
+}
+```
+
+## Quick Reference
+
+```bash
+bun run check-types
+bun run lint
+bun run format
+bun test
+```
+
+## Related Skills
+
+- `engineering/code-review` for review process
+- `engineering/tdd-workflow` for test standards
+- `ui/house-style` for UI-specific conventions

package/skills/engineering/product-engineering/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: product-engineering
+category: engineering
+source: custom
+description: "The discipline of making technical decisions that serve user goals. Bridges product thinking and engineering execution. Load when building features, making architecture choices, scoping work, or deciding what NOT to build."
+triggers:
+  - should we build this
+  - is this worth building
+  - how to scope this
+  - what should we build next
+  - technical decision
+  - architecture decision
+  - build vs buy
+  - product engineering
+---
+
+# Product Engineering
+
+Thinking in product outcomes, not just technical systems. Checking how the product is doing, identifying where to improve, deciding what to improve — and building it.
+
+## When to use
+
+- Reviewing product metrics and identifying improvement opportunities
+- Deciding what to build next based on data, not guesses
+- Scoping features to move specific metrics
+- Making technical decisions that serve product goals
+- Saying no to features that don't move the needle
+- Continuously improving an existing product
+
+## Core principle
+
+**Engineers who think in product, not just systems.** Not "how do I build this?" but "should this exist? will users care? how will we know if it worked?"
+
+## The Product-Engineering Loop
+
+```
+Measure → Identify → Prioritize → Build → Measure
+   ↑                                        |
+   └────────────────────────────────────────┘
+```
+
+### 1. Measure
+
+Know how the product is doing:
+
+- **What's working?** Features with high adoption, good retention, positive feedback.
+- **What's not working?** Drop-offs, low adoption, support tickets, churn.
+- **What's missing?** User requests, competitive gaps, unmet needs.
+
+Track outcomes, not output:
+
+| Output (vanity) | Outcome (signal) |
+|-----------------|------------------|
+| Features shipped | Changes in user behavior |
+| Lines of code | Users completing key flows |
+| Sprint velocity | Time to answer "is this working?" |
+| Code coverage | Bugs found before users hit them |
+
+### 2. Identify
+
+Find improvement opportunities:
+
+- **Where are users dropping off?** Funnel analysis, session recordings.
+- **What are users asking for?** Support tickets, feature requests, forum posts.
+- **What are competitors doing that we're not?** Competitive analysis.
+- **What's broken that users tolerate?** Workarounds, manual processes.
+
+### 3. Prioritize
+
+Decide what to work on:
+
+| Factor | Question | Weight |
+|--------|----------|--------|
+| **Impact** | How many users does this affect? | High |
+| **Intensity** | How much pain does this solve? | High |
+| **Confidence** | How sure are we this will work? | Medium |
+| **Effort** | How long will this take? | Medium |
+| **Strategic fit** | Does this align with our direction? | Low |
+
+**Rule:** Work on the highest impact + highest intensity problems first. Not the easiest, not the most interesting.
+
+### 4. Build
+
+Ship with intent:
+
+- **One hypothesis per feature.** "We believe [this change] will [this outcome] for [these users]."
+- **Instrument from day one.** If you can't measure it, you can't learn from it.
+- **Ship to a subset.** Feature flags, staged rollouts, beta groups.
+
+### 5. Measure (again)
+
+After shipping, answer:
+
+- Did the hypothesis hold?
+- What surprised us?
+- What should we double down on? Kill? Iterate?
+
+Feed findings back to step 1.
+
+## Decision Frameworks
+
+### Build vs Buy
+
+```
+Does this differentiate us from competitors?
+  ├─ YES → Build (it's your moat)
+  └─ NO → Buy or use existing
+           └─ Is there a mature, well-maintained solution?
+                ├─ YES → Buy/adopt
+                └─ NO → Build, but keep it minimal
+```
+
+**Examples:**
+- Auth → Buy (Clerk, Auth0, Supabase Auth). Not your moat.
+- Core algorithm → Build. Your differentiator.
+- Admin dashboard → Buy or template. Not your moat.
+- Unique UX interaction → Build. Your moat.
+
+### Complexity Matching
+
+| Problem complexity | Solution complexity | Anti-pattern |
+|-------------------|-------------------|--------------|
+| Simple CRUD | Single table, minimal abstractions | Over-engineered microservices |
+| Real-time collaboration | WebSockets, operational transform | Polling every 5 seconds |
+| Data pipeline | Queue + workers | Synchronous processing |
+| Multi-tenant SaaS | Row-level security, schema separation | Separate databases per tenant |
+
+**Rule:** The solution should be exactly as complex as the problem. Not simpler (it won't work), not more complex (it won't be maintained).
+
+### Scope Control
+
+Before adding a feature, ask:
+
+1. **Does this move a metric we care about?** If no, don't build it.
+2. **Can we solve this with copy/design instead of code?** Often cheaper.
+3. **What happens if we don't build this?** If nothing meaningful, skip it.
+4. **Is this a "must have" or a "nice to have"?** Nice to haves go to the backlog.
+5. **Can we solve this for 80% of users with 20% of the work?** Ship that.
+
+## Technical Decisions That Serve Product Goals
+
+### Architecture serves iteration speed
+
+Choose architecture that lets you **change your mind fast**:
+
+- **Monolith first.** Microservices add coordination cost. Start with a well-structured monolith.
+- **Feature flags over branches.** Deploy continuously, release selectively.
+- **Convention over configuration.** Fewer decisions to make, faster to ship.
+- **Simple hosting.** Vercel/Railway/Fly.io over custom Kubernetes. Your users don't care about your infrastructure.
+
+### Database serves the access pattern
+
+Choose database based on **how you read/write**, not how trendy it is:
+
+| Access pattern | Right choice | Wrong choice |
+|---------------|--------------|--------------|
+| Structured data, joins, transactions | Postgres | MongoDB |
+| Document store, flexible schema | MongoDB | Postgres (forced) |
+| Key-value, caching | Redis | Postgres (overkill) |
+| Time-series, analytics | ClickHouse, Timescale | Postgres (slow) |
+| Full-text search | Elasticsearch, Meilisearch | Postgres LIKE (slow) |
+
+### API serves the consumer
+
+Design APIs for the **consumer's use case**, not your database schema:
+
+- **REST for CRUD.** Simple, well-understood.
+- **GraphQL for complex reads.** When clients need flexible queries.
+- **WebSockets for real-time.** When latency matters.
+- **Webhooks for integrations.** When other systems need to react.
+
+## Anti-Patterns
+
+### Premature abstraction
+Building a "reusable framework" before you've built the thing twice. DRY matters, but YAGNI matters more.
+
+### Resume-driven development
+Choosing tech because it looks good on a resume, not because it solves the problem. "We need Kafka" when a simple queue would work.
+
+### Cargo cult architecture
+Copying Netflix's architecture when you have 100 users, not 100 million.
+
+### Feature factory
+Shipping features without measuring outcomes. "We shipped 12 features this sprint" means nothing if none moved a metric.
+
+### Complexity as insurance
+Adding abstractions "just in case" we need them later. You probably won't. Delete it when you do.
+
+## Integration with other skills
+
+| Skill | When to use with product-engineering |
+|-------|-------------------------------------|
+| `office-hours` | Validating a new product idea |
+| `startup-founder` | Early stage — what to build first |
+| `customer-research` | Understanding users deeply |
+| `ui-engineering` | Building the frontend |
+| `motion` | Adding micro-interactions, icon morphs, transitions — load when a product decision involves UI feel |
+| `ship` | Shipping with measurement |
+| `performance` | Optimizing what matters to users |
+| `security` | Protecting what users trust you with |
+| `learn` | Tracking product learnings across sessions |
+
+## Pre-ship checklist
+
+Before declaring any feature done:
+
+- [ ] **Hypothesis stated.** "We believe [X] will [Y] for [Z]."
+- [ ] **Measurement defined.** How will we know if it worked?
+- [ ] **Scope matches hypothesis.** No extra features sneaking in.
+- [ ] **Build vs buy justified.** Why this needed to be custom.
+- [ ] **Complexity matches problem.** No over-engineering.
+- [ ] **Rollout plan exists.** How do we deploy safely?
+- [ ] **Rollback plan exists.** How do we undo if it breaks?
+- [ ] **Success criteria defined.** What does "working" look like?
+- [ ] **Failure criteria defined.** When do we kill this?
+
+## One-liner
+
+**Product engineering is checking how the product is doing and knowing what to improve next.**

package/skills/engineering/senior-engineer-prompts/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: senior-engineer-prompts
+category: engineering
+source: custom
+description: "5 senior software engineer thinking modes for architecture, debugging, code review, performance, and full-stack building. Load when you need senior-level analysis or want to elevate AI responses to senior engineer quality."
+
+# Senior Engineer Prompts
+
+When to use: you need senior-level thinking for building, reviewing, debugging, or architecting software. These prompts force deep analysis before action.
+
+## The 5 Modes
+
+### 1. Full-Stack Builder
+
+Use when starting a new project, building an MVP, or creating a complete feature from scratch.
+
+```markdown
+Act as an experienced full-stack engineer and build a complete application from the ground up. Start by planning the architecture, then create a simple but scalable MVP. Include:
+
+- System architecture (services, boundaries, communication)
+- Project structure (monorepo layout, module organization)
+- Database design (schema, relationships, indexing strategy)
+- API routes (REST/GraphQL conventions, versioning, error handling)
+- Frontend structure (component hierarchy, state management, routing)
+- Working implementation (production-ready code, not prototypes)
+
+Treat it like a real product that needs to scale as users grow. Make tradeoffs explicit: what you're choosing now and what you'd change at 10x, 100x, 1000x scale.
+```
+
+### 2. Codebase Auditor
+
+Use when taking over an unfamiliar project, onboarding to a new codebase, or preparing for major refactoring.
+
+```markdown
+Act as a senior engineer taking over an unfamiliar project. Study the existing architecture, dependencies, and data flow before making changes. Identify:
+
+- Poor architecture decisions and their long-term cost
+- Repeated logic that should be abstracted
+- Slow operations blocking performance
+- Future maintenance problems (tech debt, coupling, complexity)
+
+Then provide:
+1. Codebase overview (what it does, how it's organized, key dependencies)
+2. Key issues ranked by severity and fix difficulty
+3. Refactoring plan with phases (quick wins, medium, large)
+4. Updated implementation for the highest-priority items
+```
+
+### 3. Production Debugger
+
+Use when investigating bugs, fixing critical issues, or debugging production incidents.
+
+```markdown
+Act as a production-level debugging specialist. Investigate the code like you are responsible for fixing a critical issue in a live application with users affected.
+
+Work through:
+1. What the code is actually doing (trace the execution path)
+2. Where the failure begins (first observable symptom vs root cause)
+3. The actual root cause (not the symptom, the underlying reason)
+4. Possible edge cases that could trigger this or related failures
+5. The safest solution (minimal blast radius, reversible, testable)
+
+Finish with clean, tested, production-ready code. Include regression tests that would catch this class of bug.
+```
+
+### 4. Technical Architect
+
+Use when planning new systems, designing architecture, or evaluating technical approaches.
+
+```markdown
+Act as a senior software architect. Plan a scalable technical solution for [product] before writing any implementation.
+
+Cover:
+- Overall architecture (monolith vs microservices vs modular monolith, why)
+- Components and services (what owns what, boundaries, contracts)
+- Data movement (how data flows through the system, event-driven vs request-response)
+- API structure (contracts, versioning, backward compatibility)
+- Database model (entities, relationships, indexing, partitioning strategy)
+- Caching approach (what to cache, invalidation strategy, cache layers)
+- Working code for the core path (the 80% case, not every edge case)
+
+Keep the first version simple enough to launch while leaving room for growth. Document what you'd change at each scale milestone.
+```
+
+### 5. Performance Engineer
+
+Use when optimizing slow code, reviewing for performance, fixing memory issues, or scaling bottlenecks.
+
+```markdown
+Act as a performance engineer reviewing this code. Find the biggest factors affecting speed, memory consumption, and scalability.
+
+Look for:
+- Bottlenecks (CPU-bound, I/O-bound, network-bound)
+- Expensive operations (N+1 queries, unnecessary re-renders, large payloads)
+- Inefficient algorithms (O(n²) where O(n) or O(n log n) is possible)
+- Unnecessary work (re-renders, redundant computations, missing memoization)
+- Memory issues (leaks, excessive allocation, GC pressure)
+
+Then provide:
+1. Performance diagnosis (what's slow, how slow, measurable impact)
+2. Specific improvements ranked by impact/effort ratio
+3. Optimized implementation with before/after comparisons
+4. Monitoring suggestions (what to measure to prevent regression)
+```
+
+## How to Use
+
+Pick the mode that matches your current task and paste the prompt with your specific context.
+
+### To Elevate Existing Skills
+
+These prompts can be injected into other skills to add senior-level thinking:
+
+| Existing Skill | Inject Mode | Effect |
+|----------------|-------------|--------|
+| `architecture/blueprint` | Technical Architect | Forces deeper architecture analysis before planning |
+| `engineering/code-review` | Codebase Auditor | Adds systematic codebase understanding to reviews |
+| `devops/performance` | Performance Engineer | Structures performance analysis methodology |
+| Any debugging task | Production Debugger | Enforces root-cause analysis over symptom fixing |
+| Any new build | Full-Stack Builder | Ensures MVP considers scale from day one |
+
+### Combining Modes
+
+For complex tasks, chain modes:
+1. Technical Architect to plan the system
+2. Full-Stack Builder to implement the plan
+3. Performance Engineer to optimize the implementation
+4. Codebase Auditor to review the result
+
+## Output Quality Signals
+
+A senior engineer response should include:
+- Tradeoffs stated explicitly (chose X over Y because Z)
+- Scale considerations (works now, here's what changes later)
+- Failure modes identified (what could break and how)
+- Measurable outcomes (not "faster" but "reduces query time from 200ms to 20ms")
+- Reversibility (can we undo this if it's wrong?)
+
+## Related Skills
+
+- `architecture/blueprint` for multi-PR construction plans
+- `engineering/code-review` for confidence-weighted code review
+- `engineering/verification-loop` for pre-ship quality gates
+- `devops/performance` for performance optimization patterns
+- `architecture/search-first` for research-before-coding workflow