opencode-skills-collection 4.0.54 → 4.0.55

package/bundled-skills/secrets-management/SKILL.md

@@ -8,365 +8,40 @@ date_added: "2026-02-27"
 
 # Secrets Management
 
-Secure secrets management practices for CI/CD pipelines using Vault, AWS Secrets Manager, and other tools.
+## When to Use
 
-## Purpose
+Design or repair secret retrieval, CI credentials, workload identity, access policies and rotation for an authorized system.
 
-Implement secure secrets management in CI/CD pipelines without hardcoding sensitive information.
+## Inputs
 
-## Use this skill when
+Identify secret names and owners, consumers, environments, authentication mechanism and the rotation/recovery policy. Inspect configuration without displaying values.
 
-- Store API keys and credentials
-- Manage database passwords
-- Handle TLS certificates
-- Rotate secrets automatically
-- Implement least-privilege access
+## Procedure
 
-## Do not use this skill when
+1. Choose the existing supported backend: Vault, a cloud secret manager or the host's protected secret store. Keep environment boundaries and minimum privileges explicit.
+2. For Vault, read `references/vault-setup.md`. Development mode and root tokens are not production configuration.
+3. For GitHub Actions, read `references/github-secrets.md`. Keep pull-request validation separate from privileged jobs. Supply values to the consuming process, never interpolate them into generated shell source or print them for debugging.
+4. Prefer short-lived workload identity when the backend supports it. Check issuer, audience, workload/environment restrictions and denied access before enabling retrieval.
+5. Rotate through prepare, consumer switch, verification and old-credential revocation. Use the backend's supported rotation protocol; retries must not leave the database and secret store on different credentials.
+6. Inspect logs, error paths, artifacts and crash reports with synthetic secret markers. Record metadata such as operation, principal and outcome rather than values.
 
-- You plan to hardcode secrets in source control
-- You cannot secure access to the secrets backend
-- You only need local development values without sharing
+## Example
 
-## Instructions
+A deployment needs a database credential. The trusted job retrieves it through the configured identity and passes it only to the migration process. Test missing access and an expired identity in staging. Verify no credential appears in output, and that a failed rotation leaves a recoverable working state.
 
-1. Identify secret types, owners, and rotation requirements.
-2. Choose a secrets backend and access model.
-3. Integrate CI/CD or runtime retrieval with least privilege.
-4. Validate rotation and audit logging.
+## Verification
 
-## Safety
+- Authorized retrieval succeeds; a different workload or environment is denied.
+- Missing credentials fail closed without exposing values.
+- Rotation and rollback are exercised with synthetic data.
+- Logs and artifacts contain no secret markers, including on failure.
+- Exposed credentials are revoked or rotated; merely deleting their log entry is insufficient.
 
