opencode-skills-collection 4.0.53 → 4.0.55

package/bundled-skills/frontend-design/SKILL.md

@@ -1,12 +1,14 @@
 ---
 name: frontend-design
-description: "You are a frontend designer-engineer, not a layout generator."
+description: "Design and implement a distinctive frontend within the product’s existing brand, accessibility, performance and framework constraints."
 risk: critical
 source: community
 date_added: "2026-02-27"
 ---
 
-# Frontend Design (Distinctive, Production-Grade)
+# Frontend Design
+
+Modified by AAS maintainers on 2026-09-05: clarified design constraints, subjective scoring and verification. The bundled Apache-2.0 license is preserved.
 
 You are a **frontend designer-engineer**, not a layout generator.
 
@@ -14,7 +16,7 @@ Your goal is to create **memorable, high-craft interfaces** that:
 
 * Avoid generic “AI UI” patterns
 * Express a clear aesthetic point of view
-* Are fully functional and production-ready
+* Implement the requested interactions and report what was actually verified
 * Translate design intent directly into code
 
 This skill prioritizes **intentional design systems**, not default frameworks.
@@ -23,7 +25,7 @@ This skill prioritizes **intentional design systems**, not default frameworks.
 
 ## 1. Core Design Mandate
 
-Every output must satisfy **all four**:
+For new visual directions, consider all four; existing product constraints take precedence:
 
 1. **Intentional Aesthetic Direction**
    A named, explicit design stance (e.g. *editorial brutalism*, *luxury minimal*, *retro-futurist*, *industrial utilitarian*).
@@ -32,21 +34,18 @@ Every output must satisfy **all four**:
    Real, working HTML/CSS/JS or framework code — not mockups.
 
 3. **Visual Memorability**
-   At least one element the user will remember 24 hours later.
+   A clear visual anchor; memorability is a hypothesis until tested with users.
 
 4. **Cohesive Restraint**
    No random decoration. Every flourish must serve the aesthetic thesis.
 
-❌ No default layouts
-❌ No design-by-components
-❌ No “safe” palettes or fonts
-✅ Strong opinions, well executed
+Reuse an established design system when it serves the task. Novelty must not override familiar controls, readable typography, the user’s brand or existing accessibility patterns.
 
 ---
 
 ## 2. Design Feasibility & Impact Index (DFII)
 
-Before building, evaluate the design direction using DFII.
+DFII is an optional, subjective discussion aid with no validated predictive power. Prefer concrete user tasks and measurable checks over a total score.
 
 ### DFII Dimensions (1–5)
 
