@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/react-native-callstack/references/navigation-patterns.md

@@ -1,206 +0,0 @@
-# Navigation Patterns
-
-Load this when setting up React Navigation, configuring deep linking, or implementing complex navigation flows in React Native.
-
-## Navigator Selection
-
-| Navigator | Use When | Key Trait |
-|-----------|----------|-----------|
-| Native Stack | Most screen transitions | Native platform animations, best performance |
-| Stack | Custom transition animations needed | JS-driven animations, more customizable |
-| Bottom Tabs | 3-5 primary sections | Persistent tab bar, each tab keeps its state |
-| Material Top Tabs | Swipeable content sections | Gesture-driven tab switching |
-| Drawer | Side menu navigation | Slide-out navigation panel |
-
-## Type-Safe Navigation
-
-### Defining the Param List
-
-```typescript
-export type RootStackParamList = {
-  Home: undefined;
-  Profile: { userId: string };
-  Settings: undefined;
-  EditProfile: { userId: string; field?: 'name' | 'avatar' };
-};
-```
-
-- `undefined` means the screen takes no parameters.
-- Optional params use `?` in the type.
-- Always export the param list for use in screen props.
-
-### Global Type Declaration
-
-```typescript
-declare global {
-  namespace ReactNavigation {
-    interface RootParamList extends RootStackParamList {}
-  }
-}
-```
-
-This enables type-safe `useNavigation()` from any component without passing the type parameter.
-
-### Typed Screen Props
-
-```typescript
-import { NativeStackScreenProps } from '@react-navigation/native-stack';
-
-type ProfileScreenProps = NativeStackScreenProps<RootStackParamList, 'Profile'>;
-
-function ProfileScreen({ route, navigation }: ProfileScreenProps) {
-  const { userId } = route.params; // type-safe: string
-  navigation.navigate('EditProfile', { userId }); // type-checked
-}
-```
-
-## Nested Navigators
-
-### Tabs Inside Stack
-
-```typescript
-export type RootStackParamList = {
-  MainTabs: NavigatorScreenParams<TabParamList>;
-  Modal: { title: string };
-};
-
-export type TabParamList = {
-  Feed: undefined;
-  Search: undefined;
-  Profile: undefined;
-};
-```
-
-Navigate to a nested screen:
-
-```typescript
-navigation.navigate('MainTabs', {
-  screen: 'Profile',
-});
-```
-
-### Accessing Parent Navigator
-
-```typescript
-import { useNavigation, CompositeScreenProps } from '@react-navigation/native';
-
-// Combine tab props with parent stack props
-type Props = CompositeScreenProps<
-  BottomTabScreenProps<TabParamList, 'Feed'>,
-  NativeStackScreenProps<RootStackParamList>
->;
-
-function FeedScreen({ navigation }: Props) {
-  // Can navigate to both tab and stack screens
-  navigation.navigate('Modal', { title: 'Hello' });
-}
-```
-
-## Deep Linking
-
-### Configuration
-
-```typescript
-const linking: LinkingOptions<RootStackParamList> = {
-  prefixes: ['myapp://', 'https://app.example.com'],
-  config: {
-    screens: {
-      MainTabs: {
-        screens: {
-          Feed: 'feed',
-          Profile: 'profile/:userId',
-        },
-      },
-      Modal: 'modal/:title',
-    },
-  },
-};
-```
-
-### Universal Links (iOS)
-
-Requires Associated Domains entitlement and an `apple-app-site-association` file on your server.
-
-```json
-{
-  "applinks": {
-    "apps": [],
-    "details": [
-      {
-        "appID": "TEAM_ID.com.example.app",
-        "paths": ["/profile/*", "/feed"]
-      }
-    ]
-  }
-}
-```
-
-### App Links (Android)
-
-Requires intent filter in AndroidManifest.xml and a `.well-known/assetlinks.json` on your server.
-
-```xml
-<intent-filter android:autoVerify="true">
-  <action android:name="android.intent.action.VIEW" />
-  <category android:name="android.intent.category.DEFAULT" />
-  <category android:name="android.intent.category.BROWSABLE" />
-  <data android:scheme="https" android:host="app.example.com" />
-</intent-filter>
-```
-
-## Navigation State Persistence
-
-```typescript
-const [isReady, setIsReady] = useState(false);
-const [initialState, setInitialState] = useState();
-
-useEffect(() => {
-  AsyncStorage.getItem('NAV_STATE').then((state) => {
-    if (state) setInitialState(JSON.parse(state));
-    setIsReady(true);
-  });
-}, []);
-
-if (!isReady) return null;
-
-<NavigationContainer
-  initialState={initialState}
-  onStateChange={(state) => {
-    AsyncStorage.setItem('NAV_STATE', JSON.stringify(state));
-  }}
->
-```
-
-- Useful for restoring the user's position after app background/kill.
-- Do not persist state in production if your navigation structure changes between versions. Guard with a version check.
-
-## Auth Flow Pattern
-
-```typescript
-function RootNavigator() {
-  const { isLoggedIn, isLoading } = useAuth();
-
-  if (isLoading) return <SplashScreen />;
-
-  return (
-    <Stack.Navigator>
-      {isLoggedIn ? (
-        <Stack.Screen name="Main" component={MainNavigator} />
-      ) : (
-        <Stack.Screen name="Auth" component={AuthNavigator} />
-      )}
-    </Stack.Navigator>
-  );
-}
-```
-
-- Conditional rendering ensures the user cannot navigate back to auth screens after login.
-- React Navigation handles the transition animation automatically.
-
-## Performance Considerations
-
-- Use `native-stack` over `stack` for native animations that do not block the JS thread.
-- Set `detachInactiveScreens: true` (default) to free memory for off-screen tabs.
-- Use `freezeOnBlur: true` on tabs to prevent re-renders of hidden screens.
-- Avoid passing large objects as route params. Pass IDs and fetch data in the screen.
-- Use `React.memo` on screen components to prevent re-renders from navigation state changes.

