imhcode 1.0.0

package/skills/radix-ui-primitives/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: radix-ui-primitives
+description: >-
+  Radix UI headless primitives for accessible, unstyled UI components. Covers
+  Dialog, Dropdown, Popover, Tooltip, Tabs, Accordion, and custom compositions.
+---
+
+# Radix UI Primitives
+
+## Overview
+
+Radix Primitives are unstyled, accessible UI component building blocks. They handle complex interactions (focus management, keyboard navigation, ARIA attributes) so you can focus on styling and composition.
+
+## When to Use
+
+- Building custom design systems from scratch
+- Needing WAI-ARIA compliant components without opinions on styling
+- Creating complex interactive patterns (modals, dropdown menus, comboboxes)
+- Working alongside Tailwind CSS or any CSS framework
+
+## Core Primitives
+
+### Dialog (Modal)
+
+```tsx
+import * as Dialog from "@radix-ui/react-dialog"
+
+export function Modal({ children, trigger }) {
+  return (
+    <Dialog.Root>
+      <Dialog.Trigger asChild>{trigger}</Dialog.Trigger>
+      <Dialog.Portal>
+        <Dialog.Overlay className="fixed inset-0 bg-black/50 backdrop-blur-sm" />
+        <Dialog.Content className="fixed left-1/2 top-1/2 -translate-x-1/2 -translate-y-1/2 bg-white rounded-lg p-6 shadow-xl">
+          <Dialog.Title className="text-lg font-semibold">Title</Dialog.Title>
+          <Dialog.Description className="text-sm text-gray-500">Description</Dialog.Description>
+          {children}
+          <Dialog.Close asChild>
+            <button aria-label="Close">×</button>
+          </Dialog.Close>
+        </Dialog.Content>
+      </Dialog.Portal>
+    </Dialog.Root>
+  )
+}
+```
+
+### Dropdown Menu
+
+```tsx
+import * as DropdownMenu from "@radix-ui/react-dropdown-menu"
+
+<DropdownMenu.Root>
+  <DropdownMenu.Trigger asChild>
+    <button>Options</button>
+  </DropdownMenu.Trigger>
+  <DropdownMenu.Portal>
+    <DropdownMenu.Content sideOffset={5} className="bg-white rounded-md shadow-lg p-1">
+      <DropdownMenu.Item className="cursor-pointer px-2 py-1.5 rounded hover:bg-gray-100">
+        Edit
+      </DropdownMenu.Item>
+      <DropdownMenu.Separator className="h-px bg-gray-200 my-1" />
+      <DropdownMenu.Item className="cursor-pointer px-2 py-1.5 rounded text-red-600 hover:bg-red-50">
+        Delete
+      </DropdownMenu.Item>
+    </DropdownMenu.Content>
+  </DropdownMenu.Portal>
+</DropdownMenu.Root>
+```
+
+## Guidelines
+
+1. **Always use `asChild`** when wrapping custom trigger elements
+2. **Always include `Dialog.Title`** for screen reader accessibility
+3. **Use `Portal`** for overlays to avoid z-index stacking issues
+4. **Handle focus trapping** — Radix does this automatically, don't override
+5. **Compose primitives** — combine Popover + Command for Combobox patterns
+6. **Style with data attributes** — Radix exposes `data-state`, `data-side`, `data-orientation`
+
+## Anti-Patterns
+
+- ❌ Removing `Dialog.Title` (breaks screen readers)
+- ❌ Not using `Portal` for floating elements
+- ❌ Overriding Radix's built-in focus management
+- ❌ Using `onClick` on `Trigger` instead of Radix's built-in toggle
+- ❌ Nesting Dialogs without proper scope management

