opencode-skills-collection 3.1.23 → 4.0.1

package/bundled-skills/docs/vietnamese/SECURITY_GUARDRAILS.vi.md

@@ -1,6 +1,6 @@
 # 🛡️ Chính sách Bảo mật & Rào chắn An toàn (Guardrails)
 
-Antigravity Awesome Skills là một bộ công cụ mạnh mẽ. Và quyền lực lớn luôn đi kèm với trách nhiệm lớn. Tài liệu này xác định **Quy tắc Ứng xử** cho tất cả các khả năng bảo mật và tấn công trong repository này.
+Agentic Awesome Skills là một bộ công cụ mạnh mẽ. Và quyền lực lớn luôn đi kèm với trách nhiệm lớn. Tài liệu này xác định **Quy tắc Ứng xử** cho tất cả các khả năng bảo mật và tấn công trong repository này.
 
 ## 🔴 Chính sách đối với Skill Tấn công (Vạch kẻ đỏ)
 

package/bundled-skills/docs/vietnamese/SKILLS_README.vi.md

@@ -1,6 +1,6 @@
 # Thư mục Kỹ năng (Skills Directory)
 
-**Chào mừng đến với thư mục Kỹ năng!** Đây là nơi tập hợp tất cả 1,684+ kỹ năng AI chuyên biệt.
+**Chào mừng đến với thư mục Kỹ năng!** Đây là nơi tập hợp tất cả 1,936+ kỹ năng AI chuyên biệt.
 
 ## 🤔 Kỹ năng là gì?
 
@@ -63,7 +63,7 @@ ls skills/ | grep "từ khóa"
 ```
 
 ### Cách 3: Kiểm tra README chính
-Xem [README chính](README.vi.md) và [CATALOG.md](../../CATALOG.md) để biết danh sách đầy đủ tất cả 1,684+ kỹ năng được tổ chức theo danh mục.
+Xem [README chính](README.vi.md) và [CATALOG.md](../../CATALOG.md) để biết danh sách đầy đủ tất cả 1,936+ kỹ năng được tổ chức theo danh mục.
 
 ---
 

package/bundled-skills/docs/vietnamese/TRANSLATION_PLAN.vi.md

@@ -1,6 +1,6 @@
 # 🗺️ Kế hoạch Dịch thuật (Translation Master Plan)
 
-Tài liệu này dùng để theo dõi tiến độ dịch thuật toàn bộ repository `antigravity-awesome-skills` sang tiếng Việt.
+Tài liệu này dùng để theo dõi tiến độ dịch thuật toàn bộ repository `agentic-awesome-skills` sang tiếng Việt.
 
 **Mục tiêu:** Dịch toàn bộ 1,684+ kỹ năng và tài liệu hướng dẫn.
 **Quy tắc:**

package/bundled-skills/docs/vietnamese/VISUAL_GUIDE.vi.md

@@ -28,12 +28,12 @@
 ## 📦 Cấu trúc Repository (Trực quan)
 
 ```
-antigravity-awesome-skills/
+agentic-awesome-skills/
 │
 ├── 📄 README.md                    ← Tổng quan & danh sách skill
 ├── 📄 CONTRIBUTING.md              ← Cách thức đóng góp
 │
-├── 📁 skills/                      ← Nguồn canonical cho 1,684+ skills
+├── 📁 skills/                      ← Nguồn canonical cho 1,936+ skills
 │   │
 │   ├── 📁 brainstorming/
 │   │   └── 📄 SKILL.md             ← Định nghĩa skill
@@ -42,7 +42,7 @@ antigravity-awesome-skills/
 │   │   ├── 📄 SKILL.md
 │   │   └── 📁 examples/            ← Các phần bổ sung tùy chọn
 │   │
-│   └── ... (1,684+ skills khác)
+│   └── ... (1,936+ skills khác)
 │
 ├── 📁 tools/
 │   ├── 📁 scripts/                 ← Quản lý, xác thực và tạo catalog
