@ryuenn3123/agentic-senior-core 2.0.4 → 2.0.5

package/.agent-context/skills/frontend/README.md

@@ -1,36 +1,36 @@
-# Frontend Engineering Skills
-
-The frontend domain covers component architecture, state management, performance optimization, accessibility, motion design, and visual polish. Content consolidated from **minimax-ai/skills** (design focus), **awesome-copilot** (architectural patterns), and **antigravity-awesome-skills** (React patterns), with production-grade automation and enforcement.
-
-## Topics
-- [UI Architecture](ui-architecture.md) - Smart/Dumb components, state management, composition patterns
-- [Accessibility](accessibility.md) - WCAG compliance, keyboard navigation, semantic HTML, color contrast
-- [Motion](motion.md) - Animation patterns, performance, CSS containment
-- [Performance](performance.md) - Memoization, code splitting, bundle gates, profiling
-
-## What Makes Ours Different
-
-- Smart/Dumb Architecture (awesome-copilot) + animation system patterns (minimax) + React patterns (antigravity)
-- Anti-Slop Enforcer (ABOVE LINE) - Detect forbidden visual patterns and style drift
-- Accessibility Auditor (ABOVE LINE) - Detect contrast failures, ARIA issues, and keyboard navigation gaps
-- Performance Budget Enforcer (ABOVE LINE) - Bundle size gates and LCP/FID/CLS thresholds
-
-## Recommended Reading Order
-
-1. `ui-architecture.md` - Mental models first (EXPERT)
-2. `accessibility.md` - Compliance baseline (EXPERT)
-3. `motion.md` - Design patterns and optimization (EXPERT)
-4. `performance.md` - Profiling and gates (EXPERT)
-
-## Coverage vs 3 Repos
-
-| Aspect | antigravity | awesome-copilot | MiniMax | Ours |
-|--------|-------------|-----------------|---------|------|
-| Component Patterns | Medium | High | Medium | High + quality gates |
-| Animation Patterns | Low | Low | High | High + performance rules |
-| Accessibility | Medium | High | Medium | High + automated audits |
-| Automation | None | None | None | Anti-slop, accessibility, and performance tooling |
-
-## Default Tier Behavior
-- Use `advance` for typical web apps (1500+ employees)
+# Frontend Engineering Skills
+
+The frontend domain covers component architecture, state management, performance optimization, accessibility, motion design, and visual polish. Content consolidated from **minimax-ai/skills** (design focus), **awesome-copilot** (architectural patterns), and **antigravity-awesome-skills** (React patterns), with production-grade automation and enforcement.
+
+## Topics
+- [UI Architecture](ui-architecture.md) - Smart/Dumb components, state management, composition patterns
+- [Accessibility](accessibility.md) - WCAG compliance, keyboard navigation, semantic HTML, color contrast
+- [Motion](motion.md) - Animation patterns, performance, CSS containment
+- [Performance](performance.md) - Memoization, code splitting, bundle gates, profiling
+
+## What Makes Ours Different
+
+- Smart/Dumb Architecture (awesome-copilot) + animation system patterns (minimax) + React patterns (antigravity)
+- Anti-Slop Enforcer (ABOVE LINE) - Detect forbidden visual patterns and style drift
+- Accessibility Auditor (ABOVE LINE) - Detect contrast failures, ARIA issues, and keyboard navigation gaps
+- Performance Budget Enforcer (ABOVE LINE) - Bundle size gates and LCP/FID/CLS thresholds
+
+## Recommended Reading Order
+
+1. `ui-architecture.md` - Mental models first (EXPERT)
+2. `accessibility.md` - Compliance baseline (EXPERT)
+3. `motion.md` - Design patterns and optimization (EXPERT)
+4. `performance.md` - Profiling and gates (EXPERT)
+
+## Coverage vs 3 Repos
+
+| Aspect | antigravity | awesome-copilot | MiniMax | Ours |
+|--------|-------------|-----------------|---------|------|
+| Component Patterns | Medium | High | Medium | High + quality gates |
+| Animation Patterns | Low | Low | High | High + performance rules |
+| Accessibility | Medium | High | Medium | High + automated audits |
+| Automation | None | None | None | Anti-slop, accessibility, and performance tooling |
+
+## Default Tier Behavior
+- Use `advance` for typical web apps (1500+ employees)
 - Escalate to `expert` when component library, state complexity, or accessibility/performance tuning is critical

