Add review-skill-sflabs skill + CONTRIBUTING update

CONTRIBUTING.md

@@ -4,6 +4,7 @@ We are thrilled you want to contribute! The Snowflake community is full of peopl
 
 - [Before you start](#before-you-start)
 - [Skill format](#skill-format)
+- [Review your skill before submitting](#review-your-skill-before-submitting)
 - [Submit a skill from Cortex Code CLI](#submit-a-skill-from-cortex-code-cli)
 - [Review criteria](#review-criteria)
 
@@ -67,6 +68,23 @@ Pick any existing skill in `skills/` whose shape matches what you're building, c
 
 ---
 
+## Review your skill before submitting
+
+Before opening a pull request, run `$review-skill-sflabs` against your skill directory. The skill is itself published in this repo and provides a pre-PR readiness check: format validation, public-web duplicate search, data-policy reasoning, and catalog-fit check (overlap with bundled skills, scope flexibility). It applies safe mechanical fixes in place (with your confirmation) and flags content rewrites for you to address manually.
+
+Install and run it in a Cortex Code session:
+
+```
+/skill add https://github.com/Snowflake-Labs/cortex-code-skills.git/skills/review-skill-sflabs
+$review-skill-sflabs <path-to-your-skill>
+```
+
+The output is a verdict (🟢 promote / 🟡 adapt / 🟠 skip) plus a concrete checklist of issues. Address any 🟠 *Needs Attention* findings before opening the PR.
+
+Running it does not gate PR acceptance — it is advisory. Final review is human-in-the-loop and reviewers may decline or request changes regardless of what the skill reports.
+
+---
+
 ## Submit a skill from Cortex Code CLI
 
 There is no `cortex skill export` command. A skill is just a directory with a `SKILL.md` file, so the process is to locate it, copy it into this repo, and fill in the required frontmatter fields.

skills/review-skill-sflabs/LICENSE

@@ -0,0 +1,22 @@
+Snowflake Skills License 
+
+© 2026 Snowflake Inc. All rights reserved.
+
+LICENSE: Use of these materials (including all code, prompts, assets, files, and other components of these skills (collectively, “Skills”)) is governed by your agreement with Snowflake for the Service. If no separate agreement exists, use is governed by Snowflake’s Terms of Service (available at: https://www.snowflake.com/en/legal/terms-of-service/). 
+
+Your applicable agreement is referred to as the "Agreement." "Service" is as defined in the Agreement.
+
+ADDITIONAL RESTRICTIONS: Notwithstanding anything in the Agreement to the contrary, you may not:
+
+* Extract from the Service or retain copies of the Skills outside use with the Service;
+* Reproduce or copy the Skills , except for temporary copies created automatically during authorized use of the Service;
+* Create derivative works based on the Skills; 
+* Distribute, sublicense, or transfer the Skills to any third party;
+* Make, offer to sell, sell, or import any inventions embodied in the Skills; nor, 
+* Reverse engineer, decompile, or disassemble the Skills. 
+
+The receipt, viewing, or possession of the Skills does not convey or imply any license or right beyond those expressly granted above.
+
+Snowflake retains all rights, title, and interest in the Skills, including all copyrights, trademarks, patents, and all other applicable intellectual property rights.
+
+THE SKILLS ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SKILLS OR THE USE OR OTHER DEALINGS IN THE SKILLS.

skills/review-skill-sflabs/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: review-skill-sflabs
+title: Review Skill for SF Labs
+summary: Pre-PR self-check that audits a local skill directory for Snowflake Labs catalog readiness.
+description: >-
+  Use when a contributor has built a Cortex Code skill locally and wants a
+  pre-PR readiness check before opening a pull request against
+  Snowflake-Labs/cortex-code-skills. Verdict: promote, adapt, or skip — with
+  concrete fixes. Triggers: "review a skill", "is this skill ready for labs",
+  "check this skill before PR", "audit skill for promotion", "does this skill
+  belong in labs".
+tools:
+  - Read
+  - Edit
+  - Glob
+  - Grep
+  - Bash
+  - web_search
+  - web_fetch
+prompt: "$review-skill-sflabs ~/.snowflake/cortex/skills/my-skill"
+language: en
+status: Published
+author: Daniel Myers, Cortex Code DevRel
+type: snowflake
+demo-url: ""
+---
+
+# Review Skill for SF Labs
+
+## When to Use
+
+- A contributor has authored a skill locally and wants a pre-PR readiness check
+- Before forking `Snowflake-Labs/cortex-code-skills` to submit a new skill
+- To get a checklist of mechanical fixes plus advisory findings before reviewers see the work
+
+## Overview
+
+This skill inspects a local skill directory and produces an advisory report telling the contributor whether the skill is a fit for the public Labs catalog. It applies safe mechanical fixes in place (with the contributor's confirmation) and flags content rewrites that need human judgment. It does not fork, push, or open a PR — that is the contributor's call after seeing the report.
+
+The review is advisory. Final acceptance is decided by reviewers on the pull request.
+
+## Inputs
+
+The skill takes one argument: a path to a skill directory containing a `SKILL.md`.
+
+```
+$review-skill-sflabs <path>
+```
+
+If no argument is provided, the skill uses the current working directory. If the path does not contain a `SKILL.md`, stop with a clear error.
+
+## Workflow
+
+### Phase 1: Locate and load
+
+1. Resolve the input path. Validate that `<path>/SKILL.md` exists.
+2. Read `SKILL.md` plus all sibling files under `<path>/references/`, `<path>/workflows/`, and `<path>/scripts/` into context. The `Glob` tool can enumerate them.
+
+### Phase 2: Run sub-workflows in order
+
+Run each sub-workflow and accumulate findings.
+
+1. **Format check** — read `workflows/format-check.md` and execute its steps. Output: list of `(check_id, severity, evidence, fix, suggested_change)` findings.
+2. **Duplicate search** — read `workflows/duplicate-search.md` and execute. May reach a stopping point at "your work or adapted from `<url>`?" — wait for the contributor's selection before proceeding.
+3. **Data policy scan** — read `workflows/data-policy-scan.md` and execute. Loads `references/data-policy-principles.md` first.
+4. **Catalog fit** — read `workflows/catalog-fit.md` and execute. Includes both bundled-skill overlap (disk + docs) and scope flexibility reasoning.
+
+If any later phase depends on data an earlier phase failed to gather, mark that phase as `skipped` and continue.
+
+### Phase 3: Apply mechanical fixes
+
+Read `references/mechanical-fix-rules.md`. For each finding with `fix: mechanical`:
+
+1. Show the proposed change to the contributor (a diff or a one-line description).
+2. Ask for confirmation.
+3. On approval, apply the change with the `Edit` tool (or create the file with `Write` for missing LICENSE).
+4. Record the fix in the report's "Mechanical fixes applied" section.
+
+Never apply mechanical fixes silently. The contributor stays in control.
+
+### Phase 4: Render the report
+
+Read `references/report-template.md`. Substitute findings into the template. The template defines verdict thresholds, confidence levels, and tone rules.
+
+### Phase 5: Stop
+
+After rendering the report, stop. Do not offer to fork the repo, push, or open a PR. Do not suggest "next actions". The contributor decides what to do with the report.
+
+## Stopping Points
+
+- ✋ End of Phase 1 if `SKILL.md` is not found at the path.
+- ✋ During Phase 2, sub-workflow `duplicate-search` asks the contributor "your work or adapted?" — wait for an explicit answer.
+- ✋ Before any mechanical fix in Phase 3 — confirm before applying.
+- ✋ After Phase 5 — stop. Do not offer to PR.
+
+**Resume rule:** Once the contributor confirms a stopping point, proceed without re-asking.
+
+## Output
+
+A single rendered report per `references/report-template.md`. Includes verdict, confidence, summary table of the four checks, mechanical fixes applied, manual issues to address, disclosures (if any), and an attribution of which sources were consulted.
+
+## Common Mistakes
+
+| Pitfall | Fix |
+|---|---|
+| Path argument points to a directory without `SKILL.md` | Stop in Phase 1 with a clear error; do not invent content |
+| `Bash` probes for bundled-skill paths that don't exist | Treat each missing path as a non-event; the catalog-fit workflow handles this gracefully |
+| Multiple findings overlap (e.g. tone violation that is also a hardcoded specific) | Emit each finding once, deduplicated by `check_id`; do not double-count in the verdict heuristic |
+| Contributor selects "Adapted" in duplicate search | Continue running the rest of the checks; do not short-circuit the report |
+| Sub-workflow file is missing | This is a `format-check` blocking finding; report it and skip the corresponding phase |
+| `web_search` or `web_fetch` returns an error | Mark the affected check as `skipped`, drop confidence to medium, continue |
+
+## Notes
+
+- This skill is purely advisory. It does not gate PR acceptance. Reviewers on the pull request make the final call.
+- Every check is heuristic, sourced from on-disk + live data + reasoning. There is no closed list of approved skills, banned patterns, or canonical sources baked into this skill.
+- When the data-policy principles update, only `references/data-policy-principles.md` changes — the workflows reason against whatever the current file says.

skills/review-skill-sflabs/references/data-policy-principles.md

@@ -0,0 +1,105 @@
+# Data Policy Principles for Skills
+
+> Source of truth for the `data-policy-scan` workflow. When this file changes, the workflow's behavior changes — no other file needs to update.
+
+These principles apply to any skill that surfaces data, recommendations, or assessments to a user. They are domain-agnostic — every check below is engineering hygiene that holds regardless of which platform, tool, or audience the skill targets.
+
+## 1. Never expose PII in skill output
+
+A skill must not instruct an agent to surface personally identifiable information in its output, even if the user asks for it.
+
+Field types to flag if a skill's body or example output references them:
+
+| Field type | Examples |
+|---|---|
+| User identity | `USER_NAME`, `LOGIN_NAME`, `EMAIL`, `DISPLAY_NAME`, given name, surname |
+| Contact information | phone numbers, postal addresses |
+| Network identity | `CLIENT_IP`, `SOURCE_IP`, MAC addresses |
+| Activity tied to identity | login history rows, access history with user joins, query history with user joins, raw audit log entries |
+| Authentication artifacts | SSO identifiers, MFA enrollment details, session tokens |
+
+If a user genuinely needs PII, the skill should help them write the query to run in their own environment — never deliver PII as output.
+
+## 2. Aggregate over individual
+
+When telemetry is needed, prefer aggregate metrics over per-user breakdowns.
+
+| Prefer | Avoid |
+|---|---|
+| `427 active users, 38 dormant > 90 days` | A list of those 38 users by name or email |
+| `Top warehouse by spend: ANALYTICS_WH, 1,247 credits` | `jane.doe@example.com consumed 847 credits` |
+| `3 admin roles not reviewed in 180 days` | Naming the users holding those roles |
+| Per-warehouse / per-role / per-service breakdowns | Per-user breakdowns |
+
+If the natural answer requires per-user data, the skill should produce SQL the user can run themselves — not surface the result.
+
+## 3. No customer-specific hardcoding
+
+A skill must accept the things that vary between users as parameters, not bake them into the body. Hardcoded specifics produce two problems: the skill leaks identifiers it should not, and users fork the skill to override the values.
+
+Patterns to flag:
+
+- Account locators or specific account names embedded in SQL or examples
+- Specific schema names, table names, or role names assumed without parameterization
+- Specific integration names, warehouse names, or database names baked in
+- Credentials, API tokens, secrets, or anything that looks like a key (always treat as a hard error, not just an advisory)
+
+If the skill targets a specific use case, the use case should be selectable — not the only mode.
+
+## 4. Advisory tone
+
+A skill is helping someone improve. Its tone should make the user want to take action, not feel defensive.
+
+Avoid these words. Each row gives the recommended replacement:
+
+| Avoid | Why | Use instead |
+|---|---|---|
+| Critical | Implies imminent failure | Needs attention, priority recommendation |
+| High-risk | Triggers fear or blame | Opportunity for improvement, needs attention |
+| Danger | Signals alarm | Not recommended, below best practice |
+| Failure | Implies something is broken | Underperforming, below threshold |
+| Violation | Sounds like compliance enforcement | Deviation from best practice |
+| Urgent | Creates unwarranted pressure | Recommended action |
+
+Do not paraphrase findings into harsher language than the rubric calls for. A finding is a coaching opportunity.
+
+## 5. Color discipline
+
+Skills that use status indicators (in tables, summaries, or any rendered output) must use only these three colors:
+
+| Color | Label | Meaning |
+|---|---|---|
+| 🟢 Green | On Track | Meets or exceeds expectations. No action needed. |
+| 🟡 Yellow | Needs Improvement | Below optimal. Worth addressing, but not urgent. |
+| 🟠 Amber | Needs Attention | Requires attention. Should be prioritized. |
+
+**Do not use 🔴 red.** Red implies an emergency that almost no skill output is actually communicating. Tone is advisory, not reactive.
+
+## 6. Disclaimer on assessments
+
+Any skill output that surfaces telemetry, recommendations, or an assessment must include a disclaimer near the top. The disclaimer should establish that the output is a guide, not a definitive audit.
+
+Suggested templates by category:
+
+- **General:** *This report is intended to help you evaluate against a set of recommended best practices; it is not a comprehensive audit.*
+- **Security:** *This report is intended to help you evaluate against a set of recommended security best practices; it is not a comprehensive audit. You are responsible for securing your environment and determining your compliance requirements.*
+- **Reliability:** *This report is intended to help you evaluate against a set of recommended reliability best practices; it is not a comprehensive audit. You are responsible for assessing reliability gaps within your environment.*
+- **Performance:** *This report is intended to help you evaluate against a set of recommended performance best practices; it is not a comprehensive audit. You are responsible for assessing the performance of your environment.*
+- **Cost optimization:** *This report is intended to help you evaluate against a set of recommended cost optimization best practices; it is not a comprehensive audit. You are responsible for assessing optimization opportunities within your environment.*
+- **Operational excellence:** *This report is intended to help you evaluate against a set of recommended operational excellence best practices; it is not a comprehensive audit. You are responsible for identifying gaps in observability within your environment.*
+
+A skill should pick the single most relevant template and include it once near the top of its output. Do not stack multiple disclaimers.
+
+## 7. Flexibility is a feature
+
+When a skill does not accommodate common variations in how people use it, users copy the skill and edit it to fit their case. Forks bypass review and drift over time.
+
+Ask, when reviewing a skill:
+
+| Question | When the answer is "yes," design for it |
+|---|---|
+| Will users need to filter by subset (env, region, line of business)? | Build filtering as a parameter, not a hardcoded assumption |
+| Will users need different scopes (single target vs. many)? | Accept a scope parameter |
+| Will users need different output detail (summary vs. deep-dive)? | Offer output modes |
+
+A skill that hardcodes the answer to any of these is a fork waiting to happen. Flag it as `🟡 Opportunity for Improvement`.

skills/review-skill-sflabs/references/mechanical-fix-rules.md

@@ -0,0 +1,42 @@
+# Mechanical Fix Rules
+
+> Authoritative table for the `format-check` workflow. The router consults this file to decide whether a finding is auto-fixable or must be flagged for the contributor.
+
+**Always confirm before applying any mechanical fix.** Show the proposed diff and ask the contributor.
+
+## Auto-fix vs flag
+
+| Issue | Mechanical fix? | Action |
+|---|---|---|
+| Frontmatter YAML doesn't parse | No | Stop. Show parse error to the contributor. |
+| Required field missing entirely (e.g. no `prompt:`) | No | Flag with a suggested template value. |
+| Required field present but empty | No | Flag; the agent does not invent content. |
+| `name:` doesn't match folder name | Yes | Update `name:` to match the folder. |
+| `name:` has uppercase, underscores, or more than 3 hyphens | No | Flag — renaming the folder has side effects the contributor must drive. |
+| `title:` longer than 30 chars | No | Flag with a suggested truncation; let the contributor pick. |
+| `summary:` longer than 140 chars | No | Flag with a suggested trim. |
+| `description:` doesn't start with `Use when` | Yes | Replace leading `Use for` / `Used to` / similar with `Use when`. |
+| `description:` contains first-person pronouns (`\b(I|My|my|We|we|Our|our|Us|us)\b`) | No | Flag the matches with a rewritten alternative. |
+| `description:` missing `Triggers:` list | No | Flag with a suggested template. |
+| `language:` missing | Yes | Add `language: en`. |
+| `status:` missing | Yes | Add `status: Published`. |
+| `type:` missing | No | Flag — value depends on author (`community` / `snowflake` / `partner`). |
+| `LICENSE` missing, `type: community` | Yes | Create `LICENSE` with Apache 2.0. |
+| `LICENSE` missing, `type: snowflake` | No | Flag — Snowflake employees supply their own license file. |
+| `skill_metadata/` directory present | No | Flag — internal-only seed file; remove before committing. |
+| Referenced sibling file missing (`workflows/X.md` / `references/Y.md` / `scripts/Z` linked in body) | No | Flag — the agent does not fabricate workflow content. |
+| Tone violation in body (`critical` / `failure` / `violation` / `danger` / `urgent` / `high-risk`) | No | Flag with the replacement word from `data-policy-principles.md`. |
+| 🔴 red emoji in body | No | Flag with 🟠 amber as the replacement. |
+| Hardcoded customer identifier in body (account locator, specific schema name with `_PROD` etc., specific role name) | No | Flag — context-dependent rewrite, not mechanical. |
+| Disclaimer missing on assessment-style output | No | Flag with the appropriate template from `data-policy-principles.md` Section 6. |
+
+## Rule of thumb
+
+Auto-fix only when there is exactly one correct value:
+
+- Folder-name match → one correct `name:`
+- Default language → `en`
+- Default status → `Published`
+- Default community LICENSE → Apache 2.0 (the canonical text in this repo's template)
+
+Anything that requires choosing between alternatives, anything that touches body content, anything that changes meaning — **flag, don't apply**. The contributor stays in control of their own writing.