@fprad0/skill-master-mcp 0.0.9 → 0.0.11

package/docs/skill-candidates/v0.0.10/winui-app/references/shell-navigation-and-windowing.md

@@ -0,0 +1,67 @@
+---
+title: Shell, Navigation, and Windowing
+priority: HIGH
+tags: navigationview, titlebar, appwindow, multi-window, shell
+sources:
+  - https://learn.microsoft.com/windows/apps/design/basics/navigation-basics
+  - https://learn.microsoft.com/windows/apps/design/basics/titlebar-design
+  - https://github.com/microsoft/WinUI-Gallery
+  - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Windowing
+---
+
+## What This Reference Is For
+
+Use this file for top-level app shells, page navigation models, custom title bars, and multi-window decisions.
+
+## Prefer
+
+- `NavigationView` for standard desktop shells with clear top-level destinations.
+- A small, stable set of primary destinations.
+- Built-in back navigation behavior that matches user expectations.
+- `AppWindow` and Windows App SDK windowing APIs for modern window management.
+
+## Avoid
+
+- Overloading the nav surface with every command and secondary action.
+- Turning the `NavigationView` pane into a branded hero area when the user did not ask for custom shell treatment.
+- Custom title bar layouts that break drag regions or caption button clarity.
+- Multi-window designs unless the workflow clearly benefits from them.
+
+## Navigation Guidance
+
+- Use left navigation when the app has several stable, high-level destinations.
+- Use top navigation when there are few peer destinations and width is available.
+- Use a single-page or document-first layout when navigation is shallow and the user mostly stays in one workflow.
+- Keep naming and iconography stable across pages.
+- Treat `NavigationView` as functional shell chrome first. Keep pane headers, footer content, and decorative branding minimal unless the product requirements clearly call for them.
+- Prefer the platform's normal pane structure before adding custom logo blocks, taglines, or non-navigation content that changes the shell's native feel.
+- For narrow or phone-like widths, stop reserving permanent pane width for desktop navigation. Prefer a minimal or overlay navigation mode, show the pane toggle when needed, close the pane by default after navigation, and give content the width back.
+- When a shell enters a phone-width mode, reduce content padding and decorative chrome so the page reads as one primary column instead of a desktop shell with a squeezed content strip.
+
+## Title Bar Guidance
+
+- Treat the title bar as functional chrome first, branding surface second.
+- Keep empty non-interactive areas draggable.
+- Blend title bar visuals with the rest of the app when possible.
+- Respect light, dark, and high-contrast states.
+
+## Windowing Guidance
+
+- Start with one main window.
+- Add secondary windows only for workflows such as document detachment, inspection panes, or tool windows.
+- Use Windows App SDK samples for resizing, placement, and window-specific behaviors instead of inventing custom platform abstractions.
+
+## Sample and Source Anchors
+
+- WinUI Gallery `NavigationView`, `TitleBar`, `AppWindow`, and windowing sample pages
+- WindowsAppSDK-Samples `Samples/Windowing`
+- Learn navigation and title bar guidance
+
+## Review Checklist
+
+- Is the navigation model simple and intentional?
+- Does the shell still look and behave like a normal WinUI `NavigationView` unless there is an explicit reason to diverge?
+- Does the title bar still behave like a Windows title bar?
+- Are back, search, and pane behaviors consistent?
+- Is multi-window use justified by the workflow?
+- Does the shell intentionally switch behavior at narrow or phone widths instead of leaving a full desktop pane open?

package/docs/skill-candidates/v0.0.10/winui-app/references/styling-theming-materials-and-icons.md

