@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/receiving-code-review/examples/02-handling-disagreement.md

@@ -1,67 +0,0 @@
-# Example: Handling Disagreement During Code Review
-
-## Context
-
-A developer submitted a PR refactoring the authentication middleware to use a chain-of-responsibility pattern. The reviewer suggests a different approach. The developer disagrees but needs to handle it constructively.
-
-## Reviewer Comment
-
-> "I think this chain-of-responsibility pattern is over-engineered for our use case. We only have 3 auth strategies (API key, JWT, session cookie) and they're unlikely to change often. A simple if/else chain would be more readable and easier to debug. The pattern adds 4 new classes and an interface for something that's currently 30 lines of straightforward code."
-
-## Developer's Assessment
-
-The developer chose the pattern because:
-- The auth strategies have different error handling needs
-- Each strategy needs independent testing
-- A new OAuth2 strategy is planned for Q2
-- The current if/else chain has grown hard to maintain
-
-But the reviewer's concerns are valid:
-- 4 new classes IS more code
-- The pattern does add indirection
-- The if/else chain works today
-
-## Skill Response
-
-### Step 1: Acknowledge the Valid Concern
-
-> You raise a fair point about the additional complexity — 4 new classes for 3 strategies is a legitimate concern. Let me share my reasoning and see if we can find the right balance.
-
-### Step 2: Present Trade-Off Analysis
-
-> **Why I chose this approach:**
-> 1. Each strategy needs different error semantics (API key returns 401 with `WWW-Authenticate`, JWT returns 401 with token expiry info, session returns 302 redirect). The if/else chain was mixing these concerns.
-> 2. We have a Q2 requirement for OAuth2 support (see JIRA-1234), which would make it 4 strategies.
-> 3. The current if/else chain had a bug last sprint (JIRA-1189) because the JWT branch was accidentally catching API key errors.
->
-> **Your concerns I agree with:**
-> - The 4-class structure is heavier than needed right now
-> - The interface adds a layer of indirection that makes debugging slightly harder
->
-> **Possible middle ground:** What if I simplified to a strategy map (dictionary of auth type → handler function) instead of the full chain-of-responsibility? That gives us:
-> - Independent handler functions (testable, isolated error handling) ✓
-> - No extra interface or abstract class ✓
-> - Easy to add OAuth2 in Q2 ✓
-> - Only ~50 lines vs the current 30 ✓
-
-### Step 3: Propose Resolution
-
-> I can refactor to the strategy map approach in this PR if you think that's the right balance. Or if you'd prefer to discuss synchronously, I'm free for 15 minutes this afternoon — sometimes these architectural decisions are faster to resolve in a quick call.
-
-### Step 4: Document Outcome
-
-After discussion, the reviewer agreed to the strategy map approach:
-
-> **Decision:** Use strategy map pattern (dictionary of auth type → handler function) instead of chain-of-responsibility or if/else chain.
->
-> **Rationale:** Provides independent testability and clean error handling per strategy without the overhead of the full GoF pattern. Scales to 4+ strategies (OAuth2 in Q2) without structural changes.
->
-> Updated PR description with this decision for future reference.
-
-### Key Principles Demonstrated
-
-1. **Acknowledged the valid part first** — "You raise a fair point" before defending
-2. **Used evidence, not opinion** — referenced JIRA tickets for the bug and Q2 requirement
-3. **Proposed a third option** — neither "my way" nor "your way" but a compromise
-4. **Offered synchronous discussion** — recognized that async threads can spiral
-5. **Documented the outcome** — captured the decision in the PR description

package/workflows/skills/receiving-code-review/references/disagreement-resolution.md

