From 478b18a855674469dd328b42b7f5646c0d63e8ed Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:21:10 -0500 Subject: [PATCH 01/11] Add data-policy-principles reference for review-skill-sflabs --- .../references/data-policy-principles.md | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 skills/review-skill-sflabs/references/data-policy-principles.md diff --git a/skills/review-skill-sflabs/references/data-policy-principles.md b/skills/review-skill-sflabs/references/data-policy-principles.md new file mode 100644 index 00000000..64fc6218 --- /dev/null +++ b/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`. From 78d13f0377cf0d7dbf2b5b908a4b02381761d146 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:21:44 -0500 Subject: [PATCH 02/11] Add mechanical-fix-rules reference for review-skill-sflabs --- .../references/mechanical-fix-rules.md | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 skills/review-skill-sflabs/references/mechanical-fix-rules.md diff --git a/skills/review-skill-sflabs/references/mechanical-fix-rules.md b/skills/review-skill-sflabs/references/mechanical-fix-rules.md new file mode 100644 index 00000000..3be63a38 --- /dev/null +++ b/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. From 481b43bd379ee3470066285da15e01d0cfe5961d Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:22:26 -0500 Subject: [PATCH 03/11] Add report-template reference for review-skill-sflabs --- .../references/report-template.md | 83 +++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 skills/review-skill-sflabs/references/report-template.md diff --git a/skills/review-skill-sflabs/references/report-template.md b/skills/review-skill-sflabs/references/report-template.md new file mode 100644 index 00000000..7bfec3df --- /dev/null +++ b/skills/review-skill-sflabs/references/report-template.md @@ -0,0 +1,83 @@ +# Report Template + +> Authoritative markdown shape for the final report rendered by the router. Do not paraphrase. Substitute placeholders only — wording stays as-is. + +## Template + +```markdown +# Skill Review: + +**Verdict:** <🟢 promote | 🟡 adapt | 🟠 skip> +**Confidence:** + + + +## Summary + +| Check | Status | +|---|---| +| Format | <🟢 / 🟡 / 🟠> | +| Public-duplicate search | <🟢 / 🟡 / 🟠> | +| Data policy | <🟢 / 🟡 / 🟠> | +| Catalog fit | <🟢 / 🟡 / 🟠> | + +## Mechanical fixes applied + +- `` — +- ... + +(or "None — no automatic fixes needed" when nothing was applied.) + +## Issues for you to fix + +### 🟠 Needs Attention + +- **** (`:`) + + *Suggested fix:* + +### 🟡 Opportunity for Improvement + +- **** (`:`) + + *Suggested fix:* + +(Omit the entire "Issues for you to fix" section if there are no findings at either severity.) + +## Disclosures recorded + +(Only present if duplicate-search found anything.) + +- "Adapted from ``" — recorded for reviewer visibility. +- "Original work, similar public skill at ``" — recorded for reviewer visibility. + +## What was checked + +- Bundled-skill catalog source: +- Public-duplicate search queries: +- Skipped checks: + +--- +*This review is advisory. Final acceptance is decided by reviewers on the pull request.* +``` + +## Verdict thresholds + +- **🟢 promote** — All four checks 🟢. No `🟠 Needs Attention` findings. No mechanical fixes were needed, or they were applied cleanly with contributor approval. +- **🟡 adapt** — At least one check is 🟡 or 🟠, but format-check passes (after mechanical fixes). The contributor has issues to address before opening the PR, but the skill is fundamentally sound. +- **🟠 skip** — One of: + - Catalog-fit shows the skill duplicates a bundled skill (shadowing per Labs priority order). + - Format-check has unfixable structural problems (frontmatter doesn't parse even after attempted normalization, required fields missing with no clear fix). + - Duplicate-search disclosed `adapted` AND no clear differentiation from the upstream source. + +## Confidence + +- **high** — All checks ran. No skipped checks. +- **medium** — 1-2 checks skipped (e.g. bundled-skill catalog fetch failed, web_search returned empty for unrelated reasons). +- **low** — 3 or more checks skipped, or both bundled-skill sources unavailable, or web_search blocked for the duration of the run. + +## Tone rule (binding) + +Every line in the rendered report must use advisory language from `data-policy-principles.md` Section 4. Never `critical`, `failure`, `violation`, `danger`, `urgent`, `high-risk`. Always `needs attention`, `opportunity for improvement`, `consider`, `recommended`. + +Status indicators use only 🟢, 🟡, 🟠. Never 🔴. From f60f2d89663d240c39ab0bd2886a7da2ee3a2aa4 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:23:15 -0500 Subject: [PATCH 04/11] Add format-check workflow for review-skill-sflabs --- .../workflows/format-check.md | 156 ++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 skills/review-skill-sflabs/workflows/format-check.md diff --git a/skills/review-skill-sflabs/workflows/format-check.md b/skills/review-skill-sflabs/workflows/format-check.md new file mode 100644 index 00000000..a21440f6 --- /dev/null +++ b/skills/review-skill-sflabs/workflows/format-check.md @@ -0,0 +1,156 @@ +# Workflow: Format Check + +> Mechanical YAML and file-structure validation for the target skill. Outputs a list of findings keyed by check id, severity, and disposition (mechanical fix vs. flag). The router applies mechanical fixes per `references/mechanical-fix-rules.md` after this workflow returns. + +## Inputs + +- `` — path to the target skill directory containing `SKILL.md`. + +## Outputs + +A list of findings, each with: + +- `check_id` — string id (e.g. `format.required_fields`) +- `severity` — `blocking` | `advisory` +- `evidence` — short description of what was found +- `fix` — `mechanical` (auto-applicable per rules) or `manual` (flag for contributor) +- `suggested_change` — the proposed value or rewrite, when applicable + +## Steps + +### Step 1: Parse frontmatter as YAML + +Read `/SKILL.md`. Extract the YAML block between the first `---` and the second `---`. Parse it. + +If parsing fails, emit: + +``` +{check_id: "format.frontmatter_yaml_parses", severity: "blocking", fix: "manual", + evidence: ""} +``` + +Stop and return immediately. Every later check depends on the parsed frontmatter. + +### Step 2: Required fields + +Confirm all of the following keys exist with non-empty values: + +`name`, `title`, `summary`, `description`, `tools`, `prompt`, `language`, `status`, `author`, `type` + +For each missing key, emit: + +``` +{check_id: "format.required_fields.", severity: "blocking", fix: "manual", + evidence: ": missing|empty", + suggested_change: ""} +``` + +`language` and `status`, when missing, are mechanical (see `references/mechanical-fix-rules.md`): + +``` +{check_id: "format.required_fields.language", severity: "blocking", fix: "mechanical", + suggested_change: "language: en"} +``` + +### Step 3: Length limits + +Check: + +- `title` length ≤ 30 characters +- `summary` length ≤ 140 characters + +For each over-limit field, emit `severity: blocking, fix: manual` with a suggested truncation. The agent does not silently rewrite human-facing copy. + +### Step 4: Name format + +Confirm `name` matches the folder name (case-sensitive). If it does not match, emit: + +``` +{check_id: "format.name_matches_folder", severity: "blocking", fix: "mechanical", + suggested_change: "name: "} +``` + +Confirm `name` is lowercase, hyphens-only, no underscores, no more than 3 hyphens. If it violates these rules, emit `severity: blocking, fix: manual` (renaming the folder has side effects the contributor must drive). + +### Step 5: Description shape + +Check whether `description` starts with `Use when`. If it starts with any of `Use for`, `Used to`, `For `, `When ` (without `Use`), emit: + +``` +{check_id: "format.description_use_when", severity: "advisory", fix: "mechanical", + suggested_change: ""} +``` + +Run regex `\b(I|My|my|We|we|Our|our|Us|us)\b` against `description`. For any match, emit: + +``` +{check_id: "format.description_first_person", severity: "advisory", fix: "manual", + evidence: "", + suggested_change: ""} +``` + +Search `description` for `Triggers:` (case-insensitive). If absent, emit: + +``` +{check_id: "format.description_has_triggers", severity: "advisory", fix: "manual", + suggested_change: ""} +``` + +### Step 6: Resolve sibling-file references + +Scan the body of `SKILL.md` (everything after the second `---`) for these patterns: + +- `references/` — relative reference to a file under `/references/` +- `workflows/` — relative reference to a file under `/workflows/` +- `scripts/` — relative reference to a file under `/scripts/` + +For each referenced path that does not exist on disk, emit: + +``` +{check_id: "format.referenced_file_missing", severity: "blocking", fix: "manual", + evidence: ""} +``` + +The agent does not fabricate workflow or reference content. + +### Step 7: Reject `skill_metadata/` + +If `/skill_metadata/` exists, emit: + +``` +{check_id: "format.no_skill_metadata", severity: "blocking", fix: "manual", + evidence: "skill_metadata/ directory present", + suggested_change: "Remove the skill_metadata/ directory before committing."} +``` + +This directory is internal-only seed data and must not be published. + +### Step 8: LICENSE present + +If `/LICENSE` does not exist: + +- If the parsed `type:` value is `community` (or missing), emit: + ``` + {check_id: "format.license_present", severity: "blocking", fix: "mechanical", + suggested_change: "Create LICENSE with Apache 2.0 (community contribution)"} + ``` +- If `type:` is `snowflake`, emit: + ``` + {check_id: "format.license_present", severity: "blocking", fix: "manual", + suggested_change: "Add the appropriate Snowflake employee license file"} + ``` + +## Summary status + +After running all 8 steps, the workflow's overall status for the report is: + +- 🟢 — zero findings +- 🟡 — only `advisory` findings, all `mechanical` fixes applied cleanly +- 🟠 — any `blocking` finding remains after mechanical fixes are applied + +Pass that status to the router. + +## Notes + +- The router applies mechanical fixes after this workflow returns, per the disposition table in `references/mechanical-fix-rules.md`. This workflow only identifies issues — it does not edit files. +- The router asks the contributor to confirm before applying any fix. From 0ffb45d21c3c6d23044dae3667eb80715583dcd2 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:24:03 -0500 Subject: [PATCH 05/11] Add duplicate-search workflow for review-skill-sflabs --- .../workflows/duplicate-search.md | 116 ++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 skills/review-skill-sflabs/workflows/duplicate-search.md diff --git a/skills/review-skill-sflabs/workflows/duplicate-search.md b/skills/review-skill-sflabs/workflows/duplicate-search.md new file mode 100644 index 00000000..f3bba1ad --- /dev/null +++ b/skills/review-skill-sflabs/workflows/duplicate-search.md @@ -0,0 +1,116 @@ +# Workflow: Duplicate Search + +> Detect whether the target skill is a verbatim or near-verbatim copy of content already published on the public web. Use `web_search`, not a closed catalog. The detection is heuristic; the contributor confirms intent interactively. + +## Inputs + +- `` — path to the target skill directory. +- The parsed frontmatter from format-check (specifically `name` and `description`). +- The body of `SKILL.md` (everything after the second `---`). + +## Outputs + +A single finding with: + +- `check_id` — `duplicate.public_overlap` +- `severity` — `pass` if no overlap, `advisory` if disclosed as own work, `attention` if disclosed as adapted +- `evidence` — top URLs, contributor's disclosure +- `suggested_change` — only present if the skill duplicates upstream content with no differentiation + +## Steps + +### Step 1: Generate distinctive search queries + +Build 2-3 queries from the target skill's content. The goal is to surface verbatim or near-verbatim copies, so prefer specific phrasing over keywords. + +1. **Quoted skill name** — `"" SKILL.md` (use the `name:` value verbatim, in quotes). +2. **Description fragment** — pick a 6-12 word fragment from the middle of the `description:` field. Avoid the leading `Use when` clause (too generic). Quote the fragment. +3. **Body section header phrase** — pick a top-level heading or distinctive sub-heading from the body (e.g. a step name, a table caption). Quote it. Skip if every heading is a generic word like "Overview" or "Inputs". + +Aim for 2 queries minimum. A third only if a distinctive section header is available. + +### Step 2: Run web_search per query + +For each query, call `web_search` and capture the top 5 results. + +### Step 3: Filter for likely duplicates + +A result is a likely duplicate if any of these hold: + +- URL ends in `SKILL.md` or `/SKILL` and content references skill frontmatter conventions +- URL is on `github.com`, `gitlab.com`, or any code-hosting domain, and points at a directory or markdown file with `SKILL.md` siblings +- URL is a blog post, X (Twitter) thread, or LinkedIn post that shows the skill body verbatim or with minor edits +- Title or snippet contains the skill name and at least one distinctive phrase from the queries + +Aggregate up to 3 distinct URLs across all queries. De-duplicate by domain+path. + +### Step 4: If no likely duplicates found + +Emit: + +``` +{check_id: "duplicate.public_overlap", severity: "pass", + evidence: "Searched queries; no likely public duplicates surfaced."} +``` + +Skip to the end of this workflow. + +### Step 5: Surface URLs and ask the contributor + +Present the top URLs to the contributor: + +``` +I searched the public web for content matching this skill and surfaced these URLs: + + 1. + 2. + 3. + +Is this your own work, or did you adapt it from one of these sources? + +Choose one: + - Mine — I authored this from scratch + - Adapted — I started from one of the sources above +``` + +Wait for the contributor's selection. This is a **stopping point** — do not proceed without an answer. + +### Step 6a: Contributor selects "Mine" + +Emit: + +``` +{check_id: "duplicate.public_overlap", severity: "advisory", + evidence: "Original work. Similar public skills found at: ", + disclosure: "Original work, similar public skill at "} +``` + +The disclosure goes into the report's "Disclosures recorded" section so reviewers can see what surfaced. + +### Step 6b: Contributor selects "Adapted" + +Tell the contributor: + +> Recorded. Note that PR review is human-in-the-loop and may decline duplicate skills regardless of authorship. Continuing with the rest of the checks. + +Emit: + +``` +{check_id: "duplicate.public_overlap", severity: "attention", + evidence: "Adapted from . Other matches: ", + disclosure: "Adapted from "} +``` + +The disclosure goes into the report prominently. Verdict computation continues — do not stop the workflow. + +## Summary status + +- 🟢 — `pass` (no overlap) +- 🟡 — `advisory` (mine, but similar work exists) +- 🟠 — `attention` (adapted from a public source) + +## Notes + +- This workflow does not maintain a list of "approved" or "banned" upstream sources. Every check is a `web_search`. New skill repos and new public posts appear constantly; the workflow has to discover them, not match a list. +- If `web_search` returns an error or zero results across all queries, emit `severity: "skipped"` with `evidence: "web_search unavailable or returned no results"`. The router treats this as a skipped check and lowers confidence accordingly. +- Do not block the verdict on a skipped duplicate-search — the rest of the checks still produce a useful report. From 5b68a76c839766152fd91f4e4e8c30131d06b4eb Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:25:10 -0500 Subject: [PATCH 06/11] Add data-policy-scan workflow for review-skill-sflabs --- .../workflows/data-policy-scan.md | 145 ++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 skills/review-skill-sflabs/workflows/data-policy-scan.md diff --git a/skills/review-skill-sflabs/workflows/data-policy-scan.md b/skills/review-skill-sflabs/workflows/data-policy-scan.md new file mode 100644 index 00000000..794df481 --- /dev/null +++ b/skills/review-skill-sflabs/workflows/data-policy-scan.md @@ -0,0 +1,145 @@ +# Workflow: Data Policy Scan + +> Reason about the target skill against `references/data-policy-principles.md` to surface findings about output content design, tone, hardcoded specifics, and disclaimers. No closed list of bad patterns — the agent applies judgment using the principles file as ground truth. + +## Inputs + +- `` — path to the target skill directory. +- `references/data-policy-principles.md` — the principles file (loaded into context first). +- `SKILL.md` body and any sibling files under `workflows/`. + +## Outputs + +A list of findings, each with: + +- `check_id` — `policy..` (e.g. `policy.pii.user_name`) +- `severity` — `🟢` / `🟡` / `🟠` +- `evidence` — what was found, with file:line where possible +- `suggested_change` — the principles-aligned alternative + +## Steps + +### Step 1: Load principles into context + +Read `references/data-policy-principles.md` end-to-end. Every reasoning step below references it. + +### Step 2: Decide what content to scan + +If the target skill has only `SKILL.md` (no `workflows/` directory), scan `SKILL.md` body in full. + +If the target skill is a router with sub-workflows (any `workflows/.md` referenced from the body), use **spot-check sampling**: + +- Always scan `SKILL.md` body in full. +- Scan up to 3 workflow files, prioritizing those that look most likely to surface output (filenames containing `report`, `recommend`, `analyze`, `audit`, `summary`, or that are referenced from sections about output formatting). +- Skip workflows that are clearly not output-producing (e.g. `setup.md`, `prerequisites.md`). + +This bounds token cost while still catching the common policy violations. + +### Step 3: Output content design (per principles §1 and §2) + +Read the body and the sampled workflows. Identify any place where the skill instructs the agent to surface fields from principles §1's "PII fields to flag" list. Examples of flag-worthy mentions: + +- The skill's example output, report template, or SQL examples reference any user-identity column (e.g. `USER_NAME`, `LOGIN_NAME`, `EMAIL`, `DISPLAY_NAME`). +- The skill's body says to display per-user breakdowns where an aggregate would answer the question. +- The skill returns raw query history rows joined to user identity. + +For each match, emit: + +``` +{check_id: "policy.pii.", severity: "🟠", + evidence: ": instructs surfacing ", + suggested_change: "Replace with an aggregate (count, distribution, breakdown by ) per principles §2."} +``` + +If the skill's body shows that PII is collected internally but never appears in output, that is **acceptable** — the policy is about output, not access. Note this in evidence and emit `severity: 🟢` if the design clearly aggregates before surfacing. + +### Step 4: Tone and severity language (per principles §4 and §5) + +Run a case-insensitive search across the body and sampled workflows for: + +- `\bcritical\b`, `\bfailure\b`, `\bviolation\b`, `\bdanger\b`, `\burgent\b`, `\bhigh-risk\b` +- `🔴` emoji +- the literal word `red` in a status-indicator context (table cell, status column, severity label) + +For each match, emit: + +``` +{check_id: "policy.tone.", severity: "🟡", + evidence: ":: ''", + suggested_change: ""} +``` + +If a banned word appears in a "do not use" instruction context (e.g. principles §4 itself), that is acceptable — recognize the banned-context pattern (the surrounding sentence forbids the word) and skip it. The agent must distinguish between *using* the word and *forbidding* the word. + +### Step 5: Hardcoded specifics (per principles §3) + +Look for hardcoded customer identifiers in the body and sampled workflows: + +- Account locators (any string matching common account identifier patterns, in SQL examples or instructions) +- Specific schema names with identifying suffixes (`_PROD`, `_DEV`, `_FINANCE`, named-team patterns) used as if they were universal +- Specific role names, warehouse names, integration names that are not introduced as parameters +- Anything that looks like a credential, API token, secret key, or password + +Apply judgment: a generic example like `MY_SCHEMA` or `` is fine. A specific name like `ACME_FINANCE_PROD_RL` baked into a SQL example is not. + +For each match: + +``` +{check_id: "policy.hardcoded.", severity: "🟠", + evidence: ":: ", + suggested_change: "Parameterize: replace with a placeholder (e.g. ) and instruct the user to supply their own value."} +``` + +Anything that looks like a credential or secret is a **hard error** — emit `severity: 🟠` and recommend the contributor remove the secret entirely before proceeding (and rotate it if it was a real secret). + +### Step 6: Disclaimer presence (per principles §6) + +Decide whether the skill produces assessment-style output. Indicators: + +- Body contains words like `score`, `rating`, `recommend`, `audit`, `assessment`, `evaluation` +- Body describes output that surfaces telemetry or metrics +- Body produces a report-shaped artifact (sections, summaries, traffic-light statuses) + +If yes, search the body, the workflow files sampled, and any `references/report-template.md` for one of the disclaimer templates from principles §6. If no disclaimer is present, emit: + +``` +{check_id: "policy.disclaimer_missing", severity: "🟡", + evidence: "Skill produces an assessment-style output but no disclaimer is included.", + suggested_change: "Add the most relevant template from principles §6 near the top of the rendered output."} +``` + +If the skill is purely action-oriented (executes a task, returns a result, but is not advisory in nature), skip this step and emit `severity: 🟢` with `evidence: "Not assessment-style output."`. + +### Step 7: Flexibility / fork pattern (per principles §7) + +Reason about whether the skill is parameterized or hardcoded for a single use case. Indicators of a hardcoded skill that will produce forks: + +- Single account/scope assumed throughout, no parameter for filtering +- Single output detail level (deep-dive only, or summary only) with no mode switch +- Single environment (e.g. only handles production accounts) with no env parameter + +If found, emit: + +``` +{check_id: "policy.scope_inflexible", severity: "🟡", + evidence: "", + suggested_change: "Accept a parameter for ; principles §7 explains why hardcoded scope encourages forks."} +``` + +This is a **🟡 Opportunity for Improvement**, not a 🟠. A hardcoded skill is still useful — it just has a higher chance of being copied and edited later, which the contributor should know up front. + +## Summary status + +After running steps 3-7, the workflow's overall status: + +- 🟢 — zero findings +- 🟡 — only `🟡 Opportunity for Improvement` findings +- 🟠 — at least one `🟠 Needs Attention` finding (PII surfacing, hardcoded customer identifier, secret) + +Pass that status to the router. + +## Notes + +- The agent does not maintain a closed list of "bad" identifiers or fields beyond what principles §1 enumerates. New patterns appear; the principles file is the source of truth and updates centrally. +- Examples in the body that use clearly-generic placeholders (``, `MY_TABLE`, `EXAMPLE_ROLE`) are not findings. +- When in doubt, prefer the advisory tone over silence: surface the finding, let the contributor decide whether it applies. From 7b1338fba8f183a71831ad5fc5b9488a4faab459 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:26:02 -0500 Subject: [PATCH 07/11] Add catalog-fit workflow for review-skill-sflabs --- .../workflows/catalog-fit.md | 177 ++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 skills/review-skill-sflabs/workflows/catalog-fit.md diff --git a/skills/review-skill-sflabs/workflows/catalog-fit.md b/skills/review-skill-sflabs/workflows/catalog-fit.md new file mode 100644 index 00000000..d06f376f --- /dev/null +++ b/skills/review-skill-sflabs/workflows/catalog-fit.md @@ -0,0 +1,177 @@ +# Workflow: Catalog Fit + +> Two checks: (1) does the candidate skill collide with a bundled Cortex Code skill, and (2) is the skill parameterized enough to avoid producing forks. The first check uses on-disk and docs sources; the second is reasoning-based. + +## Inputs + +- `` — path to the target skill directory. +- The parsed frontmatter `name` from format-check. + +## Outputs + +A list of findings plus two scores: + +- `external_fit` — 1-5 with one-sentence justification +- `catalog_gap_fit` — 1-5 with one-sentence justification + +Findings have the same shape as other workflows. + +## Part A: Bundled-skill overlap + +### Step A1: Probe disk paths for bundled skills + +Try these paths in order. For each that exists, record the source and continue. + +| OS | Path | +|---|---| +| Linux / macOS | `~/.local/share/cortex/*/bundled_skills/` | +| macOS app-support fallback | `~/Library/Application Support/cortex/*/bundled_skills/` | +| Windows | `%LOCALAPPDATA%\cortex\*\bundled_skills\` | +| User-level skills (any OS) | `~/.snowflake/cortex/skills/` | + +For each existing path, glob `*/SKILL.md`. Read each file's frontmatter and parse `name:`. Build a set of bundled names. Record which paths contributed. + +### Step A2: Fetch bundled skills from docs + +`web_fetch https://docs.snowflake.com/en/user-guide/cortex-code/bundled-skills` and parse the published skill list. + +Run this regardless of whether Step A1 succeeded — the contributor's local install may be older than what is currently shipping, and we want both views. + +If the fetch fails (network unavailable, page moved, 404), record the failure and continue. Do not block. + +### Step A3: Combine sources + +Union the two sets. Record the source attribution: + +| Sources available | Attribution | +|---|---| +| Both disk and docs returned a list | `disk+docs` | +| Only disk | `disk` | +| Only docs | `docs` | +| Neither | `skipped` | + +### Step A4: Compare candidate name + +Build the comparison set: + +- `` — the candidate's `name:` value, exact match. +- `` with these prefixes stripped: `manage-`, `create-`, `build-`, `deploy-`, `setup-`, `configure-`. Each stripped variant is also compared. + +For each variant, check whether it appears in the bundled-skill set. + +If a collision is found, emit: + +``` +{check_id: "catalog.bundled_collision", severity: "🟠", + evidence: "Candidate name '' (or normalized variant '') matches bundled skill '' (source: ).", + suggested_change: "Rename the skill, or substantially extend scope beyond the bundled skill. Promoting as-is creates a silent shadow per the Labs README priority order: project skills > git-sourced skills > bundled skills."} +``` + +If no collision, emit: + +``` +{check_id: "catalog.bundled_collision", severity: "🟢", + evidence: "No bundled-skill name collision. Source: ."} +``` + +### Step A5: Both sources unavailable + +If `attribution == skipped`, emit: + +``` +{check_id: "catalog.bundled_collision", severity: "skipped", + evidence: "Could not verify bundled-skill catalog: disk paths not found and docs fetch failed."} +``` + +The router does not block the verdict on a skipped catalog check. Confidence drops to `medium` (or `low` if other checks also skipped). + +## Part B: Scope flexibility + +### Step B1: Reason about parameterization + +Read the body of `SKILL.md`. Decide whether the skill accepts variations or hardcodes its scope. + +Indicators of a hardcoded scope (fork-encouraging): + +- The skill assumes a single account/environment with no parameter to switch +- Output detail is single-mode (deep-dive only, or summary only) with no way to ask for the other +- Filtering dimensions the user is likely to need (region, env, team, line of business) are not exposed as parameters +- The skill's example prompt locks in specifics that should be selectable + +Indicators the skill is well-parameterized: + +- The body asks the user upfront for scope (which env, which account, which dimension) +- The body offers output modes (summary, detailed, comparison) +- The body uses `AskUserQuestion`-style decision points instead of branching on inferred intent + +### Step B2: Emit finding + +If the skill is hardcoded: + +``` +{check_id: "catalog.scope_inflexible", severity: "🟡", + evidence: "", + suggested_change: "Add a parameter for at the top of the workflow. Hardcoded scope encourages forks (see data-policy-principles.md §7)."} +``` + +If the skill is well-parameterized: + +``` +{check_id: "catalog.scope_inflexible", severity: "🟢", + evidence: "Skill exposes for variation."} +``` + +## Part C: Scoring + +### Step C1: external_fit (1-5) + +Reason about how broadly applicable the skill is to a generic user (not just the author or the author's team). + +| Score | Meaning | +|---|---| +| 5 | Universal — every user of the platform benefits | +| 4 | Broad — most users in a common scenario benefit | +| 3 | Niche but real — a meaningful subset benefits | +| 2 | Narrow — only a specific role or team would use this | +| 1 | Single-user — built for one workflow, unlikely to apply elsewhere | + +Output: + +``` +external_fit: <1-5> +external_fit_rationale: "" +``` + +### Step C2: catalog_gap_fit (1-5) + +Reason about how much the skill fills a hole in the existing public catalog (Labs + bundled). Use the bundled-skill list from Part A as input. + +| Score | Meaning | +|---|---| +| 5 | No equivalent in bundled or Labs catalogs; novel coverage | +| 4 | Partial overlap with an existing skill, but adds substantial value | +| 3 | Adjacent to an existing skill — useful complement | +| 2 | Significant overlap with an existing skill — debatable whether worth promoting | +| 1 | Duplicates an existing skill | + +Output: + +``` +catalog_gap_fit: <1-5> +catalog_gap_fit_rationale: "" +``` + +## Summary status + +After running all parts, the workflow's overall status: + +- 🟢 — no bundled collision, scope is parameterized, both scores ≥ 4 +- 🟡 — scope inflexible, OR `catalog_gap_fit` ≤ 3, but no bundled collision +- 🟠 — bundled collision found + +Pass that status, the findings, and both scores to the router. + +## Notes + +- Disk paths and docs URLs may evolve. If neither source resolves and the workflow consistently fails, the skill may need an update — but the router treats a single skipped check as a confidence reduction, not a blocker. +- The bundled-skill list is not a static reference shipped with this skill — it is fetched fresh each run from the canonical sources. New bundled skills are picked up automatically. From 668f118690e7e99cb6bdb3e1737eebdb5b4647be Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:27:38 -0500 Subject: [PATCH 08/11] Add SKILL.md router for review-skill-sflabs --- skills/review-skill-sflabs/SKILL.md | 119 ++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 skills/review-skill-sflabs/SKILL.md diff --git a/skills/review-skill-sflabs/SKILL.md b/skills/review-skill-sflabs/SKILL.md new file mode 100644 index 00000000..41012eda --- /dev/null +++ b/skills/review-skill-sflabs/SKILL.md @@ -0,0 +1,119 @@ +--- +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 to + know whether it would be a fit for the public Snowflake-Labs/cortex-code-skills + repository before opening a pull request. Runs format checks, public-web + duplicate search, data-policy reasoning, and bundled-skill catalog-fit + reasoning, then reports a verdict (promote / adapt / 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: community +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 +``` + +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 `/SKILL.md` exists. +2. Read `SKILL.md` plus all sibling files under `/references/`, `/workflows/`, and `/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 ``?" — 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 Pitfalls + +| 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. From 90f5cdb20ac33e872e53452f74fe2e1e81818e31 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:28:15 -0500 Subject: [PATCH 09/11] Add Snowflake Skills License + set type: snowflake (employee author) --- skills/review-skill-sflabs/LICENSE | 22 ++++++++++++++++++++++ skills/review-skill-sflabs/SKILL.md | 2 +- 2 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 skills/review-skill-sflabs/LICENSE diff --git a/skills/review-skill-sflabs/LICENSE b/skills/review-skill-sflabs/LICENSE new file mode 100644 index 00000000..3b8f57ee --- /dev/null +++ b/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. diff --git a/skills/review-skill-sflabs/SKILL.md b/skills/review-skill-sflabs/SKILL.md index 41012eda..8698094c 100644 --- a/skills/review-skill-sflabs/SKILL.md +++ b/skills/review-skill-sflabs/SKILL.md @@ -23,7 +23,7 @@ prompt: "$review-skill-sflabs ~/.snowflake/cortex/skills/my-skill" language: en status: Published author: Daniel Myers, Cortex Code DevRel -type: community +type: snowflake demo-url: "" --- From 4e95092627edd0c9eb451cc56c3983bde45b01e4 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:31:35 -0500 Subject: [PATCH 10/11] Recommend running review-skill-sflabs before submitting a PR --- CONTRIBUTING.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fce75b32..b7718375 100644 --- a/CONTRIBUTING.md +++ b/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 +``` + +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. From 71855ed20907a6731f7f28fdf1099602c3620cc7 Mon Sep 17 00:00:00 2001 From: Daniel Myers Date: Tue, 26 May 2026 22:33:06 -0500 Subject: [PATCH 11/11] Tighten description and rename Common Pitfalls -> Common Mistakes per audit rubric --- skills/review-skill-sflabs/SKILL.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/skills/review-skill-sflabs/SKILL.md b/skills/review-skill-sflabs/SKILL.md index 8698094c..5c3c0d2c 100644 --- a/skills/review-skill-sflabs/SKILL.md +++ b/skills/review-skill-sflabs/SKILL.md @@ -3,12 +3,10 @@ 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 to - know whether it would be a fit for the public Snowflake-Labs/cortex-code-skills - repository before opening a pull request. Runs format checks, public-web - duplicate search, data-policy reasoning, and bundled-skill catalog-fit - reasoning, then reports a verdict (promote / adapt / skip) with concrete - fixes. Triggers: "review a skill", "is this skill ready for labs", + 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: @@ -101,7 +99,7 @@ After rendering the report, stop. Do not offer to fork the repo, push, or open a 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 Pitfalls +## Common Mistakes | Pitfall | Fix | |---|---|