@@ -0,0 +1,71 @@
+---
+title: Styling, Theming, Materials, and Icons
+priority: HIGH
+tags: styling, theme-resources, mica, acrylic, typography, icons
+sources:
+  - https://learn.microsoft.com/windows/apps/design/style/mica
+  - https://learn.microsoft.com/windows/apps/design/style/acrylic
+  - https://learn.microsoft.com/windows/apps/design/signature-experiences/typography
+  - https://learn.microsoft.com/windows/apps/design/signature-experiences/iconography
+  - https://github.com/microsoft/WinUI-Gallery
+  - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Mica
+---
+
+## What This Reference Is For
+
+Use this file for Fluent styling choices, theme resources, Mica or Acrylic usage, custom title bar visuals, typography, and iconography.
+
+## Prefer
+
+- Theme resources and system brushes over hard-coded colors.
+- Standard WinUI surface resources and default control chrome before custom panel systems.
+- Mica on long-lived surfaces such as the main window background or title bar region.
+- Acrylic on transient or light-dismiss surfaces.
+- Segoe UI Variable or platform-default typography choices.
+- Fluent iconography that matches the platform language.
+- When metadata needs a visual container, prefer small rounded rectangles or subtle badges over bright oval pills.
+
+## Avoid
+
+- Hard-coded light-theme colors that break dark or high-contrast themes.
+- Wrapping every region in a custom `Border` with a bespoke corner radius, stroke, and fill when standard WinUI surfaces would do the job.
+- Adding an outer section `Border` around content that is already visually grouped by card controls, spacing, or headers; this often creates a redundant "card around cards" effect.
+- Using Acrylic where Mica or a simple theme-aware surface would be cheaper and clearer.
+- Mixing unrelated icon styles.
+- Filling lists or cards with rows of decorative oval chips for routine metadata. Use tag treatments sparingly, and default to rounded rectangles when they are justified.
+
+## Theming Guidance
+
+- Support light, dark, and high-contrast by default.
+- Centralize brushes, typography, and corner/spacing decisions in shared resource dictionaries.
+- Let built-in controls keep their platform behavior unless there is a strong design reason to customize them.
+- When a grouped surface is needed, prefer system resources such as `CardBackgroundFillColorDefaultBrush`, `CardStrokeColorDefaultBrush`, and `LayerFillColorDefaultBrush` instead of inventing a parallel surface language.
+- If child content already uses card-like surfaces, prefer removing the outer section border and relying on layout spacing and typography for grouping unless the section needs its own distinct background, inset, or stroke.
+
+## Materials Guidance
+
+- Use Mica for long-lived base layers.
+- Use Acrylic for transient surfaces such as flyouts and menus.
+- Verify fallback behavior on older Windows versions or unsupported scenarios.
+
+## Icon and Typography Guidance
+
+- Use standard Windows iconography and keep visual weight consistent.
+- Use typography to create hierarchy instead of adding extra borders or decoration.
+- Keep title bar text and document titles aligned with Windows guidance.
+
+## Sample and Source Anchors
+
+- Learn material, typography, and iconography guidance
+- WinUI Gallery system backdrop and styling pages
+- WindowsAppSDK-Samples `Samples/Mica`
+
+## Review Checklist
+
+- Are colors and brushes theme-aware?
+- Does the app look correct in light, dark, and high contrast?
+- Is the selected material appropriate for the surface lifetime?
+- Are icon and typography choices consistent with Fluent design?
+- Are standard WinUI surfaces doing most of the visual work, with custom borders limited to clearly justified cases?
+- Are there any redundant outer borders that could be removed without losing hierarchy or usability?
+- Are tag or chip treatments sparse, visually quiet, and not rendered as default oval pills unless the product explicitly calls for that style?

package/docs/skill-candidates/v0.0.10/winui-app/references/testing-debugging-and-review-checklists.md