@@ -67,7 +67,7 @@ antigravity-awesome-skills/
 
 ```
 ┌──────────────┐
-│ 1. CÀI ĐẶT   │  npx antigravity-awesome-skills
+│ 1. CÀI ĐẶT   │  npx agentic-awesome-skills
 1 └──────┬───────┘
        │
        ↓
@@ -97,7 +97,7 @@ antigravity-awesome-skills/
 
 ```
                     ┌─────────────────────────┐
-                    │  1,684+ AWESOME SKILLS  │
+                    │  1,936+ AWESOME SKILLS  │
                     └────────────┬────────────┘
                                  │
         ┌────────────────────────┼────────────────────────┐
@@ -181,7 +181,7 @@ antigravity-awesome-skills/
 ┌─────────────────────────────────────────┐
 │ Terminal                                │
 ├─────────────────────────────────────────┤
-│ $ npx antigravity-awesome-skills        │
+│ $ npx agentic-awesome-skills        │
 │                                         │
 │ ✓ Cài vào '~/.agents/skills'...         │
 │ ✓ Hoàn tất!                             │
@@ -199,7 +199,7 @@ antigravity-awesome-skills/
 │       ├── 📁 brainstorming/             │
 │       ├── 📁 stripe-integration/        │
 │       ├── 📁 react-best-practices/      │