package/skills/react-native-best-practices/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: react-native-best-practices
+description: React Native best practices for performance, list rendering, animations, architecture, profiling, and app sizing.
+---
+
+# React Native Best Practices
+
+## Overview
+
+High-performance, production-ready React Native development guidelines to build fluid, 60fps applications across iOS and Android. This covers rendering optimization, thread management, and bundling efficiency.
+
+## 1. Thread and Rendering Optimization
+
+- **JS vs. UI Thread**: Keep the JS thread free of expensive synchronous operations. Offload animations to the native UI thread.
+- **Memoization**: Prevent unnecessary re-renders using `React.memo`, `useMemo`, and `useCallback` for expensive components, calculations, and callbacks passed as props.
+- **Hermes Engine**: Always enable the Hermes JavaScript engine in `android/app/build.gradle` and `ios/Podfile` for faster startup and lower memory footprint.
+
+## 2. List Rendering Performance (FlatList / FlashList)
+
+- **Do NOT**: Use anonymous arrow functions or inline objects in render props (e.g., `renderItem={({ item }) => <View ... />}`). These create new function instances every render.
+- **Do**: Extract `renderItem` and `keyExtractor` to standalone functions or memoized callbacks.
+- **Optimizations**:
+  - `initialNumToRender`: Keep it small (e.g., 5-10) to speed up initial mount.
+  - `maxToRenderPerBatch`: Set conservatively to prevent blocking the main thread.
+  - `windowSize`: Set to a moderate value (e.g., 5 or 7) to limit memory overhead of off-screen items.
+  - `getItemLayout`: Implement if items have a fixed height to bypass dynamic measurement passes.
+
+```typescript
+import React, { useCallback } from 'react';
+import { FlatList, StyleSheet, Text, View } from 'react-native';
+
+const ListItem = React.memo(({ title }: { title: string }) => (
+  <View style={styles.item}>
+    <Text>{title}</Text>
+  </View>
+));
+
+export function OptimizedList({ data }: { data: Array<{ id: string; title: string }> }) {
+  const renderItem = useCallback(({ item }: { item: { title: string } }) => (
+    <ListItem title={item.title} />
+  ), []);
+
+  const keyExtractor = useCallback((item: { id: string }) => item.id, []);
+
+  return (
+    <FlatList
+      data={data}
+      renderItem={renderItem}
+      keyExtractor={keyExtractor}
+      initialNumToRender={10}
+      maxToRenderPerBatch={10}
+      windowSize={5}
+      getItemLayout={(data, index) => ({
+        length: 60,
+        offset: 60 * index,
+        index,
+      })}
+    />
+  );
+}
+
+const styles = StyleSheet.create({
+  item: {
+    height: 60,
+    justifyContent: 'center',
+    paddingHorizontal: 16,
+    borderBottomWidth: 1,
+    borderBottomColor: '#eee',
+  },
+});
+```
+
+## 3. Styling & Layout
+
+- **Stylesheet.create**: Always use `StyleSheet.create` instead of inline styles. Inline styles recreate object references on every render, triggering child re-renders.
+- **Flexbox**: Prefer Flexbox for layouts rather than absolute positioning where possible to ensure clean responsive scaling.
+- **Safe Area**: Wrap top-level layouts in `SafeAreaView` from `react-native-safe-area-context`.
+
+## 4. Resource and Asset Optimization
+
+- **FastImage**: Use `react-native-fast-image` instead of the default `Image` component for aggressive disk/memory caching and flickering elimination.
+- **Vector Graphics**: Use SVG icons (`react-native-svg` and `react-native-svg-transformer`) rather than heavy PNG assets to reduce bundle size.
+- **Bundle Analysis**: Use React Native Bundle Visualizer (`react-native-bundle-visualizer`) to identify large dependencies and optimize code-splitting.

