opencode-skills-collection 4.1.15 → 4.1.17

package/bundled-skills/tune-monitor/references/validation-monitor.md

@@ -0,0 +1,132 @@
+# Tuning Validation Monitors
+
+This reference covers type-specific tuning guidance for validation monitors. Read this file after
+determining the monitor type in Phase 1.5.
+
+## Config fields to extract
+
+Extract these from the `get_monitors` config response for your Phase 2 analysis:
+
+- Alert condition tree (`alert_condition`) — a FilterGroup with UNARY, BINARY, SQL, and/or
+  nested GROUP nodes
+- Table being validated
+- Schedule interval
+- Whether conditions use simple predicates or SQL expressions
+
+---
+
+## Key constraint: limited incident detail
+
+Validation incidents only report **invalid row counts** — not what the rows contained. This
+fundamentally limits what you can recommend without troubleshooting analysis (TSA).
+
+**Without TSA:** You cannot determine _why_ rows are invalid or whether the alert condition
+itself is too broad. Only schedule changes are safe to recommend.
+
+**With TSA:** If troubleshooting analysis identifies specific values, patterns, or root causes
+for the invalid rows, you can recommend alert condition modifications.
+
+---
+
+## Schedule tuning (always safe)
+
+- If the monitor fires repeatedly for the same underlying issue (e.g., the same batch of invalid
+  rows detected on every run) → increase the schedule interval to reduce duplicate alerts.
+- If invalid rows appear only after specific ETL jobs → align the schedule to run after those
+  jobs complete.
+
+---
+
+## Alert condition modifications (requires troubleshooting analysis)
+
+**IMPORTANT:** Do NOT recommend alert condition changes unless TSA is present and identifies the
+root cause of the invalid rows. Without knowing _what_ the invalid data looks like, condition
+changes risk masking real issues.
+
+The alert condition is a FilterGroup tree. When tuning:
+
+### Add exclusions
+
+Add SQL conditions or additional predicates to exclude known-valid edge cases that trigger
+false positives:
+
+```json
+{
+  "type": "GROUP",
+  "operator": "AND",
+  "conditions": [
+    // ... existing conditions ...
+    {
+      "type": "SQL",
+      "sql": "category != 'legacy_import'"
+    }
+  ]
+}
+```
+
+### Tighten or loosen existing predicates
+
+- If a BINARY condition threshold is too tight (e.g., `greater_than 0` but 1-3 invalid rows
+  is normal) → loosen the threshold based on observed values from TSA.
+- If a UNARY null check fires on a column that is legitimately nullable for certain record
+  types → add an exclusion condition rather than removing the null check.
+
+### Produce the full FilterGroup tree
+
+When recommending changes, always output the **complete** `alert_condition` tree — not just the
+modified node. The tool replaces the full condition, not individual nodes.
+
+**NEVER** simplify or restructure the condition tree beyond the targeted change. Preserve the
+existing structure and only modify what's needed.
+
+---
+
+## What NOT to recommend without TSA
+
+- Removing conditions from the alert condition tree
+- Changing predicate logic (e.g., `null` to `not_null`, `in_set` to different values)
+- Adding new conditions based on speculation about what the invalid data might look like
+
+If TSA is absent and the monitor is noisy, say so explicitly:
+
+> This validation monitor is firing frequently, but without troubleshooting analysis I cannot
+> determine what the invalid rows contain. I can only recommend schedule changes. To enable
+> deeper tuning, run troubleshooting on recent incidents to identify the root cause.
+
+---
+
+## Applying changes
+
+Use `create_or_update_validation_monitor` to update the monitor in place.
+
+1. **Always pass `monitor_uuid=<uuid>`** so the tool updates the existing monitor rather than
+   creating a new one. Use the monitor UUID from Phase 1.
+2. **Always dry-run first** (`dry_run=True`, the default) — show the user the YAML preview
+   returned in `result.yaml`, including the full updated `alert_condition` tree, and ask for
+   confirmation before applying.
+3. **On confirmation**, call again with `dry_run=False` (and the same `monitor_uuid` plus the
+   same other parameters). The response carries the monitor's UUID in `result.monitor_uuid` and
+   a deep link in `result.instructions` — surface that to the user. `result.yaml` is `None` on
+   the live call by design.
+4. **Stale-uuid handling.** If the monitor was deleted between read and write, the tool raises a
+   clear error instructing you to retry without `monitor_uuid` (turning the intent from "update"
+   into "create"). Confirm with the user before recreating.
+
+### Common mistakes
+
+- **NEVER** omit `monitor_uuid` — this creates a duplicate monitor instead of updating.
+- **NEVER** apply changes without showing the dry-run preview first.
+- **CRITICAL: PUT semantics.** `create_or_update_validation_monitor` with `monitor_uuid` fully
+  replaces the monitor's configuration — fields you omit revert to tool defaults, they are NOT
+  left untouched. The full config from Phase 1's `get_monitors(monitor_ids=[<uuid>],
+  include_fields=["config"])` call is your source of truth: re-pass every field you want to
+  keep (the full alert_condition tree, schedule, table, audiences, notes, priority, tags, etc.)
+  alongside the ones you're changing.
+- **Diff the preview against the original.** Before running `dry_run=False`, compare the
+  rendered YAML returned in `result.yaml` against the original config — if anything you meant to
+  preserve is missing or changed, fix the call before committing.
+- **CRITICAL:** The `alert_condition` must be a dict (JSON object), never a JSON-encoded string.
+- **IMPORTANT:** Always produce the full `alert_condition` tree, not just the changed node.
+  The tool replaces the entire condition tree.
+- **NEVER** recommend condition changes without TSA evidence — schedule changes are the only
+  safe lever without it.

package/bundled-skills/turborepo-caching/SKILL.md

@@ -20,7 +20,6 @@ Production patterns for Turborepo build optimization.
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Use this skill when
 

package/bundled-skills/tutorial-engineer/SKILL.md

@@ -30,7 +30,6 @@ metadata:
  - Clarify goals, constraints, and required inputs.
  - Apply relevant best practices and validate outcomes.
  - Provide actionable steps and verification.
- - If detailed examples are required, open `resources/implementation-playbook.md`.
  
  You are a tutorial engineering specialist who transforms complex technical concepts into engaging, hands-on learning experiences. Your expertise lies in pedagogical design and progressive skill building.
  

package/bundled-skills/typescript-expert/SKILL.md

@@ -27,7 +27,8 @@ You are an advanced TypeScript expert with deep, practical knowledge of type-lev
    
    ```bash
    # Core versions and configuration
