opencode-skills-collection 3.1.12 → 3.1.13

package/bundled-skills/weaviate/scripts/weaviate_conn.py

@@ -120,6 +120,16 @@ def get_detected_providers() -> list[str]:
     return sorted(detected_providers)
 
 
+def _detected_provider_summary(detected_providers: list[str] | None) -> str | None:
+    """Return a safe verbose summary without exposing credential env var names."""
+    if not detected_providers:
+        return None
+
+    provider_count = len(detected_providers)
+    label = "provider" if provider_count == 1 else "providers"
+    return f"Detected {provider_count} {label}."
+
+
 @contextmanager
 def get_client(
     url: str | None = None,
@@ -160,9 +170,9 @@ def get_client(
         detected_providers = None
 
     if verbose:
-        detected = sorted(detected_providers) if detected_providers is not None else []
-        if detected:
-            print(f"Detected providers: {', '.join(detected)}", file=sys.stderr)
+        provider_summary = _detected_provider_summary(detected_providers)
+        if provider_summary:
+            print(provider_summary, file=sys.stderr)
         print("Connecting to Weaviate...", file=sys.stderr)
 
     client = weaviate.connect_to_weaviate_cloud(
@@ -214,9 +224,9 @@ def connect_client(
         detected_providers = None
 
     if verbose:
-        detected = sorted(detected_providers) if detected_providers is not None else []
-        if detected:
-            print(f"Detected providers: {', '.join(detected)}", file=sys.stderr)
+        provider_summary = _detected_provider_summary(detected_providers)
+        if provider_summary:
+            print(provider_summary, file=sys.stderr)
         print("Connecting to Weaviate...", file=sys.stderr)
 
     client = weaviate.connect_to_weaviate_cloud(

package/bundled-skills/webdriverio-skill/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: webdriverio-skill
+description: 'Generates WebdriverIO (WDIO) automation tests in JavaScript or TypeScript. Supports local and TestMu AI cloud. Use when user mentions "WebdriverIO", "WDIO", "wdio.conf", "browser.url", "$", "$$". Triggers on: "WebdriverIO", "WDIO", "wdio", "browser.$".'
+risk: unknown
+source: https://github.com/LambdaTest/agent-skills/tree/main/webdriverio-skill
+source_repo: LambdaTest/agent-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/LambdaTest/agent-skills/blob/main/LICENSE
+---
+
+# WebdriverIO Automation Skill
+## When to Use
+
+Use this skill when you need generates WebdriverIO (WDIO) automation tests in JavaScript or TypeScript. Supports local and TestMu AI cloud. Use when user mentions "WebdriverIO", "WDIO", "wdio.conf", "browser.url", "$", "$$". Triggers on: "WebdriverIO", "WDIO", "wdio", "browser.$".
+
+
+## Step 1 — Execution Target
+
+Default local. If mentions "cloud", "TestMu", "LambdaTest" → cloud via WDIO LambdaTest service.
+
+## Step 2 — Framework
+
+| Signal | Runner |
+|--------|--------|
+| Default | Mocha |
+| "Jasmine" | Jasmine |
+| "Cucumber", "BDD" | Cucumber |
+
+## Core Patterns
+
+### Selectors
+
+```javascript
+// ✅ Preferred
+await $('[data-testid="submit"]').click();
+await $('aria/Submit').click();
+await $('button=Submit').click(); // text-based
+
+// Chaining
+await $('form').$('input[name="email"]').setValue('test@test.com');
+
+// Multiple elements
+const items = await $$('.list-item');
+```
+
+### Basic Test (Mocha)
+
+```javascript
+describe('Login', () => {
+    it('should login successfully', async () => {
+        await browser.url('/login');
+        await $('[data-testid="email"]').setValue('user@test.com');
+        await $('[data-testid="password"]').setValue('password123');
+        await $('[data-testid="submit"]').click();
+        await expect(browser).toHaveUrl(expect.stringContaining('/dashboard'));
+    });
+});
+```
+
+### Page Object
+
+```javascript
+class LoginPage {
+    get inputEmail() { return $('[data-testid="email"]'); }
+    get inputPassword() { return $('[data-testid="password"]'); }
+    get btnSubmit() { return $('[data-testid="submit"]'); }
+
+    async login(email, password) {
+        await this.inputEmail.setValue(email);
+        await this.inputPassword.setValue(password);
+        await this.btnSubmit.click();
+    }
+}
+module.exports = new LoginPage();
+```
+
+### TestMu AI Cloud Config
+
+```javascript
+// wdio.conf.js
+exports.config = {
+    user: process.env.LT_USERNAME,
+    key: process.env.LT_ACCESS_KEY,
+    hostname: 'hub.lambdatest.com',
+    port: 80,
+    path: '/wd/hub',
+    services: ['lambdatest'],
+    capabilities: [{
+        browserName: 'Chrome',
+        browserVersion: 'latest',
+        'LT:Options': {
+            platform: 'Windows 11',
+            build: 'WDIO Build',
+            name: 'WDIO Test',
+            video: true,
+            network: true,
+        }
+    }],
+};
+```
+
+### Wait Strategies
+
+```javascript
+// Wait for element
+await $('[data-testid="result"]').waitForDisplayed({ timeout: 10000 });
+
+// Wait for condition
+await browser.waitUntil(
+    async () => (await $('[data-testid="count"]').getText()) === '5',
+    { timeout: 10000, timeoutMsg: 'Count did not reach 5' }
+);
+```
+
+## Quick Reference
+
+| Task | Command |
+|------|---------|
+| Setup | `npm init wdio@latest` |
+| Run all | `npx wdio run wdio.conf.js` |
+| Run specific | `npx wdio run wdio.conf.js --spec ./test/login.js` |
+| Run suite | `npx wdio run wdio.conf.js --suite smoke` |
+| Parallel | Set `maxInstances: 5` in config |
+| Screenshot | `await browser.saveScreenshot('./screenshot.png')` |
+
+## Reference Files
+
+| File | When to Read |
+|------|-------------|
+| `reference/cloud-integration.md` | LambdaTest service, parallel, capabilities |
+| `reference/advanced-patterns.md` | Custom commands, reporters, services |
+
+## Deep Patterns → `reference/playbook.md`
+
+| § | Section | Lines |
+|---|---------|-------|
+| 1 | Production Configuration | Multi-env, multi-browser configs |
+| 2 | Page Object Model | BasePage, LoginPage, DashboardPage |
+| 3 | Custom Commands | Browser + element commands, TypeScript |
+| 4 | Network Mocking | DevTools mock, abort, error simulation |
+| 5 | File Operations | Upload, download, drag & drop |
+| 6 | Multi-Tab, iFrame & Shadow DOM | Window handles, nested shadow |
+| 7 | Visual Regression | Image comparison service |
+| 8 | API Testing | Fetch-based, API+UI combined |
+| 9 | Mobile Testing | Appium service integration |
+| 10 | LambdaTest Integration | Cloud grid config |
+| 11 | CI/CD Integration | GitHub Actions, Docker Compose |
+| 12 | Debugging Quick-Reference | 11 common problems |
+| 13 | Best Practices Checklist | 14 items |
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/wjttc-builder/SKILL.md

@@ -0,0 +1,355 @@
+---
+name: wjttc-builder
+description: PLAN and GENERATE WJTTC (Championship-Grade) test suites for any project. Analyzes the codebase, classifies components across the WJTTC five tiers (Brake · Engine · Aero · Tyre · Pit), writes a tiered test plan, and scaffolds executable test files. This is the BUILDER — it plans and...
+risk: unknown
+source: https://github.com/Wolfe-Jam/faf-skills/tree/main/skills/wjttc-builder
+source_repo: Wolfe-Jam/faf-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/Wolfe-Jam/faf-skills/blob/main/LICENSE
+---
+
+# WJTTC Builder - Championship Test Suite Generator
+
+**Philosophy:** "We break things so others never have to know they were broken."
+
+This skill generates F1-inspired test suites following the WJTTC (Wolfe James Tests The Code) methodology.
+
+## GOALS
+
+| Goal | How |
+|------|-----|
+| **Pre-defined** | Test plan before code → improves code quality |
+| **Inline Testing** | Tests/approves at write time → catches bugs at inception |
+| **Layer 1 → Layer 2** | Industry + Expert = GOLD Code |
+| **AI Optimized** | 100% bi-sync with project.faf |
+| **Best Code Possible** | ✪ Championship standard |
+
+## GOLD Code ✨
+
+**Code earns GOLD status when:**
+
+```
+┌────────────────────────────────────────┐
+│         ✪ GOLD CODE ✨                │
+│  ════════════════════════════════════  │
+│  ✓ Pre-test plan defined               │
+│  ✓ Inline testing at write time        │
+│  ✓ Layer 1: 100% industry coverage     │
+│  ✓ Layer 2: WJTTC expert edge cases    │
+│  ✓ Bi-sync with project.faf            │
+│  ✓ All tests passing                   │
+│  ════════════════════════════════════  │
+│  This code has earned its name.        │
+└────────────────────────────────────────┘
+```
+
+## Position in Development Pipeline
+
+**WJTTC comes AFTER project.faf, BEFORE coding:**
+
+```
+1. project.faf      → Define WHAT we're building (context)
+2. WJTTC-TESTS.md   → Define SUCCESS CRITERIA (tests first)
+3. Code             → Build to pass the tests
+4. Test             → Pass/Fail
+5. Repeat           → Until Championship grade
+```
+
+## Test-Driven Code (TDC)
+
+**The WJTTC Cycle:**
+
+```
+Think → Cross-check → Confirm → Code → Test → [Repeat]
+  │         │           │        │       │
+  │         │           │        │       └── Pass/Fail verdict
+  │         │           │        └── Write implementation
+  │         │           └── Green light to proceed
+  │         └── STOP if missing info - get it first
+  └── Understand what we're building
+```
+
+**Cross-check Gate:** STOP if missing information. Get it before proceeding.
+- Missing requirements? Ask.
+- Unclear acceptance criteria? Clarify.
+- Unknown edge cases? Define them.
+
+**Red → Green → Refactor:**
+1. Write failing test (RED)
+2. Write code to pass (GREEN)
+3. Clean up (REFACTOR)
+
+**Never code without knowing what "done" looks like.**
+
+## Two-Layer Testing Architecture
+
+### Layer 1: Industry Standard (100% Coverage)
+Use the framework's native testing - Jest, pytest, Vitest, etc.
+- Unit tests
+- Integration tests
+- Standard assertions
+- Coverage requirements
+
+**This is the baseline. Non-negotiable.**
+
+### Layer 2: WJTTC Expert (Stress + Edge Cases)
+The championship layer that catches what industry tests miss:
+
+| Category | What We Test |
+|----------|--------------|
+| **Syntax** | Special chars, escapes, quotes, brackets |
+| **Emoji** | 🏎️ in strings, filenames, variables |
+| **Typecases** | camelCase, snake_case, SCREAMING_CASE, mixed |
+| **Variables** | Empty, null, undefined, MAX_INT, negative |
+| **Unicode** | RTL text, combining chars, zero-width |
+| **Injection** | SQL, XSS, command injection attempts |
+| **Boundaries** | 0, 1, -1, MAX, MAX+1, empty array |
+
+**Test Targets:**
+- MCP servers and tools
+- CLI commands and flags
+- API endpoints and payloads
+- Engine internals
+- Infrastructure configs
+
+## We Test the Testing
+
+**Meta-testing checklist:**
+- [ ] Do the tests actually run?
+- [ ] Do they fail when code is broken?
+- [ ] Do they pass when code is correct?
+- [ ] Are edge cases covered?
+- [ ] Can tests be run in isolation?
+- [ ] Do tests clean up after themselves?
+
+## Signal Integrity Audit (The Red-Means-Real Doctrine)
+
+**Before you measure coverage, measure signal trust.**
+
+Red CI is a contract: stop, look, fix. If red means *"shrug, runner had a noisy neighbor, just rerun,"* the signal is dead — and dead signal is worse than no signal at all. A test suite with 100% coverage but flaky reds is **less trustworthy** than one with 80% coverage and zero false alarms, because the team has stopped reading the reds.
+
+**This is the parent doctrine. Every other testing principle serves it.**
+
+### The Audit
+
+For any test suite under review, classify the last 30 days of CI failures into three buckets:
+
+| Bucket | Meaning | Action |
+|--------|---------|--------|
+| **Real bug** | Red corresponded to an actual code defect that was fixed by a code change | ✓ Signal worked |
+| **Flake** | Red was timing/network/concurrency noise; passed on rerun with no code change | ✗ Test design defect |
+| **Infra** | Red was missing secret, runner image change, dep upstream — not the code under test | ✗ Workflow design defect |
+
+### Signal Integrity Score
+
+```
+SI = (Real bugs) / (Real bugs + Flakes + Infra) × 100
+```
+
+| SI % | Verdict | Required Action |
+|------|---------|-----------------|
+| 100% | TROPHY ✪ | Maintain — exemplary signal |
+| 95-99% | Championship | Annotate any flake immediately |
+| 85-94% | Acceptable | Schedule flake-class fix this sprint |
+| 70-84% | Eroding | Stop adding tests; fix flakes first |
+| <70% | DEAD SIGNAL | Block all merges until signal restored |
+
+**The credibility problem precedes the coverage problem.** A suite at 60% coverage with 100% SI is healthier than one at 95% coverage with 70% SI.
+
+### Common Flake Sources to Eliminate on Sight
+
+- **Hard absolute-time perf assertions on shared CI runners** — `expect(time).toBeLessThan(30)`. Move to non-gating workflow with `continue-on-error: true`.
+- **Network-dependent tests in main suite** — mock at the boundary or route to integration tier.
+- **Concurrency tests without explicit ordering** — use deterministic schedulers.
+- **OS scheduler-dependent timing** — replace with statistical (P95 over N) or relative (vs same-run baseline) assertions.
+- **Secret-dependent steps that fail when missing** — grey-skip, don't fail.
+
+### The Inverse Rule
+
+**Green CI that passes when something is broken is equally a contract violation.** If a real bug shipped despite green CI, that's a coverage gap that demands a regression test BEFORE the fix lands. Treat false negatives with the same urgency as false positives.
+
+### When the Conversation Is the Real Gate
+
+Automated CI is supporting infrastructure. **The human + AI conversational audit — noticing patterns, tracing root causes, fixing systems — is the actual quality gate.** Flaky CI wastes the conversation's bandwidth. Signal Integrity exists to keep CI worthy of the conversation it serves.
+
+## When to Use This Skill
+
+- AFTER defining project.faf context
+- BEFORE writing any implementation code
+- When starting a new feature (define tests first)
+- When fixing a bug (write failing test first)
+- Building regression test suites
+
+## Test Tier System — the WJTTC Five
+
+WJTTC has **five** tiers: **Brake · Engine · Aero · Tyre · Pit**. The builder classifies every component into one of them. (`faf wjttc` audits a suite for the same five and flags untiered tests — name your tests with a tier word so the audit can place them.)
+
+### Tier 1: BRAKE (Safety — Critical)
+**When failure = catastrophic consequences**
+
+Identify and test:
+- Security vulnerabilities (auth bypass, injection, XSS)
+- Data loss or corruption risks
+- Payment/financial processing
+- API key/credential exposure
+- Backup/restore functionality
+
+### Tier 2: ENGINE (Core Functionality)
+**When failure = poor experience or incorrect results**
+
+Identify and test:
+- Core API endpoints
+- Data transformations
+- Business logic accuracy
+- Integration points
+- Performance benchmarks
+
+### Tier 3: AERO (Polish)
+**When failure = minor inconvenience**
+
+Identify and test:
+- UI/UX edge cases
+- Error message formatting
+- Optional features
+- Documentation accuracy
+
+### Tier 4: TYRE (Live — the Real Road)
+**Where the rubber meets the road: durability under real conditions over time**
+
+Identify and test:
+- Edge cases and boundary inputs against the real surface (live data shapes, large payloads)
+- Wear and durability — long-running sessions, repeated calls, soak/load behavior
+- Degraded conditions — slow networks, partial data, rate limits, retries
+- Resource leaks (memory, file handles, connections) under sustained use
+
+### Tier 5: PIT (Operational — When Needed)
+**The pit stop: getting it onto the track and keeping it serviceable**
+
+Identify and test:
+- Integration and end-to-end wiring across components
+- Deploy / release checks (build, packaging, smoke tests, migrations)
+- Ops health — startup/shutdown, config loading, secrets present, observability
+- Rollback and recovery paths
+
+## Test Suite Generation Process
+
+### Step 1: Analyze the Project
+
+To understand what to test:
+
+1. Read key files (package.json, main entry points, API routes)
+2. Identify the project type (web app, CLI, API, library)
+3. List all public interfaces (APIs, functions, UI interactions)
+4. Note external dependencies (databases, APIs, services)
+
+### Step 2: Categorize by Tier
+
+For each identified component, assign one of the five tiers:
+
+```
+Tier 1 (Brake): Authentication, data writes, payments, security
+Tier 2 (Engine): Core features, API responses, business logic
+Tier 3 (Aero):  UI polish, optional features, error formatting
+Tier 4 (Tyre):  Edge cases, durability, soak/load, degraded conditions
+Tier 5 (Pit):   Integration, deploy/release checks, ops health, rollback
+```
+
+### Step 3: Generate Test Plan
+
+Create a WJTTC-TEST-SUITE.md file with:
+
+1. **Header** - Project name, version, date, tester
+2. **Test Summary** - Objectives and pass rate targets
+3. **Tier 1 (Brake) Tests** - All critical/safety tests with pass/fail tables
+4. **Tier 2 (Engine) Tests** - Core functionality tests
+5. **Tier 3 (Aero) Tests** - Polish and formatting tests
+6. **Tier 4 (Tyre) Tests** - Edge cases, durability, degraded conditions
+7. **Tier 5 (Pit) Tests** - Integration, deploy/ops, rollback checks
+8. **Performance Targets** - Timing benchmarks
+9. **Execution Log** - Checklist for running tests
+10. **Championship Certification** - Pass rate to tier mapping
+
+### Step 4: Generate Executable Tests (Optional)
+
+If requested, generate test files:
+
+- JavaScript: `tests/*.test.js` (Jest/Vitest)
+- Python: `tests/test_*.py` (pytest)
+- Bash: `tests/test_*.sh` (shell scripts)
+
+## Output Format
+
+### Test Suite Location
+```
+project/
+└── tests/
+    ├── WJTTC-TEST-SUITE.md     # Test plan document
+    ├── test_tier1_brake.js     # Executable tests (optional)
+    ├── test_tier2_engine.js
+    ├── test_tier3_aero.js
+    ├── test_tier4_tyre.js
+    └── test_tier5_pit.js
+```
+
+### Championship Scoring
+
+Pass rate maps to the canonical FAF tier system (the same tiers FAF uses everywhere):
+
+| Score | Tier | Symbol | Status |
+|-------|------|--------|--------|
+| 100% | Trophy | ✪ | Perfect — Gold Code |
+| 99% | Gold | ★ | Exceptional |
+| 95% | Silver | ◆ | Top tier |
+| 85% | Bronze | ◇ | Production ready |
+| 70% | Green | ● | Solid foundation |
+| 55% | Yellow | ● | Needs improvement |
+| 1% | Red | ○ | Major work needed |
+| 0% | White | ♡ | Empty |
+
+## Quick Generation Command
+
+To generate a test suite for the current project:
+
+1. Analyze the codebase structure
+2. Identify all testable components
+3. Assign tiers to each component
+4. Generate WJTTC-TEST-SUITE.md
+5. Optionally generate executable test files
+
+## Example Test Table Format
+
+```markdown
+### T1.1 - [Test Name]
+**Status:** ⏳ PENDING
+**Priority:** CRITICAL
+
+| Test | Expected | Actual | Status |
+|------|----------|--------|--------|
+| [Scenario 1] | [Expected result] | | |
+| [Scenario 2] | [Expected result] | | |
+
+**Test Command:**
+\`\`\`bash
+[How to run this test]
+\`\`\`
+```
+
+## Integration — where the builder hands off
+
+This skill is the **builder**: it plans and generates. It does **not** run the suite.
+
+- **Execute + report** → use the `wjttc-tester` skill (it runs tests, finds bugs, writes WJTTC reports).
+- **Audit tier balance** → `faf wjttc` classifies an existing suite across the five tiers and flags untiered tests (`--strict` exits non-zero on any untiered; `--json` for CI). Name your generated tests with a tier word (brake/engine/aero/tyre/pit) so the audit can place them.
+- **Wire CI receipts** → `faf taf setup` installs the TAF receipt printer so each run leaves a verifiable record.
+
+---
+
+*Championship Testing Standards 🏎️*
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.