-│       └── ... (1,684+ skills)           │
+│       └── ... (1,936+ skills)           │
 └─────────────────────────────────────────┘
 ```
 
@@ -436,7 +436,7 @@ BẮT ĐẦU TẠI ĐÂY
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │  📥 CÀI ĐẶT                                                 │
-│  npx antigravity-awesome-skills                             │
+│  npx agentic-awesome-skills                             │
 │                                                             │
 │  🎯 SỬ DỤNG                                                 │
 │  @ten-skill [yêu cầu của bạn]                               │

package/bundled-skills/docs-guard/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: "docs-guard"
+description: "Review generated or changed documentation before it ships, including READMEs, API references, docstrings, changelogs, tutorials, and documentation sites."
+risk: "critical"
+source: "community"
+source_repo: "amElnagdy/guard-skills"
+source_type: "community"
+date_added: 2026-07-13
+author: "community"
+tags: []
+tools: []
+---
+
+
+# Docs Guard
+
+You are reviewing generated or changed documentation before it ships. Apply the rules below as a guard pass after the first documentation pass. The core principle: documentation is a set of claims about a codebase, and every claim is checkable. Your job is to check them.
+
+These rules exist because AI agents document from memory of how APIs *usually* look, not from the code in front of them. Published research: half of AI answers to programming questions contain incorrect information, and models produce valid invocations for infrequent APIs barely a third of the time — yet the prose sounds authoritative either way. Readers cannot tell verified docs from hallucinated docs. You can, because you have the source.
+
+## When to Use
+
+Use this skill when reviewing generated or changed documentation before it ships. Activate it reactively after an agent writes or updates READMEs, API references, docstrings, PHPDoc/JSDoc, changelogs, tutorials, or doc sites.
+
+## How to use this skill
+
+**Guard-pass mode** (recommended): after documentation or docstrings have been generated or edited, verify every claim against the source and run the self-check before delivery.
+
+**Live mode** (explicit): when the user invokes this skill before writing docs, verify before you write — read the actual implementation, then document what it does. Run the self-check before delivery.
+
+**Review mode** (the user asks you to review, audit, or fact-check docs): walk [references/review-checklist.md](references/review-checklist.md) against the target docs and produce a findings report with file:line evidence. Do not rewrite in review mode unless asked.
+
+## Adapt to the project first
+
+1. Read the project's agent instructions (CLAUDE.md, AGENTS.md) and any docs style guide. Project conventions win on conflict.
+2. Identify the docs surfaces that must move together: README, reference docs, docstrings, changelog, examples, config samples. A change to one usually owes a change to others (Rule 6).
+3. Note the documented version policy: which versions does the project support, and where are features version-tagged?
+
+## The Rules
+
+### Accuracy — must fix
+
+1. **Every referenced symbol must exist.** Every function, method, class, hook, CLI command, flag, endpoint, config key, env var, and file path mentioned in the docs gets verified against the actual source, CLI help output, route table, or schema — by reading it, not recalling it. The verification procedure is in [references/verification.md](references/verification.md). An unverifiable reference does not ship.
+
+2. **Every code sample must work.** Imports resolve, APIs exist with the documented signatures (names, argument order, defaults, return shape), and the sample runs outside the author's machine — no hardcoded local paths, no real credentials, no implicit prior state. Sample rules: [references/code-samples.md](references/code-samples.md).
+
+3. **Document the code's actual behavior, not its intended behavior.** Read the implementation before describing it. Where code and comments/specs disagree, the code is the truth — and flag the disagreement to the user instead of silently picking a side.
+
+4. **No unverifiable claims.** Performance numbers, compatibility matrices, scale limits, and "production-ready" assertions require a source in the repository (benchmark script, CI matrix, changelog entry) or they come out. "Fast" is marketing; "O(n log n), benchmarked in bench/sort.md" is documentation.
+
+### Versioning and drift
+
+5. **Versions are explicit.** Features, flags, and behaviors state the version that introduced them when the project tracks versions. Prerequisites are pinned or ranged, never "latest". Deprecated items say so, with the replacement.
+
+6. **A code change owes a docs change.** When editing code whose behavior is documented — rename, signature change, new default, removed flag — update every doc surface that mentions it in the same change. Grep the docs for the old symbol before finishing.
+
+### Substance — should fix
+
+7. **No filler, no slop.** Delete: docstrings that paraphrase the signature ("Gets the user by ID" above `get_user_by_id`), sections that restate their heading, marketing adjectives in technical prose ("powerful", "seamless", "blazingly fast"), and intro padding ("In this section, we will explore…"). A docstring earns its place by adding contracts the signature cannot express: units, ranges, error conditions, side effects, threading/ordering guarantees.
+
+8. **Don't paraphrase upstream docs.** Link to external documentation instead of restating it — paraphrased upstream docs drift the moment upstream changes. Document only your project's relationship to the external thing (which subset you use, what you configure differently).
+
+9. **Examples cover the failure path too.** A tutorial that only shows the happy path documents half the API. Show what the error looks like and what the caller should do — using the error types the code actually raises (verify per Rule 1).
+
+### Structure — worth noting
+
+10. **Navigation tells the truth.** Headings describe their sections, the table of contents matches the actual headings, internal links and anchors resolve, and there are no TODO stubs or "coming soon" sections in published docs — unwritten sections are removed, not promised.
+
+## Self-check before delivery
+
+1. List every symbol, flag, endpoint, config key, and path your docs mention. Did you verify each one against the source in this session — not from memory?
+2. Would every code sample run on a clean machine? Did you check each import and signature?
+3. Any number, compatibility claim, or superlative without a repo-verifiable source?
+4. If this change touched code: did you grep all docs surfaces for the old names?
+5. Any docstring that just restates the signature? Any section that restates its heading?
+6. Do all internal links and anchors resolve?
+
+If any answer is wrong, fix it before showing the user.
+
+## Reporting format (review mode)
+
+```
+**Rule N violation** in `docs/path.md:<line or section>`
+- Claim: <what the docs say>
+- Reality: <what the code/CLI/schema actually has, with file:line>
+- Fix: <one sentence>
+```
+
+Lead with Rule 1–4 findings (false claims), then drift, then substance. If a doc is clean, say so in one line — accuracy deserves credit.
+
+## Severity guide
+
+- **Must fix:** Rules 1–4 — false documentation is worse than no documentation; readers act on it
+- **Should fix:** Rules 5–9 — drift debt and noise that buries the signal
+- **Worth noting:** Rule 10 — navigation and polish
+
+## References
+
+- [references/verification.md](references/verification.md) — the mechanical procedure: extracting claims, verifying symbols, signatures, CLI flags, endpoints, config keys, links
+- [references/code-samples.md](references/code-samples.md) — what makes a sample shippable: runnability, realistic data, secrets hygiene, error paths
+- [references/docstrings.md](references/docstrings.md) — docstring/PHPDoc/JSDoc-specific rules: when one is justified, what it must contain, paraphrase detection
+- [references/review-checklist.md](references/review-checklist.md) — structured walk-through for review mode
+- [references/sources.md](references/sources.md) — research and style-guide URLs; read only when citing a source
+
+## What this skill does not do
+
+- Review the code itself — clean-code-guard's jurisdiction. This skill reviews what the docs *claim about* the code.
+- Generate documentation strategy or information architecture from scratch — it guards accuracy and substance, not scope decisions.
+- Enforce a prose style guide — tone belongs to the project; truth belongs to this skill.

package/bundled-skills/docs-guard/references/code-samples.md

@@ -0,0 +1,46 @@
+# Docs Guard — Code Sample Rules
+
+A code sample is the most-trusted part of any documentation: readers paste it. That trust makes a broken sample worse than no sample.
+
+## Contents
+
+- Shippable sample checklist
+- Realistic data
+- Secrets and credentials
+- Error-path examples
+- Language and environment tags
+- Sample drift
+
+## Shippable sample checklist
+
+Every sample must pass all of these:
+
+1. **Imports resolve** — every import/require/use names a real module at the documented version.
+2. **APIs are real** — every call verified per [verification.md](verification.md): name, argument order, defaults, return shape.
+3. **Self-contained or explicit** — runs on a clean machine, or states its prerequisites immediately above the block ("requires the client from the previous step").
+4. **No local residue** — no `/Users/yourname/`, no `C:\Dev\`, no machine-specific ports or hostnames; use placeholder conventions the project already uses.
+5. **Syntactically valid** — parse it mentally line by line; when the runtime allows, actually run or lint it.
+6. **Output shown is output produced** — if the sample shows a result, that result must be what the code yields, not an idealized version.
+
+## Realistic data
+
+Use data that exposes the API's shape honestly: realistic field names, plausible values, at least one non-ASCII string where text handling matters. `foo`/`bar` hides bugs that `"Café Münster"` reveals — especially for the i18n-aware audience.
+
+## Secrets and credentials
+
+- Placeholders that cannot be mistaken for real values: `YOUR_API_KEY`, `example.com`, RFC 5737 IPs (`192.0.2.x`), `sk_test_…` style markers only when the provider defines them.
+- Never paste real-looking tokens — even invented ones train readers to paste theirs, and secret scanners will flag the repo.
+- Auth setup goes in one place and is linked, not repeated with variations in every sample.
+
+## Error-path examples
+
+For any API that can fail in normal operation, show one failure: what the error object/exception/status looks like and the minimal correct response to it — using the error types the code actually raises (verify the raise site). Happy-path-only documentation produces catch-all error swallowing downstream, the exact failure clean-code-guard exists to stop.
+
+## Language and environment tags
+
+- Fenced blocks carry the correct language tag — broken highlighting is a trust signal readers notice.
+- State the environment when it changes behavior: shell prompts (`$` vs `#`), OS-specific paths, version-gated syntax.
+
+## Sample drift
+
+Samples drift faster than prose because nobody re-runs them. On any code change touching a documented API, grep the docs for the old symbol (SKILL.md Rule 6) — samples are where the stale hits hide. Projects with executable-docs tooling (doctest and kin): prefer it; this skill's manual verification is the floor, not the ceiling.

