opencode-skills-collection 4.1.11 → 4.1.13

package/bundled-skills/skeleton-first/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: skeleton-first
+description: "Prove a data/AI/agent workflow end to end on a tiny sample, find cheap wins, then scale in cost-gated steps within budget."
+category: workflow
+risk: safe
+source: self
+source_type: self
+date_added: "2026-10-11"
+author: Dan He
+tags: [llm, cost, pipeline, etl, rag, dbt, snowflake, budget, data-engineering]
+tools: [claude, codex, cursor]
+---
+
+# Skeleton first: prove the workflow cheaply, then scale
+
+Agents tend to build every stage at full size before anything has run end to end. In data and AI work that fails expensively: a wrong prompt runs over a whole table, a wrong grain is discovered after twenty models exist, a big warehouse burns credits on a query that returns the wrong answer.
+
+This skill changes the order of work:
+
+1. Make the **whole path** work on the **smallest possible input** with the **cheapest settings**.
+2. Prove it with a test.
+3. Scale up in **cost-gated rungs**, measuring and projecting cost before each one.
+4. Only then add features, **one at a time**, re-running the tests after each.
+
+## When to Use
+
+- A workflow with 2+ stages (ingest -> transform -> model/LLM -> output), or anything that touches paid compute: warehouse credits, LLM tokens, embeddings, API calls.
+- New or unfamiliar data, a new tool or SDK, an architecture that has not run in this environment before.
+- The user asks to "build X end to end", "set up the pipeline", "process all the documents", "create the models".
+
+Skip it for: one-file fixes, a single query, work already proven at full scale, or when the user explicitly says to go straight to full scale (then still state the projected cost first).
+
+## Step 0 - Define "it works" before building
+
+Write down, and show the user in 3-5 lines:
+
+- **The thinnest end-to-end path**: every stage present, the minimum of each. Example: 1 source table -> 1 transform -> 1 LLM call -> 1 output row.
+- **One pass/fail test** a person can check, e.g. "for these 3 sample rows the output has columns A, B, C and the value for row 2 is X". Prefer tests with a known right answer.
+- **A budget**: maximum spend and time for the whole job, and for the skeleton (the skeleton should cost almost nothing).
+
+If the user has not given a budget, propose one and say so.
+
+## Step 1 - Write the ladder
+
+Plan the work as rungs. Each rung adds exactly one thing and has a gate.
+
+| Rung | Adds | Input size | Gate to pass |
+| --- | --- | --- | --- |
+| L0 skeleton | every stage, stubbed or minimal | 1 record | test passes end to end |
+| L1 | real logic in the weakest stage | 10 records | test passes, cost per record measured |
+| L2 | scale | ~1% or 100 records | quality spot-check, projected full cost under budget |
+| L3 | full run | 100% | totals reconcile, test still passes |
+| L4+ | one feature each | as needed | all previous tests still pass |
+
+Show the ladder to the user before building unless the task is small. Keep it short.
+
+## Step 2 - Build L0, the walking skeleton
+
+- Every stage exists and is connected; none is polished.
+- Hardcode or stub anything that is not on the critical path (config, retries, UI, logging beyond a print).
+- Use the cheapest settings everywhere (see Cost levers).
+- Run it. If it fails, fix the path; do not start adding features.
+- **Look at the sample before scaling it.** Read a few raw records and measure what you are paying for. Most cheap wins hide here: duplicate records (cache by content hash), boilerplate repeated in every record (headers, footers, legal notices, signatures, templated sections), empty or invalid inputs that the API still bills. Count how much of the cost each one accounts for; stripping a footer that is 70% of every document is worth more than any tuning later.
+
+Not allowed until L0 passes: a second source, a second model or table, parallelism, tuning, UI, abstractions, handling edge cases that have not been seen yet.
+
+## Step 3 - Scale up in cost-gated rungs
+
+At every rung:
+
+1. Run on the rung's input size.
+2. Record: records in/out, errors, wall time, cost (tokens, credits, API calls).
+3. **Project the next rung**: cost per record x next size, time per record x next size.
+4. **Gate**: continue only if the test passes, errors are understood, and the projection is under budget.
+
+When the projection is over budget, the budget is a constraint to design around, not a reason to hand the job back. First look for a cheaper path that still passes the test: remove redundancy found in the sample, send less per record (relevant sections, truncation), cache, use a cheaper model or a free local method for part of the work. Prove the cheaper path on the same small rung, re-project, and continue if it fits. Stop and report to the user with the numbers and options only when no cheaper path passes the test, or when it would change what the user asked for in a way they would likely care about (say which trade-off you made either way).
+
+Grow by roughly 10x per rung (1 -> 10 -> 100 or 1% -> full). Never jump from the skeleton straight to the full run.
+
+Keep a run log in the working folder (e.g. `RUNLOG.md`):
+
+| Rung | Input | Result | Errors | Time | Cost | Projected next | Decision |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+## Step 4 - Add features one at a time
+
+- One change per step: a new source, a new model, a new tool, a prompt change.
+- After each change, re-run every existing test (regression). If something that passed now fails, fix it before adding anything else.
+- When tests were written by the same agent that built the system, ask for (or create via an independent subagent) a few held-out tests the builder has not seen, before claiming quality.
+
+## Cost levers
+
+General
+
+- Sample first: `LIMIT`, `SAMPLE`, a handful of files, one page of results.
+- Cheapest model that can pass the test; a stronger model only for the stage that fails.
+- Dry runs: compile, `EXPLAIN`, validate config without executing.
+- Cap spend per call: `max_tokens`, timeouts, low concurrency until proven.
+- Cache everything that is deterministic (embeddings, parsed files, API responses) so re-runs are free.
+- Count tokens on the sample and multiply before the full run.
+- Parse structure deterministically when it exists (headings, tables, templates); call an LLM only for prose.
+
+Snowflake / Cortex Code
+
+- Smallest warehouse (XS) with a short auto-suspend; scale the warehouse only after the logic is right.
+- `SAMPLE` / `TABLESAMPLE` or `LIMIT` on sources; check grain and row counts on the sample.
+- `EXPLAIN` before expensive queries; prefer transient or temporary tables for intermediate steps.
+- Cortex AI functions: run on a few rows first, check output, estimate tokens (e.g. `SNOWFLAKE.CORTEX.COUNT_TOKENS` where available) before applying to a table.
+- dbt: build one model with `--select`; use `--empty` (dbt 1.8+) to check the DAG compiles and runs with no data; `--defer` to reuse production parents instead of rebuilding them.
+
+LLM / RAG / agents
+
+- Ingest 1 document, then 10, before the corpus; measure seconds and cost per chunk and extrapolate.
+- Evaluate on 5-10 questions with known answers before adding tools, rerankers or critics.
+- Add one agent or tool at a time; log which tool calls each answer used.
+
+## Reporting at each gate
+
+Tell the user, briefly:
+
+- What ran (rung, input size) and whether the test passed.
+- Cost and time so far, and the projection for the next rung.
+- The decision you recommend (continue, fix, or stop), and anything that needs their call.
+
+## Anti-patterns
+
+- Building every stage at full size, then running for the first time.
+- Running an LLM or AI function over a whole table to "see what happens".
+- Adding the second data source before the first one passes its test.
+- Tuning or adding UI before the path works.
+- Writing many tools or rules that each fit one test question (overfitting); fix classes of errors instead, and confirm on held-out tests.
+- Claiming success on tests written by the same agent that built the system.
+- Stopping at an over-budget projection without first trying to make the job fit the budget.
+
+## Example
+
+User: "Tag all 400 tickets in tickets.csv with a category using our LLM endpoint."
+
+```text
+Step 0  path: CSV -> 1 LLM call -> tagged.csv | test: 10 hand-checked tickets correct | budget: $2 (proposed)
+Sample: 3 tickets have empty bodies (API bills then errors) -> skip; only 220 of 400 texts are unique -> cache by hash
+Spent so far:
+L0  1 ticket    pass   $0.004
+L1  10 tickets  10/10  $0.04   -> full run projected $0.88 (with dedupe) < $2, continue
+L2  100         12/12  $0.25   -> continue
+L3  400         pass   $0.88 total (naive run would have cost $1.60)
+```
+
+## Limitations
+
+- Needs a way to measure cost (a ledger, billing view, token counts or query history); without it, projections are estimates and should be labeled as such.
+- Small rungs can miss problems that only appear at scale (rate limits, rare record types, skewed partitions); keep the full-run gate and reconcile totals.
+- Adds a few minutes and some tokens per task; not worth it for one-off queries, single-file fixes or work already proven at full size.
+- Tests written by the same agent can be too easy; use held-out tests or a human spot-check before claiming quality.
+- Cost levers listed for Snowflake and dbt are starting points; check your platform's current pricing and features.
+
+## Done means
+
+- The full run completed within budget.
+- Every test from every rung still passes.
+- The run log shows cost, time and decisions per rung.
+- The user knows the real cost per unit, so future runs are predictable.
+- Intermediate outputs from earlier rungs (sample CSVs, partial indexes) are deleted or clearly marked, so only the final result is left for the user.