package/workflows/skills/react-native-callstack/references/performance-optimization.md

@@ -1,233 +0,0 @@
-# Performance Optimization
-
-Load this when profiling render performance, optimizing lists, reducing bridge overhead, or diagnosing frame drops.
-
-## Profiling Tools
-
-### React DevTools Profiler
-
-Measures component render times and identifies unnecessary re-renders.
-
-```bash
-# Start the profiler
-npx react-devtools
-```
-
-- Record a session, then inspect the flamegraph for components that render frequently.
-- Look for components that re-render without prop changes (missing memoization).
-- Gray bars indicate components that did not render during a commit.
-
-### Flipper Performance Plugin
-
-Measures JS and UI thread frame rates.
-
-- JS thread FPS < 60 indicates expensive JavaScript execution.
-- UI thread FPS < 60 indicates heavy native rendering or layout.
-- Bridge traffic tab shows message volume between threads.
-
-### Systrace (Android)
-
-```bash
-# Capture a systrace while reproducing the issue
-npx react-native profile-hermes
-
-# Or use Android systrace directly
-python systrace.py --time=10 -o trace.html sched gfx view
-```
-
-### Xcode Instruments (iOS)
-
-Use the Time Profiler instrument to identify CPU hotspots and the Core Animation instrument for rendering performance.
-
-## Eliminating Unnecessary Re-renders
-
-### React.memo
-
-```typescript
-const ExpensiveRow = React.memo(function ExpensiveRow({ item }: { item: Item }) {
-  return (
-    <View>
-      <Text>{item.title}</Text>
-      <ComplexChart data={item.chartData} />
-    </View>
-  );
-});
-```
-
-- Wrap components that receive the same props frequently but do not need to re-render.
-- Provide a custom comparison function for complex props: `React.memo(Component, areEqual)`.
-
-### useMemo and useCallback
-
-```typescript
-function Dashboard({ transactions }: Props) {
-  // Memoize expensive computation
-  const summary = useMemo(() => {
-    return transactions.reduce(
-      (acc, t) => ({
-        total: acc.total + t.amount,
-        count: acc.count + 1,
-      }),
-      { total: 0, count: 0 }
-    );
-  }, [transactions]);
-
-  // Stable callback reference for child components
-  const onRefresh = useCallback(() => {
-    fetchTransactions();
-  }, [fetchTransactions]);
-
-  return <TransactionList data={transactions} summary={summary} onRefresh={onRefresh} />;
-}
-```
-
-- `useMemo` prevents recalculating derived data on every render.
-- `useCallback` prevents child components wrapped in `React.memo` from re-rendering due to new function references.
-
-## List Optimization
-
-### FlashList over FlatList
-
-```typescript
-import { FlashList } from '@shopify/flash-list';
-
-<FlashList
-  data={items}
-  renderItem={({ item }) => <ItemRow item={item} />}
-  estimatedItemSize={80}   // Required: approximate row height in pixels
-  keyExtractor={(item) => item.id}
-/>
-```
-
-- FlashList recycles native views instead of creating new ones, reducing memory allocation.
-- `estimatedItemSize` is required and should be close to the average item height for accurate scroll position calculation.
-- Up to 5x performance improvement on lists with 1000+ items compared to FlatList.
-
-### FlatList Tuning
-
-If you must use FlatList:
-
-```typescript
-<FlatList
-  data={items}
-  renderItem={renderItem}
-  keyExtractor={keyExtractor}
-  removeClippedSubviews={true}      // Detach off-screen views
-  maxToRenderPerBatch={10}           // Render 10 items per batch
-  windowSize={5}                     // Keep 5 viewports worth of items
-  initialNumToRender={10}            // Render 10 items initially
-  getItemLayout={(data, index) => ({ // Skip measurement if items are fixed height
-    length: 80,
-    offset: 80 * index,
-    index,
-  })}
-/>
-```
-
-## Image Optimization
-
-```typescript
-import { Image } from 'expo-image'; // or FastImage
-
-<Image
-  source={{ uri: imageUrl }}
-  style={{ width: 100, height: 100 }}
-  cachePolicy="memory-disk"
-  placeholder={{ blurhash: item.blurhash }}
-  transition={200}
-  recyclingKey={item.id}
-/>
-```
-
-- Use `expo-image` or `react-native-fast-image` instead of the built-in `Image` component.
-- Serve images at the display size. Loading a 4000x3000 image for a 100x100 thumbnail wastes memory and CPU.
-- Use WebP format for 25-35% smaller file sizes compared to JPEG at equivalent quality.
-
-## JavaScript Thread Optimization
-
-### Moving Work Off the JS Thread
-
-```typescript
-import { InteractionManager } from 'react-native';
-
-function onNavigationComplete() {
-  // Defer expensive work until after the transition animation completes
-  InteractionManager.runAfterInteractions(() => {
-    loadHeavyData();
-    initializeAnalytics();
-  });
-}
-```
-
-### Hermes Engine
-
-Hermes provides faster startup through bytecode precompilation and lower memory usage.
-
-```json
-// android/app/build.gradle
-project.ext.react = [
-    enableHermes: true
-]
-```
-
-- Hermes is the default engine in React Native 0.70+.
-- Hermes reduces startup time by 50-80% on Android through bytecode precompilation.
-- Use `hermes-profile-transformer` to convert Hermes sampling profiles into Chrome DevTools format.
-
-## Animation Performance
-
-### Use Reanimated for JS-driven animations
-
-```typescript
-import Animated, {
-  useSharedValue,
-  useAnimatedStyle,
-  withSpring,
-} from 'react-native-reanimated';
-
-function AnimatedCard() {
-  const scale = useSharedValue(1);
-
-  const animatedStyle = useAnimatedStyle(() => ({
-    transform: [{ scale: scale.value }],
-  }));
-
-  const onPressIn = () => { scale.value = withSpring(0.95); };
-  const onPressOut = () => { scale.value = withSpring(1); };
-
-  return (
-    <Animated.View style={animatedStyle}>
-      <Pressable onPressIn={onPressIn} onPressOut={onPressOut}>
-        <Text>Card</Text>
-      </Pressable>
-    </Animated.View>
-  );
-}
-```
-
-- Reanimated runs animations on the UI thread via worklets, avoiding JS thread blocking.
-- Use `useAnimatedStyle` instead of inline styles for animated values.
-- Prefer `withSpring` and `withTiming` over manual `Animated.Value` manipulation.
-
-## Memory Leak Detection
-
-Common React Native memory leaks:
-
-1. **Event listeners not removed** -- always return cleanup functions from `useEffect`.
-2. **Timers not cleared** -- clear `setTimeout` and `setInterval` on unmount.
-3. **Subscriptions not unsubscribed** -- navigation listeners, keyboard events, network state.
-4. **Large closures in callbacks** -- avoid capturing entire screens or large data in callbacks passed to native modules.
-
-```typescript
-useEffect(() => {
-  const subscription = eventEmitter.addListener('event', handler);
-  const timer = setInterval(pollData, 5000);
-
-  return () => {
-    subscription.remove();
-    clearInterval(timer);
-  };
-}, []);
-```
-
-Use Xcode's Memory Graph Debugger (iOS) or Android Studio's Memory Profiler to identify retained objects.