@@ -64,13 +63,13 @@ Before building, evaluate the design direction using DFII.
 DFII = (Impact + Fit + Feasibility + Performance) − Consistency Risk
 ```
 
-**Range:** `-5 → +15`
+**Arithmetic range:** `-1 → +19` when each dimension is scored from 1 to 5. This is not a certification or a release gate.
 
 ### Interpretation
 
 | DFII      | Meaning   | Action                      |
 | --------- | --------- | --------------------------- |
-| **12–15** | Excellent | Execute fully               |
+| **12–19** | Excellent | Discuss the tradeoffs               |
 | **8–11**  | Strong    | Proceed with discipline     |
 | **4–7**   | Risky     | Reduce scope or effects     |
 | **≤ 3**   | Weak      | Rethink aesthetic direction |
@@ -112,11 +111,11 @@ This anchor must be visible in the final UI.
 
 ---
 
-## 4. Aesthetic Execution Rules (Non-Negotiable)
+## 4. Aesthetic Execution Choices
 
 ### Typography
 
-* Avoid system fonts and AI-defaults (Inter, Roboto, Arial, etc.)
+* Preserve brand fonts and use system fonts when they improve speed, readability or platform fit
 * Choose:
 
   * 1 expressive display font
@@ -219,24 +218,18 @@ When generating frontend work:
 * Full working code
 * Comments only where intent isn’t obvious
 
-### 4. Differentiation Callout
-
-Explicitly state:
+### 4. Verification
 
-> “This avoids generic UI by doing X instead of Y.”
+State which primary action, responsive widths, keyboard/focus behavior, contrast and loading/error states were checked. Include observed results and remaining gaps.
 
 ---
 
-## 7. Anti-Patterns (Immediate Failure)
+## 7. Avoid
 
-❌ Inter/Roboto/system fonts
-❌ Purple-on-white SaaS gradients
-❌ Default Tailwind/ShadCN layouts
-❌ Symmetrical, predictable sections
-❌ Overused AI design tropes
-❌ Decoration without intent
-
-If the design could be mistaken for a template → restart.
+- Replacing established components merely to look unusual.
+- Downloading fonts or visual assets without checking licensing and product constraints.
+- Hiding controls, weakening contrast or increasing motion for an aesthetic effect.
+- Calling a rendered screenshot functional or production-ready without interaction checks.
 
 ---
 
@@ -255,11 +248,11 @@ If the design could be mistaken for a template → restart.
 Before finalizing output:
 
 * [ ] Clear aesthetic direction stated
-* [ ] DFII ≥ 8
+* [ ] Subjective design judgments are separated from observed usability checks
 * [ ] One memorable design anchor
-* [ ] No generic fonts/colors/layouts
+* [ ] Brand and existing component conventions are respected
 * [ ] Code matches design ambition
-* [ ] Accessible and performant
+* [ ] Keyboard, focus, responsive layout and performance checks recorded
 
 ---
 
@@ -274,9 +267,15 @@ Before finalizing output:
 ---
 
 ## When to Use
-This skill is applicable to execute the workflow or actions described in the overview.
+
+Use for a new page, component or deliberate visual refresh with a known primary user action. For an isolated bug fix, preserve the surrounding design unless a change is needed to solve the bug.
+
+## Inputs and worked example
+
+Collect the existing design system, target devices, content, framework and acceptance criteria. Example: a JSON import screen must expose errors and a useful next action on a 390px viewport. Reuse the app’s form controls, associate errors with inputs, wrap long digests and reserve clear pending/success states. Verify keyboard submission and that editing an input removes stale success. Expected: the complete workflow remains usable without horizontal page scrolling.
 
 ## Limitations
-- Use this skill only when the task clearly matches the scope described above.
-- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+- Visual distinctiveness does not prove usability or conversion impact.
+- A screenshot cannot verify keyboard order, async behavior, screen-reader output or network failure states.
+- Reduced-motion preferences, localization and real content lengths can change the design; test them where the product needs them.

package/bundled-skills/frontend-observability/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: frontend-observability
-description: A portable, framework-agnostic field-side observability system for any React or React Native app. Establishes one typed event taxonomy (canonical event-name constants, never inline strings), a best-effort non-blocking provider fan-out so a failing or absent analytics provider can never...
+description: "A portable, framework-agnostic field-side observability system for any React or React Native app."
 risk: critical
 source: https://github.com/stareezy-1/frontend-architecture-skill/tree/main/skills/frontend-observability
 source_repo: stareezy-1/frontend-architecture-skill

package/bundled-skills/frontend-optimistic-mutations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: frontend-optimistic-mutations
-description: A portable, framework-agnostic discipline for the write path of any React or React Native app using a query/cache layer. Codifies the optimistic-update lifecycle (cancel in-flight queries → snapshot every affected cache → patch instantly → roll back verbatim on error → invalidate on...
+description: "A portable, framework-agnostic discipline for the write path of any React or React Native app using a query/cache layer."
 risk: critical
 source: https://github.com/stareezy-1/frontend-architecture-skill/tree/main/skills/frontend-optimistic-mutations
 source_repo: stareezy-1/frontend-architecture-skill

package/bundled-skills/frontend-security-coder/SKILL.md

@@ -68,13 +68,13 @@ Expert frontend security developer with comprehensive knowledge of client-side s
 - **Third-party CSS**: External stylesheet validation, subresource integrity for stylesheets
 
 ### Clickjacking Protection
-- **Frame detection**: Intersection Observer API implementation, UI overlay detection, frame-busting logic
+- **Frame detection**: Supplementary UI signals only; do not treat viewport observation as a frame authorization boundary
 - **Frame-busting techniques**: JavaScript-based frame busting, top-level navigation protection
 - **X-Frame-Options**: DENY and SAMEORIGIN implementation, frame ancestor control
 - **CSP frame-ancestors**: Content Security Policy frame protection, granular frame source control
 - **SameSite cookie protection**: Cross-frame CSRF protection, cookie isolation techniques
 - **Visual confirmation**: User action confirmation, critical operation verification, overlay detection
-- **Environment-specific deployment**: Apply clickjacking protection only in production or standalone applications, disable or relax during development when embedding in iframes
+- **Environment-specific deployment**: Define an explicit allowed embedding policy per environment; do not disable protection as a convenience
 
 ### Secure Redirects and Navigation
 - **Redirect validation**: URL allowlist validation, internal redirect verification, domain allowlist enforcement
@@ -117,7 +117,7 @@ Expert frontend security developer with comprehensive knowledge of client-side s
 
 ### Mobile and Responsive Security
 - **Touch interaction security**: Gesture validation, touch event security, haptic feedback
-- **Viewport security**: Secure viewport configuration, zoom prevention for sensitive forms
+- **Viewport security**: Secure viewport configuration, preserve user zoom and accessible scaling
 - **Device API security**: Geolocation privacy, camera/microphone permissions, sensor data protection
 - **App-like behavior**: PWA security, full-screen mode security, navigation gesture handling
 - **Cross-platform compatibility**: Platform-specific security considerations, feature detection security
@@ -127,7 +127,7 @@ Expert frontend security developer with comprehensive knowledge of client-side s
 - Implements comprehensive input validation with allowlist approaches
 - Uses Content Security Policy headers to prevent script injection
 - Validates all user-supplied URLs before navigation or redirects
-- Applies frame-busting techniques only in production environments
+- Uses server-delivered frame-ancestors policy; frame detection is only supplementary
 - Sanitizes all dynamic content with established libraries like DOMPurify
 - Implements secure authentication token storage and management
 - Uses modern browser security features and APIs
@@ -151,7 +151,7 @@ Expert frontend security developer with comprehensive knowledge of client-side s
 2. **Implement secure DOM manipulation** using textContent and secure APIs
 3. **Configure Content Security Policy** with appropriate directives and violation reporting
 4. **Validate all user inputs** with allowlist-based validation and sanitization
-5. **Implement clickjacking protection** with frame detection and busting techniques
+5. **Implement clickjacking protection** with server-delivered frame-ancestors policy and authorized embedding tests
 6. **Secure navigation and redirects** with URL validation and allowlist enforcement
 7. **Apply browser security features** including SRI, Trusted Types, and security headers
 8. **Handle authentication securely** with proper token storage and session management

package/bundled-skills/frontend-security-coder/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Frontend security implementation
+
+## Inputs
+
+The component, rendering framework, trusted content policy, session design and browser test route.
+
+## Procedure
+
+1. Identify untrusted text, HTML, URLs and cross-window messages. Prefer text rendering; use an established sanitizer only where authored HTML is required.
+2. Enforce URL schemes and destination rules. Validate message origin and source. Coordinate server headers and authorization; client validation is only usability feedback.
+3. Test an inert markup payload as text, disallowed URL schemes and messages from another origin. Inspect rendered DOM, network effects and console. Preserve zoom and keyboard access.
+
+## Worked example
+
+A profile biography contains markup. Render it as text unless rich text is explicitly required; verify no extra element or request appears and legitimate text remains readable.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Frame detection and frame-busting scripts do not replace frame-ancestors response policy. Browser storage is not a safe place for server secrets.