package/bundled-skills/system-prompt-lookup/SKILL.md

@@ -144,7 +144,7 @@ a match on generic safety boilerplate is not.
 ## Best Practices
 
 - ✅ Cite file name plus capture date every time you quote.
-- ✅ State whether the artifact was captured or vendor-reported.
+- ✅ State whether the artifact was captured off the wire or reported by the model itself.
 - ✅ Treat every number — characters, tool counts — as tied to one dated file.
 - ✅ Say plainly when the archive has no entry for the product being asked about.
 - ❌ Do not paraphrase a prompt you did not fetch in this session.

package/bundled-skills/uxkin-research/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: uxkin-research
+description: "Research how real products handle a screen, flow or visual style before designing it: search UXKIN's real iOS screens, user journeys and website design systems, compare several and report what they share."
+category: frontend
+risk: safe
+source: https://github.com/uxkin/agent/tree/main/skills/uxkin-research
+source_repo: uxkin/agent
+source_type: official
+date_added: "2026-10-09"
+author: UXKIN
+tags: [ui, ux, design, research, mcp, design-system]
+tools: [claude, codex, cursor, copilot, gemini]
+license: MIT
+license_source: https://github.com/uxkin/agent/blob/main/LICENSE
+---
+
+# UXKIN research
+
+When a design decision depends on how real products do it, look at
+several real examples, compare them properly and report what they show,
+before anyone writes code. This skill uses the UXKIN MCP tools:
+
+- `find_ui_references`: real apps, screens, journeys and websites
+- `get_journey`: every screen of one journey, in order
+- `find_ui_materials`: colors with their roles, typography, components
+  and the DESIGN.md of real website design systems
+- `list_collections` / `get_collection`: references the person saved on
+  UXKIN; when they mention their saved picks or a collection, start there
+
+## When to Use
+
+- Use when the person asks how other apps handle a screen or flow ("how do other apps do onboarding?").
+- Use when they want UI inspiration or comparable apps before designing.
+- Use when they need examples of a flow: onboarding, sign-up, checkout, paywall, cancellation, account deletion, empty states.
+- Use when they need a real website design system to start from.
+
+## If the tools aren't connected
+
+Don't present examples from memory as if they were real research, and
+don't describe screens you haven't seen. Answer from the project itself
+and general principles, say clearly that it isn't based on real
+references, and mention once, in one short sentence, that connecting
+UXKIN (https://uxkin.com) lets you compare real apps and flows for this.
+Don't repeat it.
+
+If a search says the account needs a plan, tell the person once and
+carry on without references.
+
+## 1. Frame the question
+
+Turn the request into one or two concrete questions, for example: "Where
+do subscription apps put cancelling, and how many steps does it take?"
+or "What does a dark fintech site use for surfaces and accents?". Note
+the product type and platform, since they decide which examples are
+relevant.
+
+## 2. Search in plain words
+
+Call `find_ui_references` with the product type, the screen or flow and,
+if it matters, the platform: "meditation app onboarding", "delete
+account", "empty state search results". Leave out filler such as
+"screen", "design" or "UI".
+
+Apps name flows in their own words, so try a second wording when results
+are thin: "cancel subscription" and "manage subscription", "sign up" and
+"create an account", "paywall" and "choose a plan".
+
+For a visual style or a starting design system, call `find_ui_materials`
+with the product type and mood: "developer tools dark", "wellness light
+warm".
+
+## 3. Open journeys, don't stop at thumbnails
+
+For anything with more than one step, open 3 to 5 journey results with
+`get_journey` and compare them end to end:
+
+- **Start:** which screen leads into the flow, and what else lives there.
+- **Steps:** how many, and what each one is for. Mark steps that only
+  persuade, upsell or survey.
+- **End:** a confirmation, the home screen, the next task, a paywall.
+- **Spread:** the shortest and longest versions, and what explains the
+  difference.
+
+For design systems, compare color roles (background, surface, text,
+accent), type and the components each one names.
+
+## 4. Report
+
+Keep it short and concrete:
+
+1. What most of the examples do (the pattern), naming the apps or sites
+   and journeys so the person can look at them on uxkin.com.
+2. Where they differ, and which option fits this product and why.
+3. A recommendation, or two options with the trade-off.
+
+Report only what you saw in the results. Don't guess at screens you
+didn't open.
+
+## Use patterns, not products
+
+References guide decisions; they are not templates. Never copy another
+product's branding, logos, illustrations or text. The product's own
+requirements, accessibility and platform conventions always win over a
+reference.
+
+When the person moves on to building, follow the `no-ui-slop` skill if
+it's installed.
+
+## Examples
+
+The person asks: "How do other meditation apps onboard new users?"
+
+```text
+1. Frame it: what starts the flow, how many steps, and what ends it?
+2. find_ui_references("meditation app onboarding")
+3. get_journey on 3 to 5 results; note the start, each step's purpose and the end.
+4. Report the shared pattern, where the flows differ and one recommendation.
+```
+
+For a starting design system, call `find_ui_materials("wellness light warm")`, compare the named color roles, type and components, then say which one fits the product and why.
+
+## Limitations
+
+- Needs the UXKIN MCP tools connected. Without them the skill answers from the project and general principles, and says so.
+- Real references depend on the UXKIN account; a plan-limited search returns no examples and the skill carries on without them.
+- Covers iOS app screens, user journeys and website design systems. Other platforms may have no references.
+- References inform decisions; they are not templates and never override the product's own requirements, accessibility or platform conventions.

package/package.json

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

package/skills_index.json

@@ -18916,6 +18916,36 @@
     "license": "MIT",
     "license_source": "https://github.com/zhaoxuya520/reverse-skill/blob/main/LICENSE"
   },