package/workflows/skills/receiving-code-review/SKILL.md

@@ -1,72 +0,0 @@
----
-name: receiving-code-review
-description: "Use when responding to code review feedback, incorporating reviewer suggestions, handling disagreements constructively, iterating through review cycles, or learning from repeated feedback patterns."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: "Claude Code, Codex, GitHub Copilot"
----
-
-# Receiving Code Review
-
-## Purpose
-
-Transform code review from a defensive ordeal into a high-leverage learning opportunity. This skill provides a systematic approach to processing reviewer feedback, responding constructively, incorporating changes efficiently, and extracting lasting lessons from repeated patterns — reducing review cycles, strengthening team relationships, and accelerating personal growth as an engineer.
-
-## When to Use
-
-- Responding to reviewer comments on a pull request
-- Deciding how to handle feedback you disagree with
-- Iterating through multiple review rounds efficiently
-- Learning from repeated reviewer feedback to avoid future issues
-- Managing conflicting feedback from multiple reviewers
-- Determining when to push back and when to accept suggestions
-
-## Instructions
-
-1. **Read all feedback before responding** — read every comment across the entire PR before writing any response, because reacting comment-by-comment leads to contradictory responses and misses cross-cutting themes that reviewers are collectively surfacing.
-
-2. **Respond to every comment** — acknowledge every piece of feedback with either a resolution, a question, or a brief "Done", because unacknowledged comments signal disrespect for the reviewer's time and leave ambiguity about whether the feedback was seen or ignored.
-
-3. **Distinguish blocking from non-blocking feedback** — identify which comments are must-fix (correctness, security, breaking changes) versus nice-to-have (style, naming, minor refactors), because treating all feedback as equally urgent wastes time on low-impact changes while potentially delaying critical fixes.
-
-4. **Ask clarifying questions when feedback is ambiguous** — when a comment isn't clear, ask a specific follow-up question rather than guessing the reviewer's intent, because misinterpreting feedback leads to wasted implementation effort and additional review rounds.
-
-5. **Make requested changes promptly** — address blocking feedback as quickly as possible after the review is complete (not piecemeal during the review), because fast turnaround keeps the reviewer's context fresh and prevents the PR from going stale in the queue.
-
-6. **Explain trade-offs when pushing back** — when you disagree with feedback, present your reasoning with specific trade-offs rather than simply declining, because reviewers are more receptive to well-reasoned alternatives than unexplained resistance, and the discussion often surfaces a better solution than either original proposal.
-
-7. **Use suggestion commits for small fixes** — adopt GitHub's suggestion feature or create small fixup commits for trivial changes (typos, naming, formatting), because atomic change tracking makes it easy for reviewers to verify their feedback was addressed without re-reviewing the entire diff.
-
-8. **Batch responses rather than replying piecemeal** — collect all your responses and push all changes together in a single update, because piecemeal updates trigger multiple notification rounds that fragment the reviewer's attention and make it harder to see the complete resolution.
-
-9. **Update PR description when scope changes** — modify the PR description to reflect any scope changes, new limitations, or additional context that emerged during review, because the description is the permanent record of the change and future readers will rely on it, not the review comments.
-
-10. **Resolve conversations only when addressed** — mark a comment as resolved only after the feedback has been genuinely addressed (code changed, question answered, or explicit agreement to defer), because prematurely resolving conversations hides unfinished work from reviewers.
-
-11. **Re-request review after addressing all comments** — explicitly re-request review with a summary of what changed rather than waiting for reviewers to notice your updates, because reviewers manage multiple PRs and a clear "ready for re-review" signal moves yours back to the top of their queue.
-
-12. **Learn from repeated feedback patterns** — track feedback themes you receive across multiple reviews (missing tests, unclear naming, insufficient error handling) and proactively address these in future PRs, because systematic pattern recognition converts reactive feedback into proactive quality habits.
-
-13. **Handle conflicting reviewer opinions** — when two reviewers disagree, surface the conflict explicitly and propose a resolution rather than picking one reviewer's side silently, because hidden conflicts lead to flip-flopping changes across review rounds and erode trust.
-
-14. **Manage review cycles without scope creep** — resist the temptation to expand scope based on review feedback and instead create follow-up issues for good ideas that are out of scope, because unbounded scope growth turns focused PRs into sprawling changes that are harder to review, test, and revert.
-
-## Output Format
-
-When responding to review feedback, provide:
-
-1. **Feedback summary** — categorized list of all reviewer comments (blocking/non-blocking/questions)
-2. **Response plan** — how each comment will be addressed (fix, discuss, defer)
-3. **Changes made** — summary of code changes in response to feedback
-4. **Open questions** — any feedback that needs further discussion
-5. **Re-review request** — clear signal that changes are ready for re-review with context
-
-## References
-
-| File | Purpose |
-|------|---------|
-| `references/feedback-response-patterns.md` | Templates for responding to different types of review feedback constructively |
-| `references/disagreement-resolution.md` | Strategies for handling pushback and resolving conflicts during code review |
-| `references/review-iteration.md` | Techniques for efficiently iterating through multiple review cycles |

