@neyugn/agent-kits 0.5.1 → 0.5.4

package/kits/coder/skills/mermaid-diagrams/SKILL.md

@@ -8,36 +8,42 @@ priority: LOW
 
 # Mermaid Diagrams - Visual Documentation
 
-> **Philosophy:** A good diagram is worth a thousand words. Keep it simple, readable, and purposeful.
+## ⚡ Quick Reference
+
+- **Diagram types**: `flowchart` (process) · `sequenceDiagram` (HTTP/API) · `erDiagram` (DB) · `classDiagram` (OOP)
+- **Flowchart**: `TD` (top-down) or `LR` (left-right) · `[box]` `(oval)` `{diamond}` `[[subroutine]]`
+- **Mermaid v10+**: Quote labels with special chars `A["Label (note)"]` · Avoid HTML in labels
+- **Sequence**: `participant A` → `A->>B: message` · `activate/deactivate` for lifelines · `Note over A: text`
+- **Colors**: `style node fill:#4CAF50` · Better: use classDef for reuse
+- **Length**: Max 20 nodes for readability · Split complex diagrams · Comment with `%%`
+
+---
+
 
 ---
 
 ## 🎯 Core Principles
 
-| Principle       | Rule                                         |
-| --------------- | -------------------------------------------- |
-| **Clarity**     | One diagram, one concept                     |
-| **Simplicity**  | Avoid overcrowding - less is more            |
-| **Consistency** | Same styling and conventions across diagrams |
-| **Purpose**     | Every element should serve understanding     |
-| **Maintenance** | Easy to update as system evolves             |
+- **Clarity**: One diagram, one concept
+- **Simplicity**: Avoid overcrowding - less is more
+- **Consistency**: Same styling and conventions across diagrams
+- **Purpose**: Every element should serve understanding
+- **Maintenance**: Easy to update as system evolves
 
 ---
 
 ## 📊 Diagram Types
 
-| Type              | Best For                                |
-| ----------------- | --------------------------------------- |
-| `flowchart`       | Processes, decision trees, workflows    |
-| `sequenceDiagram` | API calls, interactions, timing         |
-| `classDiagram`    | Object relationships, inheritance       |
-| `erDiagram`       | Database schemas, entity relationships  |
-| `stateDiagram-v2` | State machines, lifecycle               |
-| `gantt`           | Project timelines, milestones           |
-| `pie`             | Proportions, distributions              |
-| `gitGraph`        | Branch strategies, merges               |
-| `journey`         | User experience flows                   |
-| `C4Context`       | System architecture (with C4 extension) |
+- `flowchart`: Processes, decision trees, workflows
+- `sequenceDiagram`: API calls, interactions, timing
+- `classDiagram`: Object relationships, inheritance
+- `erDiagram`: Database schemas, entity relationships
+- `stateDiagram-v2`: State machines, lifecycle
+- `gantt`: Project timelines, milestones
+- `pie`: Proportions, distributions
+- `gitGraph`: Branch strategies, merges
+- `journey`: User experience flows
+- `C4Context`: System architecture (with C4 extension)
 
 ---
 
@@ -102,14 +108,12 @@ sequenceDiagram
 
 ### Arrow Types
 
-| Arrow   | Meaning                |
-| ------- | ---------------------- |
-| `->>`   | Solid with arrowhead   |
-| `-->`   | Dotted with arrowhead  |
-| `->>+`  | Activate lifeline      |
-| `-->>-` | Deactivate lifeline    |
-| `-x`    | Solid with X (failure) |
-| `--x`   | Dotted with X          |
+- `->>`: Solid with arrowhead
+- `-->`: Dotted with arrowhead
+- `->>+`: Activate lifeline
+- `-->>-`: Deactivate lifeline
+- `-x`: Solid with X (failure)
+- `--x`: Dotted with X
 
 ### Notes and Loops
 
@@ -177,12 +181,10 @@ erDiagram
 
 ### Relationship Symbols
 