+  {
+    "id": "datacircle",
+    "path": "skills/datacircle",
+    "category": "data",
+    "name": "datacircle",
+    "description": "Look up LinkedIn profiles by URL through Datacircle (Up2Data, HarvestAPI or Fetchin, no markup), over its hosted MCP server or REST API, with the user's yes before each paid call.",
+    "risk": "critical",
+    "source": "self",
+    "date_added": "2026-10-10",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "self",
+    "tags": [
+      "b2b-data",
+      "linkedin",
+      "enrichment",
+      "rest-api",
+      "mcp"
+    ]
+  },
   {
     "id": "datadog",
     "path": "skills/datadog",
@@ -35241,6 +35271,38 @@
       "reasons": []
     }
   },
+  {
+    "id": "kernel-prompt",
+    "path": "skills/kernel-prompt",
+    "category": "productivity",
+    "name": "kernel-prompt",
+    "description": "Use when composing or improving an LLM prompt or agent instruction. Asks one round of questions, then returns only the prompt; never performs the task.",
+    "risk": "safe",
+    "source": "community",
+    "date_added": "2026-10-10",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "community",
+    "source_repo": "codegiveness/kernel-prompt",
+    "license": "MIT",
+    "license_source": "https://github.com/codegiveness/kernel-prompt/blob/main/LICENSE",
+    "tags": [
+      "prompt-engineering",
+      "meta-prompting",
+      "prompt-optimization",
+      "agent-handoff"
+    ]
+  },
   {
     "id": "keyword-extractor",
     "path": "skills/keyword-extractor",
@@ -49937,6 +49999,40 @@
     "license": "MIT",
     "license_source": "https://github.com/amElnagdy/delegate-skills/blob/master/LICENSE"
   },