package/bundled-skills/docs-guard/references/docstrings.md

@@ -0,0 +1,60 @@
+# Docs Guard — Docstring, PHPDoc, and JSDoc Rules
+
+In-code documentation has one extra constraint the other surfaces lack: it sits next to the truth. There is no excuse for a docstring that disagrees with the signature three lines below it.
+
+## Contents
+
+- When a docstring is justified
+- The paraphrase test
+- What a good docstring contains
+- Tag accuracy (PHPDoc/JSDoc)
+- Generated-docs hygiene
+
+## When a docstring is justified
+
+- Public API surface: always — it feeds IDEs, generated references, and agents.
+- Internal helpers: only when the contract is not expressible in the signature (units, invariants, side effects, "why"). An internal one-liner with an intention-revealing name usually needs nothing — and clean-code-guard's comment rules apply.
+
+## The paraphrase test
+
+Delete any docstring whose entire information content is recoverable from the signature:
+
+```php
+// Fails the test — restates the obvious, documents nothing.
+/**
+ * Gets the user by ID.
+ *
+ * @param int $user_id The user ID.
+ * @return WP_User The user.
+ */
+function get_user_by_id( $user_id ) { /* … */ }
+```
+
+AI generators emit these by the thousand; they are comment pollution wearing a suit. Either say something the signature cannot, or say nothing.
+
+## What a good docstring contains
+
+The contract the types cannot express:
+
+- Units and ranges (`$timeout` in seconds? milliseconds? what happens at 0?)
+- Error behavior: which exceptions/returns on failure, and when (verify the raise/return sites)
+- Side effects: writes, cache invalidation, events fired, global state touched
+- Null/empty semantics: what `null` means here, what an empty array does
+- Ordering, idempotency, concurrency guarantees when callers depend on them
+- The "why" for surprising design ("returns 1.0 on API failure so prices never disappear")
+
+## Tag accuracy (PHPDoc/JSDoc)
+
+- `@param` names and order match the signature exactly — drift here actively lies to IDEs.
+- `@param` and `@return` types match the real types, including nullability (`int|WP_Error`, `?string`) and generics where the project uses them.
+- `@throws` lists what the body actually throws — verify each raise site; remove what no longer throws.
+- `@since` matches the changelog/tag where the project versions its API.
+- `@deprecated` always names the replacement.
+
+## Generated-docs hygiene
+
+When docstrings feed a generated reference (phpDocumentor, JSDoc, Sphinx, TypeDoc):
+
+- A wrong docstring becomes a published wrong reference page — Rule 1 severity applies as if it were the README.
+- Check that examples inside docstrings obey [code-samples.md](code-samples.md) — they are the least-reviewed samples in any codebase.
+- Markup must be valid for the generator in use; broken tags silently truncate published pages.