@@ -0,0 +1,77 @@
+---
+title: Testing, Debugging, and Review Checklists
+priority: HIGH
+tags: testing, debugging, review, hot-reload, live-visual-tree, checklists
+sources:
+  - https://learn.microsoft.com/windows/apps/get-started/start-here
+  - https://learn.microsoft.com/windows/apps/get-started/developer-mode-features-and-debugging
+  - https://learn.microsoft.com/windows/apps/performance/winui-perf
+---
+
+## What This Reference Is For
+
+Use this file for final review passes, debugging sessions, and "what should I verify before I call this done?" prompts.
+
+## Required Verification Loop
+
+- Build after each meaningful edit, not only at the end.
+- Run the app after changes when the user asked for it or when startup-sensitive files changed.
+- Verify actual launch instead of assuming success from a spawned process.
+- If the app fails before showing a window, debug the startup path before continuing feature work.
+
+## Design Review Checklist
+
+- Shell and navigation are simple and predictable.
+- `NavigationView` still reads like standard WinUI shell chrome unless the product explicitly calls for branded pane content or custom shell composition.
+- Layout stays usable when the window is narrow.
+- Layout has been checked at more than one breakpoint, including a genuinely phone-like width when the app can be resized that far.
+- Collection pages with mixed scroll regions have been checked at runtime so shelves still render in the intended direction and do not collapse into a single vertical column.
+- Theme, contrast, hierarchy, and interactive state visibility hold up in both light and dark mode, and typography and iconography still feel native to Windows.
+- Command placement and hierarchy are clear.
+- Default WinUI surfaces and control templates carry most of the layout instead of a custom border/card system.
+- Search and filter workflows avoid redundant controls when live local filtering would be clearer.
+- At narrow and phone widths, nonessential controls are simplified, hidden, or moved behind shell affordances instead of merely compressed.
+
+## Code Review Checklist
+
+- App structure is coherent and scalable.
+- Resource dictionaries and styles are centralized where they should be.
+- Platform controls are preferred over unnecessary custom control work.
+- New dependencies are justified.
+- The packaging model matches the startup, storage, and launch code.
+- The app builds cleanly from the workflow the user will actually use.
+
+## Accessibility Checklist
+
+- Keyboard-only flow works end to end.
+- Focus states are visible and sensible.
+- Automation properties are present where needed.
+- High contrast and text scaling do not break the UI.
+
+## Performance Checklist
+
+- No obvious UI-thread blocking work in interactive paths.
+- Large collections use an appropriate control and layout.
+- Scroll ownership is intentional for collection-heavy pages; nested `GridView` plus outer `ScrollViewer` combinations have been justified or replaced.
+- Expensive styling or template choices are justified.
+- Profiling data exists for non-obvious performance claims.
+
+## Debugging Tools
+
+- Use Hot Reload for fast visual iteration.
+- Use Live Visual Tree and Live Property Explorer for layout and property debugging.
+- Use WPR and WPA when diagnosing frame or responsiveness issues.
+- Reproduce resize, theme, and input-mode changes before concluding the issue is fixed.
+- When resize behavior is part of the task, verify wide, medium, and phone-width states against the running app rather than trusting the XAML structure alone.
+- When a collection page looks wrong, inspect the live tree for nested `ScrollViewer` ownership before rewriting the item template; the bug may be layout ownership rather than card markup.
+- Use startup exception details, debugger output, or Event Viewer when the process dies before any window appears.
+
+## Exit Criteria
+
+- The build succeeds from the intended local workflow.
+- The feature works on the intended machine configuration.
+- The app launches and shows the expected shell or window.
+- The app remains usable in light, dark, and high contrast.
+- Primary flows are keyboard-accessible.
+- Resize behavior, startup, and interactive responsiveness have been checked.
+- If the window can become phone-width, the shell and content have been verified there too.

package/docs/skill-candidates/v0.0.10/winui-app/references/windows-app-sdk-lifecycle-notifications-and-deployment.md

@@ -0,0 +1,52 @@
+---
+title: Windows App SDK Lifecycle, Notifications, and Deployment
+priority: HIGH
+tags: windows-app-sdk, lifecycle, activation, notifications, deployment, packaged, unpackaged
+sources:
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-packaged-apps
+  - https://learn.microsoft.com/windows/apps/windows-app-sdk/deploy-unpackaged-apps
+  - https://github.com/microsoft/WindowsAppSDK-Samples
+---
+
+## What This Reference Is For
+
+Use this file when the user needs lifecycle, activation, notification, packaged vs unpackaged, or runtime initialization guidance that goes beyond plain XAML UI work.
+
+## Prefer
+
+- Learning the scenario from the matching WindowsAppSDK sample before designing an abstraction.
+- Packaged deployment when it fits the product constraints.
+- Explicit unpackaged guidance when the user has an installer, external-location requirement, or expects repeatable direct executable launches during development.
+
+## Avoid
+
+- Mixing packaged and unpackaged guidance in one answer without stating which path applies.
+- Treating deployment requirements as optional details.
+- Re-implementing lifecycle behavior already covered by Windows App SDK APIs.
+- Using package-identity-dependent APIs in unpackaged startup code without an explicit guard or replacement path.
+
+## Guidance
+
+- Use AppLifecycle guidance and samples for activation, instancing, restart, and state notifications.
+- Use notifications samples for push or app notifications rather than inventing custom delivery logic.
+- For packaged apps, account for framework-dependent deployment and runtime package requirements.
+- For unpackaged apps, account for bootstrapper and runtime initialization requirements.
+- For unpackaged apps, treat package identity as absent unless the app deliberately establishes it through the chosen deployment model.
+- Keep storage, settings, and startup services aligned with the deployment model. If a service assumes packaged storage or activation, redesign it before local unpackaged verification.
+- Explain the deployment model before giving build or publish steps.
+
+## Sample and Source Anchors
+
+- WindowsAppSDK-Samples `Samples/AppLifecycle`
+- WindowsAppSDK-Samples `Samples/Notifications`
+- WindowsAppSDK-Samples `Samples/Unpackaged`
+- WindowsAppSDK-Samples `Samples/CustomControls`
+- Learn packaged and unpackaged deployment guides
+
+## Review Checklist
+
+- Is the app’s deployment model explicit?
+- Are lifecycle and activation behaviors using platform APIs rather than ad hoc workarounds?
+- Are notification requirements matched to the correct sample and runtime guidance?
+- Does the recommendation match packaged or unpackaged constraints?