package/.agent-context/skills/frontend/accessibility.md

@@ -1,107 +1,107 @@
-# Accessibility and Inclusive Interaction
-
-**Tier:** EXPERT | **Source:** awesome-copilot (WCAG) + minimax (motion and dark mode) + antigravity (UX patterns)
-
-## Purpose
-
-Accessibility is a production requirement. Inclusive interaction reduces support burden, improves usability, and prevents last-minute retrofit work.
-
-## Part 1: Semantic Structure
-
-Use native HTML elements first. They provide keyboard support, roles, and state semantics without extra work.
-
-```javascript
-<nav>
-  <button aria-expanded={isOpen} aria-controls="menu-panel">Menu</button>
-  <ul id="menu-panel" hidden={!isOpen}>
-    <li><a href="/">Home</a></li>
-    <li><a href="/about">About</a></li>
-  </ul>
-</nav>
-```
-
-Avoid replacing native controls with generic containers unless there is a specific reason.
-
-## Part 2: Keyboard Support
-
-Every interactive control must be reachable and operable by keyboard.
-
-- Tab order should follow the visual order.
-- Enter and Space should activate buttons and custom controls.
-- Focus should never get trapped unless a modal or dialog deliberately manages it.
-- Skip links should exist on content-heavy pages.
-
-```javascript
-<div
-  role="button"
-  tabIndex={0}
-  onClick={handleDelete}
-  onKeyDown={(event) => {
-    if (event.key === 'Enter' || event.key === ' ') {
-      handleDelete();
-    }
-  }}
->
-  Delete
-</div>
-```
-
-## Part 3: Contrast and Text Scaling
-
-- Normal text contrast should meet WCAG AA minimums.
-- Large text may use the relaxed large-text ratio, but still needs clear contrast.
-- Layouts should survive zoom and text scaling without truncation.
-- Avoid fixed-height containers that clip longer translated content.
-
-## Part 4: Screen Reader Support
-
-Use accessible names and state descriptions.
-
-```javascript
-<button aria-label="Close menu" onClick={handleClose}>
-  X
-</button>
-```
-
-If content updates dynamically, use live regions only when needed and keep them concise.
-
-## Part 5: Motion and Reduced Motion
-
-Animations should respect reduced-motion settings. Motion must support understanding, not create distraction.
-
-```javascript
-const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
-
-const menuVariants = {
-  open: {
-    opacity: 1,
-    transition: prefersReducedMotion ? { duration: 0 } : { duration: 0.2 }
-  }
-};
-```
-
-## Part 6: Forms and Error Messaging
-
-- Every input needs a visible label.
-- Error messages should describe the problem and how to fix it.
-- Validation should be announced in a way screen readers can reach.
-- Do not rely on color alone to communicate state.
-
-## Part 7: Testing Approach
-
-Test accessibility with a mix of manual and automated checks.
-
-- Automated scans for contrast, labels, and roles.
-- Keyboard-only navigation passes for critical flows.
-- Screen-reader spot checks for key screens.
-- Motion tests for reduced-motion behavior.
-
-## Review Checklist
-
-- [ ] Semantic elements are used first.
-- [ ] Keyboard operation is complete.
-- [ ] Contrast and zoom behavior are acceptable.
-- [ ] Accessible names exist for icon-only controls.
-- [ ] Reduced-motion behavior is implemented.
-- [ ] Form labels and errors are clear.
-- [ ] Critical flows are tested with keyboard and screen readers.
+# Accessibility and Inclusive Interaction
+
+**Tier:** EXPERT | **Source:** awesome-copilot (WCAG) + minimax (motion and dark mode) + antigravity (UX patterns)
+
+## Purpose
+
+Accessibility is a production requirement. Inclusive interaction reduces support burden, improves usability, and prevents last-minute retrofit work.
+
+## Part 1: Semantic Structure
+
+Use native HTML elements first. They provide keyboard support, roles, and state semantics without extra work.
+
+```javascript
+<nav>
+  <button aria-expanded={isOpen} aria-controls="menu-panel">Menu</button>
+  <ul id="menu-panel" hidden={!isOpen}>
+    <li><a href="/">Home</a></li>
+    <li><a href="/about">About</a></li>
+  </ul>
+</nav>
+```
+
+Avoid replacing native controls with generic containers unless there is a specific reason.
+
+## Part 2: Keyboard Support
+
+Every interactive control must be reachable and operable by keyboard.
+
+- Tab order should follow the visual order.
+- Enter and Space should activate buttons and custom controls.
+- Focus should never get trapped unless a modal or dialog deliberately manages it.
+- Skip links should exist on content-heavy pages.
+
+```javascript
+<div
+  role="button"
+  tabIndex={0}
+  onClick={handleDelete}
+  onKeyDown={(event) => {
+    if (event.key === 'Enter' || event.key === ' ') {
+      handleDelete();
+    }
+  }}
+>
+  Delete
+</div>
+```
+
+## Part 3: Contrast and Text Scaling
+
+- Normal text contrast should meet WCAG AA minimums.
+- Large text may use the relaxed large-text ratio, but still needs clear contrast.
+- Layouts should survive zoom and text scaling without truncation.
+- Avoid fixed-height containers that clip longer translated content.
+
+## Part 4: Screen Reader Support
+
+Use accessible names and state descriptions.
+
+```javascript
+<button aria-label="Close menu" onClick={handleClose}>
+  X
+</button>
+```
+
+If content updates dynamically, use live regions only when needed and keep them concise.
+
+## Part 5: Motion and Reduced Motion
+
+Animations should respect reduced-motion settings. Motion must support understanding, not create distraction.
+
+```javascript
+const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
+
+const menuVariants = {
+  open: {
+    opacity: 1,
+    transition: prefersReducedMotion ? { duration: 0 } : { duration: 0.2 }
+  }
+};
+```
+
+## Part 6: Forms and Error Messaging
+
+- Every input needs a visible label.
+- Error messages should describe the problem and how to fix it.
+- Validation should be announced in a way screen readers can reach.
+- Do not rely on color alone to communicate state.
+
+## Part 7: Testing Approach
+
+Test accessibility with a mix of manual and automated checks.
+
+- Automated scans for contrast, labels, and roles.
+- Keyboard-only navigation passes for critical flows.
+- Screen-reader spot checks for key screens.
+- Motion tests for reduced-motion behavior.
+
+## Review Checklist
+
+- [ ] Semantic elements are used first.
+- [ ] Keyboard operation is complete.
+- [ ] Contrast and zoom behavior are acceptable.
+- [ ] Accessible names exist for icon-only controls.
+- [ ] Reduced-motion behavior is implemented.
+- [ ] Form labels and errors are clear.
+- [ ] Critical flows are tested with keyboard and screen readers.