-| Symbol | Meaning      |
-| ------ | ------------ | ----------- | ----------- |
-| `      |              | `           | Exactly one |
-| `o{`   | Zero or more |
-| `      | {`           | One or more |
-| `o     | `            | Zero or one |
+- `
+- `o{`: Zero or more
+- `: {`
+- `o: `
 
 ---
 
@@ -221,12 +223,10 @@ flowchart LR
     A --> B
 ```
 
-| Theme     | Best For                |
-| --------- | ----------------------- |
-| `default` | Light backgrounds       |
-| `dark`    | Dark mode documentation |
-| `forest`  | Calm, professional      |
-| `neutral` | Minimal, clean          |
+- `default`: Light backgrounds
+- `dark`: Dark mode documentation
+- `forest`: Calm, professional
+- `neutral`: Minimal, clean
 
 ### Custom Styling
 
@@ -245,23 +245,19 @@ flowchart TD
 
 ### Do's
 
-| Practice                | Why                              |
-| ----------------------- | -------------------------------- |
-| One concept per diagram | Clarity and focus                |
-| Use descriptive labels  | Self-documenting                 |
-| Consistent direction    | TD/LR - pick one and stick to it |
-| Group with subgraphs    | Visual organization              |
-| Use proper shapes       | Semantic meaning                 |
+- One concept per diagram: Clarity and focus
+- Use descriptive labels: Self-documenting
+- Consistent direction: TD/LR - pick one and stick to it
+- Group with subgraphs: Visual organization
+- Use proper shapes: Semantic meaning
 
 ### Don'ts
 
-| Anti-Pattern          | Problem                          |
-| --------------------- | -------------------------------- |
-| Too many nodes        | Overwhelming, hard to read       |
-| Long text in nodes    | Cluttered diagram                |
-| Crossing lines        | Confusing flow                   |
-| Inconsistent styling  | Unprofessional look              |
-| No legend when needed | Readers can't understand symbols |
+- Too many nodes: Overwhelming, hard to read
+- Long text in nodes: Cluttered diagram
+- Crossing lines: Confusing flow
+- Inconsistent styling: Unprofessional look
+- No legend when needed: Readers can't understand symbols
 
 ---
 
@@ -339,12 +335,10 @@ Before sharing a diagram:
 
 ## 🔗 Related Skills
 
-| Need                   | Skill                     |
-| ---------------------- | ------------------------- |
-| Architecture decisions | `architecture`            |
-| Database design        | `database-design`         |
-| API documentation      | `documentation-templates` |
-| Project planning       | `plan-writing`            |
+- Architecture decisions: `architecture`
+- Database design: `database-design`
+- API documentation: `documentation-templates`
+- Project planning: `plan-writing`
 
 ---
 

package/kits/coder/skills/mobile-design/SKILL.md

@@ -6,6 +6,18 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 
 # Mobile Design Patterns
 
+## ⚡ Quick Reference
+
+- **Touch targets**: 44×44pt iOS minimum · 48×48dp Android · Padding not just hit area
+- **Navigation**: Bottom tabs for primary (iOS) · Hamburger for secondary · Back gesture support
+- **Gestures**: Swipe-back iOS native · Pull-to-refresh for lists · Long press for contextual menus
+- **Performance**: 60fps animation · Cold start < 2s · Skeleton screens not spinners · Lazy load
+- **Keyboard**: `KeyboardAvoidingView` in RN · Scroll content up · Dismiss on background tap
+- **Safe areas**: Respect notch/Dynamic Island/home indicator · `SafeAreaView` / `useSafeAreaInsets`
+
+---
+
+
 > Design for thumbs, not mice. Every millisecond matters.
 
 ---
@@ -69,14 +81,8 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 
 ```
 +-----------------------------------+
-|           Hard to reach           |  <- Top 1/4
-|-----------------------------------|
-|                                   |
-|        Okay - may stretch         |  <- Middle
-|                                   |
-|-----------------------------------|
-|      ✅ Natural thumb zone        |  <- Bottom 1/3
-|         Primary actions           |
+- Okay - may stretch: <- Middle
+- ✅ Natural thumb zone: <- Bottom 1/3
 +-----------------------------------+
 ```
 
@@ -112,10 +118,8 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 
 ### Adaptive vs Responsive
 
-| Approach       | When to Use                    |
-| -------------- | ------------------------------ |
-| **Adaptive**   | Different layouts per platform |
-| **Responsive** | Same layout, flexible sizing   |
+- **Adaptive**: Different layouts per platform
+- **Responsive**: Same layout, flexible sizing
 
 ---
 
@@ -166,21 +170,17 @@ const colors = {
 
 ### 60fps Animation Rules
 
-| ❌ Don't                 | ✅ Do                      |
-| ------------------------ | -------------------------- |
-| Animate width/height     | Use transform: scale()     |
-| Animate left/top         | Use transform: translate() |
-| Animate during scroll    | Use native driver          |
-| Complex animations in JS | Use Reanimated/Worklets    |
+- Animate width/height: Use transform: scale()
+- Animate left/top: Use transform: translate()
+- Animate during scroll: Use native driver
+- Complex animations in JS: Use Reanimated/Worklets
 
 ### List Performance
 
-| Technique            | When to Use              |
-| -------------------- | ------------------------ |
-| **FlashList**        | Large lists (100+ items) |
-| **Virtualization**   | Any scrollable list      |
-| **Item memoization** | Complex item components  |
-| **Skeleton loading** | Initial data fetch       |
+- **FlashList**: Large lists (100+ items)
+- **Virtualization**: Any scrollable list
+- **Item memoization**: Complex item components
+- **Skeleton loading**: Initial data fetch
 
 ### Image Optimization
 
@@ -202,14 +202,12 @@ const colors = {
 
 ### States to Handle
 
-| State       | UI Pattern                      |
-| ----------- | ------------------------------- |
-| **Loading** | Skeleton or spinner             |
-| **Success** | Content display                 |
-| **Empty**   | Empty state with action         |
-| **Error**   | Error message + retry           |
-| **Offline** | Cached data + offline indicator |
-| **Syncing** | Subtle sync indicator           |
+- **Loading**: Skeleton or spinner
+- **Success**: Content display
+- **Empty**: Empty state with action
+- **Error**: Error message + retry
+- **Offline**: Cached data + offline indicator
+- **Syncing**: Subtle sync indicator
 
 ### Optimistic UI
 
@@ -225,24 +223,20 @@ User Action → Immediate UI Update → Background Sync
 
 ### Haptic Feedback
 
-| Type        | Use Case                   |
-| ----------- | -------------------------- |
-| **Light**   | UI selection               |
-| **Medium**  | Toggle, switch             |
-| **Heavy**   | Significant action         |
-| **Success** | Task completed             |
-| **Warning** | Destructive action confirm |
-| **Error**   | Failed action              |
+- **Light**: UI selection
+- **Medium**: Toggle, switch
+- **Heavy**: Significant action
+- **Success**: Task completed
+- **Warning**: Destructive action confirm
+- **Error**: Failed action
 
 ### Loading States
 
-| Duration | Pattern                      |
-| -------- | ---------------------------- |
-| < 100ms  | No indicator                 |
-| 100ms-1s | Inline spinner               |
-| 1s-3s    | Progress indicator           |
-| > 3s     | Progress + estimated time    |
-| Unknown  | Skeleton + content streaming |
+- < 100ms: No indicator
+- 100ms-1s: Inline spinner
+- 1s-3s: Progress indicator
+- > 3s: Progress + estimated time
+- Unknown: Skeleton + content streaming
 
 ---
 
@@ -280,25 +274,21 @@ User Action → Immediate UI Update → Background Sync
 
 ## ❌ Anti-Patterns
 
-| ❌ Don't                           | ✅ Do                               |
-| ---------------------------------- | ----------------------------------- |
-| Small tap targets (< 44pt)         | Minimum 44x44pt                     |
-| Important actions at screen top    | Primary actions in thumb zone       |
-| Hamburger menu for main navigation | Bottom tab bar                      |
-| Custom back button behavior        | Respect platform conventions        |
-| Infinite scroll without pagination | Load more or paginate               |
-| Text that doesn't scale            | Support Dynamic Type / Font Scaling |
+- Small tap targets (< 44pt): Minimum 44x44pt
+- Important actions at screen top: Primary actions in thumb zone
+- Hamburger menu for main navigation: Bottom tab bar
+- Custom back button behavior: Respect platform conventions
+- Infinite scroll without pagination: Load more or paginate
+- Text that doesn't scale: Support Dynamic Type / Font Scaling
 
 ---
 
 ## 🔗 Related Skills
 
-| Need                  | Skill                    |
-| --------------------- | ------------------------ |
-| React Native patterns | `react-native-patterns`  |
-| Flutter patterns      | `flutter-patterns`       |
-| Accessibility         | `accessibility-patterns` |
-| Performance profiling | `performance-profiling`  |
+- React Native patterns: `react-native-patterns`
+- Flutter patterns: `flutter-patterns`
+- Accessibility: `accessibility-patterns`
+- Performance profiling: `performance-profiling`
 
 ---
 

package/kits/coder/skills/monitoring-observability/SKILL.md

@@ -7,19 +7,27 @@ version: 2.0
 
 # Monitoring & Observability - SRE Patterns
 
-> **Philosophy:** Observability is not about collecting metrics—it's about understanding system behavior.
+## ⚡ Quick Reference
+
+- **3 pillars**: Metrics (trends) · Logs (events) · Traces (distributed request flow)
+- **Alert tiers**: Critical (< 5min) · High (< 15min) · Medium (< 1hr) · Low (next day)
+- **SLOs**: Define before shipping · P99 latency · Error rate · Availability goals
+- **Logs**: Structured JSON always · Include request ID + tenant ID · No PII in logs
+- **Health checks**: /health (liveness) + /ready (readiness) · Check DB/Redis/deps
+- **Avoid**: Alert fatigue (too many low-value alerts) · Log PII · Monitor without alerting
+
+---
+
 
 ---
 
 ## When to Use This Skill
 
-| ✅ Use                           | ❌ Don't Use                    |
-| -------------------------------- | ------------------------------- |
-| Designing monitoring systems     | Single ad-hoc dashboard         |
-| Defining SLI/SLO/SLA             | Application feature development |
-| Configuring alerting strategy    | Local development debugging     |
-| Building observability pipelines | No access to telemetry data     |
-| Incident response workflow       | Static reporting only           |
+- Designing monitoring systems: Single ad-hoc dashboard
+- Defining SLI/SLO/SLA: Application feature development
+- Configuring alerting strategy: Local development debugging
+- Building observability pipelines: No access to telemetry data
+- Incident response workflow: Static reporting only
 
 ---
 
@@ -219,13 +227,11 @@ groups:
 
 ### Reducing Alert Noise
 
-| Problem          | Solution                             |
-| ---------------- | ------------------------------------ |
-| Flapping alerts  | Increase `for` duration              |
-| Too many alerts  | Alert on SLOs, not individual causes |
-| Duplicate alerts | Use `group_by` and aggregation       |
-| Weekend pages    | Time-based routing, error budgets    |
-| Alert storms     | Implement alerting hierarchy         |
+- Flapping alerts: Increase `for` duration
+- Too many alerts: Alert on SLOs, not individual causes
+- Duplicate alerts: Use `group_by` and aggregation
+- Weekend pages: Time-based routing, error budgets
+- Alert storms: Implement alerting hierarchy
 
 ---
 
@@ -417,15 +423,13 @@ async function processOrder(orderId: string) {
 
 ## Anti-Patterns
 
-| ❌ Don't                        | ✅ Do                               |
-| ------------------------------- | ----------------------------------- |
-| Alert on causes (CPU, memory)   | Alert on symptoms (latency, errors) |
-| Log everything at INFO          | Use appropriate log levels          |
-| Unstructured log messages       | JSON structured logging             |
-| Alert without runbook           | Every alert has a runbook           |
-| Collect metrics without purpose | Define SLIs first, then instrument  |
-| Secret values in logs           | Redact sensitive data               |
-| High-cardinality labels         | Bounded label values                |
+- Alert on causes (CPU, memory): Alert on symptoms (latency, errors)
+- Log everything at INFO: Use appropriate log levels
+- Unstructured log messages: JSON structured logging
+- Alert without runbook: Every alert has a runbook
+- Collect metrics without purpose: Define SLIs first, then instrument
+- Secret values in logs: Redact sensitive data
+- High-cardinality labels: Bounded label values
 
 ---
 
@@ -446,12 +450,10 @@ Before production:
 
 ## Related Skills
 
-| Need                | Skill                   |
-| ------------------- | ----------------------- |
-| Kubernetes ops      | `kubernetes-patterns`   |
-| CI/CD pipelines     | `github-actions`        |
-| Performance tuning  | `performance-profiling` |
-| Security monitoring | `security-fundamentals` |
+- Kubernetes ops: `kubernetes-patterns`
+- CI/CD pipelines: `github-actions`
+- Performance tuning: `performance-profiling`
+- Security monitoring: `security-fundamentals`
 
 ---
 

package/kits/coder/skills/multi-tenancy/SKILL.md

@@ -7,7 +7,17 @@ tags: [architecture, saas, isolation, tenancy, compliance]
 
 # Multi-Tenancy - SaaS Architecture Skill
 
-> **Purpose:** Enable AI agents to design and implement robust multi-tenant systems with proper isolation, context propagation, and scalability.
+## ⚡ Quick Reference
+
+- **Isolation levels**: Shared DB + RLS (startup) · Schema-per-tenant (1000+) · DB-per-tenant (enterprise/HIPAA)
+- **Tenant resolution**: Early in middleware · validate → cache (Redis with TTL) → attach to request context
+- **Data access**: EVERY query filters by `tenant_id` · RLS as second layer · Never trust client-provided tenant ID
+- **Context propagation**: HTTP → Service → Queue → Worker → DB · AsyncLocalStorage (Node.js)
+- **Cache isolation**: All keys prefixed `tenant:{id}:` · Separate Redis DB index for critical isolation
+- **Audit**: Log all cross-tenant boundary access · Rate limit per tenant · No global unfiltered queries
+
+---
+
 
 ---
 
@@ -26,13 +36,11 @@ tags: [architecture, saas, isolation, tenancy, compliance]
 
 > **"Multi-tenancy is trust architecture—design for distrust, verify always."**
 
-| Principle                  | Implementation                               |
-| -------------------------- | -------------------------------------------- |
-| **Defense in Depth**       | Multiple isolation layers (app + DB + infra) |
-| **Context Everywhere**     | Tenant ID flows through every layer          |
-| **Fail Closed**            | Missing tenant context = deny access         |
-| **Explicit Over Implicit** | Never infer tenant, always verify            |
-| **Audit Everything**       | Log all cross-boundary access                |
+- **Defense in Depth**: Multiple isolation layers (app + DB + infra)
+- **Context Everywhere**: Tenant ID flows through every layer
+- **Fail Closed**: Missing tenant context = deny access
+- **Explicit Over Implicit**: Never infer tenant, always verify
+- **Audit Everything**: Log all cross-boundary access
 
 ---
 

package/kits/coder/skills/nodejs-best-practices/SKILL.md

@@ -6,10 +6,19 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 
 # Node.js Best Practices
 
-> JavaScript on the server, done right.
+## ⚡ Quick Reference
+
+- **Async**: Always `async/await` · Never blocking I/O in hot paths · `Promise.all()` for parallel
+- **Error handling**: `try/catch` in all async · Unhandled rejection → exit process · Typed custom errors
+- **Event loop**: No sync fs/crypto/heavy compute · Offload to worker threads or background jobs
+- **Config**: `dotenv` for local · env vars always · validate with `zod` on startup · never commit `.env`
+- **Logging**: `pino` (fast, structured JSON) · Correlation IDs · No console.log in production
+- **Security**: `helmet` always · `express-rate-limit` · Validate all inputs (zod) · CORS configured strictly
 
 ---
 
+
+
 ## Core Principles
 
 1. **Async by default** - Never block the event loop
@@ -21,12 +30,10 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 
 ## 🔧 Framework Selection
 
-| Framework   | Best For                    |
-| ----------- | --------------------------- |
-| **Express** | Simple APIs, custom needs   |
-| **Fastify** | Performance, schema-first   |
-| **NestJS**  | Enterprise, DDD, TypeScript |
-| **Hono**    | Edge runtime, lightweight   |
+- **Express**: Simple APIs, custom needs
+- **Fastify**: Performance, schema-first
+- **NestJS**: Enterprise, DDD, TypeScript
+- **Hono**: Edge runtime, lightweight
 
 ---
 
@@ -202,13 +209,11 @@ logger.error({ err, requestId }, "Request failed");
 
 ## ❌ Anti-Patterns
 
-| Don't                          | Do                          |
-| ------------------------------ | --------------------------- |
-| `async` without error handling | Wrap with asyncHandler      |
-| Callback APIs                  | Promisify or use async libs |
-| `console.log` in production    | Structured logging          |
-| Sync file operations           | Use async fs methods        |
-| Throwing strings               | Custom Error classes        |
+- `async` without error handling: Wrap with asyncHandler
+- Callback APIs: Promisify or use async libs
+- `console.log` in production: Structured logging
+- Sync file operations: Use async fs methods
+- Throwing strings: Custom Error classes
 
 ---
 

package/kits/coder/skills/performance-profiling/SKILL.md

@@ -6,7 +6,17 @@ allowed-tools: Read, Edit, Glob, Grep, Bash
 
 # Performance Profiling - Measure First, Optimize Second
 
-> **Philosophy:** Never optimize without data. Gut feelings about performance are usually wrong.
+## ⚡ Quick Reference
+
+- **Measure first**: Profile before optimizing · No gut feelings · `console.time()` / Chrome DevTools / clinic.js
+- **Core Web Vitals**: LCP < 2.5s · FID/INP < 200ms · CLS < 0.1 · Check with Lighthouse
+- **Frontend**: Lazy load images/routes · Eliminate render-blocking resources · Bundle splitting · `preconnect` for external
+- **Backend**: EXPLAIN ANALYZE for slow queries · Connection pooling · Response caching (Redis) · Pagination
+- **Node.js**: Event loop not blocked · Avoid sync fs in hot paths · `--prof` for CPU profiling
+- **Priority**: Fix worst P99 first · Cache before compute · Network before CPU
+
+---
+
 
 ---
 
@@ -204,12 +214,10 @@ npx webpack-bundle-analyzer dist/stats.json
 ```
 
 **Solutions:**
-| Problem | Solution |
-| ------- | -------- |
-| Large library | Use lighter alternative (date-fns vs moment) |
-| Unused exports | Enable tree shaking |
-| One big bundle | Code split by route |
-| Duplicate dependencies | Dedupe in package manager |
+- Large library: Use lighter alternative (date-fns vs moment)
+- Unused exports: Enable tree shaking
+- One big bundle: Code split by route
+- Duplicate dependencies: Dedupe in package manager
 
 ### Memory Leaks
 
@@ -220,12 +228,10 @@ npx webpack-bundle-analyzer dist/stats.json
 - OutOfMemory errors in production
 
 **Common Causes:**
-| Cause | Solution |
-| ----- | -------- |
-| Event listeners not removed | Cleanup in useEffect/componentWillUnmount |
-| Growing global arrays/maps | Use WeakMap/WeakSet or bounded caches |
-| Closures holding references | Break reference chains |
-| Uncleared timers | clearTimeout/clearInterval |
+- Event listeners not removed: Cleanup in useEffect/componentWillUnmount
+- Growing global arrays/maps: Use WeakMap/WeakSet or bounded caches
+- Closures holding references: Break reference chains
+- Uncleared timers: clearTimeout/clearInterval
 
 ---
 
@@ -273,16 +279,14 @@ const throttledScroll = throttle(handleScroll, 100);
 
 ## 🚨 Anti-Patterns
 
-| ❌ Don't                          | ✅ Do                                      |
-| --------------------------------- | ------------------------------------------ |
-| Optimize without measuring        | Profile first, then optimize               |
-| Premature optimization            | Focus on correctness, then performance     |
-| Optimize cold paths               | Focus on hot paths (frequently executed)   |
-| Micro-optimize trivial code       | Target the biggest bottleneck              |
-| Cache everything                  | Cache strategically, consider invalidation |
-| Load everything upfront           | Lazy load non-critical resources           |
-| Block main thread with heavy work | Use web workers, async processing          |
-| Ignore p99 latency                | p99 affects real users, not just averages  |
+- Optimize without measuring: Profile first, then optimize
+- Premature optimization: Focus on correctness, then performance
+- Optimize cold paths: Focus on hot paths (frequently executed)
+- Micro-optimize trivial code: Target the biggest bottleneck
+- Cache everything: Cache strategically, consider invalidation
+- Load everything upfront: Lazy load non-critical resources
+- Block main thread with heavy work: Use web workers, async processing
+- Ignore p99 latency: p99 affects real users, not just averages
 
 ---
 
@@ -321,12 +325,10 @@ const throttledScroll = throttle(handleScroll, 100);
 
 ## 🔗 Related Skills
 
-| Need                  | Skill                  |
-| --------------------- | ---------------------- |
-| Frontend optimization | `react-best-practices` |
-| Database optimization | `database-design`      |
-| Testing performance   | `testing-patterns`     |
-| Clean efficient code  | `clean-code`           |
+- Frontend optimization: `react-best-practices`
+- Database optimization: `database-design`
+- Testing performance: `testing-patterns`
+- Clean efficient code: `clean-code`
 
 ---