-- Never commit secrets to source control.
-- Limit access and log secret usage for auditing.
-
-## Secrets Management Tools
-
-### HashiCorp Vault
-- Centralized secrets management
-- Dynamic secrets generation
-- Secret rotation
-- Audit logging
-- Fine-grained access control
-
-### AWS Secrets Manager
-- AWS-native solution
-- Automatic rotation
-- Integration with RDS
-- CloudFormation support
-
-### Azure Key Vault
-- Azure-native solution
-- HSM-backed keys
-- Certificate management
-- RBAC integration
-
-### Google Secret Manager
-- GCP-native solution
-- Versioning
-- IAM integration
-
-## HashiCorp Vault Integration
-
-### Setup Vault
-
-```bash
-# Start Vault dev server
-vault server -dev
-
-# Set environment
-export VAULT_ADDR='http://127.0.0.1:8200'
-export VAULT_TOKEN='root'
-
-# Enable secrets engine
-vault secrets enable -path=secret kv-v2
-
-# Store secret
-vault kv put secret/database/config username=admin password=secret
-```
-
-### GitHub Actions with Vault
-
-```yaml
-name: Deploy with Vault Secrets
-
-on: [push]
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-
-    - name: Import Secrets from Vault
-      uses: hashicorp/vault-action@v2
-      with:
-        url: https://vault.example.com:8200
-        token: ${{ secrets.VAULT_TOKEN }}
-        secrets: |
-          secret/data/database username | DB_USERNAME ;
-          secret/data/database password | DB_PASSWORD ;
-          secret/data/api key | API_KEY
-
-    - name: Use secrets
-      run: |
-        echo "Connecting to database as $DB_USERNAME"
-        # Use $DB_PASSWORD, $API_KEY
-```
-
-### GitLab CI with Vault
-
-```yaml
-deploy:
-  image: vault:latest
-  before_script:
-    - export VAULT_ADDR=https://vault.example.com:8200
-    - export VAULT_TOKEN=$VAULT_TOKEN
-    - apk add curl jq
-  script:
-    - |
-      DB_PASSWORD=$(vault kv get -field=password secret/database/config)
-      API_KEY=$(vault kv get -field=key secret/api/credentials)
-      echo "Deploying with secrets..."
-      # Use $DB_PASSWORD, $API_KEY
-```
-
-**Reference:** See `references/vault-setup.md`
-
-## AWS Secrets Manager
-
-### Store Secret
-
-```bash
-aws secretsmanager create-secret \
-  --name production/database/password \
-  --secret-string "super-secret-password"
-```
-
-### Retrieve in GitHub Actions
-
-```yaml
-- name: Configure AWS credentials
-  uses: aws-actions/configure-aws-credentials@v4
-  with:
-    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
-    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
-    aws-region: us-west-2
-
-- name: Get secret from AWS
-  run: |
-    SECRET=$(aws secretsmanager get-secret-value \
-      --secret-id production/database/password \
-      --query SecretString \
-      --output text)
-    echo "::add-mask::$SECRET"
-    echo "DB_PASSWORD=$SECRET" >> $GITHUB_ENV
-
-- name: Use secret
-  run: |
-    # Use $DB_PASSWORD
-    ./deploy.sh
-```
-
-### Terraform with AWS Secrets Manager
-
-```hcl
-data "aws_secretsmanager_secret_version" "db_password" {
-  secret_id = "production/database/password"
-}
-
-resource "aws_db_instance" "main" {
-  allocated_storage    = 100
-  engine              = "postgres"
-  instance_class      = "db.t3.large"
-  username            = "admin"
-  password            = jsondecode(data.aws_secretsmanager_secret_version.db_password.secret_string)["password"]
-}
-```
-
-## GitHub Secrets
-
-### Organization/Repository Secrets
-
-```yaml
-- name: Use GitHub secret
-  run: |
-    echo "API Key: ${{ secrets.API_KEY }}"
-    echo "Database URL: ${{ secrets.DATABASE_URL }}"
-```
-
-### Environment Secrets
-
-```yaml
-deploy:
-  runs-on: ubuntu-latest
-  environment: production
-  steps:
-  - name: Deploy
-    run: |
-      echo "Deploying with ${{ secrets.PROD_API_KEY }}"
-```
-
-**Reference:** See `references/github-secrets.md`
-
-## GitLab CI/CD Variables
-
-### Project Variables
-
-```yaml
-deploy:
-  script:
-    - echo "Deploying with $API_KEY"
-    - echo "Database: $DATABASE_URL"
-```
-
-### Protected and Masked Variables
-- Protected: Only available in protected branches
-- Masked: Hidden in job logs
-- File type: Stored as file
-
-## Best Practices
-
-1. **Never commit secrets** to Git
-2. **Use different secrets** per environment
-3. **Rotate secrets regularly**
-4. **Implement least-privilege access**
-5. **Enable audit logging**
-6. **Use secret scanning** (GitGuardian, TruffleHog)
-7. **Mask secrets in logs**
-8. **Encrypt secrets at rest**
-9. **Use short-lived tokens** when possible
-10. **Document secret requirements**
-
-## Secret Rotation
-
-### Automated Rotation with AWS
-
-```python
-import boto3
-import json
-
-def lambda_handler(event, context):
-    client = boto3.client('secretsmanager')
-
-    # Get current secret
-    response = client.get_secret_value(SecretId='my-secret')
-    current_secret = json.loads(response['SecretString'])
-
-    # Generate new password
-    new_password = generate_strong_password()
-
-    # Update database password
-    update_database_password(new_password)
-
-    # Update secret
-    client.put_secret_value(
-        SecretId='my-secret',
-        SecretString=json.dumps({
-            'username': current_secret['username'],
-            'password': new_password
-        })
-    )
-
-    return {'statusCode': 200}
-```
-
-### Manual Rotation Process
-
-1. Generate new secret
-2. Update secret in secret store
-3. Update applications to use new secret
-4. Verify functionality
-5. Revoke old secret
-
-## External Secrets Operator
-
-### Kubernetes Integration
-
-```yaml
-apiVersion: external-secrets.io/v1beta1
-kind: SecretStore
-metadata:
-  name: vault-backend
-  namespace: production
-spec:
-  provider:
-    vault:
-      server: "https://vault.example.com:8200"
-      path: "secret"
-      version: "v2"
-      auth:
-        kubernetes:
-          mountPath: "kubernetes"
-          role: "production"
-
----
-apiVersion: external-secrets.io/v1beta1
-kind: ExternalSecret
-metadata:
-  name: database-credentials
-  namespace: production
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    name: vault-backend
-    kind: SecretStore
-  target:
-    name: database-credentials
-    creationPolicy: Owner
-  data:
-  - secretKey: username
-    remoteRef:
-      key: database/config
-      property: username
-  - secretKey: password
-    remoteRef:
-      key: database/config
-      property: password
-```
-
-## Secret Scanning
-
-### Pre-commit Hook
-
-```bash
-#!/bin/bash
-# .git/hooks/pre-commit
-
-# Check for secrets with TruffleHog
-docker run --rm -v "$(pwd):/repo" \
-  trufflesecurity/trufflehog:latest \
-  filesystem --directory=/repo
-
-if [ $? -ne 0 ]; then
-  echo "❌ Secret detected! Commit blocked."
-  exit 1
-fi
-```
-
-### CI/CD Secret Scanning
-
-```yaml
-secret-scan:
-  stage: security
-  image: trufflesecurity/trufflehog:latest
-  script:
-    - trufflehog filesystem .
-  allow_failure: false
-```
-
-## Reference Files
-
-- `references/vault-setup.md` - HashiCorp Vault configuration
-- `references/github-secrets.md` - GitHub Secrets best practices
+## Limitations
 