+  {
+    "id": "qrx",
+    "path": "skills/qrx",
+    "category": "design",
+    "name": "qrx",
+    "description": "Make branded, print-ready art QR codes that always scan with QRX (qrx.codes). Use when a link needs a QR code that looks like artwork or matches a brand for print, packaging, signs, slides or event badges, and to list or re-point QRX codes. Not for plain QR codes the agent makes locally.",
+    "risk": "critical",
+    "source": "https://github.com/qrxcodes/qrx-mcp/tree/main/skills/qrx",
+    "date_added": "2026-10-10",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "official",
+    "source_repo": "qrxcodes/qrx-mcp",
+    "license": "MIT",
+    "license_source": "https://github.com/qrxcodes/qrx-mcp/blob/main/LICENSE",
+    "tags": [
+      "qr-code",
+      "design",
+      "branding",
+      "mcp",
+      "rest-api",
+      "print"
+    ]
+  },
   {
     "id": "quality-nonconformance",
     "path": "skills/quality-nonconformance",
@@ -51829,6 +51925,32 @@
       "reasons": []
     }
   },
+  {
+    "id": "reverse-engineer-anything",
+    "path": "skills/reverse-engineer-anything",
+    "category": "uncategorized",
+    "name": "reverse-engineer-anything",
+    "description": "Use REA to investigate shipped apps, binaries, packages, and runtimes; trace features with evidence, compare versions, or guide reconstruction. Skip ordinary source-code analysis.",
+    "risk": "safe",
+    "source": "https://github.com/morluto/rea/tree/main/skill-src/reverse-engineer-anything",
+    "date_added": "2026-10-10",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "community",
+    "source_repo": "morluto/rea",
+    "license": "MIT",
+    "license_source": "https://github.com/morluto/rea/blob/main/LICENSE"
+  },
   {
     "id": "reverse-engineering",
     "path": "skills/reverse-engineering",
@@ -55913,6 +56035,40 @@
       "reasons": []
     }
   },
