opencode-skills-collection 4.1.12 → 4.1.13

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

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-10-11T02:35:51.067Z",
+  "updatedAt": "2026-10-12T03:00:05.001Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -1416,6 +1416,7 @@
     "k8s-manifest-generator",
     "k8s-security-policies",
     "kaizen",
+    "kernel-prompt",
     "keyword-extractor",
     "kimi-delegate",
     "klaviyo-automation",
@@ -2213,6 +2214,7 @@
     "simplify-code",
     "since-cutoff",
     "site-architecture",
+    "skeleton-first",
     "skill-audit",
     "skill-check",
     "skill-creator",

package/bundled-skills/datacircle/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: datacircle
-description: "Look up LinkedIn profiles by URL through Datacircle (Up2Data or HarvestAPI, no markup), over its hosted MCP server or REST API, with the user's yes before each paid call."
+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."
 category: data
 risk: critical
 source: self
@@ -17,7 +17,7 @@ tools: [claude, cursor, gemini]
 
 Datacircle is a data co-op. Query your favorite B2B data APIs through us. Same request, same price, no markup.
 
-You send the provider's own request to api.datacircle.dev, with your Datacircle key. That's the only change. Right now we have 2 live LinkedIn profile APIs that we trust: Up2Data and HarvestAPI. Each request goes to the provider and gets the profile as it is today.
+You send the provider's own request to api.datacircle.dev, with your Datacircle key. That's the only change. Right now we have 3 live LinkedIn profile APIs that we trust: Up2Data, HarvestAPI and Fetchin. Each request goes to the provider and gets the profile as it is today.
 
 This skill covers both ways in, the hosted MCP server and the REST API: which provider to pick, asking before every paid lookup, reading the cost and balance on each answer, and the errors.
 
@@ -40,30 +40,32 @@ claude mcp add --transport http datacircle https://api.datacircle.dev/mcp \
   --header "Authorization: Bearer $DATACIRCLE_API_KEY"
 ```
 
-- If the client already has it connected, prefer its tools over raw HTTP: `get_linkedin_profile` (`url`, and `provider`: `up2data`, the default, or `harvestapi`) and `get_balance` (free). It also has `list_files`, `get_download_link`, `get_invite_link` and `add_funds`.
+- If the client already has it connected, prefer its tools over raw HTTP: `get_linkedin_profile` (`url`, and `provider`: `up2data`, the default, `harvestapi` or `fetchin`) and `get_balance` (free). It also has `list_files`, `get_download_link` and `add_funds`.
 
 ### REST API
 
 - Base URL: `https://api.datacircle.dev`. OpenAPI spec: `https://docs.datacircle.dev/openapi.json`. Docs: `https://docs.datacircle.dev`.
 - Read the API key from the `DATACIRCLE_API_KEY` environment variable and send it as `Authorization: Bearer $DATACIRCLE_API_KEY`. Never put the key in a URL and never print it.