package/bundled-skills/docs-guard/references/review-checklist.md

@@ -0,0 +1,45 @@
+# Docs Guard — Review Checklist
+
+Structured walk for review mode. Findings first, file:line evidence always. Priorities: false claims → drift → substance → navigation.
+
+## Contents
+
+- Pass 1: Claim verification
+- Pass 2: Code samples
+- Pass 3: Drift scan
+- Pass 4: Substance
+- Pass 5: Navigation
+- Reporting
+
+## Pass 1: Claim verification (must fix)
+
+Run the full procedure in [verification.md](verification.md):
+
+- Extract every symbol, flag, endpoint, config key, path, version, and behavioral claim.
+- Verify each against its source of truth (definition site, parser, route table, changelog).
+- Every unverified or contradicted claim is a Rule 1/3 finding with the contradicting file:line.
+- Numbers and superlatives without a repo source are Rule 4 findings.
+
+## Pass 2: Code samples (must fix)
+
+For every fenced block, run the [code-samples.md](code-samples.md) checklist: imports, signatures, self-containment, local residue, secrets, shown output. Samples in docstrings count.
+
+## Pass 3: Drift scan (should fix)
+
+- Take the public API surface (or the diff, when reviewing a change) and grep the docs for renamed/removed symbols, old defaults, and dead flags.
+- Check the changelog mentions what the docs claim is new, and versions agree (Rule 5).
+- Cross-surface consistency: README vs reference vs docstrings vs config samples — one claim per fact, surfaces agreeing (Rule 6).
+
+## Pass 4: Substance (should fix)
+
+- Paraphrase docstrings, heading-restating sections, marketing adjectives, intro padding (Rule 7).
+- Paraphrased upstream documentation that should be a link (Rule 8).
+- Happy-path-only tutorials and API examples (Rule 9).
+
+## Pass 5: Navigation (worth noting)
+
+- TOC vs actual headings; internal links and anchors resolve; no TODO stubs or "coming soon" in published docs (Rule 10).
+
+## Reporting
+
+Use the SKILL.md reporting format (Claim / Reality / Fix). Lead with the count: "N claims checked, M false, K unverifiable." End with a verdict — publish / fix first / do not publish — and at most three things the docs do well. A review that verifies 40 claims and finds 2 false is a *good* result; say so.