+  {
+    "id": "skeleton-first",
+    "path": "skills/skeleton-first",
+    "category": "workflow",
+    "name": "skeleton-first",
+    "description": "Prove a data/AI/agent workflow end to end on a tiny sample, find cheap wins, then scale in cost-gated steps within budget.",
+    "risk": "safe",
+    "source": "self",
+    "date_added": "2026-10-11",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "self",
+    "tags": [
+      "llm",
+      "cost",
+      "pipeline",
+      "etl",
+      "rag",
+      "dbt",
+      "snowflake",
+      "budget",
+      "data-engineering"
+    ]
+  },
   {
     "id": "skeuomorphism",
     "path": "skills/design-it/skeuomorphism",
@@ -63830,6 +63986,40 @@
       "reasons": []
     }
   },
+  {
+    "id": "uxkin-research",
+    "path": "skills/uxkin-research",
+    "category": "frontend",
+    "name": "uxkin-research",
+    "description": "Research how real products handle a screen, flow or visual style before designing it: search UXKIN's real iOS screens, user journeys and website design systems, compare several and report what they share.",
+    "risk": "safe",
+    "source": "https://github.com/uxkin/agent/tree/main/skills/uxkin-research",
+    "date_added": "2026-10-09",
+    "plugin": {
+      "targets": {
+        "codex": "supported",
+        "claude": "supported"
+      },
+      "setup": {
+        "type": "none",
+        "summary": "",
+        "docs": null
+      },
+      "reasons": []
+    },
+    "source_type": "official",
+    "source_repo": "uxkin/agent",
+    "license": "MIT",
+    "license_source": "https://github.com/uxkin/agent/blob/main/LICENSE",
+    "tags": [
+      "ui",
+      "ux",
+      "design",
+      "research",
+      "mcp",
+      "design-system"
+    ]
+  },
   {
     "id": "uxui-principles",
     "path": "skills/uxui-principles",