package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/SKILL.md

@@ -0,0 +1,399 @@
+---
+name: frontend-dev-guidelines
+description: Frontend development guidelines for React/TypeScript applications. Modern patterns including Suspense, lazy loading, useSuspenseQuery, file organization with features directory, MUI v7 styling, TanStack Router, performance optimization, and TypeScript best practices. Use when creating components, pages, features, fetching data, styling, routing, or working with frontend code.
+---
+
+# Frontend Development Guidelines
+
+## Purpose
+
+Comprehensive guide for modern React development, emphasizing Suspense-based data fetching, lazy loading, proper file organization, and performance optimization.
+
+## When to Use This Skill
+
+- Creating new components or pages
+- Building new features
+- Fetching data with TanStack Query
+- Setting up routing with TanStack Router
+- Styling components with MUI v7
+- Performance optimization
+- Organizing frontend code
+- TypeScript best practices
+
+---
+
+## Quick Start
+
+### New Component Checklist
+
+Creating a component? Follow this checklist:
+
+- [ ] Use `React.FC<Props>` pattern with TypeScript
+- [ ] Lazy load if heavy component: `React.lazy(() => import())`
+- [ ] Wrap in `<SuspenseLoader>` for loading states
+- [ ] Use `useSuspenseQuery` for data fetching
+- [ ] Import aliases: `@/`, `~types`, `~components`, `~features`
+- [ ] Styles: Inline if <100 lines, separate file if >100 lines
+- [ ] Use `useCallback` for event handlers passed to children
+- [ ] Default export at bottom
+- [ ] No early returns with loading spinners
+- [ ] Use `useMuiSnackbar` for user notifications
+
+### New Feature Checklist
+
+Creating a feature? Set up this structure:
+
+- [ ] Create `features/{feature-name}/` directory
+- [ ] Create subdirectories: `api/`, `components/`, `hooks/`, `helpers/`, `types/`
+- [ ] Create API service file: `api/{feature}Api.ts`
+- [ ] Set up TypeScript types in `types/`
+- [ ] Create route in `routes/{feature-name}/index.tsx`
+- [ ] Lazy load feature components
+- [ ] Use Suspense boundaries
+- [ ] Export public API from feature `index.ts`
+
+---
+
+## Import Aliases Quick Reference
+
+| Alias | Resolves To | Example |
+|-------|-------------|---------|
+| `@/` | `src/` | `import { apiClient } from '@/lib/apiClient'` |
+| `~types` | `src/types` | `import type { User } from '~types/user'` |
+| `~components` | `src/components` | `import { SuspenseLoader } from '~components/SuspenseLoader'` |
+| `~features` | `src/features` | `import { authApi } from '~features/auth'` |
+
+Defined in: [vite.config.ts](../../vite.config.ts) lines 180-185
+
+---
+
+## Common Imports Cheatsheet
+
+```typescript
+// React & Lazy Loading
+import React, { useState, useCallback, useMemo } from 'react';
+const Heavy = React.lazy(() => import('./Heavy'));
+
+// MUI Components
+import { Box, Paper, Typography, Button, Grid } from '@mui/material';
+import type { SxProps, Theme } from '@mui/material';
+
+// TanStack Query (Suspense)
+import { useSuspenseQuery, useQueryClient } from '@tanstack/react-query';
+
+// TanStack Router
+import { createFileRoute } from '@tanstack/react-router';
+
+// Project Components
+import { SuspenseLoader } from '~components/SuspenseLoader';
+
+// Hooks
+import { useAuth } from '@/hooks/useAuth';
+import { useMuiSnackbar } from '@/hooks/useMuiSnackbar';
+
+// Types
+import type { Post } from '~types/post';
+```
+
+---
+
+## Topic Guides
+
+### 🎨 Component Patterns
+
+**Modern React components use:**
+- `React.FC<Props>` for type safety
+- `React.lazy()` for code splitting
+- `SuspenseLoader` for loading states
+- Named const + default export pattern
+
+**Key Concepts:**
+- Lazy load heavy components (DataGrid, charts, editors)
+- Always wrap lazy components in Suspense
+- Use SuspenseLoader component (with fade animation)
+- Component structure: Props → Hooks → Handlers → Render → Export
+
+**[📖 Complete Guide: resources/component-patterns.md](resources/component-patterns.md)**
+
+---
+
+### 📊 Data Fetching
+
+**PRIMARY PATTERN: useSuspenseQuery**
+- Use with Suspense boundaries
+- Cache-first strategy (check grid cache before API)
+- Replaces `isLoading` checks
+- Type-safe with generics
+
+**API Service Layer:**
+- Create `features/{feature}/api/{feature}Api.ts`
+- Use `apiClient` axios instance
+- Centralized methods per feature
+- Route format: `/form/route` (NOT `/api/form/route`)
+
+**[📖 Complete Guide: resources/data-fetching.md](resources/data-fetching.md)**
+
+---
+
+### 📁 File Organization
+
+**features/ vs components/:**
+- `features/`: Domain-specific (posts, comments, auth)
+- `components/`: Truly reusable (SuspenseLoader, CustomAppBar)
+
+**Feature Subdirectories:**
+```
+features/
+  my-feature/
+    api/          # API service layer
+    components/   # Feature components
+    hooks/        # Custom hooks
+    helpers/      # Utility functions
+    types/        # TypeScript types
+```
+
+**[📖 Complete Guide: resources/file-organization.md](resources/file-organization.md)**
+
+---
+
+### 🎨 Styling
+
+**Inline vs Separate:**
+- <100 lines: Inline `const styles: Record<string, SxProps<Theme>>`
+- >100 lines: Separate `.styles.ts` file
+
+**Primary Method:**
+- Use `sx` prop for MUI components
+- Type-safe with `SxProps<Theme>`
+- Theme access: `(theme) => theme.palette.primary.main`
+
+**MUI v7 Grid:**
+```typescript
+<Grid size={{ xs: 12, md: 6 }}>  // ✅ v7 syntax
+<Grid xs={12} md={6}>             // ❌ Old syntax
+```
+
+**[📖 Complete Guide: resources/styling-guide.md](resources/styling-guide.md)**
+
+---
+
+### 🛣️ Routing
+
+**TanStack Router - Folder-Based:**
+- Directory: `routes/my-route/index.tsx`
+- Lazy load components
+- Use `createFileRoute`
+- Breadcrumb data in loader
+
+**Example:**
+```typescript
+import { createFileRoute } from '@tanstack/react-router';
+import { lazy } from 'react';
+
+const MyPage = lazy(() => import('@/features/my-feature/components/MyPage'));
+
+export const Route = createFileRoute('/my-route/')({
+    component: MyPage,
+    loader: () => ({ crumb: 'My Route' }),
+});
+```
+
+**[📖 Complete Guide: resources/routing-guide.md](resources/routing-guide.md)**
+
+---
+
+### ⏳ Loading & Error States
+
+**CRITICAL RULE: No Early Returns**
+
+```typescript
+// ❌ NEVER - Causes layout shift
+if (isLoading) {
+    return <LoadingSpinner />;
+}
+
+// ✅ ALWAYS - Consistent layout
+<SuspenseLoader>
+    <Content />
+</SuspenseLoader>
+```
+
+**Why:** Prevents Cumulative Layout Shift (CLS), better UX
+
+**Error Handling:**
+- Use `useMuiSnackbar` for user feedback
+- NEVER `react-toastify`
+- TanStack Query `onError` callbacks
+
+**[📖 Complete Guide: resources/loading-and-error-states.md](resources/loading-and-error-states.md)**
+
+---
+
+### ⚡ Performance
+
+**Optimization Patterns:**
+- `useMemo`: Expensive computations (filter, sort, map)
+- `useCallback`: Event handlers passed to children
+- `React.memo`: Expensive components
+- Debounced search (300-500ms)
+- Memory leak prevention (cleanup in useEffect)
+
+**[📖 Complete Guide: resources/performance.md](resources/performance.md)**
+
+---
+
+### 📘 TypeScript
+
+**Standards:**
+- Strict mode, no `any` type
+- Explicit return types on functions
+- Type imports: `import type { User } from '~types/user'`
+- Component prop interfaces with JSDoc
+
+**[📖 Complete Guide: resources/typescript-standards.md](resources/typescript-standards.md)**
+
+---
+
+### 🔧 Common Patterns
+
+**Covered Topics:**
+- React Hook Form with Zod validation
+- DataGrid wrapper contracts
+- Dialog component standards
+- `useAuth` hook for current user
+- Mutation patterns with cache invalidation
+
+**[📖 Complete Guide: resources/common-patterns.md](resources/common-patterns.md)**
+
+---
+
+### 📚 Complete Examples
+
+**Full working examples:**
+- Modern component with all patterns
+- Complete feature structure
+- API service layer
+- Route with lazy loading
+- Suspense + useSuspenseQuery
+- Form with validation
+
+**[📖 Complete Guide: resources/complete-examples.md](resources/complete-examples.md)**
+
+---
+
+## Navigation Guide
+
+| Need to... | Read this resource |
+|------------|-------------------|
+| Create a component | [component-patterns.md](resources/component-patterns.md) |
+| Fetch data | [data-fetching.md](resources/data-fetching.md) |
+| Organize files/folders | [file-organization.md](resources/file-organization.md) |
+| Style components | [styling-guide.md](resources/styling-guide.md) |
+| Set up routing | [routing-guide.md](resources/routing-guide.md) |
+| Handle loading/errors | [loading-and-error-states.md](resources/loading-and-error-states.md) |
+| Optimize performance | [performance.md](resources/performance.md) |
+| TypeScript types | [typescript-standards.md](resources/typescript-standards.md) |
+| Forms/Auth/DataGrid | [common-patterns.md](resources/common-patterns.md) |
+| See full examples | [complete-examples.md](resources/complete-examples.md) |
+
+---
+
+## Core Principles
+
+1. **Lazy Load Everything Heavy**: Routes, DataGrid, charts, editors
+2. **Suspense for Loading**: Use SuspenseLoader, not early returns
+3. **useSuspenseQuery**: Primary data fetching pattern for new code
+4. **Features are Organized**: api/, components/, hooks/, helpers/ subdirs
+5. **Styles Based on Size**: <100 inline, >100 separate
+6. **Import Aliases**: Use @/, ~types, ~components, ~features
+7. **No Early Returns**: Prevents layout shift
+8. **useMuiSnackbar**: For all user notifications
+
+---
+
+## Quick Reference: File Structure
+
+```
+src/
+  features/
+    my-feature/
+      api/
+        myFeatureApi.ts       # API service
+      components/
+        MyFeature.tsx         # Main component
+        SubComponent.tsx      # Related components
+      hooks/
+        useMyFeature.ts       # Custom hooks
+        useSuspenseMyFeature.ts  # Suspense hooks
+      helpers/
+        myFeatureHelpers.ts   # Utilities
+      types/
+        index.ts              # TypeScript types
+      index.ts                # Public exports
+
+  components/
+    SuspenseLoader/
+      SuspenseLoader.tsx      # Reusable loader
+    CustomAppBar/
+      CustomAppBar.tsx        # Reusable app bar
+
+  routes/
+    my-route/
+      index.tsx               # Route component
+      create/
+        index.tsx             # Nested route
+```
+
+---
+
+## Modern Component Template (Quick Copy)
+
+```typescript
+import React, { useState, useCallback } from 'react';
+import { Box, Paper } from '@mui/material';
+import { useSuspenseQuery } from '@tanstack/react-query';
+import { featureApi } from '../api/featureApi';
+import type { FeatureData } from '~types/feature';
+
+interface MyComponentProps {
+    id: number;
+    onAction?: () => void;
+}
+
+export const MyComponent: React.FC<MyComponentProps> = ({ id, onAction }) => {
+    const [state, setState] = useState<string>('');
+
+    const { data } = useSuspenseQuery({
+        queryKey: ['feature', id],
+        queryFn: () => featureApi.getFeature(id),
+    });
+
+    const handleAction = useCallback(() => {
+        setState('updated');
+        onAction?.();
+    }, [onAction]);
+
+    return (
+        <Box sx={{ p: 2 }}>
+            <Paper sx={{ p: 3 }}>
+                {/* Content */}
+            </Paper>
+        </Box>
+    );
+};
+
+export default MyComponent;
+```
+
+For complete examples, see [resources/complete-examples.md](resources/complete-examples.md)
+
+---
+
+## Related Skills
+
+- **error-tracking**: Error tracking with Sentry (applies to frontend too)
+- **backend-dev-guidelines**: Backend API patterns that frontend consumes
+
+---
+
+**Skill Status**: Modular structure with progressive loading for optimal context management