package/workflows/skills/receiving-code-review/evals/assertions.md

@@ -1,35 +0,0 @@
-# Receiving Code Review — Eval Assertions
-
-## Eval 1: Categorizing and responding to mixed feedback
-
-### Assertion 1: Race condition as blocking
-The skill must identify the race condition comment as the highest priority. Race conditions cause data corruption and are correctness bugs — they must be fixed before merge.
-
-### Assertion 2: Variable naming as non-blocking
-Naming feedback is a style improvement that doesn't affect behavior. Categorizing it correctly prevents over-prioritizing cosmetic changes.
-
-### Assertion 3: Acknowledge positive feedback
-Responding to praise builds reviewer rapport and signals that all feedback is valued, not just criticism.
-
-### Assertion 4: Integration tests for cache miss
-When a reviewer asks "why no tests?", the correct response is usually to add the tests. The skill should recommend writing them.
-
-### Assertion 5: Technical approach for race condition
-The response should include a specific fix strategy (locking, atomic operations, or compare-and-swap), not just acknowledge the problem.
-
-## Eval 2: Handling conflicting reviewer opinions
-
-### Assertion 1: Surface the conflict explicitly
-Silently choosing one reviewer's approach leads to confusion. The skill must recommend making the disagreement visible.
-
-### Assertion 2: Trade-off analysis
-Both approaches have valid merits. The skill must analyze testability vs simplicity trade-offs with specific reasoning.
-
-### Assertion 3: Resolution mechanism
-Async comment threads can spiral. The skill should suggest a synchronous discussion for faster resolution.
-
-### Assertion 4: YAGNI consideration
-Bob's concern about unnecessary abstraction for a single implementation is a valid YAGNI argument that should be weighed.
-
-### Assertion 5: Document the decision
-Regardless of outcome, the reasoning should be captured so future developers understand the choice.