package/bundled-skills/docs-guard/references/sources.md

@@ -0,0 +1,22 @@
+# Docs Guard — Sources
+
+Central bibliography. Operational guidance lives in the other references; read this file only when a source URL is needed.
+
+## Contents
+
+- Research on AI-generated documentation defects
+- Documentation craft references
+
+## Research on AI-generated documentation defects
+
+- Kabir et al., "Is Stack Overflow Obsolete? An Empirical Study of the Characteristics of ChatGPT Answers to Stack Overflow Questions", CHI 2024 — 52% of answers contained incorrect information; evaluators missed AI errors 39% of the time: https://dl.acm.org/doi/10.1145/3613904.3642596
+- CloudAPIBench, "On Mitigating Code LLM Hallucinations with API Documentation" (AWS, 2024) — 38.58% valid invocations for low-frequency APIs: https://arxiv.org/abs/2407.09726
+- De-Hallucinator (2024) — LLMs routinely invent non-existent APIs; project-API grounding fixed 63.2% of hallucination-caused failures: https://arxiv.org/abs/2401.01701
+- Spracklen et al., "We Have a Package for You!" (USENIX Security 2025) — package hallucination averages 19.6% across 16 models: https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen
+
+## Documentation craft references
+
+- Diátaxis — the four documentation modes (tutorial, how-to, reference, explanation): https://diataxis.fr/
+- Write the Docs — style guide collection: https://www.writethedocs.org/guide/writing/style-guides/
+- RFC 5737 — IPv4 address blocks reserved for documentation: https://www.rfc-editor.org/rfc/rfc5737
+- Google developer documentation style guide: https://developers.google.com/style

package/bundled-skills/docs-guard/references/verification.md

@@ -0,0 +1,51 @@
+# Docs Guard — Verification Procedure
+
+The mechanical heart of this skill: turn a document into a list of claims, then check each claim against the source of truth.
+
+## Contents
+
+- Step 1: Extract the claims
+- Step 2: Verify each claim type
+- Step 3: Record what you verified
+- When you cannot verify
+
+## Step 1: Extract the claims
+
+Scan the doc and list every:
+
+- Function, method, class, constant, hook, event name
+- CLI command, subcommand, flag, default value
+- HTTP endpoint, method, status code, request/response field
+- Config key, env var, file path, directory layout claim
+- Version number, compatibility statement, dependency requirement
+- Behavioral claim ("retries three times", "case-insensitive", "idempotent")
+
+Inline code spans and code blocks are claim-dense; prose hides claims in verbs ("automatically reconnects" is a claim).
+
+## Step 2: Verify each claim type
+
+| Claim type | Source of truth | How |
+|---|---|---|
+| Symbol exists | The codebase | Grep definition (`function name`, `class Name`, `def name`, export) — not usages, the definition |
+| Signature | The definition site | Read parameters, defaults, return; compare name-by-name with the doc |
+| CLI flag | The argument parser source, or `--help` output if runnable | Read the parser registration; flags in README but not in the parser are hallucinations |
+| Endpoint | Route registration (router file, `register_rest_route`, annotations) | Match path, method, and handler |
+| Config key | The code that reads it (`getenv`, config schema, `get_option`) | A documented key nothing reads is dead documentation |
+| Default value | The definition, not the docs of the definition | Defaults drift silently; read the current line |
+| Version claim | Changelog, git tags, dependency manifests | "Since 2.3" must appear in the 2.3 changelog or tag diff |
+| Behavioral claim | The implementation path | Read the function; trace the claimed behavior (retry loop, case fold, guard clause) |
+| Internal link/anchor | The target file/heading | Resolve the relative path; slugify the heading and compare |
+
+## Step 3: Record what you verified
+
+In write-time mode, keep a short verification trail in your working notes (not in the doc): claim → file:line where confirmed. In review mode, this trail becomes your evidence — every finding cites the definition site that contradicts the doc.
+
+When the runtime allows execution, prefer executable checks: run `--help`, run the sample, run a link checker. When it does not, source-reading is the standard — never skip to "it looks right."
+
+## When you cannot verify
+
+If the source of truth is unavailable (private dependency, external service, missing schema):
+
+1. Say so explicitly rather than guessing.
+2. Downgrade the claim to what you can verify ("the client calls the `/v2/orders` endpoint" → verified in client code, even if the server is unreachable).
+3. Never decorate an unverified claim with confident language. "Should", "appears to", or a direct question to the user beats a fluent hallucination.

