opencode-skills-collection 4.0.60 → 4.0.62

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/md2video-audio/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: md2video-audio
+description: "Convert Markdown documents into narrated MP4 videos with synchronized visuals and voice narration."
+category: media
+risk: safe
+source: community
+source_repo: 70v-Yoyo/md2video-audio-skill
+source_type: community
+date_added: "2026-09-12"
+author: 70v-Yoyo
+tags: [markdown, video, audio, text-to-speech, marp, presentation]
+tools: [claude, cursor, gemini]
+license: "Apache-2.0"
+license_source: "https://github.com/70v-Yoyo/md2video-audio-skill/blob/main/LICENSE"
+---
+
+# Md2video-audio
+
+## Overview
+
+`md2video-audio` converts a Markdown document into a narrated MP4 video by transforming the source into synchronized presentation visuals and spoken narration.
+
+The workflow preserves the original file and generates separate presentation, narration, and video outputs.
+
+- `source_repo: 70v-Yoyo/md2video-audio-skill`
+- `source_type: community`
+
+## When to Use This Skill
+
+- Use when converting Markdown tutorials, reports, or presentations into narrated videos.
+- Use when creating presentation-style videos.
+- Use when the user asks for Markdown-to-video, narrated slides, or audio-video generation.
+
+## How It Works
+
+### Step 1: Check Environment
+
+Verify required local dependencies before running the workflow. Do not install, remove, or modify dependencies without user confirmation.
+
+### Step 2: Prepare the Markdown
+
+Keep the original file unchanged.
+
+Create a new Markdown file with improved sectioning, formatting, and natural transitions while preserving the original meaning.
+
+### Step 3: Generate Presentation Markdown
+
+Convert the prepared document into Marp-compatible slides.
+
+- Separate slides with `---`.
+- Prevent content overflow.
+- Split oversized tables, code blocks, or sections when necessary.
+- Ask the user to choose a Marp style when required.
+
+### Step 4: Generate Narration
+
+Create a narration Markdown file aligned one-to-one with the presentation slides.
+
+Remove visual-only characters that should not be spoken and verify that slide separators remain synchronized.
+
+### Step 5: Generate Video
+
+Run the provided video-generation script with the presentation and narration files:
+
+```
+python ai-2md2marp2av.py presentation.md narration.md
+```
+
+The script renders Marp slides, generates speech with Edge-TTS, and combines them into an MP4 video.
+
+Ask the user to complete any interactive input required by the script.
+
+### Step 6: Fallback
+
+If the primary workflow fails, try the included fallback scripts in order:
+
+```
+python md2marp2av.py
+```
+
+Then:
+
+```
+python md2video.py
+```
+
+## Examples
+
+### Example 1: Convert a Tutorial
+
+```
+/md2video-audio tutorial.md
+```
+
+Produces presentation Markdown, narration Markdown, and a narrated MP4 video.
+
+### Example 2: Convert a Work Report
+
+```
+/md2video-audio project-review.md
+```
+
+Use the generated slides and narration to create a presentation-style report video.
+
+## Best Practices
+
+- ✅ Preserve the original Markdown file.
+- ✅ Keep presentation and narration slide counts synchronized.
+- ✅ Split slides that exceed safe layout limits.
+- ✅ Confirm before installing dependencies or running interactive actions.
+- ❌ Do not overwrite the source document.
+- ❌ Do not silently install, remove, or modify system dependencies.
+
+## Limitations
+
+- Requires the local runtime and dependencies used by the included scripts.
+- Complex Markdown layouts may require manual adjustment.
+- Edge-TTS availability depends on the local network and runtime environment.
+- Stop and ask for clarification when required files, permissions, or user choices are missing.
+
+## Security & Safety Notes
+
+- Run scripts only in a local or authorized environment.
+- Confirm with the user before installing dependencies or making environment changes.
+- Generated files should be written as new files rather than replacing source content.
+- Do not execute interactive or destructive commands without explicit user confirmation.
+
+## Common Pitfalls
+
+- **Problem:** Presentation and narration contain different slide counts.
+  **Solution:** Verify the number of `---` separators and realign the narration.
+- **Problem:** Slide content overflows the Marp layout.
+  **Solution:** Split the content into smaller logical sections before rendering.
+- **Problem:** Video generation fails because dependencies are unavailable.
+  **Solution:** Verify the environment first, then use the fallback scripts if appropriate.