package/skills/react-native-brownfield-migration/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: react-native-brownfield-migration
+description: Incremental migration strategy to adopt React Native or Expo in native apps with setup, packaging, and integration steps.
+---
+
+# React Native Brownfield Migration
+
+## Overview
+
+Brownfield integration allows developers to incrementally embed React Native views or features into an existing native iOS or Android application. This reduces migration risk and allows teams to share components without rewriting the entire host application.
+
+## 1. Architecture Strategy
+
+- **Shared Bridge**: Instantiate a single, global `RCTBridge` (iOS) or `ReactInstanceManager` (Android) and reuse it across multiple screens to save startup time and memory.
+- **Micro-Frontends**: Design separate React components as distinct entry points registered via `AppRegistry.registerComponent`.
+- **Cross-Platform Communication**: Use native modules (`RCTEventEmitter` or Custom Modules) to pass events and data boundaries between Native host view controllers and React Native views.
+
+## 2. iOS Integration
+
+### Podfile Setup
+
+Add React Native dependencies to your native iOS `Podfile`:
+
+```ruby
+platform :ios, '15.0'
+
+require_relative '../node_modules/react-native/scripts/react_native_pods'
+require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
+
+target 'MyNativeApp' do
+  use_react_native!(
+    :path => "../node_modules/react-native",
+    :hermes_enabled => true
+  )
+end
+```
+
+### RCTRootView Initialization
+
+```objc
+// SharedBridgeManager.h
+#import <React/RCTBridge.h>
+
+@interface SharedBridgeManager : NSObject
++ (instancetype)sharedInstance;
+@property (nonatomic, strong) RCTBridge *bridge;
+@end
+
+// EmbeddedViewController.m
+#import "SharedBridgeManager.h"
+#import <React/RCTRootView.h>
+
+@implementation EmbeddedViewController
+- (void)viewDidLoad {
+    [super viewDidLoad];
+    
+    RCTBridge *bridge = [SharedBridgeManager sharedInstance].bridge;
+    RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
+                                                    moduleName:@"MyEmbeddedFeature"
+                                             initialProperties:@{@"tenantId": @"123"}];
+    rootView.frame = self.view.bounds;
+    [self.view addSubview:rootView];
+}
+@end
+```
+
+## 3. Android Integration
+
+### Gradle Configuration
+
+Configure your native `settings.gradle` and `app/build.gradle`:
+
+```groovy
+// settings.gradle
+includeBuild('../node_modules/@react-native/gradle-plugin')
+
+// app/build.gradle
+apply plugin: "com.facebook.react"
+
+dependencies {
+    implementation("com.facebook.react:react-android")
+    implementation("com.facebook.react:hermes-android")
+}
+```
+
+### ReactRootView Setup
+
+```java
+public class EmbeddedFragment extends Fragment {
+    private ReactRootView mReactRootView;
+    private ReactInstanceManager mReactInstanceManager;
+
+    @Override
+    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
+        mReactRootView = new ReactRootView(getContext());
+        mReactInstanceManager = ((MainApplication) getActivity().getApplication()).getReactInstanceManager();
+        
+        Bundle initialProperties = new Bundle();
+        initialProperties.putString("tenantId", "123");
+        
+        mReactRootView.startReactApplication(
+            mReactInstanceManager,
+            "MyEmbeddedFeature",
+            initialProperties
+        );
+        return mReactRootView;
+    }
+}
+```
+
+## 4. Best Practices
+
+1. **Pre-warm the Bridge**: Initialize the react bridge early in the native application lifecycle (e.g., `AppDelegate` or `Application.onCreate()`) to eliminate view load delays.
+2. **Handle Back Press**: Wire Android's native back button dispatch to React Native's back handler using the `ReactInstanceManager` hooks.
+3. **Memory management**: Unmount and release `ReactRootView` instances when views are popped from the navigation stack to avoid native memory leaks.

package/skills/react-spring-physics/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: react-spring-physics
+description: react spring physics — loaded from design-skills plugin
+source: design-skills-plugin
+---
+# React Spring Physics
+
+> **Plugin Skill**: This skill is provided by the `design-skills` plugin. When available, read the full skill from the plugin directory. When not available, use the agent's embedded knowledge of react spring physics patterns.

