Create an explainer-review skill.

.github/workflows/eval-skills.yml

@@ -0,0 +1,14 @@
+name: build
+on:
+  pull_request: {}
+jobs:
+  build:
+    name: Evaluate AI skills
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v6
+      - name: Install Copilot CLI
+        # From https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli
+        run: curl -fsSL https://gh.io/copilot-install | bash

skills/explainer-review/evals/eyedropper/LICENSE.md

@@ -0,0 +1,10 @@
+All Reports in this Repository are licensed by Contributors
+under the
+[W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).
+
+Contributions to Specifications are made under the
+[W3C CLA](https://www.w3.org/community/about/agreements/cla/).
+
+Contributions to Test Suites are made under the
+[W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)
+

skills/explainer-review/evals/eyedropper/README.md

@@ -0,0 +1,107 @@
+# EyeDropper API 
+Authors: [Ionel Popescu](https://github.com/ipopescu93), [Sidhika Tripathee](https://github.com/t-sitri), [McKinna Estridge](https://github.com/t-saestr), [Sammy Hannat](https://github.com/samhannat)
+
+## Status of this Document
+This document is intended as a starting point for engaging the community and standards bodies in developing collaborative solutions fit for standardization. As the solutions to problems described in this document progress along the standards-track, we will retain this document as an archive and use this section to keep the community up-to-date with the most current standards venue and content location of future work and discussions.
+* This document status: **Active**
+* Current venue: [W3C Web Incubator Community Group](https://wicg.io/)
+* Current version: this document
+
+## Introduction
+Currently on the web, creative application developers are unable to implement an eyedropper, a tool that allows users to select a color from the pixels on their screen, including the pixels rendered outside of the web page requesting the color data. This explainer proposes an API that enables developers to use a browser-supplied eyedropper in the construction of custom color pickers. 
+
+## Problem/Motivation
+Several creative applications would like to utilize the ability to pick a color from pixels on the screen. Many "native" applications, e.g. PowerPoint, have eyedropper functionality but are unable to carry it over the web.      
+
+Even though some browsers have built-in eyedropper functionality into color input tags, this limits customizability and can be seen as being out of place for many applications.
+
+## Goals 
+1. Provide access to the color value of one user-selected pixel, including pixels rendered by different origins, or outside of the browser.
+2. Allow the developer to enable the eyedropper through script (subject to user activation).
+3. Keep the user in control by providing the means to exit the eyedropper mode, for example, by pressing the ESC key and ensuring the event is not cancellable by the author.
+4. Keep the user in control by requiring some explicit action, for example pressing a mouse button, to indicate which pixel will have color information returned to the web page.
+5. Allow browser implementors the freedom to implement eyedropper pixel selection UI that best fits their platform and browser.  Note that a future version of the proposal may afford web developers more control over that UI.  One example supported by Chromium-based browsers is shown below.
+
+<img src= "preview.png" alt= "example eyedropper cursor" width="500"/>
+
+## Non-Goals
+1. This proposal does not currently define an object model for a color, though it seems like something that would be a good addition to the web platform. 
+2. This proposal does not currently define a mechanism to allow developers to hide or show the eyedropper's pixel selection UI while remaining in eyedropoper mode, but a future version may allow that, for example, to facilitate clicking on application UI elements instead of selecting a color value.
+3. This proposal does not provide a mechanism for capturing data other than the selected pixel, such as coordinates of the selected pixel.
+
+## Privacy
+Exposing endpoints allowing developers to access unrestricted pixel data from a user's machine presents security challenges. In particular any eyedropper implementation should not allow a web page to "screen scrape" information the user didn't intend to share with the web application, for example, while the user moves the mouse around the screen.
+
+One way to mitigate this threat is to require that pixel data only be made available to the web application when the user takes some explicit action like pressing a mouse button.
+
+Additionally, browsers should provide a clear indication as to when the user has been transitioned into an eyedropper mode, for example by changing the cursor, and provide the means for the user to exit that mode, for example, by pressing an ESC key and not allowing the behavior to be cancelled by the author.
+
+The transition into eyedropper mode should require [consumable user activation](https://github.com/mustaqahmed/user-activation-v2), for example, clicking on a button from the web page, to help avoid unintentionally revealing pixel data.
+
+## Solution
+The API will enable web developers to incorporate an eyedropper in their web applications. The eyedropper would allow the developer to access the hex value (of the form `#RRGGBB`) of a user specified pixel.
+
+Since the representation of color on the web is in transition and the [Color on the Web Community Group](https://w3c.github.io/ColorWeb-CG) is already working on better representing colors, to avoid competing with other effors this API will initially provide a single color string which is gamut mapped to the sRGB color space. It is expected that a color object will be the primary mechanism by which authors will access sampled color data in the future and that it will have the facilities to map between color spaces.
+
+### Web IDL
+```
+dictionary ColorSelectionResult {
+    DOMString sRGBHex;
+};
+
+dictionary ColorSelectionOptions {
+    AbortSignal signal;
+}
+
+[Exposed=Window]
+interface EyeDropper {
+    constructor();
+
+    Promise<ColorSelectionResult> open(
+        optional ColorSelectionOptions options = {});
+};
+```
+
+The `open` method places the web page into an "eyedropper mode" where user input is suppressed: no UI events are dispatched to the web page.
+
+The `open` method returns a `Promise` which resolves if the user has succesfully selected a color based on existing onscreen colors and rejects otherwise to facilitate any scenario where the user has exited the "eyedropper mode" without selecting a color.
+
+The `ColorSelectionResult` contains the result of calling `open()`. It contains one member, `sRGBHex`, which is a 6-digit hex value representing the red, green and blue color components of the selected color in the form: `#RRGGBB`.
+
+If the user presses ESC or invokes some other affordance for exiting "eyedropper mode", the `Promise` is going to be rejected.
+
+## Example Usage
+```javascript
+// Create an EyeDropper object
+let eyeDropper = new EyeDropper();
+
+// Enter eyedropper mode
+let icon = document.getElementById("eyeDropperIcon")
+icon.addEventListener('click', e => {
+    eyeDropper.open()
+    .then(colorSelectionResult => {
+        // returns hex color value (#RRGGBB) of the selected pixel
+        console.log(colorSelectionResult.sRGBHex);
+    })
+    .catch(error => {
+        // handle the user choosing to exit eyedropper mode without a selection
+    });
+});
+ ```
+
+## Feature Detection
+Authors can feature detect the EyeDropper by testing for the presence of the interface on `window`: 
+```javascript
+if ("EyeDropper" in window) {
+    // EyeDropper supported
+}
+else {
+    // not supported
+}
+```
+
+## Alternatives Considered
+### Extending input[type=color]
+This [WhatWG issue](https://github.com/whatwg/html/issues/5584) proposes a new eyedropper attribute on the HTMLInputElement.  This approach wasn't pursued primarily to avoid adding `open` and `close` methods to an already crowded HTMLInputElement API surface.
+
+Having `open` and `close` methods allows the author more control over the duration of "eyedropper mode" and can enable repeated color selections by the user until they either ESC "eyedropper mode" or the author explicitly exits the mode, for example, in response to a click on a non-eyedropper tool.

skills/explainer-review/evals/eyedropper/security-privacy.md

@@ -0,0 +1,71 @@
+# EyeDropper API Security and Privacy Review
+
+The following document contains answers to the [Self-Review Security and Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
+
+### 2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? 
+
+The API will enable web developers to incorporate an eyedropper in their web applications. The eyedropper would allow the developer to access the hex value (of the form #RRGGBB) of a user specified pixel.
+
+Note that the eyedropper only provides pixels back to the web app when the user is explicitly instructing it to capture one, for example, by clicking a mouse button. Simply moving the eyedropper around the screen does not “screen scrape” information and make it available to the web app.
+
+### 2.2 Is this specification exposing the minimum amount of information necessary to power the feature? 
+
+Yes.
+
+### 2.3 How does this specification deal with personal information or personally-identifiable information or information derived thereof? 
+
+Not applicable.
+
+### 2.4 How does this specification deal with sensitive information? 
+
+Not applicable.
+
+### 2.5 Does this specification introduce new state for an origin that persists across browsing sessions? 
+
+No.
+
+### 2.6 What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin? 
+
+Not applicable.
+
+### 2.7 Does this specification allow an origin access to sensors on a user’s device 
+
+No.
+
+### 2.8 What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. 
+
+As noted above, it exposes information about the hex value (of the form #RRGGBB) of a user specified pixel.
+
+### 2.9 Does this specification enable new script execution/loading mechanisms? 
+
+No.
+
+### 2.10 Does this specification allow an origin to access other devices? 
+
+No.
+
+### 2.11 Does this specification allow an origin some measure of control over a user agent’s native UI? 
+
+Browsers should provide a clear indication as to when the user has been transitioned into an eyedropper mode, for example by changing the cursor, and provide the means for the user to exit that mode, for example, by pressing an ESC key and not allowing the behavior to be cancelled by the author. 
+
+The transition into eyedropper mode should require consumable user activation, for example, clicking on a button from the web page, to help avoid unintentionally revealing pixel data.
+
+### 2.12 What temporary identifiers might this this specification create or expose to the web? 
+
+None.
+
+### 2.13 How does this specification distinguish between behavior in first-party and third-party contexts? 
+
+Not applicable.
+
+### 2.14 How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode? 
+
+No difference.
+
+### 2.15 Does this specification have a "Security Considerations" and "Privacy Considerations" section? 
+
+Yes: https://github.com/WICG/eyedropper-api#privacy
+
+### 2.16 Does this specification allow downgrading default security characteristics? 
+
+No.