package/workflows/skills/receiving-code-review/evals/evals.json

@@ -1,24 +0,0 @@
-{
-  "evals": [
-    {
-      "prompt": "I received code review feedback on my PR that adds a caching layer to our API. The reviewer left these comments: (1) 'This cache invalidation logic has a race condition when two concurrent writes happen.' (2) 'Consider using Redis TTL instead of manual expiration tracking.' (3) 'The variable name `d` should be more descriptive.' (4) 'Why didn't you add integration tests for the cache miss path?' (5) 'Nice use of the decorator pattern here.' Help me categorize this feedback and plan my responses.",
-      "assertions": [
-        "categorizes the race condition comment as blocking/critical since it affects correctness",
-        "categorizes the variable naming comment as non-blocking/style since it does not affect behavior",
-        "recommends acknowledging the positive feedback about the decorator pattern",
-        "suggests writing integration tests for the cache miss path as the reviewer requested",
-        "provides a concrete response plan for addressing the race condition with specific technical approach"
-      ]
-    },
-    {
-      "prompt": "Two reviewers on my PR disagree. Alice says I should use an interface-based approach for the payment processor abstraction because it enables easier testing. Bob says I should use a concrete class with dependency injection because the interface adds unnecessary indirection for a single implementation. Both are senior engineers. How should I handle this?",
-      "assertions": [
-        "recommends surfacing the conflict explicitly rather than silently choosing one side",
-        "analyzes the trade-offs of both approaches with specific technical reasoning",
-        "suggests a resolution mechanism such as a brief discussion thread or synchronous conversation",
-        "considers the YAGNI principle regarding the single implementation concern",
-        "recommends documenting the decision rationale regardless of which approach is chosen"
-      ]
-    }
-  ]
-}