@@ -1,122 +0,0 @@
-# Disagreement Resolution
-
-## Overview
-
-Disagreements during code review are normal and often productive. The goal is not to avoid disagreement but to resolve it efficiently while preserving relationships and making the best technical decision.
-
-## The Resolution Ladder
-
-Escalate through these levels only as needed:
-
-### Level 1: Async Discussion (Default)
-
-Reply to the comment with your reasoning. Most disagreements resolve here.
-
-**Template:**
-```
-"I see your point about [their concern]. I went with [your approach] because
-[specific reasoning]. [Alternative proposal if applicable]. What do you think?"
-```
-
-Time limit: 2 comment rounds. If unresolved, escalate.
-
-### Level 2: Synchronous Conversation
-
-Schedule a 15-minute call or huddle. Voice communication resolves misunderstandings faster than text.
-
-**Preparation:**
-- Write down your position and their position
-- Identify the specific technical trade-off
-- Come with a willingness to be wrong
-
-**After the call:** Summarize the decision in the PR comment thread so it's documented.
-
-### Level 3: Third-Party Opinion
-
-Bring in a third engineer for perspective. Choose someone with relevant domain expertise who isn't invested in either position.
-
-**When to use:**
-- Both positions are technically valid
-- The disagreement is about architecture, not style
-- The decision has long-term implications
-
-### Level 4: Team Lead/Tech Lead Decision
-
-If the team can't reach consensus, the tech lead makes the call.
-
-**When to use:**
-- Rarely. Most disagreements should resolve at Level 1-2.
-- Only for decisions with significant architectural impact
-- When the team is blocked and needs to move forward
-
-## Disagreement Categories
-
-### Style Disagreements
-
-Example: "Use `forEach` vs `for...of`"
-
-Resolution: Defer to the team's linter/style guide. If no guide exists, accept the reviewer's preference — style consistency matters more than personal preference.
-
-### Design Disagreements
-
-Example: "Use composition vs inheritance"
-
-Resolution: Discuss trade-offs. Consider YAGNI, testability, and the team's familiarity with the pattern. Document the decision.
-
-### Correctness Disagreements
-
-Example: "This will cause a race condition" / "No it won't"
-
-Resolution: Write a test that proves or disproves the claim. Code doesn't lie.
-
-### Scope Disagreements
-
-Example: "You should also handle the edge case where..." / "That's out of scope"
-
-Resolution: If the edge case is a real risk, create a follow-up issue. If it's speculative, explain why it's deferred.
-
-## Constructive Pushback Techniques
-
-### The Evidence-Based Pushback
-
-Present data, benchmarks, or references:
-```
-"I benchmarked both approaches. The current implementation handles
-10K requests/sec while the suggested approach peaks at 6K due to
-[specific bottleneck]. See benchmark results: [link]."
-```
-
-### The Trade-Off Acknowledgment
-
-Show you understand both sides:
-```
-"Your approach is cleaner. The trade-off is [specific cost]. Given our
-current requirements of [context], I think [your approach] is the better
-fit because [reasoning]. Happy to revisit if requirements change."
-```
-
-### The Compromise Proposal
-
-Offer a middle ground:
-```
-"What if we [alternative that addresses both concerns]? This gives us
-[benefit from their suggestion] while preserving [benefit from your approach]."
-```
-
-### The Deferral with Issue
-
-Accept the feedback but defer execution:
-```
-"That's a great improvement. It's a bigger change than I want to include
-in this PR though — I've created #N to track it. Can we merge this as-is
-and address it in the follow-up?"
-```
-
-## Red Lines: When NOT to Compromise
-
-- **Security vulnerabilities** — never compromise on known security issues
-- **Data integrity** — don't accept approaches that risk data loss or corruption
-- **Legal/compliance** — regulatory requirements are non-negotiable
-- **Team standards** — if the team decided on a standard, follow it
-
-For everything else, be flexible. The best code is shipped code, and perfect is the enemy of good.

package/workflows/skills/receiving-code-review/references/feedback-response-patterns.md