-   npx tsc --version
+   # --no-install: never download. Without a local TypeScript, plain `npx tsc` can fetch the unrelated "tsc" npm package.
+   npx --no-install tsc --version
    node -v
    # Detect tooling ecosystem (prefer parsing package.json)
    node -e "const p=require('./package.json');console.log(Object.keys({...p.devDependencies,...p.dependencies}||{}).join('\n'))" 2>/dev/null | grep -E 'biome|eslint|prettier|vitest|jest|turborepo|nx' || echo "No tooling detected"
@@ -48,8 +49,8 @@ You are an advanced TypeScript expert with deep, practical knowledge of type-lev
 4. Validate thoroughly:
    ```bash
    # Fast fail approach (avoid long-lived processes)
-   npm run -s typecheck || npx tsc --noEmit
-   npm test -s || npx vitest run --reporter=basic --no-watch
+   npm run -s typecheck || npx --no-install tsc --noEmit
+   npm test -s || npx --no-install vitest run
    # Only if needed and build affects outputs/config
    npm run -s build
    ```
@@ -110,7 +111,7 @@ type Route = typeof routes[number]; // '/home' | '/about' | '/contact'
 **Type Checking Performance**
 ```bash
 # Diagnose slow type checking
-npx tsc --extendedDiagnostics --incremental false | grep -E "Check time|Files:|Lines:|Nodes:"
+npx --no-install tsc --extendedDiagnostics --incremental false | grep -E "Check time|Files:|Lines:|Nodes:"
 
 # Common fixes for "Type instantiation is excessively deep"
 # 1. Replace type intersections with interfaces
@@ -143,8 +144,9 @@ npx tsc --extendedDiagnostics --incremental false | grep -E "Check time|Files:|L
 // types/ambient.d.ts
 declare module 'some-untyped-package' {
   const value: unknown;
-  export default value;
-  export = value; // if CJS interop is needed
+  export default value; // ESM package
+  // OR, for a CommonJS package, use `export = value;` instead.
+  // Do not use both: TypeScript rejects that with TS2309.
 }
 ```
 - For more details: [Declaration Files Guide](https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html)
