@ryuenn3123/agentic-senior-core 2.0.5 → 2.0.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agent-context/blueprints/mobile-app.md +91 -21
- package/.agent-context/profiles/platform.md +13 -13
- package/.agent-context/profiles/regulated.md +13 -13
- package/.agent-context/profiles/startup.md +13 -13
- package/.agent-context/prompts/review-code.md +3 -3
- package/.agent-context/review-checklists/frontend-skill-parity.md +28 -28
- package/.agent-context/review-checklists/frontend-usability.md +33 -33
- package/.agent-context/review-checklists/pr-checklist.md +11 -6
- package/.agent-context/review-checklists/release-operations.md +29 -29
- package/.agent-context/rules/api-docs.md +34 -0
- package/.agent-context/skills/README.md +62 -62
- package/.agent-context/skills/backend/README.md +67 -67
- package/.agent-context/skills/backend/architecture.md +360 -360
- package/.agent-context/skills/backend/compatibility-manifest.json +8 -8
- package/.agent-context/skills/backend/data-access.md +230 -230
- package/.agent-context/skills/backend/errors.md +137 -137
- package/.agent-context/skills/backend/validation.md +116 -116
- package/.agent-context/skills/backend.md +28 -28
- package/.agent-context/skills/cli/README.md +55 -49
- package/.agent-context/skills/cli/compatibility-manifest.json +8 -8
- package/.agent-context/skills/cli/init.md +37 -37
- package/.agent-context/skills/cli/output.md +35 -35
- package/.agent-context/skills/cli/safety-telemetry.md +39 -0
- package/.agent-context/skills/cli/upgrade.md +37 -37
- package/.agent-context/skills/cli.md +31 -28
- package/.agent-context/skills/distribution/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/distribution/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/distribution/.evidence/test-report.json +8 -0
- package/.agent-context/skills/distribution/CHANGELOG.md +7 -0
- package/.agent-context/skills/distribution/README.md +27 -19
- package/.agent-context/skills/distribution/compatibility-manifest.json +8 -8
- package/.agent-context/skills/distribution/compatibility.md +31 -31
- package/.agent-context/skills/distribution/package.json +5 -0
- package/.agent-context/skills/distribution/provenance-attestation.md +47 -0
- package/.agent-context/skills/distribution/publish.md +36 -36
- package/.agent-context/skills/distribution/rollback.md +31 -31
- package/.agent-context/skills/distribution/tests/.gitkeep +1 -0
- package/.agent-context/skills/distribution.md +31 -28
- package/.agent-context/skills/frontend/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/frontend/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/frontend/.evidence/test-report.json +8 -0
- package/.agent-context/skills/frontend/CHANGELOG.md +7 -0
- package/.agent-context/skills/frontend/README.md +49 -36
- package/.agent-context/skills/frontend/accessibility.md +107 -107
- package/.agent-context/skills/frontend/compatibility-manifest.json +8 -8
- package/.agent-context/skills/frontend/conversion-clarity.md +51 -0
- package/.agent-context/skills/frontend/motion.md +66 -66
- package/.agent-context/skills/frontend/package.json +5 -0
- package/.agent-context/skills/frontend/performance.md +62 -62
- package/.agent-context/skills/frontend/responsive-delivery.md +41 -0
- package/.agent-context/skills/frontend/tests/.gitkeep +1 -0
- package/.agent-context/skills/frontend/ui-architecture.md +128 -128
- package/.agent-context/skills/frontend.md +35 -29
- package/.agent-context/skills/fullstack/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/fullstack/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/fullstack/.evidence/test-report.json +8 -0
- package/.agent-context/skills/fullstack/CHANGELOG.md +7 -0
- package/.agent-context/skills/fullstack/README.md +27 -19
- package/.agent-context/skills/fullstack/compatibility-manifest.json +8 -8
- package/.agent-context/skills/fullstack/contracts.md +52 -52
- package/.agent-context/skills/fullstack/end-to-end.md +41 -41
- package/.agent-context/skills/fullstack/feature-slicing.md +64 -64
- package/.agent-context/skills/fullstack/package.json +5 -0
- package/.agent-context/skills/fullstack/release-coordination.md +51 -0
- package/.agent-context/skills/fullstack/tests/.gitkeep +1 -0
- package/.agent-context/skills/fullstack.md +29 -26
- package/.agent-context/skills/index.json +107 -107
- package/.agent-context/skills/review-quality/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/review-quality/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/review-quality/.evidence/test-report.json +8 -0
- package/.agent-context/skills/review-quality/CHANGELOG.md +7 -0
- package/.agent-context/skills/review-quality/README.md +27 -19
- package/.agent-context/skills/review-quality/benchmark.md +29 -29
- package/.agent-context/skills/review-quality/compatibility-manifest.json +8 -8
- package/.agent-context/skills/review-quality/package.json +5 -0
- package/.agent-context/skills/review-quality/planning.md +37 -37
- package/.agent-context/skills/review-quality/release-decision.md +49 -0
- package/.agent-context/skills/review-quality/security.md +33 -33
- package/.agent-context/skills/review-quality/tests/.gitkeep +1 -0
- package/.agent-context/skills/review-quality.md +33 -27
- package/.agent-context/stacks/flutter.md +16 -16
- package/.agent-context/stacks/react-native.md +16 -16
- package/.agent-context/state/architecture-map.md +25 -25
- package/.agent-context/state/benchmark-analysis.json +431 -431
- package/.agent-context/state/benchmark-thresholds.json +10 -10
- package/.agent-context/state/benchmark-watchlist.json +19 -19
- package/.agent-context/state/dependency-map.md +32 -32
- package/.agent-context/state/quality-trend-report.json +16 -6
- package/.agent-context/state/skill-platform.json +38 -38
- package/.agent-context/state/weekly-governance-report.json +126 -0
- package/.agent-override.md +36 -36
- package/.cursorrules +1 -1
- package/.gemini/instructions.md +20 -20
- package/.github/ISSUE_TEMPLATE/v1.7-frontend-work-item.yml +54 -54
- package/.github/copilot-instructions.md +21 -21
- package/.github/workflows/benchmark-detection.yml +38 -38
- package/.github/workflows/benchmark-intelligence.yml +50 -50
- package/.github/workflows/frontend-usability-gate.yml +36 -36
- package/.github/workflows/governance-weekly-report.yml +43 -0
- package/.github/workflows/release-gate.yml +32 -32
- package/.github/workflows/sbom-compliance.yml +32 -32
- package/.windsurfrules +1 -1
- package/AGENTS.md +27 -27
- package/README.md +389 -368
- package/lib/cli/commands/init.mjs +13 -1
- package/lib/cli/commands/optimize.mjs +171 -171
- package/lib/cli/commands/upgrade.mjs +9 -1
- package/lib/cli/compatibility.mjs +124 -124
- package/lib/cli/constants.mjs +37 -2
- package/lib/cli/token-optimization.mjs +275 -275
- package/lib/cli/utils.mjs +24 -3
- package/mcp.json +92 -92
- package/package.json +2 -1
- package/scripts/benchmark-gate.mjs +121 -121
- package/scripts/benchmark-intelligence.mjs +140 -140
- package/scripts/detection-benchmark.mjs +138 -138
- package/scripts/frontend-usability-audit.mjs +87 -87
- package/scripts/generate-sbom.mjs +61 -61
- package/scripts/governance-weekly-report.mjs +293 -0
- package/scripts/init-project.ps1 +104 -104
- package/scripts/llm-judge.mjs +664 -664
- package/scripts/quality-trend-report.mjs +288 -288
- package/scripts/release-gate.mjs +261 -259
- package/scripts/skill-tier-policy.mjs +75 -75
- package/scripts/token-optimization-benchmark.mjs +252 -252
- package/scripts/validate.mjs +942 -865
|
@@ -1,67 +1,67 @@
|
|
|
1
|
-
# Motion Design and Implementation
|
|
2
|
-
|
|
3
|
-
Tier: EXPERT
|
|
4
|
-
|
|
5
|
-
Motion is part of product behavior. It should clarify state changes, guide focus, and provide feedback without reducing accessibility or performance.
|
|
6
|
-
|
|
7
|
-
## Motion Intent Model
|
|
8
|
-
|
|
9
|
-
Use motion only for one of these intents:
|
|
10
|
-
- Transition intent: communicate screen or state transition.
|
|
11
|
-
- Feedback intent: confirm user action success/failure.
|
|
12
|
-
- Focus intent: direct attention to newly relevant content.
|
|
13
|
-
|
|
14
|
-
If a transition has no intent, remove it.
|
|
15
|
-
|
|
16
|
-
## Timing and Consistency
|
|
17
|
-
|
|
18
|
-
Adopt a small timing scale and reuse it across the product:
|
|
19
|
-
- Fast: 120ms for micro-feedback.
|
|
20
|
-
- Standard: 200ms to 260ms for component transitions.
|
|
21
|
-
- Slow: 320ms to 420ms for route transitions.
|
|
22
|
-
|
|
23
|
-
Avoid mixing unrelated easing curves in one flow.
|
|
24
|
-
|
|
25
|
-
## Performance-Safe Animation Rules
|
|
26
|
-
|
|
27
|
-
Prefer animating properties that do not trigger expensive layout and paint work:
|
|
28
|
-
- Preferred: transform, opacity.
|
|
29
|
-
- Avoid for frequent animation: top, left, width, height, box-shadow blur radius.
|
|
30
|
-
|
|
31
|
-
Use CSS containment and selective `will-change` only for elements that actually animate.
|
|
32
|
-
|
|
33
|
-
## Reduced Motion Compliance
|
|
34
|
-
|
|
35
|
-
Always implement reduced-motion fallback:
|
|
36
|
-
|
|
37
|
-
```css
|
|
38
|
-
.panel {
|
|
39
|
-
transition: transform 220ms ease, opacity 220ms ease;
|
|
40
|
-
}
|
|
41
|
-
|
|
42
|
-
@media (prefers-reduced-motion: reduce) {
|
|
43
|
-
.panel {
|
|
44
|
-
transition: none;
|
|
45
|
-
}
|
|
46
|
-
}
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
## Interaction Patterns
|
|
50
|
-
|
|
51
|
-
Recommended patterns:
|
|
52
|
-
- Enter/exit fade + translate for dialogs.
|
|
53
|
-
- Staggered list reveal for scannability on load.
|
|
54
|
-
- Subtle press/hover feedback for actionable controls.
|
|
55
|
-
|
|
56
|
-
Avoid these patterns:
|
|
57
|
-
- Continuous decorative motion on primary content.
|
|
58
|
-
- Multiple competing animations in one viewport.
|
|
59
|
-
- Looping movement that can distract reading flow.
|
|
60
|
-
|
|
61
|
-
## Review Checklist
|
|
62
|
-
|
|
63
|
-
- [ ] Every animation has explicit product intent.
|
|
64
|
-
- [ ] Timing scale is consistent across components.
|
|
65
|
-
- [ ] Heavy layout-triggering properties are avoided.
|
|
66
|
-
- [ ] Reduced-motion mode is implemented and tested.
|
|
1
|
+
# Motion Design and Implementation
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Motion is part of product behavior. It should clarify state changes, guide focus, and provide feedback without reducing accessibility or performance.
|
|
6
|
+
|
|
7
|
+
## Motion Intent Model
|
|
8
|
+
|
|
9
|
+
Use motion only for one of these intents:
|
|
10
|
+
- Transition intent: communicate screen or state transition.
|
|
11
|
+
- Feedback intent: confirm user action success/failure.
|
|
12
|
+
- Focus intent: direct attention to newly relevant content.
|
|
13
|
+
|
|
14
|
+
If a transition has no intent, remove it.
|
|
15
|
+
|
|
16
|
+
## Timing and Consistency
|
|
17
|
+
|
|
18
|
+
Adopt a small timing scale and reuse it across the product:
|
|
19
|
+
- Fast: 120ms for micro-feedback.
|
|
20
|
+
- Standard: 200ms to 260ms for component transitions.
|
|
21
|
+
- Slow: 320ms to 420ms for route transitions.
|
|
22
|
+
|
|
23
|
+
Avoid mixing unrelated easing curves in one flow.
|
|
24
|
+
|
|
25
|
+
## Performance-Safe Animation Rules
|
|
26
|
+
|
|
27
|
+
Prefer animating properties that do not trigger expensive layout and paint work:
|
|
28
|
+
- Preferred: transform, opacity.
|
|
29
|
+
- Avoid for frequent animation: top, left, width, height, box-shadow blur radius.
|
|
30
|
+
|
|
31
|
+
Use CSS containment and selective `will-change` only for elements that actually animate.
|
|
32
|
+
|
|
33
|
+
## Reduced Motion Compliance
|
|
34
|
+
|
|
35
|
+
Always implement reduced-motion fallback:
|
|
36
|
+
|
|
37
|
+
```css
|
|
38
|
+
.panel {
|
|
39
|
+
transition: transform 220ms ease, opacity 220ms ease;
|
|
40
|
+
}
|
|
41
|
+
|
|
42
|
+
@media (prefers-reduced-motion: reduce) {
|
|
43
|
+
.panel {
|
|
44
|
+
transition: none;
|
|
45
|
+
}
|
|
46
|
+
}
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
## Interaction Patterns
|
|
50
|
+
|
|
51
|
+
Recommended patterns:
|
|
52
|
+
- Enter/exit fade + translate for dialogs.
|
|
53
|
+
- Staggered list reveal for scannability on load.
|
|
54
|
+
- Subtle press/hover feedback for actionable controls.
|
|
55
|
+
|
|
56
|
+
Avoid these patterns:
|
|
57
|
+
- Continuous decorative motion on primary content.
|
|
58
|
+
- Multiple competing animations in one viewport.
|
|
59
|
+
- Looping movement that can distract reading flow.
|
|
60
|
+
|
|
61
|
+
## Review Checklist
|
|
62
|
+
|
|
63
|
+
- [ ] Every animation has explicit product intent.
|
|
64
|
+
- [ ] Timing scale is consistent across components.
|
|
65
|
+
- [ ] Heavy layout-triggering properties are avoided.
|
|
66
|
+
- [ ] Reduced-motion mode is implemented and tested.
|
|
67
67
|
- [ ] Motion does not block keyboard or screen-reader flow.
|
|
@@ -1,63 +1,63 @@
|
|
|
1
|
-
# Frontend Performance Engineering
|
|
2
|
-
|
|
3
|
-
Tier: EXPERT
|
|
4
|
-
|
|
5
|
-
Performance work should be evidence-driven. Start with baseline metrics, optimize where bottlenecks are proven, then verify that user-facing indicators improved.
|
|
6
|
-
|
|
7
|
-
## Core Metrics
|
|
8
|
-
|
|
9
|
-
Track Core Web Vitals in CI and release checks:
|
|
10
|
-
- LCP target: less than 2.5s on reference environments.
|
|
11
|
-
- INP target: less than 200ms.
|
|
12
|
-
- CLS target: less than 0.1.
|
|
13
|
-
|
|
14
|
-
Also track bundle size and script execution time for key routes.
|
|
15
|
-
|
|
16
|
-
## Render Efficiency
|
|
17
|
-
|
|
18
|
-
Common controls:
|
|
19
|
-
- Keep expensive computation outside render path with memoization.
|
|
20
|
-
- Use stable callbacks for memoized child components.
|
|
21
|
-
- Split large component trees by feature boundary.
|
|
22
|
-
|
|
23
|
-
```javascript
|
|
24
|
-
const visibleRows = useMemo(() => {
|
|
25
|
-
return allRows.filter((row) => row.isVisible);
|
|
26
|
-
}, [allRows]);
|
|
27
|
-
|
|
28
|
-
const handleRowOpen = useCallback((rowId) => {
|
|
29
|
-
openRowDetails(rowId);
|
|
30
|
-
}, [openRowDetails]);
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
## Network and Caching Strategy
|
|
34
|
-
|
|
35
|
-
- Treat server state separately from UI state.
|
|
36
|
-
- Use query caching with explicit stale policies.
|
|
37
|
-
- Avoid duplicate API calls by keying requests consistently.
|
|
38
|
-
|
|
39
|
-
For route transitions, prefetch data for likely next navigation paths.
|
|
40
|
-
|
|
41
|
-
## Bundle Governance
|
|
42
|
-
|
|
43
|
-
Use route and component-level code splitting:
|
|
44
|
-
- Lazy-load non-critical routes.
|
|
45
|
-
- Defer optional heavy modules until needed.
|
|
46
|
-
- Audit bundle growth at each release.
|
|
47
|
-
|
|
48
|
-
Set a budget and fail CI on unapproved bundle-size regressions.
|
|
49
|
-
|
|
50
|
-
## Diagnostics Workflow
|
|
51
|
-
|
|
52
|
-
1. Capture baseline profile and web-vitals report.
|
|
53
|
-
2. Apply one optimization change.
|
|
54
|
-
3. Re-profile and compare deltas.
|
|
55
|
-
4. Keep only changes with measurable improvement.
|
|
56
|
-
|
|
57
|
-
## Review Checklist
|
|
58
|
-
|
|
59
|
-
- [ ] Core metrics targets are monitored and reported.
|
|
60
|
-
- [ ] Render-heavy paths are profiled with tooling evidence.
|
|
61
|
-
- [ ] Data fetching uses cache and deduplication strategy.
|
|
62
|
-
- [ ] Bundle-size budget is defined and enforced.
|
|
1
|
+
# Frontend Performance Engineering
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Performance work should be evidence-driven. Start with baseline metrics, optimize where bottlenecks are proven, then verify that user-facing indicators improved.
|
|
6
|
+
|
|
7
|
+
## Core Metrics
|
|
8
|
+
|
|
9
|
+
Track Core Web Vitals in CI and release checks:
|
|
10
|
+
- LCP target: less than 2.5s on reference environments.
|
|
11
|
+
- INP target: less than 200ms.
|
|
12
|
+
- CLS target: less than 0.1.
|
|
13
|
+
|
|
14
|
+
Also track bundle size and script execution time for key routes.
|
|
15
|
+
|
|
16
|
+
## Render Efficiency
|
|
17
|
+
|
|
18
|
+
Common controls:
|
|
19
|
+
- Keep expensive computation outside render path with memoization.
|
|
20
|
+
- Use stable callbacks for memoized child components.
|
|
21
|
+
- Split large component trees by feature boundary.
|
|
22
|
+
|
|
23
|
+
```javascript
|
|
24
|
+
const visibleRows = useMemo(() => {
|
|
25
|
+
return allRows.filter((row) => row.isVisible);
|
|
26
|
+
}, [allRows]);
|
|
27
|
+
|
|
28
|
+
const handleRowOpen = useCallback((rowId) => {
|
|
29
|
+
openRowDetails(rowId);
|
|
30
|
+
}, [openRowDetails]);
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Network and Caching Strategy
|
|
34
|
+
|
|
35
|
+
- Treat server state separately from UI state.
|
|
36
|
+
- Use query caching with explicit stale policies.
|
|
37
|
+
- Avoid duplicate API calls by keying requests consistently.
|
|
38
|
+
|
|
39
|
+
For route transitions, prefetch data for likely next navigation paths.
|
|
40
|
+
|
|
41
|
+
## Bundle Governance
|
|
42
|
+
|
|
43
|
+
Use route and component-level code splitting:
|
|
44
|
+
- Lazy-load non-critical routes.
|
|
45
|
+
- Defer optional heavy modules until needed.
|
|
46
|
+
- Audit bundle growth at each release.
|
|
47
|
+
|
|
48
|
+
Set a budget and fail CI on unapproved bundle-size regressions.
|
|
49
|
+
|
|
50
|
+
## Diagnostics Workflow
|
|
51
|
+
|
|
52
|
+
1. Capture baseline profile and web-vitals report.
|
|
53
|
+
2. Apply one optimization change.
|
|
54
|
+
3. Re-profile and compare deltas.
|
|
55
|
+
4. Keep only changes with measurable improvement.
|
|
56
|
+
|
|
57
|
+
## Review Checklist
|
|
58
|
+
|
|
59
|
+
- [ ] Core metrics targets are monitored and reported.
|
|
60
|
+
- [ ] Render-heavy paths are profiled with tooling evidence.
|
|
61
|
+
- [ ] Data fetching uses cache and deduplication strategy.
|
|
62
|
+
- [ ] Bundle-size budget is defined and enforced.
|
|
63
63
|
- [ ] Performance regressions are blocked until reviewed.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Responsive Delivery
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
Responsive delivery is not just resizing components. It defines how information hierarchy, interaction ergonomics, and loading behavior adapt across screen classes.
|
|
6
|
+
|
|
7
|
+
## Breakpoint Contract
|
|
8
|
+
|
|
9
|
+
Define a small set of supported breakpoints and explicitly map each critical screen to layout behavior:
|
|
10
|
+
|
|
11
|
+
- Mobile baseline for primary one-handed flows.
|
|
12
|
+
- Tablet landscape/portrait handling for mixed navigation density.
|
|
13
|
+
- Desktop behavior for dense data views and power-user shortcuts.
|
|
14
|
+
|
|
15
|
+
## Hierarchy and Readability
|
|
16
|
+
|
|
17
|
+
- Keep primary value proposition and main action in first viewport.
|
|
18
|
+
- Promote one primary CTA and one secondary CTA at most on conversion screens.
|
|
19
|
+
- Prevent layout shift when optional content loads asynchronously.
|
|
20
|
+
- Keep typography scaling consistent with design tokens.
|
|
21
|
+
|
|
22
|
+
## Interaction Ergonomics
|
|
23
|
+
|
|
24
|
+
- Maintain touch target minimum sizes for mobile.
|
|
25
|
+
- Preserve keyboard navigability on desktop and tablet keyboard scenarios.
|
|
26
|
+
- Avoid hover-only critical interactions.
|
|
27
|
+
- Ensure sticky bars and bottom sheets do not hide required form controls.
|
|
28
|
+
|
|
29
|
+
## Validation Workflow
|
|
30
|
+
|
|
31
|
+
1. Capture screenshots for each breakpoint from the same scenario.
|
|
32
|
+
2. Execute keyboard and pointer flow checks on critical journeys.
|
|
33
|
+
3. Verify loading, empty, and error states for each breakpoint class.
|
|
34
|
+
4. Attach responsive evidence to release artifact bundle.
|
|
35
|
+
|
|
36
|
+
## Review Checklist
|
|
37
|
+
|
|
38
|
+
- [ ] Breakpoint behavior is documented per critical screen.
|
|
39
|
+
- [ ] Primary CTA remains clear on all supported viewports.
|
|
40
|
+
- [ ] Touch and keyboard interactions are both functional.
|
|
41
|
+
- [ ] Loading and error states preserve layout stability.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
# Frontend skill test fixtures placeholder
|
|
@@ -1,128 +1,128 @@
|
|
|
1
|
-
# Component Architecture and State Management
|
|
2
|
-
|
|
3
|
-
**Tier:** EXPERT | **Source:** awesome-copilot (smart/dumb) + minimax (design systems) + antigravity (React patterns)
|
|
4
|
-
|
|
5
|
-
## Purpose
|
|
6
|
-
|
|
7
|
-
UI architecture decides how state, behavior, and presentation are split. Good structure reduces re-render churn, keeps component boundaries stable, and makes features easier to test.
|
|
8
|
-
|
|
9
|
-
## Part 1: Smart and Dumb Separation
|
|
10
|
-
|
|
11
|
-
A smart component owns data flow, side effects, and orchestration. A dumb component renders input and emits events.
|
|
12
|
-
|
|
13
|
-
```javascript
|
|
14
|
-
function PaymentFormContainer() {
|
|
15
|
-
const [amount, setAmount] = useState('');
|
|
16
|
-
const [status, setStatus] = useState('idle');
|
|
17
|
-
const [errorMessage, setErrorMessage] = useState(null);
|
|
18
|
-
|
|
19
|
-
const handleSubmit = async (submittedAmount) => {
|
|
20
|
-
setStatus('loading');
|
|
21
|
-
try {
|
|
22
|
-
const response = await fetch('/api/payments', {
|
|
23
|
-
method: 'POST',
|
|
24
|
-
body: JSON.stringify({ amount: submittedAmount })
|
|
25
|
-
});
|
|
26
|
-
|
|
27
|
-
if (!response.ok) {
|
|
28
|
-
throw new Error('Payment request failed');
|
|
29
|
-
}
|
|
30
|
-
|
|
31
|
-
setStatus('success');
|
|
32
|
-
} catch (caughtError) {
|
|
33
|
-
setErrorMessage(caughtError.message);
|
|
34
|
-
setStatus('error');
|
|
35
|
-
}
|
|
36
|
-
};
|
|
37
|
-
|
|
38
|
-
return (
|
|
39
|
-
<PaymentFormView
|
|
40
|
-
amount={amount}
|
|
41
|
-
isLoading={status === 'loading'}
|
|
42
|
-
errorMessage={errorMessage}
|
|
43
|
-
onAmountChange={setAmount}
|
|
44
|
-
onSubmit={handleSubmit}
|
|
45
|
-
/>
|
|
46
|
-
);
|
|
47
|
-
}
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
```javascript
|
|
51
|
-
function PaymentFormView({ amount, isLoading, errorMessage, onAmountChange, onSubmit }) {
|
|
52
|
-
return (
|
|
53
|
-
<form onSubmit={(event) => { event.preventDefault(); onSubmit(amount); }}>
|
|
54
|
-
<input
|
|
55
|
-
value={amount}
|
|
56
|
-
onChange={(event) => onAmountChange(event.target.value)}
|
|
57
|
-
disabled={isLoading}
|
|
58
|
-
/>
|
|
59
|
-
<button disabled={isLoading}>
|
|
60
|
-
{isLoading ? 'Processing' : 'Pay'}
|
|
61
|
-
</button>
|
|
62
|
-
{errorMessage ? <p>{errorMessage}</p> : null}
|
|
63
|
-
</form>
|
|
64
|
-
);
|
|
65
|
-
}
|
|
66
|
-
```
|
|
67
|
-
|
|
68
|
-
## Part 2: State Ownership Rules
|
|
69
|
-
|
|
70
|
-
Use the smallest useful state scope.
|
|
71
|
-
|
|
72
|
-
- Local component state: form fields, toggles, ephemeral UI state.
|
|
73
|
-
- Shared UI state: theme, sidebar state, modal visibility.
|
|
74
|
-
- Server state: remote data, caching, invalidation, refetching.
|
|
75
|
-
- Derived state: compute from existing data instead of duplicating it.
|
|
76
|
-
|
|
77
|
-
Recommended mapping:
|
|
78
|
-
- `useState` for local state.
|
|
79
|
-
- `Zustand` or context for global UI state.
|
|
80
|
-
- `TanStack Query` for server state.
|
|
81
|
-
- Avoid context for high-frequency server data when query caching is the better fit.
|
|
82
|
-
|
|
83
|
-
## Part 3: Composition and Contracts
|
|
84
|
-
|
|
85
|
-
A component contract should define what it accepts, what it renders, and what events it emits.
|
|
86
|
-
|
|
87
|
-
```javascript
|
|
88
|
-
interface ButtonProps {
|
|
89
|
-
variant?: 'primary' | 'secondary' | 'danger';
|
|
90
|
-
size?: 'small' | 'medium' | 'large';
|
|
91
|
-
disabled?: boolean;
|
|
92
|
-
loading?: boolean;
|
|
93
|
-
onClick: () => void;
|
|
94
|
-
children: React.ReactNode;
|
|
95
|
-
}
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
Keep public component APIs stable. If the component grows many optional props, split it into smaller feature-specific components instead of adding more flags.
|
|
99
|
-
|
|
100
|
-
## Part 4: Anti-Patterns
|
|
101
|
-
|
|
102
|
-
- Prop drilling across many levels.
|
|
103
|
-
- Global context for everything.
|
|
104
|
-
- Mixing network calls into presentational views.
|
|
105
|
-
- Repeating derived values in both state and render.
|
|
106
|
-
- Reaching into another feature's internals instead of using the feature public API.
|
|
107
|
-
|
|
108
|
-
## Part 5: Design System Integration
|
|
109
|
-
|
|
110
|
-
Design tokens should drive spacing, color, and sizing. Avoid one-off values unless the design system explicitly allows them.
|
|
111
|
-
|
|
112
|
-
```javascript
|
|
113
|
-
const buttonStyles = {
|
|
114
|
-
primary: 'bg-primary text-on-primary',
|
|
115
|
-
secondary: 'bg-surface text-primary',
|
|
116
|
-
danger: 'bg-danger text-on-danger'
|
|
117
|
-
};
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
## Review Checklist
|
|
121
|
-
|
|
122
|
-
- [ ] Smart and dumb layers are separated.
|
|
123
|
-
- [ ] State ownership is minimal and deliberate.
|
|
124
|
-
- [ ] Server state uses a cache-aware tool.
|
|
125
|
-
- [ ] Component contracts are explicit and stable.
|
|
126
|
-
- [ ] Feature boundaries are respected.
|
|
127
|
-
- [ ] Design tokens are used consistently.
|
|
128
|
-
- [ ] Prop drilling does not replace composition or shared state.
|
|
1
|
+
# Component Architecture and State Management
|
|
2
|
+
|
|
3
|
+
**Tier:** EXPERT | **Source:** awesome-copilot (smart/dumb) + minimax (design systems) + antigravity (React patterns)
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
|
|
7
|
+
UI architecture decides how state, behavior, and presentation are split. Good structure reduces re-render churn, keeps component boundaries stable, and makes features easier to test.
|
|
8
|
+
|
|
9
|
+
## Part 1: Smart and Dumb Separation
|
|
10
|
+
|
|
11
|
+
A smart component owns data flow, side effects, and orchestration. A dumb component renders input and emits events.
|
|
12
|
+
|
|
13
|
+
```javascript
|
|
14
|
+
function PaymentFormContainer() {
|
|
15
|
+
const [amount, setAmount] = useState('');
|
|
16
|
+
const [status, setStatus] = useState('idle');
|
|
17
|
+
const [errorMessage, setErrorMessage] = useState(null);
|
|
18
|
+
|
|
19
|
+
const handleSubmit = async (submittedAmount) => {
|
|
20
|
+
setStatus('loading');
|
|
21
|
+
try {
|
|
22
|
+
const response = await fetch('/api/payments', {
|
|
23
|
+
method: 'POST',
|
|
24
|
+
body: JSON.stringify({ amount: submittedAmount })
|
|
25
|
+
});
|
|
26
|
+
|
|
27
|
+
if (!response.ok) {
|
|
28
|
+
throw new Error('Payment request failed');
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
setStatus('success');
|
|
32
|
+
} catch (caughtError) {
|
|
33
|
+
setErrorMessage(caughtError.message);
|
|
34
|
+
setStatus('error');
|
|
35
|
+
}
|
|
36
|
+
};
|
|
37
|
+
|
|
38
|
+
return (
|
|
39
|
+
<PaymentFormView
|
|
40
|
+
amount={amount}
|
|
41
|
+
isLoading={status === 'loading'}
|
|
42
|
+
errorMessage={errorMessage}
|
|
43
|
+
onAmountChange={setAmount}
|
|
44
|
+
onSubmit={handleSubmit}
|
|
45
|
+
/>
|
|
46
|
+
);
|
|
47
|
+
}
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
```javascript
|
|
51
|
+
function PaymentFormView({ amount, isLoading, errorMessage, onAmountChange, onSubmit }) {
|
|
52
|
+
return (
|
|
53
|
+
<form onSubmit={(event) => { event.preventDefault(); onSubmit(amount); }}>
|
|
54
|
+
<input
|
|
55
|
+
value={amount}
|
|
56
|
+
onChange={(event) => onAmountChange(event.target.value)}
|
|
57
|
+
disabled={isLoading}
|
|
58
|
+
/>
|
|
59
|
+
<button disabled={isLoading}>
|
|
60
|
+
{isLoading ? 'Processing' : 'Pay'}
|
|
61
|
+
</button>
|
|
62
|
+
{errorMessage ? <p>{errorMessage}</p> : null}
|
|
63
|
+
</form>
|
|
64
|
+
);
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
## Part 2: State Ownership Rules
|
|
69
|
+
|
|
70
|
+
Use the smallest useful state scope.
|
|
71
|
+
|
|
72
|
+
- Local component state: form fields, toggles, ephemeral UI state.
|
|
73
|
+
- Shared UI state: theme, sidebar state, modal visibility.
|
|
74
|
+
- Server state: remote data, caching, invalidation, refetching.
|
|
75
|
+
- Derived state: compute from existing data instead of duplicating it.
|
|
76
|
+
|
|
77
|
+
Recommended mapping:
|
|
78
|
+
- `useState` for local state.
|
|
79
|
+
- `Zustand` or context for global UI state.
|
|
80
|
+
- `TanStack Query` for server state.
|
|
81
|
+
- Avoid context for high-frequency server data when query caching is the better fit.
|
|
82
|
+
|
|
83
|
+
## Part 3: Composition and Contracts
|
|
84
|
+
|
|
85
|
+
A component contract should define what it accepts, what it renders, and what events it emits.
|
|
86
|
+
|
|
87
|
+
```javascript
|
|
88
|
+
interface ButtonProps {
|
|
89
|
+
variant?: 'primary' | 'secondary' | 'danger';
|
|
90
|
+
size?: 'small' | 'medium' | 'large';
|
|
91
|
+
disabled?: boolean;
|
|
92
|
+
loading?: boolean;
|
|
93
|
+
onClick: () => void;
|
|
94
|
+
children: React.ReactNode;
|
|
95
|
+
}
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
Keep public component APIs stable. If the component grows many optional props, split it into smaller feature-specific components instead of adding more flags.
|
|
99
|
+
|
|
100
|
+
## Part 4: Anti-Patterns
|
|
101
|
+
|
|
102
|
+
- Prop drilling across many levels.
|
|
103
|
+
- Global context for everything.
|
|
104
|
+
- Mixing network calls into presentational views.
|
|
105
|
+
- Repeating derived values in both state and render.
|
|
106
|
+
- Reaching into another feature's internals instead of using the feature public API.
|
|
107
|
+
|
|
108
|
+
## Part 5: Design System Integration
|
|
109
|
+
|
|
110
|
+
Design tokens should drive spacing, color, and sizing. Avoid one-off values unless the design system explicitly allows them.
|
|
111
|
+
|
|
112
|
+
```javascript
|
|
113
|
+
const buttonStyles = {
|
|
114
|
+
primary: 'bg-primary text-on-primary',
|
|
115
|
+
secondary: 'bg-surface text-primary',
|
|
116
|
+
danger: 'bg-danger text-on-danger'
|
|
117
|
+
};
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Review Checklist
|
|
121
|
+
|
|
122
|
+
- [ ] Smart and dumb layers are separated.
|
|
123
|
+
- [ ] State ownership is minimal and deliberate.
|
|
124
|
+
- [ ] Server state uses a cache-aware tool.
|
|
125
|
+
- [ ] Component contracts are explicit and stable.
|
|
126
|
+
- [ ] Feature boundaries are respected.
|
|
127
|
+
- [ ] Design tokens are used consistently.
|
|
128
|
+
- [ ] Prop drilling does not replace composition or shared state.
|
|
@@ -1,30 +1,36 @@
|
|
|
1
|
-
# Frontend Skill Pack
|
|
2
|
-
|
|
3
|
-
Default tier: `advance`
|
|
4
|
-
|
|
5
|
-
## Purpose
|
|
6
|
-
Deliver frontend experiences that are visually intentional, accessible, and efficient.
|
|
7
|
-
|
|
8
|
-
## In Scope
|
|
9
|
-
- UI architecture and component composition
|
|
10
|
-
- Responsive layouts and breakpoints
|
|
11
|
-
- Motion, animation, and interaction polish
|
|
12
|
-
- Accessibility and keyboard flows
|
|
13
|
-
- Conversion clarity and onboarding flow
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
-
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
-
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
1
|
+
# Frontend Skill Pack
|
|
2
|
+
|
|
3
|
+
Default tier: `advance`
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
Deliver frontend experiences that are visually intentional, accessible, and efficient.
|
|
7
|
+
|
|
8
|
+
## In Scope
|
|
9
|
+
- UI architecture and component composition
|
|
10
|
+
- Responsive layouts and breakpoints
|
|
11
|
+
- Motion, animation, and interaction polish
|
|
12
|
+
- Accessibility and keyboard flows
|
|
13
|
+
- Conversion clarity and onboarding flow
|
|
14
|
+
- Performance budgets and render diagnostics
|
|
15
|
+
- Release evidence for visual and interaction quality
|
|
16
|
+
|
|
17
|
+
## Must-Have Checks
|
|
18
|
+
- Feature-driven folder structure
|
|
19
|
+
- Smart and dumb component separation
|
|
20
|
+
- Server state and client state separation
|
|
21
|
+
- Reduced-motion fallback
|
|
22
|
+
- Accessibility baseline pass
|
|
23
|
+
- Responsive behavior verified on mobile and desktop
|
|
24
|
+
- First viewport communicates value proposition and primary action clearly
|
|
25
|
+
- Error and empty states provide explicit next actions
|
|
26
|
+
- Performance budget and regression thresholds are documented per release
|
|
27
|
+
|
|
28
|
+
## Evidence
|
|
29
|
+
- Usability audit result
|
|
30
|
+
- Visual regression output
|
|
31
|
+
- Accessibility checklist result
|
|
32
|
+
- Release notes for motion and interaction changes
|
|
33
|
+
- Performance trend snapshot and remediation notes when regressions occur
|
|
34
|
+
|
|
35
|
+
## Fallback
|
|
30
36
|
- If a feature cannot meet the advance tier, ship standard mode only as a temporary compatibility path.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
+
"artifactType": "skill-domain-evidence",
|
|
4
|
+
"domain": "fullstack",
|
|
5
|
+
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
+
"nodeMin": "18",
|
|
7
|
+
"platforms": ["windows", "linux", "macos"],
|
|
8
|
+
"validatedAt": "2026-04-11T12:00:00Z"
|
|
9
|
+
}
|