@@ -1,112 +0,0 @@
-# Feedback Response Patterns
-
-## Overview
-
-Different types of review feedback require different response strategies. Using the right pattern prevents misunderstandings, reduces review cycles, and maintains productive working relationships.
-
-## Response Templates by Feedback Type
-
-### Blocking Feedback (Must Fix)
-
-**Pattern:** Acknowledge → Fix → Verify
-
-```
-"Good catch — [restate the issue]. Fixed in [commit SHA]. I also added
-a test for [specific scenario] to prevent regression."
-```
-
-When to use: Bugs, security issues, correctness problems, missing error handling.
-
-Key principle: Never argue with blocking feedback about correctness. If the reviewer found a bug, fix it and thank them.
-
-### Suggestion Feedback (Could Improve)
-
-**Pattern:** Evaluate → Decide → Explain
-
-```
-"Thanks for the suggestion. I [adopted it / went with a variation / deferred it]
-because [specific reasoning]. [If deferred:] Created issue #N to track this."
-```
-
-When to use: Refactoring ideas, alternative approaches, performance optimizations.
-
-Key principle: You can decline suggestions with good reasoning. The key is explaining why, not just saying no.
-
-### Clarification Request
-
-**Pattern:** Answer → Show → Offer Context
-
-```
-"This [code/approach] works by [explanation]. I added an inline comment
-to make this clearer for future readers. See [file:line]."
-```
-
-When to use: "Why did you...?", "What does this do?", "Is this intentional?"
-
-Key principle: If a reviewer is confused, future readers will be too. Add a comment.
-
-### Nitpick/Style Feedback
-
-**Pattern:** Fix Quickly → Move On
-
-```
-"Done." or "Fixed — good eye."
-```
-
-When to use: Naming, formatting, import ordering, minor style issues.
-
-Key principle: Don't debate nitpicks. Fix them immediately and save energy for substantive discussions.
-
-### Positive Feedback
-
-**Pattern:** Thank → Elaborate (optional)
-
-```
-"Thanks! [Optional: brief context about why you chose this approach]."
-```
-
-When to use: Compliments, "nice!" comments, approval comments.
-
-Key principle: Acknowledge praise briefly. Don't over-explain.
-
-## Anti-Patterns to Avoid
-
-### The Defensive Response
-
-Bad: "It works fine on my machine." / "That's not what the ticket says."
-
-Why it fails: Signals that you're protecting ego rather than improving code. Reviewers stop giving honest feedback.
-
-Fix: Assume good intent. Restate the concern to confirm understanding before responding.
-
-### The Silent Fix
-
-Bad: Pushing changes without responding to comments.
-
-Why it fails: Reviewers can't tell if you understood their feedback or just made a random change. They'll re-review more skeptically.
-
-Fix: Always respond to the comment AND push the fix.
-
-### The Scope Expander
-
-Bad: "While I'm at it, I also refactored the entire module..."
-
-Why it fails: Expanding scope during review makes the PR harder to review and delays merge.
-
-Fix: Create follow-up issues for good ideas that are out of scope.
-
-### The Passive Resolver
-
-Bad: Marking comments as "resolved" without addressing them.
-
-Why it fails: Hides unfinished work and destroys reviewer trust.
-
-Fix: Only resolve after genuinely addressing the feedback.
-
-## Tone Guidelines
-
-- **Use "we" language** — "We should probably add a test" not "You're wrong"
-- **Assume good intent** — reviewers are trying to improve the code, not attack you
-- **Be specific** — "Fixed in abc123" not "Fixed"
-- **Stay professional** — avoid sarcasm, passive aggression, or dismissiveness
-- **Separate ego from code** — the review is about the code, not about you

package/workflows/skills/receiving-code-review/references/review-iteration.md