package/.agent-context/skills/frontend/compatibility-manifest.json

@@ -1,8 +1,8 @@
-{
-  "schemaVersion": "compatibility-manifest-v1",
-  "artifactType": "skill-domain",
-  "domain": "frontend",
-  "ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
-  "nodeMin": "18",
-  "platforms": ["windows", "linux", "macos"]
-}
+{
+  "schemaVersion": "compatibility-manifest-v1",
+  "artifactType": "skill-domain",
+  "domain": "frontend",
+  "ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
+  "nodeMin": "18",
+  "platforms": ["windows", "linux", "macos"]
+}

package/.agent-context/skills/frontend/motion.md

@@ -1,67 +1,67 @@
-# Motion Design and Implementation
-
-Tier: EXPERT
-
-Motion is part of product behavior. It should clarify state changes, guide focus, and provide feedback without reducing accessibility or performance.
-
-## Motion Intent Model
-
-Use motion only for one of these intents:
-- Transition intent: communicate screen or state transition.
-- Feedback intent: confirm user action success/failure.
-- Focus intent: direct attention to newly relevant content.
-
-If a transition has no intent, remove it.
-
-## Timing and Consistency
-
-Adopt a small timing scale and reuse it across the product:
-- Fast: 120ms for micro-feedback.
-- Standard: 200ms to 260ms for component transitions.
-- Slow: 320ms to 420ms for route transitions.
-
-Avoid mixing unrelated easing curves in one flow.
-
-## Performance-Safe Animation Rules
-
-Prefer animating properties that do not trigger expensive layout and paint work:
-- Preferred: transform, opacity.
-- Avoid for frequent animation: top, left, width, height, box-shadow blur radius.
-
-Use CSS containment and selective `will-change` only for elements that actually animate.
-
-## Reduced Motion Compliance
-
-Always implement reduced-motion fallback:
-
-```css
-.panel {
-	transition: transform 220ms ease, opacity 220ms ease;
-}
-
-@media (prefers-reduced-motion: reduce) {
-	.panel {
-		transition: none;
-	}
-}
-```
-
-## Interaction Patterns
-
-Recommended patterns:
-- Enter/exit fade + translate for dialogs.
-- Staggered list reveal for scannability on load.
-- Subtle press/hover feedback for actionable controls.
-
-Avoid these patterns:
-- Continuous decorative motion on primary content.
-- Multiple competing animations in one viewport.
-- Looping movement that can distract reading flow.
-
-## Review Checklist
-
-- [ ] Every animation has explicit product intent.
-- [ ] Timing scale is consistent across components.
-- [ ] Heavy layout-triggering properties are avoided.
-- [ ] Reduced-motion mode is implemented and tested.
+# Motion Design and Implementation
+
+Tier: EXPERT
+
+Motion is part of product behavior. It should clarify state changes, guide focus, and provide feedback without reducing accessibility or performance.
+
+## Motion Intent Model
+
+Use motion only for one of these intents:
+- Transition intent: communicate screen or state transition.
+- Feedback intent: confirm user action success/failure.
+- Focus intent: direct attention to newly relevant content.
+
+If a transition has no intent, remove it.
+
+## Timing and Consistency
+
+Adopt a small timing scale and reuse it across the product:
+- Fast: 120ms for micro-feedback.
+- Standard: 200ms to 260ms for component transitions.
+- Slow: 320ms to 420ms for route transitions.
+
+Avoid mixing unrelated easing curves in one flow.
+
+## Performance-Safe Animation Rules
+
+Prefer animating properties that do not trigger expensive layout and paint work:
+- Preferred: transform, opacity.
+- Avoid for frequent animation: top, left, width, height, box-shadow blur radius.
+
+Use CSS containment and selective `will-change` only for elements that actually animate.
+
+## Reduced Motion Compliance
+
+Always implement reduced-motion fallback:
+
+```css
+.panel {
+	transition: transform 220ms ease, opacity 220ms ease;
+}
+
+@media (prefers-reduced-motion: reduce) {
+	.panel {
+		transition: none;
+	}
+}
+```
+
+## Interaction Patterns
+
+Recommended patterns:
+- Enter/exit fade + translate for dialogs.
+- Staggered list reveal for scannability on load.
+- Subtle press/hover feedback for actionable controls.
+
+Avoid these patterns:
+- Continuous decorative motion on primary content.
+- Multiple competing animations in one viewport.
+- Looping movement that can distract reading flow.
+
+## Review Checklist
+
+- [ ] Every animation has explicit product intent.
+- [ ] Timing scale is consistent across components.
+- [ ] Heavy layout-triggering properties are avoided.
+- [ ] Reduced-motion mode is implemented and tested.
 - [ ] Motion does not block keyboard or screen-reader flow.

