opencode-skills-collection 4.0.61 → 4.0.63

package/README.md

@@ -9,6 +9,7 @@
 
 [![npm version](https://img.shields.io/npm/v/opencode-skills-collection?style=for-the-badge&color=cb3837&label=npm)](https://www.npmjs.com/package/opencode-skills-collection)
 [![npm downloads](https://img.shields.io/npm/dm/opencode-skills-collection?style=for-the-badge&color=orange)](https://www.npmjs.com/package/opencode-skills-collection)
+[![HOL Guard](https://img.shields.io/endpoint?url=https%3A%2F%2Fhol.org%2Fapi%2Fregistry%2Fbadges%2Fplugin%3Fslug%3Dfrancostino%252Fopencode-skills-collection%26metric%3Dtrust&style=for-the-badge)](https://hol.org/go/guard/rawsar?dest=%2Fguard%2Fbilling%3Fpromo%3DGUARD20-RAWSAR%23upgrade&link_id=02c248f9-50d5-4c60-abf0-ca80d2604a6b&utm_source=insights_share&utm_medium=affiliate_cta&utm_campaign=share20)
 [![license](https://img.shields.io/github/license/FrancoStino/opencode-skills-collection?style=for-the-badge&color=blue)](./LICENSE)
 [![zread](https://img.shields.io/badge/Documentation-_.svg?style=for-the-badge&color=00b0aa&labelColor=000000&logo=data%3Aimage%2Fsvg%2Bxml%3Bbase64%2CPHN2ZyB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPHBhdGggZD0iTTQuOTYxNTYgMS42MDAxSDIuMjQxNTZDMS44ODgxIDEuNjAwMSAxLjYwMTU2IDEuODg2NjQgMS42MDE1NiAyLjI0MDFWNC45NjAxQzEuNjAxNTYgNS4zMTM1NiAxLjg4ODEgNS42MDAxIDIuMjQxNTYgNS42MDAxSDQuOTYxNTZDNS4zMTUwMiA1LjYwMDEgNS42MDE1NiA1LjMxMzU2IDUuNjAxNTYgNC45NjAxVjIuMjQwMUM1LjYwMTU2IDEuODg2NjQgNS4zMTUwMiAxLjYwMDEgNC45NjE1NiAxLjYwMDFaIiBmaWxsPSIjZmZmIi8%2BCjxwYXRoIGQ9Ik00Ljk2MTU2IDEwLjM5OTlIMi4yNDE1NkMxLjg4ODEgMTAuMzk5OSAxLjYwMTU2IDEwLjY4NjQgMS42MDE1NiAxMS4wMzk5VjEzLjc1OTlDMS42MDE1NiAxNC4xMTM0IDEuODg4MSAxNC4zOTk5IDIuMjQxNTYgMTQuMzk5OUg0Ljk2MTU2QzUuMzE1MDIgMTQuMzk5OSA1LjYwMTU2IDE0LjExMzQgNS42MDE1NiAxMy43NTk5VjExLjAzOTlDNS42MDE1NiAxMC42ODY0IDUuMzE1MDIgMTAuMzk5OSA0Ljk2MTU2IDEwLjM5OTlaIiBmaWxsPSIjZmZmIi8%2BCjxwYXRoIGQ9Ik0xMy43NTg0IDEuNjAwMUgxMS4wMzg0QzEwLjY4NSAxLjYwMDEgMTAuMzk4NCAxLjg4NjY0IDEwLjM5ODQgMi4yNDAxVjQuOTYwMUMxMC4zOTg0IDUuMzEzNTYgMTAuNjg1IDUuNjAwMSAxMS4wMzg0IDUuNjAwMUgxMy43NTg0QzE0LjExMTkgNS42MDAxIDE0LjM5ODQgNS4zMTM1NiAxNC4zOTg0IDQuOTYwMVYyLjI0MDFDMTQuMzk4NCAxLjg4NjY0IDE0LjExMTkgMS42MDAxIDEzLjc1ODQgMS42MDAxWiIgZmlsbD0iI2ZmZiIvPgo8cGF0aCBkPSJNNCAxMkwxMiA0TDQgMTJaIiBmaWxsPSIjZmZmIi8%2BCjxwYXRoIGQ9Ik00IDEyTDEyIDQiIHN0cm9rZT0iI2ZmZiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIvPgo8L3N2Zz4K&logoColor=ffffff)](https://zread.ai/FrancoStino/opencode-skills-collection)
 </div>
@@ -20,6 +21,11 @@
 
 ---
 
+## Sponsor
+[![Sponsored by GitAds](https://gitads.dev/v1/ad-serve?source=francostino/opencode-skills-collection@github)](https://gitads.dev/v1/ad-track?source=francostino/opencode-skills-collection@github)
+
+---
+
 ## Overview
 
 **OpenCode Skills Collection** ships a pre-bundled snapshot of 1595+ universal skills for the OpenCode.
@@ -255,9 +261,6 @@ To use the latest beta version, update your `~/.config/opencode/opencode.json`:
 
 [MIT ©](./LICENSE)
 
-## GitAds Sponsored
-[![Sponsored by GitAds](https://gitads.dev/v1/ad-serve?source=francostino/opencode-skills-collection@github)](https://gitads.dev/v1/ad-track?source=francostino/opencode-skills-collection@github)
-
 ## Star History
 
 <a href="https://www.star-history.com/?repos=FrancoStino%2Fopencode-skills-collection&type=date&legend=top-left">

package/bundled-skills/.antigravity-install-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-09-13T01:46:17.010Z",
+  "updatedAt": "2026-09-15T02:11:34.766Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -954,6 +954,7 @@
     "gitlab-automation",
     "gitlab-ci-patterns",
     "gitops-workflow",
+    "glasser",
     "global-chat-agent-discovery",
     "gmail-automation",
     "go-concurrency-patterns",
@@ -1239,6 +1240,7 @@
     "marketing-ideas",
     "marketing-plan",
     "marketing-psychology",
+    "marketplace-rbac-audit",
     "markstream-angular",
     "markstream-custom-components",
     "markstream-install",
@@ -1517,6 +1519,7 @@
     "product-marketing-context",
     "production-audit",
     "production-code-audit",
+    "production-runtime-certification",
     "production-scheduling",
     "professional-proofreader",
     "programmatic-seo",

package/bundled-skills/glasser/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: glasser
+description: "Search, inspect, and run third-party data APIs through one CLI when the environment has no suitable integration."
+category: data
+risk: critical
+source: self
+source_type: self
+date_added: "2026-09-12"
+author: adriansurething
+tags: [api, data, search, enrichment, marketing, research, cli]
+tools: [claude, cursor, codex, gemini]
+---
+
+# Glasser
+
+## Overview
+
+Glasser is a commercial API broker that exposes third-party data providers
+through one CLI and one account. Use it to fill a data gap after checking the
+environment's free tools and the user's existing integrations. Provider output
+keeps its native structure, so inspect the selected endpoint before every run.
+
+This skill was contributed by a member of the Glasser team.
+
+## When to Use This Skill
+
+- Use when a task needs current web, news, search, social, business, people,
+  places, shopping, image, video, or enrichment data that available tools
+  cannot supply.
+- Use when the user wants pay-per-call access without creating a separate
+  account with the underlying provider.
+- Use for marketing and research workflows that need structured evidence from
+  a named data provider.
+- Prefer the user's explicit provider choice, existing API keys, installed
+  integrations, and free tools before Glasser.
+
+## How It Works
+
+### Step 1: Check Availability and Authentication
+
+Use the CLI only if it is already installed or the user has approved its
+installation under the host environment's software-installation policy.
+Installation instructions are maintained at
+<https://glasser.ai/SKILL.md>. Do not download or install executable code
+without the review and approval required by the current environment.
+
+Check the CLI and account:
+
+```bash
+glasser --version
+glasser balance
+```
+
+If authentication is missing in an interactive session, run `glasser login`.
+It opens a browser-based device flow. Relay the URL and code printed by the CLI
+and wait for the command to finish. Never ask the user to paste a Key into chat.
+
+For unattended environments, the user can configure `GLASSER_API_KEY` through
+the environment's secret manager. Never write it to a project file or include
+it in a command argument.
+
+### Step 2: Discover Candidate Endpoints
+
+Search by capability instead of guessing a provider or endpoint:
+
+```bash
+glasser search -q "Google search results"
+glasser search -q "company enrichment"
+glasser search -q "Reddit posts and comments"
+```
+
+Compare the provider, endpoint, and listed price. Search results are ranked by
+relevance; rank is not a quality or price recommendation.
+
+### Step 3: Inspect the Contract
+
+Inspect the exact endpoint before constructing input:
+
+```bash
+glasser inspect -p serper -e /search
+```
+
+Record:
+
+- the current price and all charge clauses;
+- required and optional input fields;
+- fields that control result volume;
+- run mode and timeout;
+- the provider that will receive the request.
+
+Schemas, prices, and charge clauses can change. The live `inspect` result is
+the contract for the next run.
+
+### Step 4: Authorize the Paid Scope
+
+Only `run` spends the workspace balance. Before the first paid call, show the
+user the provider, endpoint, per-call price, charge exceptions, input scope,
+and requested result volume. Wait for approval unless the user already gave an
+exact scope or budget that covers the call.
+
+Create the provider-native JSON input in a file after inspection. A file avoids
+shell-quoting errors and keeps the request reviewable. Do not include unrelated
+personal, confidential, or credential data.
+
+### Step 5: Run and Recover Safely
+
+Run the approved request:
+
+```bash
+glasser run -p serper -e /search -f request.json --wait
+```
+
+The CLI prints an Idempotency-Key. If a timeout or transport failure leaves the
+outcome uncertain, repeat the request with that same key:
+
+```bash
+glasser run -p serper -e /search -f request.json --idempotency-key <same-key> --wait
+```
+
+Do not create a new key for an ambiguous retry. It can create and charge a
+second run. For a known run, use `glasser runs get -r <run-id> --wait` instead
+of starting another one.
+
+### Step 6: Report Evidence and Cost
+
+For every run used in the answer, report:
+
+1. the provider and endpoint;
+2. the Glasser run status;
+3. what the provider response says;
+4. the exact `Charge` printed by the CLI;
+5. the private `Run URL` printed by the CLI.
+
+`COMPLETED` means the provider answered. It does not guarantee that the
+provider found a result, so describe both the run status and the payload.
+
+## Examples
+
+### Example 1: Research a Search Results Page
+
+```text
+Find a Google SERP endpoint in Glasser, show me its current price and input
+schema, and ask before running one query for "best email marketing tools".
+```
+
+The agent searches the catalog, inspects the selected endpoint, obtains paid
+scope approval, writes input that matches the live schema, and returns sourced
+results with the charge and Run URL.
+
+### Example 2: Fill a Company-Data Gap
+
+```text
+Our current tools cannot enrich these five companies. Find suitable Glasser
+endpoints, compare their prices and required inputs, and stop before spending.
+```
+
+The agent returns a provider comparison without making a paid run.
+
+## Best Practices
+
+- Start with the smallest result count that can answer the question.
+- Reuse data already retrieved during the current task.
+- Keep exact decimal money values as strings when calculating totals.
+- Save large outputs to a file and read only the fields needed for analysis.
+- Preserve provider attribution when presenting evidence.
+
+## Limitations
+
+- Glasser is a paid service. Endpoint availability, prices, and provider terms
+  can change.
+- Data quality and coverage depend on the selected third-party provider.
+- A Glasser run does not grant permission to collect or use personal data.
+  Apply the user's purpose, applicable law, and provider terms.
+- The private Run URL is available only to members of the Glasser workspace.
+- The skill cannot complete interactive login without the user approving the
+  browser device flow.
+
+## Security & Safety Notes
+
+- Treat every `run` as a state-changing paid operation.
+- Keep Keys in an environment secret store and out of files, logs, prompts,
+  command arguments, commits, and generated reports.
+- Tell the user which provider receives the request before sending sensitive
+  or personal data, and minimize the submitted fields.
+- Do not run speculative calls, retry loops, or unapproved bulk jobs.
+- Stop on insufficient balance, rejected authorization, or a schema mismatch;
+  correct the cause before considering another paid call.
+
+## Common Pitfalls
+
+- **Problem:** Input validation fails.
+  **Solution:** Inspect the endpoint again and rebuild the JSON from the live
+  schema instead of guessing field names.
+- **Problem:** A request timed out after submission.
+  **Solution:** Reuse the printed Idempotency-Key or fetch the known run.
+- **Problem:** A completed run contains no useful result.
+  **Solution:** Report the provider outcome and charge clause; do not label the
+  transport as failed or rerun automatically.
+- **Problem:** The CLI reports an available update.
+  **Solution:** Finish the current task, then follow the official upgrade
+  instructions and refresh the Glasser skill before the next task.
+
+## Related Skills
+
+- `@seo-dataforseo` - Use when DataForSEO is already configured and the task is
+  specifically SEO data.
+- `@apify-market-research` - Use when the user already has an Apify integration
+  for the selected research source.
+- `@parallel-search-mcp` - Use when Parallel is installed and covers the task.

package/bundled-skills/marketplace-rbac-audit/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: marketplace-rbac-audit
+description: "Audit multi-role marketplace authorization across roles, resource ownership, tenant boundaries, and order-state transitions; use when access rules need evidence, not UI assumptions."
+category: security
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-12"
+author: mosinlshaikh
+tags: [marketplace, rbac, authorization, access-control, security]
+tools: [claude, cursor, codex, gemini]
+---
+
+# Marketplace RBAC Audit
+
+## Overview
+
+Audit authorization in marketplaces where customers, vendors, fulfillment staff, couriers, support agents, administrators, and service accounts act on shared orders and resources. Build an explicit policy matrix, trace enforcement from route to data access, and verify both allowed and denied behavior without treating hidden UI controls as security.
+
+This is a read-only review by default. It does not grant permission to scan a live service, create test accounts, alter permissions, or access another person's data.
+
+## When to Use This Skill
+
+- Reviewing authorization in a marketplace, delivery platform, multi-vendor store, or fulfillment system.
+- Adding or changing roles, administrative powers, ownership rules, or order-state transitions.
+- Investigating whether one customer, vendor, courier, hub, or tenant can access another party's resources.
+- Preparing negative authorization tests before release or after an access-control incident.
+
+Do not use this skill for authentication design alone, generic multi-tenant architecture, offensive ID enumeration, or penetration testing outside an explicitly authorized test environment.
+
+## Establish the Authorization Contract
+
+Record the actual actors and resources instead of assuming standard role names.
+
+For each actor, capture:
+
+- identity source and role-assignment authority;
+- tenant, organization, store, hub, region, or assignment scope;
+- resource relationships such as owner, seller, assigned courier, servicing hub, or support case;
+- permitted operations and state transitions;
+- emergency, support, delegated, and service-account access;
+- audit-log and approval requirements for privileged actions.
+
+Separate these policy dimensions:
+
+1. **Role** — what this actor type may generally do.
+2. **Relationship** — which specific object the actor may access.
+3. **Tenant or operational scope** — where the permission applies.
+4. **Resource state** — whether the operation is valid now.
+5. **Field scope** — which attributes may be viewed or changed.
+
+A matching role is not sufficient when ownership, assignment, tenant, state, or field rules fail.
+
+## Build the Policy Matrix
+
+Create one row per meaningful actor-resource-operation combination.
+
+| Field | Required content |
+|---|---|
+| Actor | Role plus relevant tenant/store/hub/assignment |
+| Resource | Order, product, inventory, payout, address, profile, delivery, refund, or admin object |
+| Operation | List, view, create, update, delete, assign, transition, refund, export, or impersonate |
+| Relationship | Owner, seller, assignee, servicing hub, same tenant, or none |
+| Required state | Order/payment/delivery state in which the operation is allowed |
+| Field scope | Allowed and prohibited fields |
+| Expected result | Allow or deny, including disclosure policy such as 403 versus 404 |
+| Enforcement point | Route, policy layer, service, query predicate, database policy, or queue consumer |
+| Evidence | Code reference, test ID, request ID, or audit event |
+
+Mark an undocumented decision as **UNDEFINED**; do not invent a permission merely because current code allows it.
+
+## Audit Workflow
+
+### 1. Inventory Entry Points
+
+Map HTTP routes, GraphQL operations, server actions, background jobs, webhooks, file downloads, exports, administrative tools, and queue consumers that access marketplace resources. Include bulk operations and alternate HTTP methods.
+
+### 2. Trace Identity and Scope
+
+For every entry point, trace how the authenticated principal becomes an authorization context. Confirm that role, tenant, store, hub, assignment, and delegation claims come from a trusted server-side source and are current enough for the operation.
+
+Do not accept actor, tenant, owner, vendor, hub, courier, price, payout, or privilege fields from the request merely because they are present in a signed-in session.
+
+### 3. Trace Object Authorization
+
+Follow the resource identifier from request to data access. Prefer a scoped query or atomic mutation that includes every required predicate:
+
+~~~text
+resource_id
++ tenant/store/hub scope
++ owner/seller/assignee relationship
++ permitted current state
+= authorized object or no match
+~~~
+
+A separate “check then update” sequence may race with reassignment or state changes. Record where a transaction, conditional update, row-level lock, or equivalent consistency control is required.
+
+### 4. Check Field-Level Authorization
+
+Compare request and response schemas by role. Verify that mass assignment, serializer defaults, ORM spreads, exports, and error payloads cannot expose or change protected fields.
+
+Examples of sensitive fields include:
+
+- another customer's address or contact details;
+- vendor settlement and payout configuration;
+- courier identity or precise location outside an active delivery need;
+- internal fraud, moderation, cost, or risk fields;
+- role, tenant, hub, assignment, price, refund, and payment-state attributes.
+
+### 5. Audit State Transitions
+
+Build an allowlist of valid transitions with authorized actors and invariants. For example, “assigned courier may mark picked up” is incomplete unless the order is assigned to that courier, is in the expected prior state, belongs to the same operational scope, and has not been cancelled.
+
+Reject client-selected final states when the server should derive the transition. Verify idempotency and concurrency behavior for assignment, cancellation, refund, fulfillment, and delivery confirmation.
+
+### 6. Verify Indirect Paths
+
+Apply the same policy to:
+
+- nested resources and parent-child ownership;
+- invoice, receipt, label, media, and document downloads;
+- search, autocomplete, counts, and analytics;
+- bulk update, import, and export;
+- webhook and queue-triggered changes;
+- cached responses and pre-signed URLs;
+- support tools, impersonation, and “view as user” modes.
+
+UI visibility is evidence of presentation only. A hidden button, disabled control, or unpublished link does not enforce authorization.
+
+### 7. Design Negative Tests
+
+Use synthetic identities and records in an authorized test environment. For every important allowed case, add the nearest denied cases:
+
+- same role, different owner;
+- same role, different vendor/store/hub/tenant;
+- correct role, wrong assignment;
+- correct relationship, invalid resource state;
+- expired, disabled, removed, or downgraded membership;
+- protected field added to an otherwise valid request;
+- bulk request containing one unauthorized object;
+- stale session after role or assignment revocation;
+- guessed nested-resource or download identifier.
+
+Do not use real customer records as “victim” data. Do not enumerate identifiers or run live probes without explicit target authorization and a bounded test plan.
+
+### 8. Report Evidence and Gaps
+
+Report confirmed behavior separately from code inference. A route with no test is not proven secure; mark it **NOT VERIFIED**. A permission with no owner is **UNDEFINED**.
+
+## Findings Format
+
+~~~text
+MARKETPLACE RBAC AUDIT
+Revision: <immutable source revision>
+Environment: <code review or authorized test target>
+Observed at: <UTC timestamp>
+
+POLICY COVERAGE: <covered rows>/<required rows>
+ALLOWED-PATH TESTS: PASS | FAIL | NOT VERIFIED
+DENIED-PATH TESTS: PASS | FAIL | NOT VERIFIED
+OBJECT OWNERSHIP: PASS | FAIL | NOT VERIFIED
+TENANT/STORE/HUB ISOLATION: PASS | FAIL | NOT VERIFIED
+STATE TRANSITIONS: PASS | FAIL | NOT VERIFIED
+FIELD-LEVEL ACCESS: PASS | FAIL | NOT VERIFIED
+INDIRECT PATHS: PASS | FAIL | NOT VERIFIED
+PRIVILEGED ACTION AUDITABILITY: PASS | FAIL | NOT VERIFIED
+
+OVERALL: PASS | FAIL | INCOMPLETE
+Findings: <IDs with actor, resource, operation, evidence, and impact>
+Undefined policies: <explicit list>
+Untested paths: <explicit list>
+~~~
+
+## Example Policy Rows
+
+| Actor | Resource and operation | Relationship/state | Expected |
+|---|---|---|---|
+| Customer | View order | Own order | Allow |
+| Customer | View order | Another customer's order | Deny |
+| Vendor operator | Update product | Product belongs to vendor; editable state | Allow permitted fields only |
+| Vendor operator | View payout | Different vendor | Deny |
+| Courier | Update delivery status | Assigned delivery; valid next state | Allow one transition |
+| Courier | Read customer location | Unassigned or completed delivery | Deny |
+| Hub operator | Assign courier | Order belongs to serviced hub; assignable state | Allow |
+| Hub operator | Refund payment | No refund permission | Deny |
+| Support agent | View order | Active support purpose | Allow redacted fields and audit access |
+| Administrator | Change user role | Explicit privilege plus required approval | Allow and emit audit event |
+
+## Severity Guidance
+
+- **Critical:** cross-tenant administrative access, payout destination changes, role escalation, mass customer-data access, or unauthorized refunds.
+- **High:** cross-owner order/address access, unauthorized fulfillment transitions, courier location exposure, or vendor isolation failure.
+- **Medium:** excessive fields, missing privileged audit events, stale-role access, or enumeration through counts and metadata.
+- **Low:** policy/documentation gaps with no demonstrated access bypass.
+
+Base severity on demonstrated reach, sensitivity, prerequisites, and business impact. Do not inflate severity from a role name alone.
+
+## Best Practices
+
+- Treat authorization as policy over role, relationship, scope, state, and fields.
+- Default new actor-resource-operation combinations to deny until explicitly defined.
+- Enforce policy server-side at every entry point, close to the data mutation.
+- Prefer reusable policy functions plus negative tests over scattered role-name checks.
+- Make role and assignment revocation effective within a defined, tested interval.
+- Require explicit approval and immutable audit events for high-impact privileged actions.
+- Re-run affected matrix rows after route, schema, role, workflow, or ownership changes.
+
+## Common Pitfalls
+
+- **Problem:** The frontend hides unauthorized actions.
+  **Solution:** Test the backend operation directly with a synthetic unauthorized principal.
+
+- **Problem:** A vendor role can access every vendor's records.
+  **Solution:** Require both the role and the resource's vendor/store relationship in the query.
+
+- **Problem:** A courier can submit any delivery state.
+  **Solution:** Authorize one server-defined transition from the current state for the assigned courier.
+
+- **Problem:** An admin bypass silently applies to support agents.
+  **Solution:** Define separate privileged operations, field scope, approval requirements, and audit events.
+
+- **Problem:** List endpoints are scoped but exports or downloads are not.
+  **Solution:** Reuse the same policy at every direct and indirect resource path.
+
+## Limitations
+
+- A source review cannot prove runtime identity-provider configuration or database policies without corresponding evidence.
+- Negative tests prove only the identities, resources, operations, states, and environments exercised.
+- This skill does not replace threat modeling, authentication review, privacy assessment, or an authorized penetration test.
+- Marketplace policy varies by product and jurisdiction; unresolved business decisions must remain **UNDEFINED**.
+
+## Security & Safety Notes
+
+- Keep the audit read-only unless the user separately authorizes test creation or remediation.
+- Use synthetic identities and records; never test by accessing unrelated real users' data.
+- Redact tokens, session material, personal data, internal identifiers, and sensitive topology from evidence.
+- Stop before live probing, privilege changes, impersonation, bulk exports, or state-changing requests unless the exact action and target are authorized.
+
+## Related Skills
+
+- **@api-security-best-practices** — use for broader API authentication, validation, abuse controls, and secure implementation patterns.
+- **@saas-multi-tenant** — use for designing tenant isolation and PostgreSQL row-level security.
+- **@idor-testing** — use only for explicitly authorized offensive IDOR testing.

package/bundled-skills/production-runtime-certification/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: production-runtime-certification
+description: "Certify a deployed service with fresh evidence across source, CI, migrations, runtime health, readiness, and critical routes; use before declaring a release production-ready."
+category: devops
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-12"
+author: mosinlshaikh
+tags: [production, deployment, verification, reliability, devops]
+tools: [claude, cursor, codex, gemini]
+---
+
+# Production Runtime Certification
+
+## Overview
+
+Produce an evidence-backed release verdict that distinguishes code quality, CI success, deployment success, and live runtime health. The skill prevents a green pipeline or successful deploy event from being treated as proof that a service is usable in its target environment.
+
+## When to Use This Skill
+
+- Before declaring a release, environment, or migration production-ready.
+- After a deployment when CI is green but runtime health is unknown or failing.
+- During release audits that require a concise PASS, FAIL, or BLOCKED decision with reproducible evidence.
+- When handing a deployed service from engineering to operations or a client.
+
+Do not use this skill as a substitute for feature acceptance, security review, load testing, disaster-recovery exercises, or regulatory approval.
+
+## Certification Contract
+
+Agree on these inputs before testing:
+
+- exact source revision, repository, and target environment;
+- deployment identifier and expected artifact or image digest when available;
+- health and readiness endpoints plus expected success semantics;
+- migration mechanism and expected schema version;
+- critical user journeys or routes;
+- authorized, non-destructive probes and credential boundaries.
+
+If the target, authorization, or success criteria are ambiguous, stop and request clarification. Never probe an unrelated environment, expose credentials in output, or modify production data merely to obtain a passing result.
+
+## Evidence Model
+
+Record every gate as one of:
+
+- **PASS** — fresh evidence satisfies the agreed criterion.
+- **FAIL** — fresh evidence disproves the criterion.
+- **BLOCKED** — the gate could not be tested because access, tooling, configuration, or an upstream dependency is unavailable.
+- **NOT APPLICABLE** — the gate is deliberately excluded with a written reason.
+
+`BLOCKED` is not `PASS`. An overall certification can be **GREEN** only when every required gate passes. Any required failure produces **RED**; any required blocked gate with no failure produces **BLOCKED**.
+
+## Workflow
+
+### 1. Pin the Subject
+
+Capture the immutable source revision and intended runtime artifact. Confirm that the deployed artifact maps to that revision. A branch name, local working tree, or “latest deployment” label is not immutable evidence.
+
+### 2. Verify Source and CI
+
+Run the repository's current validation and test commands on the pinned revision. Inspect the required CI jobs for the same revision, including conclusion and timestamp. Do not infer full CI success from one job or from an older run.
+
+### 3. Verify Deployment Identity
+
+Confirm that the target environment reports the expected deployment, revision, or artifact digest. Record the environment and deployment identifiers without copying secrets or sensitive configuration values.
+
+### 4. Verify Database State
+
+Use the application's supported migration status or a read-only schema-version query. Confirm migrations completed on the target database and that the application is not running against an unexpected database or schema.
+
+Do not apply, roll back, repair, or stamp migrations unless the user separately authorizes that mutation and a recovery plan exists.
+
+### 5. Probe Liveness and Readiness
+
+Test liveness and readiness separately when both exist:
+
+- **Liveness** shows that the process can respond.
+- **Readiness** shows that the service can handle intended traffic and required dependencies are available.
+
+Record timestamp, target, status code, bounded response summary, and latency. Redact tokens, cookies, internal hostnames, database addresses, and response fields that contain secrets or personal data.
+
+### 6. Exercise Critical Routes
+
+Run the smallest authorized smoke suite that proves the agreed critical journeys. Prefer synthetic or test records and read-only probes. For authenticated routes, use designated test identities with least privilege and never place credentials in commands, logs, or the report.
+
+### 7. Check Operational Signals
+
+Inspect the bounded deployment window for crash loops, unhandled exceptions, dependency failures, elevated error rates, or resource exhaustion. Absence of log access is `BLOCKED`, not proof of health.
+
+### 8. Issue the Verdict
+
+Publish the evidence matrix, unresolved risks, and exact overall verdict. Keep observations separate from inference. Include enough identifiers and timestamps for another engineer to reproduce the decision without exposing sensitive data.
+
+## Report Template
+
+```text
+PRODUCTION RUNTIME CERTIFICATION
+Environment: <target>
+Source revision: <immutable revision>
+Deployment/artifact: <immutable identifier>
+Observed at: <UTC timestamp>
+
+SOURCE VALIDATION: PASS | FAIL | BLOCKED | NOT APPLICABLE
+CI: PASS | FAIL | BLOCKED | NOT APPLICABLE
+DEPLOYMENT IDENTITY: PASS | FAIL | BLOCKED | NOT APPLICABLE
+DATABASE MIGRATIONS: PASS | FAIL | BLOCKED | NOT APPLICABLE
+LIVENESS: PASS | FAIL | BLOCKED | NOT APPLICABLE
+READINESS: PASS | FAIL | BLOCKED | NOT APPLICABLE
+CRITICAL ROUTES: PASS | FAIL | BLOCKED | NOT APPLICABLE
+OPERATIONAL SIGNALS: PASS | FAIL | BLOCKED | NOT APPLICABLE
+
+OVERALL: GREEN | RED | BLOCKED
+Evidence: <commands/checks, run IDs, timestamps, bounded results>
+Unresolved risks: <none or explicit list>
+```
+
+## Examples
+
+### CI Green, Runtime Unavailable
+
+```text
+SOURCE VALIDATION: PASS — revision 8f31c2a, tests 146/146
+CI: PASS — required run 72814 completed at 2026-09-12T10:06:00Z
+DEPLOYMENT IDENTITY: PASS — artifact maps to revision 8f31c2a
+DATABASE MIGRATIONS: BLOCKED — target database access unavailable
+LIVENESS: FAIL — HTTP 503 at 2026-09-12T10:14:22Z
+READINESS: FAIL — HTTP 503 at 2026-09-12T10:14:24Z
+CRITICAL ROUTES: BLOCKED — smoke checks stopped after readiness failure
+OPERATIONAL SIGNALS: BLOCKED — log access unavailable
+
+OVERALL: RED
+Unresolved risks: runtime cause and database state remain unverified
+```
+
+### Fully Supported Verdict
+
+```text
+SOURCE VALIDATION: PASS
+CI: PASS
+DEPLOYMENT IDENTITY: PASS
+DATABASE MIGRATIONS: PASS
+LIVENESS: PASS
+READINESS: PASS
+CRITICAL ROUTES: PASS
+OPERATIONAL SIGNALS: PASS
+
+OVERALL: GREEN
+Unresolved risks: none within the agreed certification scope
+```
+
+## Best Practices
+
+- Use fresh, timestamped evidence for the exact revision and environment.
+- Prefer immutable run, deployment, and artifact identifiers over screenshots or labels.
+- Set bounded timeouts and request counts for runtime probes.
+- Report partial success precisely; preserve FAIL and BLOCKED gates in summaries.
+- Keep the certification read-only unless a separate change request authorizes remediation.
+- Re-run affected gates after any code, configuration, migration, or infrastructure change.
+
+## Common Pitfalls
+
+- **Problem:** CI is green, so the release is declared healthy.
+  **Solution:** Verify deployment identity, migrations, readiness, routes, and operational signals independently.
+
+- **Problem:** A liveness response is treated as readiness.
+  **Solution:** Test dependency-aware readiness criteria or record readiness as BLOCKED when none exist.
+
+- **Problem:** Smoke tests accidentally create or alter customer data.
+  **Solution:** Use non-destructive probes or designated synthetic records with an explicit cleanup policy.
+
+- **Problem:** Missing access is reported as success because no error was observed.
+  **Solution:** Mark the affected gate BLOCKED and keep the overall verdict BLOCKED unless another required gate fails.
+
+- **Problem:** Credentials or internal configuration are copied into evidence.
+  **Solution:** Record identifiers and bounded outcomes; redact secrets, personal data, and sensitive topology.
+
+## Limitations
+
+- Certification is a point-in-time result for one revision and environment.
+- Passing smoke checks do not establish performance capacity, security, resilience, or business correctness beyond the agreed scope.
+- Provider dashboards and health endpoints can be incomplete; state evidence gaps explicitly.
+- A GREEN verdict expires when the deployed artifact, configuration, schema, dependencies, or target environment changes.
+
+## Security & Safety Notes
+
+- Obtain authorization for the exact target and probes before accessing a live environment.
+- Use least-privilege, designated test identities and read-only checks wherever possible.
+- Never print, store, or transmit secrets, session material, personal data, or full sensitive responses in certification evidence.
+- Stop when a check would require destructive data changes, privilege escalation, or a scope expansion that was not authorized.
+
+## Related Skills
+
+- `@verification-before-completion` — verifies that any completion claim has fresh supporting evidence; use this skill for the production-specific gate model and verdict.
+- `@deployment-procedures` — use for executing a deployment; return here afterward to certify the deployed runtime.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-skills-collection",
-  "version": "4.0.61",
+  "version": "4.0.63",
   "description": "OpenCode CLI plugin that automatically downloads and keeps skills up to date.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",