package/workflows/skills/receiving-code-review/examples/01-responding-to-feedback.md

@@ -1,56 +0,0 @@
-# Example: Responding to Review Feedback on a Feature PR
-
-## Context
-
-A developer submitted a PR adding a user notification preferences API. The reviewer left 6 comments covering a range of feedback types. The developer needs to categorize, respond to, and address all feedback.
-
-## Reviewer Comments
-
-1. "The `updatePreferences` endpoint doesn't validate that the notification channels are valid enum values. A user could POST `channel: 'pigeon'` and it would be stored."
-2. "This SQL query in `getPreferences` is doing a SELECT * — we should only select the columns we need."
-3. "The error handling in the batch update doesn't roll back partial changes if one preference fails. This could leave the user in an inconsistent state."
-4. "Nit: `prefs` is used in some places and `preferences` in others. Pick one and be consistent."
-5. "Should we add rate limiting to the preferences endpoint? Users could hammer it."
-6. "The test coverage for the happy path is solid."
-
-## Skill Response
-
-### Feedback Categorization
-
-| # | Comment | Type | Priority | Action |
-|---|---------|------|----------|--------|
-| 1 | Missing enum validation | Blocking | High | Fix: add Zod enum validation |
-| 2 | SELECT * usage | Non-blocking | Medium | Fix: specify column list |
-| 3 | No rollback on partial failure | Blocking | High | Fix: wrap in transaction |
-| 4 | Inconsistent naming | Non-blocking | Low | Fix: standardize to `preferences` |
-| 5 | Rate limiting question | Discussion | Medium | Defer: create follow-up issue |
-| 6 | Positive feedback on tests | Acknowledgment | — | Thank reviewer |
-
-### Response Plan
-
-**Blocking fixes (do first):**
-- Comment 1: Add Zod schema with `z.enum(['email', 'sms', 'push', 'in-app'])` validation to the request body. Add test for invalid channel rejection.
-- Comment 3: Wrap the batch update in a database transaction with rollback on any individual failure. Add test for partial failure scenario.
-
-**Non-blocking fixes (batch together):**
-- Comment 2: Replace `SELECT *` with explicit column list. Minor performance improvement.
-- Comment 4: Rename all `prefs` occurrences to `preferences` for consistency.
-
-**Discussion items:**
-- Comment 5: Rate limiting is a good idea but out of scope for this PR. Create issue #247 to track it. Respond: "Great point — I've created #247 to add rate limiting. I'd rather not expand this PR's scope but agree it should be done soon."
-
-**Acknowledgment:**
-- Comment 6: "Thanks! I spent extra time on the happy path tests to make sure the preference merge logic was well-covered."
-
-### Re-Review Request
-
-After pushing all changes:
-
-> All feedback addressed in fixup commits:
-> - `fix: add enum validation for notification channels` (comment 1)
-> - `fix: wrap batch update in transaction` (comment 3)
-> - `fix: select specific columns in getPreferences` (comment 2)
-> - `fix: standardize naming to preferences` (comment 4)
->
-> Created follow-up issue #247 for rate limiting (comment 5).
-> Ready for re-review — the two blocking issues are fixed with tests.