@@ -1,139 +0,0 @@
-# Review Iteration
-
-## Overview
-
-Efficient review iteration minimizes the number of round trips between author and reviewer while ensuring all feedback is properly addressed. The goal is to merge a high-quality change in 1-2 review cycles rather than 4-5.
-
-## The Iteration Cycle
-
-```
-Review received
-  → Read ALL comments (don't react yet)
-  → Categorize: blocking / non-blocking / questions / praise
-  → Address all blocking items first
-  → Batch non-blocking fixes together
-  → Respond to every comment
-  → Push all changes in one update
-  → Re-request review with summary
-```
-
-## Batching Strategy
-
-### Why Batch
-
-Piecemeal updates cause problems:
-- Each push triggers notifications, fragmenting reviewer attention
-- Partial fixes can break the build or tests
-- Reviewers can't tell if you're done or still making changes
-- Comment threads become interleaved with code changes
-
-### How to Batch
-
-1. Read all feedback completely
-2. Plan all changes before making any
-3. Make all changes locally
-4. Run tests locally to verify nothing is broken
-5. Push everything in a single force-push or commit set
-6. Respond to all comments at once
-7. Re-request review as the final action
-
-### Exception: Quick Clarifications
-
-It's fine to respond to questions immediately (without code changes) to unblock the reviewer's understanding. Just don't push code until everything is ready.
-
-## Commit Strategies for Iterations
-
-### Fixup Commits (Recommended)
-
-Create separate commits for each piece of feedback:
-```
-fix: add enum validation for notification channels (review feedback)
-fix: wrap batch update in transaction (review feedback)
-fix: standardize naming to preferences (review feedback)
-```
-
-Benefits:
-- Reviewers can see exactly what changed per comment
-- Easy to verify each piece of feedback was addressed
-- Can be squashed before merge
-
-### Amend + Force Push
-
-Rewrite the original commits to incorporate feedback:
-
-Benefits:
-- Clean commit history
-- No "fix review feedback" commits in the log
-
-Drawbacks:
-- Reviewers must re-review the entire diff (can't see just the changes)
-- Use only when the reviewer requests it or when changes are extensive
-
-## Re-Review Request Template
-
-After addressing all feedback:
-
-```markdown
-## Changes in this iteration
-
-### Blocking fixes
-- [x] Added enum validation for channels (#comment-1) — abc1234
-- [x] Wrapped batch update in transaction (#comment-3) — def5678
-
-### Non-blocking fixes
-- [x] Replaced SELECT * with column list (#comment-2)
-- [x] Standardized naming to `preferences` (#comment-4)
-
-### Deferred
-- Rate limiting → tracked in #247 (#comment-5)
-
-### Tests
-- Added test for invalid channel rejection
-- Added test for partial batch failure rollback
-
-Ready for re-review. All blocking issues addressed with tests.
-```
-
-## Reducing Review Cycles
-
-### Cycle 1: First Review
-
-Goal: Address all blocking feedback. If possible, also fix non-blocking items.
-
-Typical outcome: 2-4 blocking items, 3-6 non-blocking items.
-
-### Cycle 2: Follow-Up Review
-
-Goal: Verify fixes and address any new issues that emerged from the changes.
-
-Typical outcome: 0-1 new blocking items, 1-2 clarifications.
-
-### Cycle 3+: Escalation Signal
-
-If you're in cycle 3 or beyond, something is wrong:
-- The PR scope is too large — consider splitting
-- There's a fundamental design disagreement — escalate to synchronous discussion
-- Requirements are unclear — pause the PR and clarify with stakeholders
-
-## Stale Review Recovery
-
-When a PR has been in review for more than 3 days:
-
-1. Rebase on the latest main branch
-2. Resolve any conflicts
-3. Re-run all tests
-4. Post a comment: "Rebased and resolved conflicts. All tests passing. Ready for re-review."
-5. If the reviewer is unresponsive, find an alternate reviewer
-
-## Metrics for Review Efficiency
-
-Track these to improve over time:
-
-| Metric | Target | How to Measure |
-|--------|--------|----------------|
-| Review cycles to merge | ≤ 2 | Count re-review requests per PR |
-| Time from review to response | < 4 hours | Timestamp between review and first response |
-| Blocking comments per PR | Trending down | Count blocking comments over time |
-| Repeated feedback themes | 0 repeats | Track if same feedback appears across PRs |
-
-If blocking comments per PR is trending down over months, you're learning from review feedback effectively.

package/workflows/skills/remix/SKILL.md

@@ -1,76 +0,0 @@
----
-name: remix
-description: "Use when building Remix v2+ applications with nested routing, loaders, actions, progressive enhancement, streaming, server-side rendering, and full-stack data flow patterns."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: Claude Code, Codex, GitHub Copilot
----
-
-# Remix
-
-## Purpose
-
-Guide the design and implementation of production-grade Remix v2+ applications using nested routing, loader/action data flows, progressive enhancement, streaming with `defer` and `Await`, error boundaries, form handling, and server-side rendering. Every instruction prioritizes web-standards alignment, progressive enhancement as a default, and the Remix mental model of treating the browser as a thin client that enhances server-rendered HTML.
-
-## When to Use
-
-- Scaffolding a new Remix v2 application or migrating from Remix v1 / React Router to Remix v2 conventions.
-- Designing nested route hierarchies with shared layouts, pathless routes, and resource routes.
-- Implementing loaders and actions for server-side data fetching and form mutations.
-- Adding streaming with `defer`, `Await`, and `Suspense` for slow data sources.
-- Building progressively enhanced forms that work without JavaScript.
-- Configuring error and catch boundaries for graceful degradation.
-- Deploying Remix to edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy).
-- Reviewing Remix code for waterfall data fetching, missing revalidation, or broken progressive enhancement.
-
-## Instructions
-
-1. **Confirm the Remix version and runtime adapter before generating code** because Remix v2 introduced Vite as the default bundler, flat file routing, and breaking changes to route module exports that invalidate patterns from v1. See `references/routing-conventions.md`.
-
-2. **Organize routes using flat file conventions with dot-delimited nesting** because Remix v2 uses `routes/parent.child.tsx` instead of folder nesting, and incorrect naming produces route mismatches that silently render the wrong layout without any build error.
-
-3. **Use `loader` functions for all GET-request data fetching and return plain objects or `json()` responses** because loaders run on the server before rendering, eliminating client-side fetch waterfalls and ensuring the initial HTML contains meaningful content for SEO and perceived performance. See `references/loaders-actions.md`.
-
-4. **Use `action` functions for all non-GET mutations and return redirect responses on success** because actions follow the POST/Redirect/GET pattern that prevents duplicate form submissions on refresh and ensures the browser history stack reflects the user's intent rather than intermediate mutation states.
-
-5. **Build forms with the Remix `<Form>` component instead of `<form>` for progressive enhancement** because `<Form>` intercepts submissions with JavaScript when available for instant optimistic UI, but falls back to a standard HTML form submission when JavaScript fails or is disabled, preserving full functionality.
-
-6. **Implement optimistic UI with `useNavigation` and `useFetcher` instead of local state** because Remix tracks all in-flight navigations and fetcher submissions, providing `navigation.state`, `navigation.formData`, and `fetcher.formData` that reflect the pending mutation without manual state management or race condition handling. See `references/progressive-enhancement.md`.
-
-7. **Use `defer` with `Await` and `Suspense` for data that is not critical to the initial render** because `defer` streams the shell HTML immediately and resolves slow promises on the server, sending the completed HTML chunks as they finish without blocking time-to-first-byte for the entire page. See `references/streaming-defer.md`.
-
-8. **Define `ErrorBoundary` exports in every route segment that can fail independently** because Remix renders the nearest ancestor ErrorBoundary when a loader or action throws, isolating failures to the affected route segment while the rest of the page remains interactive.
-
-9. **Use `shouldRevalidate` to prevent unnecessary loader re-execution after mutations** because Remix revalidates all active loaders by default after any action, and skipping revalidation for loaders whose data is unaffected by the mutation reduces server load and improves post-action render speed.
-
-10. **Colocate route-specific meta, links, and headers exports in the route module** because Remix merges these exports from the entire route hierarchy at render time, and missing or conflicting exports produce incorrect `<head>` content, duplicate stylesheets, or wrong cache headers.
-
-11. **Use resource routes (modules that export only a loader or action, no default component) for API endpoints, webhooks, and file downloads** because resource routes share the same authentication middleware, session handling, and deployment infrastructure as UI routes without requiring a separate API server. See `references/resource-routes.md`.
-
-12. **Handle sessions and cookies with the Remix `createCookieSessionStorage` or `createSessionStorage` utilities** because these utilities sign and encrypt session data by default, preventing tampering, and integrate with the loader/action request flow so sessions are available server-side without client-side storage.
-
-13. **Type loader and action data with `typeof loader` inference instead of manual interfaces** because TypeScript infers the exact return shape from the loader function, and manual interfaces drift out of sync with the actual server response, causing runtime type mismatches that TypeScript cannot detect.
-
-14. **Validate action form data on the server using Zod or a similar schema library and return structured validation errors** because client-side validation is bypassable, and returning a `{ errors }` object from the action allows the form to re-render with field-level error messages without losing user input.
-
-15. **Use `useFetcher` for mutations that should not trigger a navigation** because `useFetcher` submits to an action and receives the response without changing the URL or scroll position, making it appropriate for inline edits, toggles, and background saves that happen within the current page context.
-
-16. **Configure cache headers in loader `headers` exports and use `stale-while-revalidate` for static-ish content** because Remix does not add caching by default, and proper cache headers at the route level reduce origin server load, improve TTFB for repeat visitors, and enable CDN edge caching without a separate caching layer.
-
-## Output Format
-
-Provide implementation code, route module definitions, loader/action functions, form components, and deployment configuration as appropriate. Include file paths relative to the `app/` directory using Remix v2 flat file conventions. When generating route modules, always show the complete module exports (`loader`, `action`, `default`, `ErrorBoundary`, `meta`, `headers`) relevant to the task.
-
-## References
-
-Load only what the current task requires.
-
-| File | Load when |
-| --- | --- |
-| `references/routing-conventions.md` | Task involves route hierarchy design, flat file naming, pathless routes, or layout routes. |
-| `references/loaders-actions.md` | Task involves data fetching, form mutations, server-side validation, or revalidation control. |
-| `references/progressive-enhancement.md` | Task involves optimistic UI, useFetcher, useNavigation, or forms that work without JavaScript. |
-| `references/streaming-defer.md` | Task involves defer, Await, Suspense, streaming SSR, or slow data source handling. |
-| `references/resource-routes.md` | Task involves API endpoints, webhooks, file downloads, or headless route modules. |