-## Related Skills
+Masking cannot make logging secrets safe. Secret data can persist in infrastructure state, subprocess environments or backups; review those boundaries explicitly. Do not alter real credentials or deploy secret infrastructure without authorization.
 
-- `github-actions-templates` - For GitHub Actions integration
-- `gitlab-ci-patterns` - For GitLab CI integration
-- `deployment-pipeline-design` - For pipeline architecture
+## Sources
 
-## 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.
-- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+- [GitHub secure workflow guidance](https://docs.github.com/en/actions/reference/security/secure-use)
+- [Vault production hardening](https://developer.hashicorp.com/vault/docs/concepts/production-hardening)

package/bundled-skills/secrets-management/references/github-secrets.md

@@ -0,0 +1,13 @@
+# GitHub secret handling checklist
+
+## Inputs
+
+Identify the trusted job, required secret names, environment, permitted branches and actual consuming process.
+
+## Procedure and verification
+
+Supply secrets through process environment or an approved credential action, not expression interpolation into shell source. Avoid printing, tracing, encoding or uploading secret values. Limit scope and lifetime; isolate untrusted pull-request jobs. Verify missing-secret failure and inspect test logs using synthetic markers. Review access and rotation ownership.
+
+## Limitations
+
+Masking is a fallback, not authorization to log secrets. An environment name does not by itself establish reviewer rules; inspect the configured protection before relying on it.

package/bundled-skills/secrets-management/references/vault-setup.md

@@ -0,0 +1,13 @@
+# Vault access and rotation checklist
+
+## Inputs
+
+Identify the deployment, secrets engine mount/version, workload identity, secret owner and rotation consumer.
+
+## Procedure and verification
+
+Separate disposable development mode from production. For production, verify authenticated TLS, storage, recovery procedures, audit access and least-privilege policies using the installed version's documentation. Prefer workload identity with short-lived credentials. Test allowed and denied paths with synthetic values; rotate in staging, verify consumers switch, then revoke the old credential only after successful validation.
+
+## Limitations
+
+Never use a development root token for deployment or print values to test retrieval. Rotation is a coordinated state transition with rollback, not just overwriting a secret field.

package/bundled-skills/security-and-hardening/SKILL.md

@@ -81,7 +81,7 @@ If you can't name the trust boundaries for a feature, you're not ready to secure
 
 ## OWASP Top 10 Prevention Patterns
 
-These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in `references/security-checklist.md`.
+These are prevention patterns, not a ranking. For a task-focused review checklist, see `references/security-checklist.md`.
 
 ### Injection (SQL, NoSQL, OS Command)
 
@@ -114,7 +114,7 @@ app.use(session({
   cookie: {
     httpOnly: true,     // Not accessible via JavaScript
     secure: true,       // HTTPS only
-    sameSite: 'lax',    // CSRF protection
+    sameSite: 'lax',    // Defense in depth; add CSRF protection for cookie-authenticated writes
     maxAge: 24 * 60 * 60 * 1000,  // 24 hours
   },
 }));
@@ -142,14 +142,17 @@ app.patch('/api/tasks/:id', authenticate, async (req, res) => {
   const task = await taskService.findById(req.params.id);
 
   // Check that the authenticated user owns this resource
-  if (task.ownerId !== req.user.id) {
+  if (!task || task.ownerId !== req.user.id) {
     return res.status(403).json({
       error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }
     });
   }
 
   // Proceed with update
-  const updated = await taskService.update(req.params.id, req.body);
+  const input = UpdateTaskSchema.safeParse(req.body); // Schema allowlists mutable fields only.
+  if (!input.success) return res.status(422).json({ error: 'Invalid input' });
+  // The service must atomically enforce ownerId in its update predicate.
+  const updated = await taskService.updateOwned(req.params.id, req.user.id, input.data);
   return res.json(updated);
 });
 ```
@@ -184,8 +187,7 @@ app.use(cors({
 ```typescript
 // Never return sensitive fields in API responses
 function sanitizeUser(user: UserRecord): PublicUser {
-  const { passwordHash, resetToken, ...publicFields } = user;
-  return publicFields;
+  return { id: user.id, displayName: user.displayName }; // Explicit public-field allowlist.
 }
 
 // Use environment variables for secrets

package/bundled-skills/security-and-hardening/references/security-checklist.md

@@ -0,0 +1,13 @@
+# Application security review checklist
+
+## Inputs
+
+Identify the feature, trust boundaries, stored data, external effects and authorization scope.
+
+## Procedure and verification
+
+Trace inputs to persistence and outputs. Enforce resource ownership independently from login; test another tenant and a denied role. Allowlist writable fields and response fields. Use parameterized queries and contextual output handling. For outbound URLs, consider resolution, redirects and network egress together. Inspect actual logs and errors for secrets. Test rejected requests for absence of side effects and record reproducible findings.
+
+## Limitations
+
+Use staging or local tests within authorization. A checklist does not prove every vulnerability absent. Keep server-side controls, rollback and any untested integration explicit.

package/bundled-skills/seo-content-planner/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Content planning playbook
+
+## Inputs
+
+Product/audience brief, existing pages, target market and supplied or authorized search evidence.
+
+## Procedure
+
+1. Group questions by user intent and identify existing pages that already answer them. Separate observed search evidence from topic hypotheses.
+2. Create an outline with the reader's question, useful answer, required sources and next action. Assign one primary role per page and explicit internal links.
+3. Prioritize by audience relevance, evidence and editorial capacity. Deliver a calendar with owners and dependencies rather than invented traffic estimates.
+
+## Worked example
+
+A small software site needs onboarding articles. Map installation, first task and troubleshooting into distinct pages, reusing existing documentation and flagging missing product evidence.
+
+## 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
+
+Do not invent search volume, rankings or customer research. Word count is an editorial constraint, not a ranking target.

package/bundled-skills/seo-content-writer/SKILL.md

@@ -79,14 +79,14 @@ You are an SEO content writer creating comprehensive, engaging content optimized
 
 **Quality Standards:**
 - Original, valuable content
-- 0.5-1.5% keyword density
+- Natural keyword use without a fixed density target
 - Grade 8-10 reading level
 - Short paragraphs (2-3 sentences)
 - Bullet points for scannability
 - Examples and data support
 
 **E-E-A-T Elements:**
-- First-hand experience mentions
+- First-hand experience only when supplied and verifiable
 - Specific examples and cases
 - Data and statistics citations
 - Expert perspective inclusion

package/bundled-skills/seo-content-writer/resources/implementation-playbook.md

@@ -0,0 +1,23 @@
+# Evidence-grounded content drafting
+
+## Inputs
+
+Approved brief, reader intent, factual sources, product claims and editorial voice.
+
+## Procedure
+
+1. Outline the answer before adding search terms. Keep sourced facts, supplied experience and illustrative examples distinguishable.
+2. Write clear sections that answer the reader's question. Use keywords naturally; do not force density targets or fabricate first-hand experience, quotations or statistics.
+3. Check every factual claim and proposed internal link. Provide title and metadata suggestions, noting unresolved facts and any language requiring specialist review.
+
+## Worked example
+
+Draft a setup guide from verified product documentation. Include steps, expected outcome and troubleshooting; label an untested step instead of claiming it worked.
+
+## 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
+
+A polished draft does not imply ranking gains or publication. Do not manufacture expertise signals or publish without authorization.

package/bundled-skills/shopify-development/scripts/.snyk

@@ -0,0 +1,3 @@
+version: v1.25.1
+language-settings:
+  python: '3.14'

package/bundled-skills/slack-gif-creator/.snyk

@@ -0,0 +1,5 @@
+# Match the supported interpreter used to verify these requirements.
+# Scoped to this manifest; does not change organization-wide settings.
+version: v1.25.1
+language-settings:
+  python: '3.14'

package/bundled-skills/slack-gif-creator/requirements.txt

@@ -1,5 +1,5 @@
-pillow>=12.2.0
+pillow>=12.3.0
 imageio>=2.31.0
 imageio-ffmpeg>=0.4.9
 numpy>=1.24.0
-setuptools>=78.1.1
+setuptools>=83.0.0

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.