package/.agent-context/skills/frontend/performance.md

@@ -1,63 +1,63 @@
-# Frontend Performance Engineering
-
-Tier: EXPERT
-
-Performance work should be evidence-driven. Start with baseline metrics, optimize where bottlenecks are proven, then verify that user-facing indicators improved.
-
-## Core Metrics
-
-Track Core Web Vitals in CI and release checks:
-- LCP target: less than 2.5s on reference environments.
-- INP target: less than 200ms.
-- CLS target: less than 0.1.
-
-Also track bundle size and script execution time for key routes.
-
-## Render Efficiency
-
-Common controls:
-- Keep expensive computation outside render path with memoization.
-- Use stable callbacks for memoized child components.
-- Split large component trees by feature boundary.
-
-```javascript
-const visibleRows = useMemo(() => {
-	return allRows.filter((row) => row.isVisible);
-}, [allRows]);
-
-const handleRowOpen = useCallback((rowId) => {
-	openRowDetails(rowId);
-}, [openRowDetails]);
-```
-
-## Network and Caching Strategy
-
-- Treat server state separately from UI state.
-- Use query caching with explicit stale policies.
-- Avoid duplicate API calls by keying requests consistently.
-
-For route transitions, prefetch data for likely next navigation paths.
-
-## Bundle Governance
-
-Use route and component-level code splitting:
-- Lazy-load non-critical routes.
-- Defer optional heavy modules until needed.
-- Audit bundle growth at each release.
-
-Set a budget and fail CI on unapproved bundle-size regressions.
-
-## Diagnostics Workflow
-
-1. Capture baseline profile and web-vitals report.
-2. Apply one optimization change.
-3. Re-profile and compare deltas.
-4. Keep only changes with measurable improvement.
-
-## Review Checklist
-
-- [ ] Core metrics targets are monitored and reported.
-- [ ] Render-heavy paths are profiled with tooling evidence.
-- [ ] Data fetching uses cache and deduplication strategy.
-- [ ] Bundle-size budget is defined and enforced.
+# Frontend Performance Engineering
+
+Tier: EXPERT
+
+Performance work should be evidence-driven. Start with baseline metrics, optimize where bottlenecks are proven, then verify that user-facing indicators improved.
+
+## Core Metrics
+
+Track Core Web Vitals in CI and release checks:
+- LCP target: less than 2.5s on reference environments.
+- INP target: less than 200ms.
+- CLS target: less than 0.1.
+
+Also track bundle size and script execution time for key routes.
+
+## Render Efficiency
+
+Common controls:
+- Keep expensive computation outside render path with memoization.
+- Use stable callbacks for memoized child components.
+- Split large component trees by feature boundary.
+
+```javascript
+const visibleRows = useMemo(() => {
+	return allRows.filter((row) => row.isVisible);
+}, [allRows]);
+
+const handleRowOpen = useCallback((rowId) => {
+	openRowDetails(rowId);
+}, [openRowDetails]);
+```
+
+## Network and Caching Strategy
+
+- Treat server state separately from UI state.
+- Use query caching with explicit stale policies.
+- Avoid duplicate API calls by keying requests consistently.
+
+For route transitions, prefetch data for likely next navigation paths.
+
+## Bundle Governance
+
+Use route and component-level code splitting:
+- Lazy-load non-critical routes.
+- Defer optional heavy modules until needed.
+- Audit bundle growth at each release.
+
+Set a budget and fail CI on unapproved bundle-size regressions.
+
+## Diagnostics Workflow
+
+1. Capture baseline profile and web-vitals report.
+2. Apply one optimization change.
+3. Re-profile and compare deltas.
+4. Keep only changes with measurable improvement.
+
+## Review Checklist
+
+- [ ] Core metrics targets are monitored and reported.
+- [ ] Render-heavy paths are profiled with tooling evidence.
+- [ ] Data fetching uses cache and deduplication strategy.
+- [ ] Bundle-size budget is defined and enforced.
 - [ ] Performance regressions are blocked until reviewed.