package/workflows/skills/remix/evals/assertions.md

@@ -1,50 +0,0 @@
-# Remix Eval Assertions
-
-## Eval 1: Nested Route with Loaders and Error Boundaries
-
-This eval tests the ability to design a Remix v2 blog platform with nested routing, server-side data loading, form-based mutations with progressive enhancement, and granular error boundaries.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `loader` — Server-side data fetching | Remix loaders run on the server before rendering, eliminating client-side fetch waterfalls. Without loaders, the initial HTML is empty, hurting SEO and perceived performance. |
-| 2 | contains | `action` — Server-side form handling | Actions follow the POST/Redirect/GET pattern, preventing duplicate form submissions on refresh. Using client-side fetch for mutations bypasses Remix's built-in revalidation and progressive enhancement. |
-| 3 | contains | `ErrorBoundary` — Granular error isolation | Remix renders the nearest ancestor ErrorBoundary when a loader or action throws. Without per-route error boundaries, a single failed data fetch crashes the entire page instead of just the affected section. |
-| 4 | contains | `Form` — Progressive enhancement | Remix's `<Form>` component intercepts submissions for instant optimistic UI with JavaScript, but falls back to standard HTML form submission without it. Using `<form>` directly loses the Remix navigation integration. |
-| 5 | contains | `blog.` — Flat file route conventions | Remix v2 uses dot-delimited flat file naming (blog.$slug.tsx) instead of v1 folder nesting. Wrong naming conventions produce route mismatches that silently render the wrong layout. |
-
-### What a passing response looks like
-
-- Route files: `app/routes/blog.tsx` (layout), `app/routes/blog._index.tsx` (post list), `app/routes/blog.$slug.tsx` (post detail), `app/routes/blog.$slug.edit.tsx` (edit form).
-- Each route exports a `loader` that fetches data server-side and returns `json()`.
-- The edit route exports an `action` that validates form data with Zod, saves to database, and returns `redirect()` on success or `json({ errors })` on validation failure.
-- The edit form uses `<Form method="post">` with `useActionData()` to display validation errors.
-- Each route exports an `ErrorBoundary` that renders a user-friendly error message with `useRouteError()`.
-- The blog layout route renders an `<Outlet />` for child content alongside the category sidebar.
-
----
-
-## Eval 2: Streaming Dashboard with Defer
-
-This eval tests the ability to build a streaming Remix page that returns fast data immediately and streams slow data progressively, with proper loading states and error handling for deferred promises.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `defer` — Streaming data response | `defer()` allows the server to send the HTML shell with resolved data immediately while streaming deferred promises as they complete, eliminating the need to wait for the slowest data source before sending any HTML. |
-| 2 | contains | `Await` — Deferred data rendering | The `<Await>` component resolves deferred promises in the component tree, integrating with Suspense for loading states. Without it, deferred data cannot be rendered after streaming. |
-| 3 | contains | `Suspense` — Loading state boundary | `<Suspense>` wraps `<Await>` to provide a fallback UI (skeleton) that renders in the initial HTML while deferred promises are pending. Missing Suspense boundaries cause unhandled promise errors. |
-| 4 | contains | `errorElement` — Deferred error handling | The `errorElement` prop on `<Await>` catches errors from deferred promises without propagating to the route ErrorBoundary, keeping the rest of the page functional when a single data source fails. |
-| 5 | contains | `typeof loader` — Type inference from loader | Using `typeof loader` for type inference ensures component types stay synchronized with the actual loader return shape. Manual interfaces drift out of sync when the loader changes. |
-
-### What a passing response looks like
-
-- Loader returns `defer({ user: await getUserProfile(userId), analytics: getAnalytics(userId) })` where user is awaited (critical) and analytics is a bare promise (deferred).
-- Component uses `useLoaderData<typeof loader>()` for type-safe data access.
-- User profile section renders immediately in the HTML response.
-- Analytics section is wrapped in `<Suspense fallback={<AnalyticsSkeleton />}>` with `<Await resolve={data.analytics} errorElement={<AnalyticsError />}>`.
-- The `<Await>` render function receives the resolved analytics data and renders charts/metrics.
-- `errorElement` renders a graceful fallback message when the analytics API fails.
-- TypeScript types are inferred from the loader, not manually defined.