package/bundled-skills/efficient-web-research/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: efficient-web-research
+source: community
 risk: safe
 description: >
   Protocol for token-efficient web research. Use when accessing URLs, GitHub repos, or running search queries. Prevents full-page fetching waste.
@@ -12,6 +13,9 @@ using the right tool at the right depth, and stopping as soon as the question is
 
 ---
 
+## When to Use
+- Use this skill when the task matches this description: Protocol for token-efficient web research. Use when accessing URLs, GitHub repos, or running search queries. Prevents full-page fetching waste.
+
 ## Core Principle
 
 > **Fetch the minimum needed to answer. Skim before you dive. Stop when you can answer.**

package/bundled-skills/electron-development/SKILL.md

@@ -295,7 +295,7 @@ const unsubscribe = window.electronAPI.on('update:available', (version) => {
 
 ── CONTENT ──
 [ ] Content Security Policy (CSP) headers set on all windows
-[ ] No use of eval(), new Function(), or innerHTML with untrusted data
+[ ] No use of eval(), new Function(), or innerHTML with untrusted data <!-- security-allowlist: defensive Electron checklist -->
 [ ] Remote content (if any) loaded in separate BrowserView with restricted permissions
 [ ] protocol.registerSchemesAsPrivileged() uses minimal permissions
 

package/bundled-skills/event-staffing-compliance/SKILL.md

@@ -13,6 +13,9 @@ often discover only after an incident: worker misclassification penalties,
 joint-employer liability, uninsured on-site injuries, and wage/hour
 violations. Use this skill to help a user evaluate a staffing arrangement.
 
+## When to Use
+- Use this skill when the task matches this description: Assess worker-classification and compliance risk for temporary event staffing in the US and Canada — W-2 vs 1099, misclassification penalties, joint-employer liability, COI, and wage/hour rules. Includes live state-by-state lookups via MCP.
+
 ## Live data
 
 Endpoint: `POST https://mcp.tempguru.co/mcp` (read-only, no auth).

package/bundled-skills/event-staffing-ordering/SKILL.md

@@ -19,6 +19,9 @@ many cities the event spans.
 Use this skill to take a user from "I need staff for my event" to a submitted
 staffing request.
 
+## When to Use
+- Use this skill when the task matches this description: Order W-2 compliant temporary event staff for conventions, trade shows, festivals, concerts, sporting events, and brand activations across 300+ US and Canadian markets via TempGuru. Covers city coverage, role pricing, availability, state compliance lookups via MCP, and request submission.
+
 ## Live data: use the MCP server, do not scrape pages
 
 Endpoint: `POST https://mcp.tempguru.co/mcp` (streamable HTTP, read-only, no auth).