opencode-skills-collection 3.1.12 → 3.1.14

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

@@ -0,0 +1,258 @@
+---
+name: selenium-skill
+description: Generates production-grade Selenium WebDriver automation scripts and tests in Java, Python, JavaScript, C#, Ruby, or PHP. Supports local execution and TestMu AI cloud with 3000+ browser/OS combinations. Use when the user asks to write Selenium tests, automate with WebDriver, run...
+risk: unknown
+source: https://github.com/LambdaTest/agent-skills/tree/main/selenium-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
+---
+
+# Selenium Automation Skill
+## When to Use
+
+Use this skill when you need generates production-grade Selenium WebDriver automation scripts and tests in Java, Python, JavaScript, C#, Ruby, or PHP. Supports local execution and TestMu AI cloud with 3000+ browser/OS combinations. Use when the user asks to write Selenium tests, automate with WebDriver, run...
+
+
+You are a senior QA automation architect. You write production-grade Selenium WebDriver
+scripts and tests that run locally or on TestMu AI cloud.
+
+## Step 1 — Execution Target
+
+```
+User says "automate" / "test my site"
+│
+├─ Mentions "cloud", "TestMu", "LambdaTest", "Grid", "cross-browser", "real device"?
+│  └─ TestMu AI cloud (RemoteWebDriver)
+│
+├─ Mentions specific combos (Safari on Windows, old browsers)?
+│  └─ Suggest TestMu AI cloud
+│
+├─ Mentions "locally", "my machine", "ChromeDriver"?
+│  └─ Local execution
+│
+└─ Ambiguous? → Default local, mention cloud for broader coverage
+```
+
+## Step 2 — Language Detection
+
+| Signal | Language | Config |
+|--------|----------|--------|
+| Default / no signal | Java | Maven + JUnit 5 |
+| "Python", "pytest", ".py" | Python | pip + pytest |
+| "JavaScript", "Node", ".js" | JavaScript | npm + Mocha/Jest |
+| "C#", ".NET", "NUnit" | C# | NuGet + NUnit |
+| "Ruby", ".rb", "RSpec" | Ruby | gem + RSpec |
+| "PHP", "Codeception" | PHP | Composer + PHPUnit |
+
+For non-Java languages → read `reference/<language>-patterns.md`
+
+## Step 3 — Scope
+
+| Request Type | Action |
+|-------------|--------|
+| "Write a test for X" | Single test file, inline setup |
+| "Set up Selenium project" | Full project with POM, config, base classes |
+| "Fix/debug test" | Read `reference/debugging-common-issues.md` |
+| "Run on cloud" | Read `reference/cloud-integration.md` |
+
+## Core Patterns — Java (Default)
+
+### Locator Priority
+
+```
+1. By.id("element-id")           ← Most stable
+2. By.name("field-name")         ← Form elements
+3. By.cssSelector(".class")      ← Fast, readable
+4. By.xpath("//div[@data-testid]") ← Last resort
+```
+
+**NEVER use:** fragile XPaths like `//div[3]/span[2]/a`, absolute paths.
+
+### Wait Strategy — CRITICAL
+
+```java
+// ✅ ALWAYS use explicit waits
+WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
+WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));
+
+// ❌ NEVER use Thread.sleep() or implicit waits mixed with explicit
+Thread.sleep(3000); // FORBIDDEN
+driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); // Don't mix
+```
+
+### Anti-Patterns
+
+| Bad | Good | Why |
+|-----|------|-----|
+| `Thread.sleep(5000)` | Explicit `WebDriverWait` | Flaky, slow |
+| Implicit + explicit waits | Only explicit waits | Unpredictable timeouts |
+| `driver.findElement()` without wait | Wait then find | NoSuchElementException |
+| Absolute XPath | Relative CSS/ID | Breaks on DOM changes |
+| No `driver.quit()` | Always `quit()` in finally/teardown | Leaks browsers |
+
+### Basic Test Structure
+
+```java
+import org.openqa.selenium.WebDriver;
+import org.openqa.selenium.chrome.ChromeDriver;
+import org.openqa.selenium.By;
+import org.openqa.selenium.support.ui.WebDriverWait;
+import org.openqa.selenium.support.ui.ExpectedConditions;
+import org.junit.jupiter.api.*;
+import java.time.Duration;
+
+public class LoginTest {
+    private WebDriver driver;
+    private WebDriverWait wait;
+
+    @BeforeEach
+    void setUp() {
+        driver = new ChromeDriver();
+        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
+        driver.manage().window().maximize();
+    }
+
+    @Test
+    void testLogin() {
+        driver.get("https://example.com/login");
+        wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("username")))
+            .sendKeys("user@test.com");
+        driver.findElement(By.id("password")).sendKeys("password123");
+        driver.findElement(By.cssSelector("button[type='submit']")).click();
+        wait.until(ExpectedConditions.urlContains("/dashboard"));
+        Assertions.assertTrue(driver.getTitle().contains("Dashboard"));
+    }
+
+    @AfterEach
+    void tearDown() {
+        if (driver != null) driver.quit();
+    }
+}
+```
+
+### Page Object Model — Quick Example
+
+```java
+// pages/LoginPage.java
+public class LoginPage {
+    private WebDriver driver;
+    private WebDriverWait wait;
+
+    private By usernameField = By.id("username");
+    private By passwordField = By.id("password");
+    private By submitButton  = By.cssSelector("button[type='submit']");
+
+    public LoginPage(WebDriver driver) {
+        this.driver = driver;
+        this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
+    }
+
+    public void login(String username, String password) {
+        wait.until(ExpectedConditions.visibilityOfElementLocated(usernameField))
+            .sendKeys(username);
+        driver.findElement(passwordField).sendKeys(password);
+        driver.findElement(submitButton).click();
+    }
+}
+```
+
+### TestMu AI Cloud — Quick Setup
+
+```java
+import org.openqa.selenium.remote.RemoteWebDriver;
+import org.openqa.selenium.remote.DesiredCapabilities;
+import java.net.URL;
+import java.util.HashMap;
+
+String username = System.getenv("LT_USERNAME");
+String accessKey = System.getenv("LT_ACCESS_KEY");
+String hub = "https://" + username + ":" + accessKey + "@hub.lambdatest.com/wd/hub";
+
+DesiredCapabilities caps = new DesiredCapabilities();
+caps.setCapability("browserName", "Chrome");
+caps.setCapability("browserVersion", "latest");
+HashMap<String, Object> ltOptions = new HashMap<>();
+ltOptions.put("platform", "Windows 11");
+ltOptions.put("build", "Selenium Build");
+ltOptions.put("name", "My Test");
+ltOptions.put("video", true);
+ltOptions.put("network", true);
+caps.setCapability("LT:Options", ltOptions);
+
+WebDriver driver = new RemoteWebDriver(new URL(hub), caps);
+```
+
+### Test Status Reporting
+
+```java
+// After test — report to TestMu AI dashboard
+((JavascriptExecutor) driver).executeScript(
+    "lambda-status=" + (testPassed ? "passed" : "failed")
+);
+```
+
+## Validation Workflow
+
+1. **Locators**: No absolute XPath, prefer ID/CSS
+2. **Waits**: Only explicit WebDriverWait, zero Thread.sleep()
+3. **Cleanup**: driver.quit() in @AfterEach/teardown
+4. **Cloud**: LT_USERNAME + LT_ACCESS_KEY from env vars
+5. **POM**: Locators in page class, assertions in test class
+
+## Quick Reference
+
+| Task | Command/Code |
+|------|-------------|
+| Run with Maven | `mvn test` |
+| Run single test | `mvn test -Dtest=LoginTest` |
+| Run with Gradle | `./gradlew test` |
+| Parallel (TestNG) | `<suite parallel="tests" thread-count="5">` |
+| Screenshots | `((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE)` |
+| Actions API | `new Actions(driver).moveToElement(el).click().perform()` |
+| Select dropdown | `new Select(driver.findElement(By.id("dropdown"))).selectByValue("1")` |
+| Handle alert | `driver.switchTo().alert().accept()` |
+| Switch iframe | `driver.switchTo().frame("frameName")` |
+| New tab/window | `driver.switchTo().newWindow(WindowType.TAB)` |
+
+## Reference Files
+
+| File | When to Read |
+|------|-------------|
+| `reference/cloud-integration.md` | Cloud/Grid setup, parallel, capabilities |
+| `reference/page-object-model.md` | Full POM with base classes, factories |
+| `reference/python-patterns.md` | Python + pytest-selenium |
+| `reference/javascript-patterns.md` | Node.js + Mocha/Jest |
+| `reference/csharp-patterns.md` | C# + NUnit/xUnit |
+| `reference/ruby-patterns.md` | Ruby + RSpec/Capybara |
+| `reference/php-patterns.md` | PHP + Composer + PHPUnit |
+| `reference/debugging-common-issues.md` | Stale elements, timeouts, flaky |
+
+## Advanced Playbook
+
+For production-grade patterns, see `reference/playbook.md`:
+
+| Section | What's Inside |
+|---------|--------------|
+| §1 DriverFactory | Thread-safe, multi-browser, local + remote, headless CI |
+| §2 Config Management | Properties files, env overrides, multi-env support |
+| §3 Production BasePage | 20+ helper methods, Shadow DOM, iframe, alerts, Angular/jQuery waits |
+| §4 Page Object Example | Full LoginPage extending BasePage with fluent API |
+| §5 Smart Waits | FluentWait, retry on stale, stable list wait, custom conditions |
+| §6 Data-Driven | CSV, MethodSource, Excel DataProvider (Apache POI) |
+| §7 Screenshots | JUnit 5 Extension + TestNG Listener with Allure attachment |
+| §8 Allure Reporting | Epic/Feature/Story annotations, step-based reporting |
+| §9 CI/CD | GitHub Actions matrix + GitLab CI with Selenium service |
+| §10 Parallel | TestNG XML + JUnit 5 parallel properties |
+| §11 Advanced Interactions | File download, multi-window, network logs |
+| §12 Retry Mechanism | TestNG IRetryAnalyzer for flaky test handling |
+| §13 Debugging Table | 11 common exceptions with cause + fix |
+| §14 Best Practices | 17-item production checklist |
+
+## 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/shipping-and-launch/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: shipping-and-launch
+description: Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
+risk: unknown
+source: https://github.com/addyosmani/agent-skills/tree/main/skills/shipping-and-launch
+source_repo: addyosmani/agent-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/addyosmani/agent-skills/blob/main/LICENSE
+---
+
+# Shipping and Launch
+
+## Overview
+
+Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.
+
+## When to Use
+
+- Deploying a feature to production for the first time
+- Releasing a significant change to users
+- Migrating data or infrastructure
+- Opening a beta or early access program
+- Any deployment that carries risk (all of them)
+
+## The Pre-Launch Checklist
+
+### Code Quality
+
+- [ ] All tests pass (unit, integration, e2e)
+- [ ] Build succeeds with no warnings
+- [ ] Lint and type checking pass
+- [ ] Code reviewed and approved
+- [ ] No TODO comments that should be resolved before launch
+- [ ] No `console.log` debugging statements in production code
+- [ ] Error handling covers expected failure modes
+
+### Security
+
+- [ ] No secrets in code or version control
+- [ ] `npm audit` shows no critical or high vulnerabilities
+- [ ] Input validation on all user-facing endpoints
+- [ ] Authentication and authorization checks in place
+- [ ] Security headers configured (CSP, HSTS, etc.)
+- [ ] Rate limiting on authentication endpoints
+- [ ] CORS configured to specific origins (not wildcard)
+
+### Performance
+
+- [ ] Core Web Vitals within "Good" thresholds
+- [ ] No N+1 queries in critical paths
+- [ ] Images optimized (compression, responsive sizes, lazy loading)
+- [ ] Bundle size within budget
+- [ ] Database queries have appropriate indexes
+- [ ] Caching configured for static assets and repeated queries
+
+### Accessibility
+
+- [ ] Keyboard navigation works for all interactive elements
+- [ ] Screen reader can convey page content and structure
+- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)
+- [ ] Focus management correct for modals and dynamic content
+- [ ] Error messages are descriptive and associated with form fields
+- [ ] No accessibility warnings in axe-core or Lighthouse
+
+### Infrastructure
+
+- [ ] Environment variables set in production
+- [ ] Database migrations applied (or ready to apply)
+- [ ] DNS and SSL configured
+- [ ] CDN configured for static assets
+- [ ] Logging and error reporting configured
+- [ ] Health check endpoint exists and responds
+
+### Documentation
+
+- [ ] README updated with any new setup requirements
+- [ ] API documentation current
+- [ ] ADRs written for any architectural decisions
+- [ ] Changelog updated
+- [ ] User-facing documentation updated (if applicable)
+
+## Feature Flag Strategy
+
+Ship behind feature flags to decouple deployment from release:
+
+```typescript
+// Feature flag check
+const flags = await getFeatureFlags(userId);
+
+if (flags.taskSharing) {
+  // New feature: task sharing
+  return <TaskSharingPanel task={task} />;
+}
+
+// Default: existing behavior
+return null;
+```
+
+**Feature flag lifecycle:**
+
+```
+1. DEPLOY with flag OFF     → Code is in production but inactive
+2. ENABLE for team/beta     → Internal testing in production environment
+3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
+4. MONITOR at each stage    → Watch error rates, performance, user feedback
+5. CLEAN UP                 → Remove flag and dead code path after full rollout
+```
+
+**Rules:**
+- Every feature flag has an owner and an expiration date
+- Clean up flags within 2 weeks of full rollout
+- Don't nest feature flags (creates exponential combinations)
+- Test both flag states (on and off) in CI
+
+## Staged Rollout
+
+### The Rollout Sequence
+
+```
+1. DEPLOY to staging
+   └── Full test suite in staging environment
+   └── Manual smoke test of critical flows
+
+2. DEPLOY to production (feature flag OFF)
+   └── Verify deployment succeeded (health check)
+   └── Check error monitoring (no new errors)
+
+3. ENABLE for team (flag ON for internal users)
+   └── Team uses the feature in production
+   └── 24-hour monitoring window
+
+4. CANARY rollout (flag ON for 5% of users)
+   └── Monitor error rates, latency, user behavior
+   └── Compare metrics: canary vs. baseline
+   └── 24-48 hour monitoring window
+   └── Advance only if all thresholds pass (see table below)
+
+5. GRADUAL increase (25% -> 50% -> 100%)
+   └── Same monitoring at each step
+   └── Ability to roll back to previous percentage at any point
+
+6. FULL rollout (flag ON for all users)
+   └── Monitor for 1 week
+   └── Clean up feature flag
+```
+
+### Rollout Decision Thresholds
+
+Use these thresholds to decide whether to advance, hold, or roll back at each stage:
+
+| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |
+|--------|-----------------|-------------------------------|-----------------|
+| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |
+| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |
+| Client JS errors | No new error types | New errors at <0.1% of sessions | New errors at >0.1% of sessions |
+| Business metrics | Neutral or positive | Decline <5% (may be noise) | Decline >5% |
+
+### When to Roll Back
+
+Roll back immediately if:
+- Error rate increases by more than 2x baseline
+- P95 latency increases by more than 50%
+- User-reported issues spike
+- Data integrity issues detected
+- Security vulnerability discovered
+
+## Monitoring and Observability
+
+### What to Monitor
+
+```
+Application metrics:
+├── Error rate (total and by endpoint)
+├── Response time (p50, p95, p99)
+├── Request volume
+├── Active users
+└── Key business metrics (conversion, engagement)
+
+Infrastructure metrics:
+├── CPU and memory utilization
+├── Database connection pool usage
+├── Disk space
+├── Network latency
+└── Queue depth (if applicable)
+
+Client metrics:
+├── Core Web Vitals (LCP, INP, CLS)
+├── JavaScript errors
+├── API error rates from client perspective
+└── Page load time
+```
+
+### Error Reporting
+
+```typescript
+// Set up error boundary with reporting
+class ErrorBoundary extends React.Component {
+  componentDidCatch(error: Error, info: React.ErrorInfo) {
+    // Report to error tracking service
+    reportError(error, {
+      componentStack: info.componentStack,
+      userId: getCurrentUser()?.id,
+      page: window.location.pathname,
+    });
+  }
+
+  render() {
+    if (this.state.hasError) {
+      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
+    }
+    return this.props.children;
+  }
+}
+
+// Server-side error reporting
+app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
+  reportError(err, {
+    method: req.method,
+    url: req.url,
+    userId: req.user?.id,
+  });
+
+  // Don't expose internals to users
+  res.status(500).json({
+    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
+  });
+});
+```
+
+### Post-Launch Verification
+
+In the first hour after launch:
+
+```
+1. Check health endpoint returns 200
+2. Check error monitoring dashboard (no new error types)
+3. Check latency dashboard (no regression)
+4. Test the critical user flow manually
+5. Verify logs are flowing and readable
+6. Confirm rollback mechanism works (dry run if possible)
+```
+
+## Rollback Strategy
+
+Every deployment needs a rollback plan before it happens:
+
+```markdown
+## Rollback Plan for [Feature/Release]
+
+### Trigger Conditions
+- Error rate > 2x baseline
+- P95 latency > [X]ms
+- User reports of [specific issue]
+
+### Rollback Steps
+1. Disable feature flag (if applicable)
+   OR
+1. Deploy previous version: `git revert <commit> && git push`
+2. Verify rollback: health check, error monitoring
+3. Communicate: notify team of rollback
+
+### Database Considerations
+- Migration [X] has a rollback: `npx prisma migrate rollback`
+- Data inserted by new feature: [preserved / cleaned up]
+
+### Time to Rollback
+- Feature flag: < 1 minute
+- Redeploy previous version: < 5 minutes
+- Database rollback: < 15 minutes
+```
+## See Also
+
+- For the project-wide Definition of Done that every change must clear before this checklist, see `references/definition-of-done.md`
+- For security pre-launch checks, see `references/security-checklist.md`
+- For performance pre-launch checklist, see `references/performance-checklist.md`
+- For accessibility verification before launch, see `references/accessibility-checklist.md`
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It works in staging, it'll work in production" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |
+| "We don't need feature flags for this" | Every feature benefits from a kill switch. Even "simple" changes can break things. |
+| "Monitoring is overhead" | Not having monitoring means you discover problems from user complaints instead of dashboards. |
+| "We'll add monitoring later" | Add it before launch. You can't debug what you can't see. |
+| "Rolling back is admitting failure" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |
+
+## Red Flags
+
+- Deploying without a rollback plan
+- No monitoring or error reporting in production
+- Big-bang releases (everything at once, no staging)
+- Feature flags with no expiration or owner
+- No one monitoring the deploy for the first hour
+- Production environment configuration done by memory, not code
+- "It's Friday afternoon, let's ship it"
+
+## Verification
+
+Before deploying:
+
+- [ ] Pre-launch checklist completed (all sections green)
+- [ ] Feature flag configured (if applicable)
+- [ ] Rollback plan documented
+- [ ] Monitoring dashboards set up
+- [ ] Team notified of deployment
+
+After deploying:
+
+- [ ] Health check returns 200
+- [ ] Error rate is normal
+- [ ] Latency is normal
+- [ ] Critical user flow works
+- [ ] Logs are flowing
+- [ ] Rollback tested or verified ready
+
+## 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.