package/workflows/skills/remix/evals/evals.json

@@ -1,68 +0,0 @@
-{
-  "evals": [
-    {
-      "name": "nested-route-with-loaders-and-error-boundaries",
-      "description": "Validate that the skill produces a Remix v2 nested route structure with loaders, actions, progressive enhancement, and error boundaries for a blog platform with authenticated authors.",
-      "input": "Build a Remix v2 blog platform with nested routes. The layout route at /blog shows a sidebar with post categories. Child route /blog/$slug renders the post content loaded from a database. Authors can edit their posts at /blog/$slug/edit using a form with server-side validation. The edit form must work without JavaScript. Add error boundaries for missing posts (404) and server errors. Use flat file routing conventions.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "loader",
-          "description": "Route modules must export loader functions for server-side data fetching, ensuring the HTML response contains meaningful content on first render without client-side fetch waterfalls."
-        },
-        {
-          "type": "contains",
-          "value": "action",
-          "description": "The edit route must export an action function for handling form mutations server-side, following the POST/Redirect/GET pattern to prevent duplicate submissions on browser refresh."
-        },
-        {
-          "type": "contains",
-          "value": "ErrorBoundary",
-          "description": "Route modules must export ErrorBoundary components to isolate failures to the affected route segment, keeping the rest of the page interactive when a loader or action throws."
-        },
-        {
-          "type": "contains",
-          "value": "Form",
-          "description": "The edit form must use Remix's <Form> component for progressive enhancement, providing instant optimistic UI with JavaScript while falling back to standard HTML form submission without it."
-        },
-        {
-          "type": "contains",
-          "value": "blog.",
-          "description": "Route files must use Remix v2 flat file conventions with dot-delimited nesting (e.g., blog._index.tsx, blog.$slug.tsx) instead of folder-based nesting from v1."
-        }
-      ]
-    },
-    {
-      "name": "streaming-dashboard-with-defer",
-      "description": "Validate that the skill produces a streaming Remix page using defer and Await for a dashboard with mixed fast and slow data sources, including proper loading states and error handling.",
-      "input": "Create a Remix dashboard route at /dashboard that loads user profile data (fast, from cache) and analytics data (slow, from an external API that takes 2-3 seconds). The user profile must appear immediately in the HTML response. The analytics section should stream in after the external API responds. Show loading skeletons while analytics loads. Handle the case where the analytics API fails without breaking the profile section. Include proper TypeScript types inferred from the loader.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "defer",
-          "description": "The loader must use defer() to return a mix of resolved data (user profile) and unresolved promises (analytics), enabling the server to stream the HTML shell immediately without waiting for slow data sources."
-        },
-        {
-          "type": "contains",
-          "value": "Await",
-          "description": "The component must use the Remix <Await> component to render streamed data when it resolves, integrating with React Suspense for loading states and error handling on deferred promises."
-        },
-        {
-          "type": "contains",
-          "value": "Suspense",
-          "description": "The component must wrap <Await> in a React <Suspense> boundary with a fallback UI (loading skeleton) that renders in the initial HTML while the deferred analytics promise is pending."
-        },
-        {
-          "type": "contains",
-          "value": "errorElement",
-          "description": "The <Await> component must include an errorElement prop to handle analytics API failures gracefully, preventing the error from propagating to the ErrorBoundary and breaking the entire dashboard."
-        },
-        {
-          "type": "contains",
-          "value": "typeof loader",
-          "description": "Loader data must be typed using TypeScript inference with typeof loader rather than manual interfaces, ensuring the component types stay synchronized with the actual loader return shape."
-        }
-      ]
-    }
-  ]
-}