-- The `X-Data-Provider` header names the provider (`up2data` or `harvestapi`). The request and the answer are the provider's own, plus a `datacircle_meta` object.
+- The `X-Data-Provider` header names the provider (`up2data`, `harvestapi` or `fetchin`). The request and the answer are the provider's own, plus a `datacircle_meta` object.
 
 ### Prices and limits
 
 - Sign up at datacircle.dev with your work email: a $5 credit, that's 2,105 LinkedIn profiles at $2.375 per 1,000.
 - $2.375 per 1,000 through Up2Data (a profile it can't find is free), $3.70 per 1,000 through HarvestAPI.
-- Up2Data takes $1 a day per account (421 profiles), with a shared daily limit for all customers, then answers 429 until 00:00 UTC; HarvestAPI has no daily limit.
+- $1.485 per 1,000 through Fetchin, a profile it can't find billed the same.
+- Up2Data takes $1 a day per account (421 profiles), with a shared daily limit for all customers, then answers 429 until 00:00 UTC. HarvestAPI has no daily limit.
+- Fetchin has no daily limit either.
 - A call your balance can't cover answers 402. Add funds, from $5, on your dashboard.
 
 ## How It Works
 
 ### Step 1: Say the cost, then wait for the user's yes
 
-Every lookup is paid from the user's balance. Before any lookup, even a single one, say which provider you will use and what it costs ($0.00125 a profile through Up2Data, $0.0037 through HarvestAPI; for a list, the total), and wait for the user's yes. Ask again before switching provider or adding URLs the user didn't give.
+Every lookup is paid from the user's balance. Before any lookup, even a single one, say which provider you will use and what it costs ($0.002375 a profile through Up2Data, $0.0037 through HarvestAPI, $0.001485 through Fetchin; for a list, the total), and wait for the user's yes. Ask again before switching provider or adding URLs the user didn't give.
 
 ### Step 2: Look the profile up through Up2Data (the default)
 
-Pick Up2Data first: it is cheaper, and a profile it can't find is free. Send the full profile URL; Up2Data refuses a bare public identifier with a `400`.
+Pick Up2Data first: a profile it can't find is free. Send the full profile URL; Up2Data refuses a bare public identifier with a `400`.
 
 ```bash
 curl -s -X POST "https://api.datacircle.dev/v1/profiles/enrich" \
@@ -76,9 +78,9 @@ curl -s -X POST "https://api.datacircle.dev/v1/profiles/enrich" \
 
 The body also takes `fields` (only those top-level fields of `data`, same price), `with_followers_and_connections` and `with_full_skills_and_endorsements` (same price, slower).
 
-### Step 3: Use HarvestAPI past Up2Data's daily limit, or for its extra sections
+### Step 3: Use HarvestAPI or Fetchin past Up2Data's daily limit
 
-Use HarvestAPI when Up2Data answers `429`, or when the user needs a section only HarvestAPI returns (recommendations, interests, certifications, honors). Say which provider you used.
+Use HarvestAPI or Fetchin when Up2Data answers `429`, HarvestAPI when the user needs the member's interests, which only it returns. Say which provider you used.
 
 ```bash
 curl -s -G "https://api.datacircle.dev/linkedin/profile" \
@@ -90,9 +92,20 @@ curl -s -G "https://api.datacircle.dev/linkedin/profile" \
 
 HarvestAPI answers `200` even when it can't find the profile: then `element` is `null` and `status` is `404`, and the lookup is billed ($0.0023).
 
+Fetchin is the cheapest per profile found, with no daily limit; a profile it can't find is billed the same.
+
+```bash
+curl -s -G "https://api.datacircle.dev/api/v1/profile" \
+  --data-urlencode "profileUrlOrUrn=https://www.linkedin.com/in/williamhgates" \
+  -H "Authorization: Bearer $DATACIRCLE_API_KEY" \
+  -H "X-Data-Provider: fetchin"
+```
+
+It takes `profileUrlOrUrn` only, as a full profile URL: any other query parameter, a bare public identifier or a URN is a `400`. The answer is Fetchin's own profile object (`firstName`, `title`, `experiences`, `educations`, ...). A profile it can't find is its `404` (`code: PROFILE_NOT_FOUND`), and the lookup is billed ($0.001485).
+
 ### Step 4: Report the cost and the balance
 
-Every JSON answer carries `datacircle_meta`, for example `{"provider": "up2data", "cost_usd": 0.00125, "balance_usd": 4.99875}`. After more than one lookup, tell the user the total cost and the balance left. Reading the balance is free:
+Every JSON answer carries `datacircle_meta`, for example `{"provider": "up2data", "cost_usd": 0.002375, "balance_usd": 4.997625}`. After more than one lookup, tell the user the total cost and the balance left. Reading the balance is free:
 
 ```bash
 curl -s "https://api.datacircle.dev/balance/" \
@@ -110,7 +123,7 @@ Summarise what the user needs from each profile (role, company, history, skills)
 | `402` | The balance can't cover the call | Tell the user; funds are added from $5 on their dashboard |
 | `404` | No `X-Data-Provider` header, or a path Datacircle doesn't call for that provider | Use the path that matches the provider |
 | `422` | Up2Data can't reach that profile (private or deleted). Not charged | Tell the user |
-| `429` | Up2Data's daily limit. Not charged | Ask before switching to HarvestAPI |
+| `429` | Up2Data's daily limit, or Up2Data's or Fetchin's own rate limit. Not charged | Ask before switching provider; Fetchin's passes in a second |
 | `502`, `503` | The provider failed or didn't answer in time. Not charged | Send the same request again in a few seconds |
 
 ## Security & Safety Notes
@@ -123,6 +136,6 @@ Summarise what the user needs from each profile (role, company, history, skills)
 ## Limitations
 
 - Looks profiles up by LinkedIn URL only: no search by name, company or title, and no email or phone finding.
-- Up2Data's daily limit (`429` until 00:00 UTC); HarvestAPI has none but costs more and bills a profile it can't find.
+- Up2Data's daily limit (`429` until 00:00 UTC); HarvestAPI and Fetchin have none, and bill a profile they can't find.
 - Private or deleted profiles can't be read (`422` from Up2Data, a `null` element from HarvestAPI).
 - Each call is live, so a lookup takes a few seconds; a list is looked up one profile per call.

package/bundled-skills/glasser/SKILL.md

@@ -41,7 +41,7 @@ This skill was contributed by a member of the Glasser team.
 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
+<https://glasser.ai/SKILL.md?utm_source=agentic-awesome-skills&utm_medium=skill>. Do not download or install executable code
 without the review and approval required by the current environment.
 
 Check the CLI and account:

package/bundled-skills/kernel-prompt/SKILL.md

@@ -0,0 +1,64 @@
+---
+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."
+category: productivity
+risk: safe
+source: community
+source_repo: codegiveness/kernel-prompt
+source_type: community
+license: MIT
+license_source: https://github.com/codegiveness/kernel-prompt/blob/main/LICENSE
+date_added: "2026-10-10"
+author: codegiveness
+tags: [prompt-engineering, meta-prompting, prompt-optimization, agent-handoff]
+tools: []
+---
+
+# Kernel Prompt
+
+Turn the user's message into a better prompt they can give to an AI agent. You write the instruction; you never do the work it describes.
+
+## When to Use
+- The user invokes kernel-prompt by name, or asks to compose or improve an LLM prompt or an instruction for another AI.
+- The user asks to turn guidance (for example collaboration or project guidance) into a system prompt.
+- Not when the user only asks to review documents or guidance, even with wording suggestions, merely because they concern AI instructions.
+
+## Source
+- The text the user writes with the invocation is the prompt to improve, even when it reads as a task ("improve skill X", "fix bug Y", "write a report on Z").
+- Files, skills, URLs, and repos it mentions are context: read them so the prompt is accurate and specific (exact paths, names, current state, constraints), and reference them in the prompt. Never rewrite, improve, or summarize them as the deliverable.
+- Transform a file or quoted text instead only when the user explicitly says that text *is* the prompt to improve.
+
+## Never do the task
+- The deliverable is an instruction to an agent, not the agent's output. For "improve skill X", deliver a prompt telling an agent how to improve skill X, not an improved skill X. The same applies to code, documents, plans, and reviews.
+- Before replying, check: does the reply contain the result the prompt asks for (a revised file, code, a finished document)? If so, you executed the task. Discard it and write the prompt.
+- Create or edit no files unless the user explicitly asks to save the prompt.
+
+## Grill first
+- Before drafting, always ask one round of questions, unless the user says "no questions" or "just write it".
+- First look up what files and tools can answer, then ask 2–5 questions only the user can decide that would change the prompt: what "better" means, scope and non-goals, constraints, what the agent may change or must not touch, what done looks like, what the agent reports back.
+- Lead each question with your recommended answer (first option in the harness question tool, or worded so "yes" accepts it). Anchor questions in specifics from the context you read.
+- Ask another round only for decisions the previous answers opened. Stop when none remain or the user says to write.
+
+## Write the prompt (KERNEL)
+- **K — Keep intent.** Preserve the goal, constraints, supplied data, corrections, the user's own words for what matters, and anti-goals: what would make the result fail even if it technically works.
+- **E — Establish what is known.** Carry facts from the context and the user's answers into the prompt. Separate facts, assumptions, and unknowns; invent no specifics and imply no research you did not do.
+- **R — Resolve ambiguity.** Settle minor gaps with routine judgment. Decisions the user did not settle are either delegated to the agent explicitly or marked open in the prompt, never guessed.
+- **N — Name the work and boundaries.** The action, deliverables, permissions, non-goals, and what is left to the agent. Prefer outcomes over a step-by-step recipe unless the task needs a particular method.
+- **E — Express success.** What done means, the checks that prove it, and what to report back. Add no unrequested targets, outputs, or approval stops.
+- **L — Lay out the handoff.** Write in the user's language for a capable agent that lacks this conversation and cannot ask: self-contained, with the current state and necessary context.
+
+## Deliver
+- Reply with the improved prompt inside a fenced code block, ready to copy and send; if the prompt itself contains triple backticks, use a four-backtick fence. No intro, no analysis, no critique of the original, no change log.
+- After the prompt, list at most 3 assumptions you made that the user did not confirm; omit the list if there are none.
+
+## Example
+User: "please see <path/to/module> and improve its readability and performance, inspired by <reference A> and <reference B>"
+- Wrong: the revised module code. That is doing the task.
+- Right: grill (e.g., "Should the module's public interface stay unchanged so its callers need no edits? Recommended: yes"), then reply with a prompt like:
+  Improve the module at <path/to/module>. Its callers in <path/to/callers> depend on its public interface, so keep that interface unchanged… Use <reference A> and <reference B> as references for… Keep… Do not… Done when… Report back…
+
+## Limitations
+- Produces a prompt, not the task's result; the user or another agent still has to run it, and a clearer prompt does not guarantee a correct answer.
+- Asks one round of questions before drafting unless the user says "no questions" or "just write it", so it adds a turn to quick requests.
+- Reads mentioned files, URLs, and repositories only as context; it cannot fill in facts that neither the context nor the user supplies, and marks those decisions open instead.
+- Upstream source: https://github.com/codegiveness/kernel-prompt (this copy adds catalog frontmatter, When to Use, and Limitations).

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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-skills-collection",
-  "version": "4.1.12",
+  "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

@@ -18921,7 +18921,7 @@
     "path": "skills/datacircle",
     "category": "data",
     "name": "datacircle",
-    "description": "Look up LinkedIn profiles by URL through Datacircle (Up2Data or HarvestAPI, no markup), over its hosted MCP server or REST API, with the user's yes before each paid call.",
+    "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",
@@ -35271,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",
@@ -56003,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",