package/skills/react-three-fiber/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: react-three-fiber
+description: react three fiber — loaded from design-skills plugin
+source: design-skills-plugin
+---
+# React Three Fiber
+
+> **Plugin Skill**: This skill is provided by the `design-skills` plugin. When available, read the full skill from the plugin directory. When not available, use the agent's embedded knowledge of react three fiber patterns.

package/skills/recsys-pipeline-architect/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: recsys-pipeline-architect
+description: Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm. Use this skill whenever the user is building any system that picks "the top K items for a (user, context)" — social feeds, content CMSs, RAG rerankers, task prioritizers, notification triage, search reranking, ad ranking.
+origin: community
+---
+
+# recsys-pipeline-architect
+
+A spec-and-scaffold skill for building composable recommendation, ranking, and feed pipelines. It encodes the **six-stage pattern** — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularized by xAI's open-sourced [For You algorithm](https://github.com/xai-org/x-algorithm) (Apache 2.0). This skill is an independent reimplementation of the pattern (MIT) — no code copied from the original.
+
+Upstream: <https://github.com/mturac/recsys-pipeline-architect>
+
+## When to Use
+
+- User wants to build any system that picks "the top K items for a user/context"
+- User asks "how should I rank X" or describes a feed/personalization problem
+- User has a scoring function and needs the pipeline plumbing around it
+- User wants to migrate from a single relevance score to multi-action prediction with tunable weights
+- User is wrapping an LLM/ML scorer and needs filters, hydrators, side-effects, and a runnable scaffold in their stack (TypeScript / Go / Python)
+- Triggers: "recommendation system", "feed algorithm", "ranking pipeline", "for you feed", "candidate pipeline", "content recommender", "pipeline architecture for recsys", "RAG retrieval reranker"
+
+## When NOT to Use
+
+- Model architecture work (transformer design, two-tower retrieval, embedding training) — this skill is plumbing *around* the model, not the model itself
+- Pure ML training pipelines — the scoring function is the user's responsibility
+- Operating a deployed pipeline (monitoring, autoscaling) — out of scope
+
+## The six-stage framework
+
+| # | Stage | Job | Parallel? |
+|---|---|---|---|
+| 1 | **Source** | Fetch candidates from one or more origins | Yes — multiple sources run in parallel |
+| 2 | **Hydrator** | Enrich each candidate with metadata needed for filtering and scoring | Yes — independent hydrators run in parallel |
+| 3 | **Filter** | Drop candidates that should never be shown (blocked, expired, duplicate, ineligible) | Sequential — each filter sees fewer items |
+| 4 | **Scorer** | Assign each surviving candidate one or more scores | Sequential — later scorers see earlier scores |
+| 5 | **Selector** | Sort by final score, return top K | Single op |
+| 6 | **SideEffect** | Cache served IDs, log impressions, emit events, update counters | Async — must never block the response |
+
+### Why this exact order
+
+- Sources before hydration: know what candidates exist before paying to enrich them
+- Hydration before filtering: many filters need metadata the source did not provide
+- Filtering before scoring: scoring is the expensive stage; drop the ineligible first
+- Scorer chain (not single scorer): real systems compose ML scoring + diversity reranking + business rules
+- Selector after scoring: keeps scoring deterministic and cacheable
+- SideEffects last and async: side effects must never block the user response
+
+## Workflow when invoked
+
+Walk the user through these eight steps:
+
+1. **Clarify the use case** (one round, three questions): items being ranked? input context? language/runtime?
+2. **Identify the candidate sources**: usually in-network (followed/owned/subscribed) + out-of-network (ML retrieval / trending / similar-to-liked)
+3. **List required hydrations**: for each filter and scorer, what data does it need that the source did not provide?
+4. **List the filters**: duplicate, self, age, block/mute, previously-served, eligibility. Order matters — cheap before expensive.
+5. **Design the scorer chain**: primary (ML) → combiner (multi-action with weights) → diversity → business rules
+6. **Selector**: sort descending by final score, take top K (or stratified mix for in-network/out-of-network)
+7. **SideEffects**: cache served IDs, emit impression events, update counters, log analytics — all fire-and-forget
+8. **Generate the scaffold** in the user's stack
+
+## Key trade-offs to surface (don't default silently)
+
+### 1. Single score vs multi-action prediction
+
+- **Single score**: train one model to predict relevance. To change behavior → retrain.
+- **Multi-action**: predict `P(action)` for many actions (read, like, share, skip, report), combine with weights at serving time. To change behavior → change weights. No retraining.
+
+The X For You system uses multi-action with both positive and negative weights. Recommend multi-action when the user expects to tune frequently.
+
+### 2. Candidate isolation in scoring
+
+- **Isolated**: each candidate scored independently. Deterministic, cacheable.
+- **Joint**: candidates attend to each other during scoring (e.g., transformer over batch). More expressive but non-deterministic across batches.
+
+Default to isolation. Joint only when there's a specific reason (e.g., explicit batch-aware diversity).
+
+### 3. Online vs offline
+
+- **Request-time (online)**: pipeline runs on each request. Latency budget: 100–300ms. Default.
+- **Pre-computed (offline batch)**: pipeline runs periodically, results cached. Lower latency, lower freshness.
+- **Hybrid**: candidate retrieval offline, ranking online.
+
+## Hard rules
+
+1. **Do not invent benchmark numbers.** "How much faster?" → "depends on workload, run it yourself."
+2. **Attribution discipline.** When the pattern is referenced, attribute as "popularized by xAI's open-sourced For You algorithm" / `github.com/xai-org/x-algorithm` (Apache 2.0).
+3. **No trademark use.** Do not name the user's artifact "X-like" or use "For You" branding. Pattern is free; brand is not. Suggested naming: "candidate pipeline", "feed pipeline", "ranking pipeline", "recsys pipeline".
+4. **Surface trade-offs.** Multi-action vs single, isolation vs joint, online vs offline — never default silently.
+5. **The generated scaffold must run.** No pseudocode passing as code.
+6. **Filter order matters.** Cheap before expensive. Universal before user-specific.
+7. **Side effects never block.** Wrap in fire-and-forget patterns (goroutines / promises without await / asyncio tasks).
+
+## Anti-Patterns
+
+- Scoring before filtering (wastes compute on candidates that will be dropped anyway)
+- Synchronous side effects (cache writes / impression emits blocking the response)
+- A single "relevance" score when the product needs to tune for multiple objectives (engagement vs safety vs diversity vs ads)
+- Joint scoring as default (non-deterministic, harder to cache, doesn't compose with reranking stages)
+- Generating pseudocode "for illustration" — the scaffold must actually run
+
+## Upstream contents
+
+The upstream repository at <https://github.com/mturac/recsys-pipeline-architect> ships:
+
+- Full `SKILL.md` with the complete 8-step workflow
+- 5 load-on-demand reference docs: interfaces in 4 languages (TS/Go/Python/Rust), multi-action scoring pattern, candidate isolation, filter cookbook (12 patterns), scorer cookbook (weighted sum, MMR, diversity penalty, position debiasing)
+- 3 runnable example scaffolds, every one green on its test suite:
+  - Strapi v5 plugin (TypeScript / Jest — 3/3 pass)
+  - Zentra-compatible pipeline (Go with generics — 3/3 pass)
+  - PMAI task prioritizer (Python / FastAPI / pytest — 3/3 pass)
+- v0.1.0 release tagged
+- MIT license; pattern attributed to xAI X For You algorithm (Apache 2.0)
+
+Install via skills.sh: `npx skills add mturac/recsys-pipeline-architect`