@@ -279,11 +281,11 @@ command -v tsx >/dev/null 2>&1 && npx tsx --inspect src/file.ts
 command -v ts-node >/dev/null 2>&1 && npx ts-node --inspect-brk src/file.ts
 
 # Trace module resolution issues
-npx tsc --traceResolution > resolution.log 2>&1
+npx --no-install tsc --traceResolution > resolution.log 2>&1
 grep "Module resolution" resolution.log
 
 # Debug type checking performance (use --incremental false for clean trace)
-npx tsc --generateTrace trace --incremental false
+npx --no-install tsc --generateTrace trace --incremental false
 # Analyze trace (if installed)
 command -v @typescript/analyze-trace >/dev/null 2>&1 && npx @typescript/analyze-trace trace
 

package/bundled-skills/typescript-expert/scripts/ts_diagnostic.py

@@ -10,13 +10,43 @@ import os
 import json
 from pathlib import Path
 
+TSC = ["npx", "--no-install", "tsc"]
+
 def run_cmd(args):
-    """Run a command as an argument list (no shell) and return its output."""
+    """Run a command as an argument list (no shell). Return (returncode, output)."""
     try:
-        result = subprocess.run(args, capture_output=True, text=True)
-        return result.stdout + result.stderr
-    except Exception as e:
-        return str(e)
+        result = subprocess.run(args, capture_output=True, text=True, errors="replace")
+        return result.returncode, result.stdout + result.stderr
+    except OSError as e:
+        return None, str(e)
+
+def strip_jsonc(text: str) -> str:
+    """Remove // and /* */ comments and trailing commas, which tsconfig.json allows."""
+    out, i, n = [], 0, len(text)
+    while i < n:
+        c = text[i]
+        if c == '"':  # copy a string literal unchanged
+            j = i + 1
+            while j < n and text[j] != '"':
+                j += 2 if text[j] == "\\" else 1
+            out.append(text[i:j + 1])
+            i = j + 1
+        elif text.startswith("//", i):
+            j = text.find("\n", i)
+            i = n if j < 0 else j
+        elif text.startswith("/*", i):
+            j = text.find("*/", i + 2)
+            i = n if j < 0 else j + 2
+        else:
+            if c in "}]":  # drop a trailing comma before the closing bracket
+                k = len(out) - 1
+                while k >= 0 and out[k].isspace():
+                    k -= 1
+                if k >= 0 and out[k] == ",":
+                    del out[k]
+            out.append(c)
+            i += 1
+    return "".join(out)
 
 def grep_source_count(pattern: str, exclude: str | None = None) -> tuple[int, list[str]]:
     """Count and sample lines containing ``pattern`` under ``src/``.
@@ -44,11 +74,11 @@ def check_versions():
     print("\n📦 Versions:")
     print("-" * 40)
     
-    ts_version = run_cmd(["npx", "tsc", "--version"]).strip()
-    node_version = run_cmd(["node", "-v"]).strip()
+    ts_rc, ts_version = run_cmd([*TSC, "--version"])
+    node_rc, node_version = run_cmd(["node", "-v"])
     
-    print(f"  TypeScript: {ts_version or 'Not found'}")
-    print(f"  Node.js: {node_version or 'Not found'}")
+    print(f"  TypeScript: {ts_version.strip() if ts_rc == 0 else 'Not found (no local typescript)'}")
+    print(f"  Node.js: {node_version.strip() if node_rc == 0 else 'Not found'}")
 
 def check_tsconfig():
     """Analyze tsconfig.json settings."""
@@ -61,8 +91,8 @@ def check_tsconfig():
         return
     
     try:
-        with open(tsconfig_path) as f:
-            config = json.load(f)
+        with open(tsconfig_path, encoding="utf-8") as f:
+            config = json.loads(strip_jsonc(f.read()))
         
         compiler_opts = config.get("compilerOptions", {})
         
@@ -155,14 +185,17 @@ def check_type_errors():
     print("\n🔍 Type Check:")
     print("-" * 40)
     
-    result = run_cmd(["npx", "tsc", "--noEmit"])
+    rc, result = run_cmd([*TSC, "--noEmit"])
     lines = result.splitlines()
-    if "error TS" in result:
+    if rc == 0:
+        print("  ✅ No type errors")
+    elif "error TS" in result:
         errors = result.count("error TS")
         print(f"  ❌ {errors}+ type errors found")
         print("\n".join(lines[:20])[:500])
     else:
-        print("  ✅ No type errors")
+        print(f"  ⚠️ Type check did not run (exit code {rc}). Is typescript installed locally?")
+        print("\n".join(lines[:5])[:500])
 
 def check_any_usage():
     """Check for any type usage."""
@@ -193,7 +226,7 @@ def check_performance():
     print("\n⏱️ Type Check Performance:")
     print("-" * 40)
     
-    result = run_cmd(["npx", "tsc", "--extendedDiagnostics", "--noEmit"])
+    _, result = run_cmd([*TSC, "--extendedDiagnostics", "--noEmit"])
     keys = ("Check time", "Files:", "Lines:", "Nodes:")
     lines = [line for line in result.splitlines() if any(k in line for k in keys)]
     if lines:

package/bundled-skills/ui-ux-designer/SKILL.md

@@ -21,7 +21,6 @@ date_added: '2026-02-27'
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 You are a UI/UX design expert specializing in user-centered design, modern design systems, and accessible interface creation.
 

package/bundled-skills/ui-visual-validator/SKILL.md

@@ -21,7 +21,6 @@ date_added: '2026-02-27'
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 You are an experienced UI visual validation expert specializing in comprehensive visual testing and design verification through rigorous analysis methodologies.
 

package/bundled-skills/uniprot-database/SKILL.md

@@ -8,6 +8,14 @@ risk: safe
 source: community
 date_added: "2026-09-04"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/scripts/uniprot_client.py`
+
+Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 # UniProt Database
 

package/bundled-skills/unity-developer/SKILL.md

@@ -21,7 +21,6 @@ date_added: '2026-02-27'
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 You are a Unity game development expert specializing in high-performance, cross-platform game development with comprehensive knowledge of the Unity ecosystem.
 

package/bundled-skills/usage-based-pricing/SKILL.md

@@ -18,7 +18,7 @@ Read [the detailed guide](references/detailed-guide.md) before executing this sk
 
 ## When to Use
 
-Use this skill when you need design pricing models that developers understand, accept, and can predict. Trigger phrases: usage-based pricing, API pricing, metered billing, developer pricing, pricing page, cost calculator, pay as you go, pricing transparency, competitive pricing, developer billing.
+Use this skill when you need to design pricing models that developers understand, accept, and can predict. Trigger phrases: usage-based pricing, API pricing, metered billing, developer pricing, pricing page, cost calculator, pay as you go, pricing transparency, competitive pricing, developer billing.
 
 
 Design pricing models that developers understand, accept, and can predict—without surprise bills or confusing metrics.

package/bundled-skills/using-agent-skills/SKILL.md

@@ -12,6 +12,9 @@ license: MIT
 license_source: https://github.com/addyosmani/agent-skills/blob/main/LICENSE
 compatibility: Portable instruction skill; no CLI, MCP server, or network access required.
 ---
+## Bundled upstream support
+
+Supporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.
 
 # Using Agent Skills
 
@@ -121,7 +124,7 @@ Your job is surgical precision, not unsolicited renovation.
 
 Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence (passing tests, build output, runtime data).
 
-Per-skill verification is the local check. The project-wide bar that applies to *every* change, regardless of which skill is active, is the Definition of Done: tests pass, no regressions, behavior verified at runtime, docs updated. See `../../references/definition-of-done.md`. It complements each task's acceptance criteria rather than replacing them.
+Per-skill verification is the local check. The project-wide bar that applies to *every* change, regardless of which skill is active, is the Definition of Done: tests pass, no regressions, behavior verified at runtime, docs updated. See `references/definition-of-done.md`. It complements each task's acceptance criteria rather than replacing them.
 
 ## Failure Modes to Avoid
 

package/bundled-skills/using-agent-skills/UPSTREAM-LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Addy Osmani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS 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 SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/bundled-skills/using-agent-skills/UPSTREAM-NOTICE.md

@@ -0,0 +1,11 @@
+# Upstream helpers for using-agent-skills
+
+The files listed below were recovered from [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) at commit `aeac41d4d005999432bb7312f7ff06383a91d59d`. The repository ID is `1158722119`.
+
+They retain the upstream **MIT** license reproduced in [UPSTREAM-LICENSE.txt](UPSTREAM-LICENSE.txt). This notice applies to the listed support files; it does not replace the license metadata of other catalog files. Preserve the upstream license and this attribution when redistributing them.
+
+License wording is unchanged; text-only trailing whitespace and EOF blank lines are normalized. Original license: https://github.com/addyosmani/agent-skills/blob/aeac41d4d005999432bb7312f7ff06383a91d59d/LICENSE
+
+| Local file | Original upstream path | Original Git blob SHA | Import changes |
+| --- | --- | --- | --- |
+| `references/definition-of-done.md` | `references/definition-of-done.md` | `35e39f9e15f6dd0ff4725a6e5cbce7f2aa69064a` | text-only trailing whitespace and EOF blank lines normalized |

package/bundled-skills/using-agent-skills/references/definition-of-done.md

@@ -0,0 +1,67 @@
+# Definition of Done
+
+A standing, project-wide bar that every change must clear before it counts as done. Unlike acceptance criteria, which vary per task and answer "did we build the right thing?", the Definition of Done is the same every time and answers "is this finished to our standard?". Use it as the final gate in `planning-and-task-breakdown`, `incremental-implementation`, and `shipping-and-launch`.
+
+## Definition of Done vs. Acceptance Criteria
+
+| | Acceptance Criteria | Definition of Done |
+|---|---|---|
+| Scope | Specific to one task or spec | Applies to every increment |
+| Changes | Different for each item | Fixed and reused |
+| Answers | "Did we build *this thing*?" | "Is it *ready*?" |
+| Owner | Defined when planning the task | Defined once for the project |
+| Example | "User can reset password via email link" | "Tests pass, no regressions, docs updated" |
+
+The two are complementary. A task is done only when **its** acceptance criteria are met **and** the standing Definition of Done is satisfied. Skipping either leaves work that looks finished but is not.
+
+## The Standing Checklist
+
+Apply this to every change before declaring it done.
+
+### Correctness
+- [ ] All acceptance criteria for the task are met
+- [ ] Code runs and behaves as intended, verified at runtime, not just compiled or typechecked
+- [ ] New behavior is covered by tests that fail without the change and pass with it
+- [ ] Existing tests still pass; no regressions introduced
+- [ ] Edge cases and error paths are handled, not just the happy path
+
+### Quality
+- [ ] Code reveals intent through naming and structure; no comments needed to explain *what* it does
+- [ ] No duplicated business logic
+- [ ] No dead code, debug output, or commented-out blocks left behind
+- [ ] Changes are scoped to the task; no unrelated refactors snuck in
+- [ ] Linting and formatting pass
+
+The depth behind these items lives in `code-review-and-quality` (the five-axis review) and `code-simplification` (reducing complexity without changing behavior).
+
+### Integration
+- [ ] Change works with the rest of the system, not just in isolation
+- [ ] Database migrations, config changes, and feature flags are accounted for
+- [ ] Backward compatibility considered for any public interface or API change
+
+### Documentation
+- [ ] Public interfaces, APIs, and user-facing behavior are documented
+- [ ] Architectural decisions worth preserving are recorded (see `documentation-and-adrs`)
+- [ ] Documentation describes the current state in timeless language, not the change history
+
+### Ship-readiness
+- [ ] Security implications reviewed for any untrusted input, auth, or data handling (see `security-and-hardening`)
+- [ ] Observability in place for new critical paths (logs, metrics, traces) (see `observability-and-instrumentation`)
+- [ ] Rollback path exists for anything risky (see `shipping-and-launch`)
+- [ ] The human has reviewed and approved before merge or deploy
+
+## How to Apply
+
+- **Per task**: confirm the Correctness and Quality sections before checking the task off.
+- **Per feature**: confirm Integration and Documentation before considering the feature complete.
+- **Per release**: the full checklist is the floor; `shipping-and-launch` adds the deploy-specific gates on top.
+
+Tailor the list to the project once, then reuse it unchanged. A Definition of Done that is renegotiated every sprint is not a Definition of Done.
+
+## Red Flags
+
+- "It's done, I just haven't run it yet": unverified work is not done.
+- "Tests pass" used as a synonym for done while docs, regressions, or runtime verification are skipped.
+- A different bar applied depending on deadline pressure.
+- Acceptance criteria treated as the whole bar, with no standing quality floor.
+- "Done" declared before human review on changes that need it.

package/bundled-skills/using-neon/SKILL.md

@@ -5,6 +5,27 @@ risk: safe
 source: "https://github.com/neondatabase/agent-skills/tree/main/skills/neon-postgres"
 date_added: "2026-02-27"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/references/what-is-neon.md`
+- `<support-root>/references/referencing-docs.md`
+- `<support-root>/references/features.md`
+- `<support-root>/references/getting-started.md`
+- `<support-root>/references/connection-methods.md`
+- `<support-root>/references/devtools.md`
+- `<support-root>/references/neon-serverless.md`
+- `<support-root>/references/neon-drizzle.md`
+- `<support-root>/references/neon-auth.md`
+- `<support-root>/references/neon-js.md`
+- `<support-root>/references/neon-platform-api.md`
+- `<support-root>/references/neon-cli.md`
+- `<support-root>/references/neon-typescript-sdk.md`
+- `<support-root>/references/neon-python-sdk.md`
+
+Obtain the required material from the [declared upstream source](https://github.com/neondatabase/agent-skills/tree/main/skills/neon-postgres), or from a user-provided installation of that source. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 # Neon Serverless Postgres
 

package/bundled-skills/ux-persuasion-engineer/SKILL.md

@@ -5,12 +5,18 @@ risk: safe
 source: community
 date_added: "2026-04-04"
 ---
-You are a **Behavioral UX Researcher and Choice Architecture Specialist**. Your task is to apply behavioral psychology and persuasive design principles to UX flows. You reduce friction, increase commitment, and guide users toward the intended behavior without coercion.
+Use a marketing planning and audience-research lens. Your task is to apply behavioral psychology and persuasive design principles to UX flows. You reduce friction, increase commitment, and guide users toward the intended behavior without coercion.
 
 ## When to Use
 - Use when a product or page UX should guide decisions more clearly through layout, sequencing, and cues.
 - Use when conversion friction comes from interaction design rather than copy alone.
 
+## Evidence and scope
+
+Use observed audience research and verified product facts. Psychological interpretations and the author-year references below are inherited conceptual context, not validated evidence for this exact workflow or a guaranteed conversion effect. Before using a scientific claim externally, verify the actual publication, method and applicability; omit unsupported claims. This is marketing planning, not clinical diagnosis. Do not infer sensitive traits or exploit vulnerabilities.
+
+Original contribution: [PR 451](https://github.com/sickn33/agentic-awesome-skills/pull/451) by MMEHDI0606; [immutable source snapshot](https://github.com/MMEHDI0606/antigravity-awesome-skills/blob/9c61357e3e6bb167946036f52ac1e28fc82e04d0/skills/ux-persuasion-engineer/SKILL.md). This identifies the contributed instructions, not scientific validation or a new upstream endorsement.
+
 ## CONTEXT GATHERING
 
 Before redesigning a flow, establish:
@@ -31,23 +37,23 @@ Behavior follows motivation, ability, and prompts, but most UX failures happen b
 
 **Step 1 - Define the target behavior**
 Name the one behavior the flow must produce.
-*Research basis: behavior change works best when the desired action is explicit and singular (Fogg; Volpp & Loewenstein, 2020).*
+*Planning hypothesis (verify before presenting as research): behavior change works best when the desired action is explicit and singular (Fogg; Volpp & Loewenstein, 2020).*
 
 **Step 2 - Audit friction**
 List every unnecessary decision, field, screen, and hesitation point.
-*Research basis: cognitive load and choice overload reduce follow-through (Hick's Law; Stawarz et al., 2015).*
+*Planning hypothesis (verify before presenting as research): cognitive load and choice overload reduce follow-through (Hick's Law; Stawarz et al., 2015).*
 
 **Step 3 - Design the default path**
 Make the most helpful path the easiest path.
-*Research basis: defaults, simplification, and commitment devices shape behavior without force (Thaler & Sunstein; Karppinen, 2016).*
+*Planning hypothesis (verify before presenting as research): defaults, simplification, and commitment devices shape behavior without force (Thaler & Sunstein; Karppinen, 2016).*
 
 **Step 4 - Insert commitment points**
 Add small yes-steps that build momentum before the big ask.
-*Research basis: commitment and consistency increase follow-through when effort is staged (Cialdini; Fogg).*
+*Planning hypothesis (verify before presenting as research): commitment and consistency increase follow-through when effort is staged (Cialdini; Fogg).*
 
 **Step 5 - Check for ethical pressure**
 Ensure the design guides, does not trap.
-*Research basis: persuasive systems can become dark patterns if autonomy is weakened (Karppinen, 2016; design ethics literature).*
+*Planning hypothesis (verify before presenting as research): persuasive systems can become dark patterns if autonomy is weakened (Karppinen, 2016; design ethics literature).*
 
 ## DECISION MATRIX
 
@@ -94,7 +100,7 @@ The line between persuasion and manipulation is guiding behavior by making the i
 
 ## SKILL CHAINING
 
-Before invoking this skill, the agent should have completed:
+Optional context from related skills (equivalent supplied research is sufficient; do not create a prerequisite cycle):
 - [ ] `@customer-psychographic-profiler`
 - [ ] `@jobs-to-be-done-analyst`
 - [ ] `@awareness-stage-mapper`
@@ -119,6 +125,8 @@ Before finalizing output, the agent asks:
 
 > Redesign this product flow so layout, sequencing, and cues guide the decision clearly and ethically.
 
+**Illustrative output:** For a checkout review, make total cost and cancellation visible before commitment; compare task completion and errors without preselecting optional paid add-ons.
+
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/variant-analysis/SKILL.md

@@ -5,6 +5,16 @@ risk: offensive
 source: community
 date_added: "2026-09-04"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/resources/codeql/`
+- `<support-root>/resources/semgrep/`
+- `<support-root>/resources/variant-report-template.md`
+
+Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 > **⚠️ AUTHORIZED USE ONLY**
 > This skill is for educational purposes or authorized security assessments only.

package/bundled-skills/vexor-cli/SKILL.md

@@ -5,6 +5,14 @@ risk: critical
 source: community
 date_added: "2026-09-04"
 ---
+## Supporting material availability
+
+This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:
+
+- `<support-root>/references/install-vexor.md`
+
+Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.
+
 
 # Vexor CLI Skill
 

package/bundled-skills/vibe-delegate/SKILL.md

@@ -13,6 +13,10 @@ license_source: https://github.com/amElnagdy/delegate-skills/blob/master/LICENSE
 metadata:
   version: 0.5.0
 ---
+## Bundled upstream support
+
+Supporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.
+
 # Vibe Delegate
 
 ## When to Use
@@ -141,7 +145,7 @@ mandate). See [references/review-and-land.md](references/review-and-land.md).
 
 ## Limitations
 
-- Docs-only import — executable `scripts/relay.mjs` not included; see upstream for full runtime. Requires `vibe` CLI, Node 18+, git.
+- Runtime helper `scripts/relay.mjs` is bundled from the revision recorded in `UPSTREAM-NOTICE.md`. Requires the corresponding installed and authenticated CLI, Node 18+, and git.
 - Relay never commits — it only returns structured result JSON; you review and land the commit.
 
 > Adapted from [amElnagdy/delegate-skills](https://github.com/amElnagdy/delegate-skills) (MIT) — docs-only, runtime not bundled.