opencode-skills-collection 3.0.28 → 3.0.29

package/bundled-skills/complexity-cuts/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: complexity-cuts
+description: "Lower Big-O on existing code via a one-transformation-at-a-time playbook with verify-revert-stop. For new code use lemmaly; for math-level wins escalate to mathguard."
+risk: safe
+source: community
+source_repo: morsechimwai/lemmaly
+source_type: community
+date_added: "2026-05-26"
+author: morsechimwai
+tags: [algorithms, big-o, refactoring, optimization, performance, n-plus-one]
+tools: [claude-code, antigravity, cursor, gemini-cli, codex-cli]
+license: "Apache-2.0"
+license_source: "https://github.com/morsechimwai/lemmaly/blob/main/LICENSE"
+---
+
+# complexity-cuts — Lower Big-O on Existing Code
+
+`lemmaly` prevents bad complexity before code is written. **complexity-cuts** fixes it after the fact: code already exists, it works, but its time or space complexity is worse than necessary.
+
+**Violating the letter of these rules is violating the spirit of the skill.** Adapting "just a little" is how a faster-but-wrong rewrite ships.
+
+## When to Use This Skill
+
+Use **complexity-cuts** when refactoring existing code that has poor Big-O:
+
+- Nested loops, `O(n²)` or worse scans, repeated work, redundant allocations, blown memory.
+- Stated symptoms: "this is slow on large inputs", "times out", "OOM", "too much memory", "reduce complexity", "optimize this algorithm".
+- N+1 query patterns in ORMs (Prisma, Drizzle, SQLAlchemy, Django, ActiveRecord).
+- `await` inside `for` over independent items causing serial latency.
+
+For *preventing* bad complexity before code is written, use **`lemmaly`**. For math-level optimizations (Bloom, HLL, FFT, JL projection), escalate to **`mathguard`**.
+
+## The Iron Law
+
+```text
+NO TRANSFORMATION WITHOUT EXISTING TESTS GREEN BEFORE AND AFTER
+```
+
+If the code has no tests, you write a characterization test first (golden input → current output). Then transform. Then verify the test still passes. If you skip this, the optimization can silently break callers — and faster-but-wrong is worse than slow-and-right.
+
+## Non-negotiable rules
+
+1. **State current and target Big-O before touching code.** In one line:
+   - Current: `time = O(?)`, `space = O(?)`
+   - Target: `time = O(?)`, `space = O(?)`
+   - Dominant input dimension (n = what, how large in practice)
+
+   If you cannot state current Big-O, you do not yet understand the code. Read more.
+
+2. **Identify the bottleneck, do not guess.** Point to the exact line(s) responsible for the dominant term. Nested loop? Repeated linear scan? Recomputation? Allocation inside a hot loop? The fix lives there, not elsewhere.
+
+3. **One transformation at a time, with a verify-revert-stop loop.** The loop is:
+
+   1. Apply exactly one transformation from the playbook.
+   2. Run the existing test suite (or the characterization test you wrote per the Iron Law).
+   3. If any test breaks: **revert immediately.** Do not patch the test. Do not patch around the failure. Revert.
+   4. Count reverts on this piece of code. If **3 reverts in a row**, STOP optimizing. The bottleneck is wrong, the transformation is wrong, or the code has invariants you have not modeled. Escalate to `invariant-guard` and write the missing contract — do not try a fourth transformation.
+   5. Only after a transformation lands green: pick the next one.
+
+   Stacked changes hide regressions. Patched tests hide regressions louder.
+
+4. **Preserve semantics exactly.** Lower complexity must not change outputs, ordering guarantees, stability, or error behavior. If the optimization requires a semantic change (e.g. unordered output), call it out explicitly and confirm it is acceptable.
+
+5. **No invented numbers.** Never write "10x faster" or "saves 200MB" without measuring. Write `<measured: TBD>` and move on, or actually measure with a representative input.
+
+6. **Always report the measured speedup ratio after a transformation lands.** Once the new code is green, run a representative benchmark (same input, same machine, warm cache) and report `before → after` plus the ratio as `N× faster` (or `N× less memory`). One line, attached to the diff:
+
+   ```text
+   p50:  186 ms → 1.1 ms   (169× faster, n=20,000, 200 samples)
+   ```
+
+   If you cannot measure (e.g. the win is purely asymptotic on inputs you don't have), say so explicitly: `asymptotic only, no measurement — O(n²) → O(n)`. Never silently skip this step.
+
+## The transformation playbook
+
+The vast majority of real-world Big-O wins come from a small set of moves. Try them in this order:
+
+### Time-complexity reductions
+
+| Smell | Fix | Typical win |
+|---|---|---|
+| `for x in A: if x in B` where B is list/array | Convert B to `Set`/`Map` once | O(n·m) → O(n+m) |
+| Nested loop computing pairs/joins | Hash-join on the key; index by lookup field | O(n·m) → O(n+m) |
+| Repeated `.find` / `.indexOf` / `.includes` inside a loop | Precompute index `Map<key, item>` outside loop | O(n^2) → O(n) |
+| Repeated recomputation of same value | Memoize / cache by input key | O(n·f(n)) → O(n + f(n)) |
+| Sort inside a loop | Sort once outside | O(n^2 log n) → O(n log n) |
+| Linear scan for min/max/median repeatedly | Heap / sorted structure | O(n·k) → O(n log k) |
+| Recursive recomputation (naive Fibonacci shape) | Memoize, or convert to iterative DP | exponential → O(n) |
+| String concatenation in a loop (some langs) | Use builder / `join` / `array.push` then join | O(n^2) → O(n) |
+| Repeated regex compile in loop | Compile once outside | constant-factor, large |
+| Counting / grouping via nested loop | Single pass with `Counter` / `Map<k, count>` | O(n^2) → O(n) |
+| Sliding-window written as nested loop | Two-pointer / windowed sum | O(n^2) → O(n) |
+| Repeated prefix sums | Precompute prefix array, O(1) range queries | O(n·q) → O(n+q) |
+| Pairwise distance / containment checks on intervals | Sort + sweep line | O(n^2) → O(n log n) |
+| Top-K via full sort | Heap of size K | O(n log n) → O(n log k) |
+| Repeated set membership in loop body | `Set` once, reuse | O(n·m) → O(n) |
+| `await` inside a `for` over independent items | `Promise.all` / batched concurrency | wall-clock O(n·latency) → O(latency) |
+| ORM query inside a loop (N+1) | `IN (...)` / `select_related` / bulk fetch | O(n) round-trips → O(1) |
+
+### Space-complexity reductions
+
+| Smell | Fix | Typical win |
+|---|---|---|
+| Materializing whole list/array just to iterate | Generator / iterator / stream | O(n) → O(1) |
+| Building intermediate arrays via chained `.map().filter().map()` on huge data | Single-pass loop or lazy pipeline | k·O(n) → O(n) (often O(1) extra) |
+| Caching every intermediate result of a recursion | Rolling window (keep last k states) | O(n) → O(k) |
+| Storing parents/visited for graph traversal when only count needed | Bitset / counter only | O(n) → O(1) |
+| Copying input to mutate | In-place mutation when caller allows | O(n) → O(1) |
+| Reading entire file before processing | Stream line-by-line / chunked | O(file) → O(chunk) |
+| Deep-clone for safety in a loop | Clone once, or use structural sharing / immutables | O(n·m) → O(n+m) |
+| Holding references that prevent GC (closures, listeners, caches) | Bound the cache (LRU), remove listeners, scope closures tightly | unbounded → bounded |
+| Loading full result set from DB | Cursor / pagination / streaming query | O(rows) → O(page) |
+| `JSON.parse(JSON.stringify(x))` for cloning | `structuredClone` or targeted copy | O(n) work and allocation removed |
+
+### When you cannot lower asymptotic Big-O
+
+Sometimes O(n log n) really is the floor. Then move to constant-factor wins:
+
+- Replace pointer-chasing structures with contiguous arrays (cache locality).
+- Hoist invariants out of loops.
+- Avoid allocation in the hot loop (reuse buffers).
+- Prefer typed arrays / native containers over boxed objects for numeric work.
+- Batch syscalls / I/O.
+
+State explicitly: "Asymptotic floor is O(n log n); applying constant-factor optimizations only."
+
+## Required workflow
+
+For each piece of code you optimize:
+
+1. **Measure or estimate current Big-O.** Write it down.
+2. **Identify the bottleneck line(s).** Point at them.
+3. **Pick one transformation from the playbook.** Name it.
+4. **Apply it.** One change.
+5. **Verify behavior.** Tests pass, or outputs match on a representative input.
+6. **State new Big-O.** Time and space.
+7. **Repeat if more wins exist and are worth the complexity cost.**
+
+## Canonical example — workflow vs no-workflow
+
+The same optimization with and without the verify-revert-stop loop.
+
+**Bottleneck.** `getOrdersWithUsers()` runs 10s on 10k orders. Cause: `users.find(u => u.id === o.userId)` inside the map → O(n·m).
+
+### Without the workflow — changes semantics AND patches the test
+
+```ts
+// No workflow: change semantics + the optimization in one go
+export function getOrdersWithUsers(orders, users) {
+  const userById = Object.fromEntries(users.map(u => [u.id, u]));
+  return orders
+    .map(o => ({ ...o, user: userById[o.userId] }))
+    .filter(o => o.user); // silently drops orders whose user was deleted
+}
+```
+
+Faster, *and* changes the result set. Existing tests catch it — but the diff also "fixes" a flaky test by removing the assertion that checked the old behavior. Ships green. Breaks the billing report two weeks later.
+
+### With the workflow — one transformation, semantics preserved
+
+```ts
+// Workflow applied:
+//   Bottleneck: orders.map → users.find  (line 14)
+//   Current: time = O(n·m), space = O(1)
+//   Target:  time = O(n+m), space = O(m)
+//   Transformation: precompute index Map<userId, User> outside the loop
+//   Semantic risk: None — orders with missing users still emit `user: undefined` exactly as before
+//   Reverts so far: 0
+
+export function getOrdersWithUsers(orders, users) {
+  const userById = new Map(users.map(u => [u.id, u]));
+  return orders.map(o => ({ ...o, user: userById.get(o.userId) }));
+}
+```
+
+One transformation. Existing tests stay untouched. Run them. If green, ship. If red, revert (don't patch). After 3 reverts, stop and load `invariant-guard` — the bottleneck is wrong, or the function has a contract no one wrote down.
+
+## Output discipline
+
+When proposing or applying an optimization, your message must contain — in this order:
+
+1. **Bottleneck** — file:line and one-sentence reason.
+2. **Current complexity** — `time = O(?)`, `space = O(?)`.
+3. **Transformation** — name from the playbook (or describe it if novel).
+4. **New complexity** — `time = O(?)`, `space = O(?)`.
+5. **Semantic risk** — anything callers might notice (ordering, stability, error timing). "None" is a valid answer if true.
+6. **Measured speedup** — `before → after` with the ratio as `N× faster` (or `asymptotic only` if not measured). One line, honest numbers.
+7. **The diff.**
+
+If any of 1–6 is missing, the optimization is not ready to apply.
+
+## Stop conditions — do not optimize further when
+
+- Asymptotic Big-O already matches a known lower bound for the problem.
+- The input is provably small and bounded (n < ~100 and not on a hot path).
+- The optimization would obscure correctness or harm readability without a measured win.
+- The bottleneck is I/O or external service latency, not CPU/memory — go fix that instead.
+
+Premature optimization past these points adds risk without payoff.
+
+## Rationalizations to watch for
+
+| Excuse | Reality |
+| --- | --- |
+| "I already solved this in my head — just paste the diff and add labels after." | Retrofitted labels lie about the reasoning order. Write bottleneck → complexity → transformation → diff in that order, or you are writing fiction. |
+| "Stating the current Big-O is busywork — everyone can see the nested loop." | If everyone can see it, writing one line costs nothing. If only you can see it, you just saved the reviewer's time. |
+| "Semantic risk is None, skip that step." | "None" is a valid answer — but write it. The next reader does not know which guarantees you considered. |
+| "I'll do all three transformations in one diff." | Stacked transformations hide regressions. One transformation, verify, repeat. |
+| "It's just a small refactor, the workflow is overkill." | Then it takes 30 seconds. The cases where you skip the workflow are the ones where you miss the optimization next to the obvious one. |
+| "I'll measure later." | Later is `<measured: TBD>` forever. Either measure now or accept the asymptotic argument as the only claim. |
+
+## Red flags — STOP
+
+- Optimizing without stating current Big-O.
+- "This should be faster" without identifying a specific bottleneck line.
+- Stacking multiple transformations before verifying any one of them.
+- Claiming a speedup without measuring or without an asymptotic argument.
+- Lowering complexity by silently changing output semantics.
+- Rewriting code that runs once at startup with n = 12.
+
+## Verification checklist
+
+Before claiming an optimization is complete:
+
+- [ ] Existing tests (or a written characterization test) were green BEFORE the transformation.
+- [ ] Exactly one transformation was applied.
+- [ ] Tests are green AFTER the transformation.
+- [ ] No test was modified, weakened, or skipped to make it pass.
+- [ ] Current Big-O and target Big-O are stated in the diff or PR description.
+- [ ] Semantic risk is written down ("None" is valid if true).
+- [ ] Measured speedup ratio is reported as `before → after · N× faster` (or explicitly marked `asymptotic only` if no measurement was possible).
+- [ ] If a measured claim was made (e.g. "3x faster"), the measurement command is included.
+- [ ] Revert count on this code is < 3.
+
+Cannot check every box? The optimization is not done. Either revert or finish the gap — do not ship a half-verified speedup.
+
+## Limitations
+
+- **Requires existing tests or a written characterization test.** Without one, you cannot detect silent semantic regressions; the Iron Law refuses to skip this.
+- **Asymptotic wins only; constant-factor work is a separate mode** (clearly labeled). The playbook will not improve cache locality or SIMD utilization on its own.
+- **Single-process scope.** Distributed-system bottlenecks (consensus latency, replication lag, queue backpressure) are out of scope.
+- **3-revert rule is firm.** If three transformations failed, the skill explicitly forces escalation to `invariant-guard`; it does not let you try a fourth.
+- **Measurement is on the author.** complexity-cuts requires the ratio to be reported but does not run the benchmark for you — you must produce a representative input.
+- **Won't help I/O-bound code.** If the dominant term is network latency or disk, the playbook will not move the needle — fix the I/O pattern instead.
+
+## The thesis, in one line
+
+> **Existing code earned its slowness one shortcut at a time. complexity-cuts removes them one transformation at a time — and refuses to ship the optimization without a green test.**
+
+## Related Skills
+
+- `lemmaly` — prevention gateway; use when writing new code instead of refactoring existing.
+- `invariant-guard` — escalation target when 3+ transformations have failed tests — the missing piece is a contract, not an optimization.
+- `mathguard` — escalation when the classical floor is reached and an approximate or math-heavy structure could win.

package/bundled-skills/decision-navigator/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: decision-navigator
+description: "Guide stuck or overwhelmed users through targeted branching questions until they reach concrete next steps."
+category: planning
+risk: safe
+source: community
+source_type: community
+date_added: "2026-05-27"
+---
+
+# Decision Navigator
+
+Help users who feel stuck or overwhelmed by guiding them through a structured branching exploration
+of their situation — one clear question at a time — until they arrive at concrete, actionable steps.
+
+## Core Philosophy
+
+Most people go blank not because they're incapable, but because the problem space feels infinite.
+Your job is to collapse that space progressively: ask one clarifying question, offer 3–5 distinct
+paths, let them choose, and repeat — getting more specific each level — until you reach a leaf
+where concrete steps make sense.
+
+Never overwhelm with a wall of options or advice upfront. Navigate, don't lecture.
+
+---
+
+## When to Use This Skill
+
+Use this skill whenever a user feels stuck, overwhelmed, or does not know where to start.
+Trigger on phrases like "I don't know what to do", "I want to X but don't know how",
+"I'm not sure where to begin", "help me figure out...", "I feel lost about...", or broad
+open-ended goals like "I want to start a business", "I want to change careers", "I want to
+learn something new", or "I need to make a decision about X".
+
+Do not wait for the user to ask a precise question. If they seem stuck or overwhelmed, use
+this skill.
+
+## The Process
+
+### Step 1 — Acknowledge and orient (1–2 sentences)
+
+Reflect the situation back briefly so the user feels heard. Don't give advice yet.
+
+> "Changing careers is a big one — lots of directions it could go. Let me help you narrow it down."
+
+### Step 2 — Ask one clarifying question
+
+Ask the single most useful question to understand *what kind* of problem this actually is.
+Frame it as a choice between 3–5 concrete options, not open-ended.
+
+**Option labels must be short** — 2 to 6 words max. No explanations inside the bullet.
+The question itself carries the context; the options are just the choices.
+
+**Good question format:**
+> "What's driving this for you right now?
+> - Unhappy in my current role
+> - Want to earn more
+> - Want more flexibility
+> - Found a new interest
+> - Not sure yet"
+
+**Bad question format:**
+> "Tell me more about your situation." ← too open, doesn't reduce the space
+
+> "- Simplicity: I want the easiest setup with zero server management." ← option labels should never have colons or sub-explanations
+
+### Step 2b — Extract before you ask
+
+If the user's message already contains useful information (they described constraints, named
+platforms, listed requirements), pull that out first. Don't make them re-answer what they
+already told you.
+
+> "Ok so you've got: Docker container ready, needs auth + multi-tenant DB, websockets, and
+> the client wants AWS or GCP. That's a lot. What's the scariest part right now?
+> - Choosing between AWS and GCP
+> - Understanding how all the pieces connect
+> - Actually deploying the container
+> - Not sure where to even begin"
+
+### Step 3 — Branch based on their answer
+
+After they choose, go one level deeper. Each level should feel more specific.
+
+Typical depth: 3–4 levels before reaching actionable steps.
+
+**Level 1** — What kind of problem is this? (motivation, constraint, knowledge gap, fear, resources...)
+**Level 2** — What's the most important factor for them? (urgency, risk tolerance, resources available...)
+**Level 3** — What's their current situation / starting point?
+**Level 4** (leaf) — Give concrete steps
+
+### Step 4 — Deliver concrete steps at the leaf
+
+When you've narrowed things down enough (usually 3–4 questions in), stop branching and give
+3–6 specific, ordered action steps. These should be immediately doable, not vague advice.
+
+**Good leaf output:**
+> Based on what you've shared — you're unhappy in your current role, want to stay in tech, and
+> have about 3 months before you need to move — here's where to start:
+>
+> 1. Spend one hour this week writing down what specifically drains you vs. energizes you at work.
+> 2. Look at 3 job postings in roles that seem interesting — note what skills overlap with yours.
+> 3. Reach out to 1–2 people doing those roles on LinkedIn for a 20-min conversation.
+> 4. Set a decision deadline: commit to applying somewhere within 6 weeks.
+> 5. Tell one trusted person about your plan so you have accountability.
+
+**Bad leaf output:**
+> "You should network more and update your resume." ← too vague
+
+---
+
+## Branching Guidelines
+
+### How to design your questions
+
+- **Short option labels** — 2 to 6 words. Never a colon + explanation inside a bullet.
+  The question sets the context; options are just the fork in the road.
+- **Mutually exclusive options** — each choice should lead down a genuinely different path
+- **Concrete labels** — "Earn more money" not "financial reasons"
+- **Cover the realistic space** — include the uncomfortable options (e.g. "Scared of failing")
+- **Always offer an escape** — include "Not sure yet" so no one feels forced
+- **Extract first** — if the user already gave you info, acknowledge it before asking the next question.
+  Summarize what you know in 1–2 lines, then ask only what's still missing.
+
+### When to branch vs. when to go straight to steps
+
+Go straight to concrete steps when:
+- The user's situation is already specific enough (they've answered 3+ questions)
+- The remaining branches would all lead to the same advice
+- The user says something like "just tell me what to do"
+
+Keep branching when:
+- The advice would be meaningfully different depending on their answer
+- You'd be guessing at key constraints (budget, timeline, risk tolerance, etc.)
+- The problem space still feels large
+
+### How many options per question
+
+- **3 options** — when the distinctions are clear-cut
+- **4–5 options** — when the space is genuinely varied
+- **Never more than 5** — more than that is overwhelming (the whole problem we're solving)
+
+---
+
+## Tone and Style
+
+- Warm but efficient — not therapist-soft, not consultant-cold
+- Short sentences. No jargon.
+- Reflect their words back to them (if they said "burned out", use "burned out" not "fatigued")
+- Never judge the path they choose
+- If they seem emotionally distressed (not just confused), acknowledge that before navigating
+
+---
+
+## Format
+
+Present choices as a short list, not prose:
+
+```
+[Question]
+
+- Option A
+- Option B
+- Option C
+- Something else / not sure
+```
+
+At the leaf, use a numbered list for steps. Start with the number ("1.") not a bullet.
+
+Keep the whole interaction feeling like a conversation, not a form.
+
+---
+
+## Example Flow
+
+**User:** I want to start a business but I have no idea where to start.
+
+**Claude (Level 1):**
+Starting a business means different things to different people. What's the main thing drawing you to it?
+
+- I have a specific idea I want to build
+- I want freedom / to be my own boss
+- I want to make more money than my job pays
+- I'm not sure yet — I just know I want something different
+
+**User:** I have a specific idea I want to build.
+
+**Claude (Level 2):**
+Got it. Where are you in terms of the idea itself?
+
+- It's clear in my head but I haven't done anything yet
+- I've talked to some people about it but haven't built anything
+- I've started building / have a prototype
+- I've tried before and it didn't work out
+
+**User:** It's clear in my head but I haven't done anything yet.
+
+**Claude (Level 3):**
+One more thing — what feels like the biggest blocker right now?
+
+- I don't know if the idea is actually good
+- I don't know how to build it / lack technical skills
+- I'm worried about the financial risk
+- I don't know the first practical step to take
+
+**User:** I don't know if the idea is actually good.
+
+**Claude (Leaf):**
+That's the right thing to worry about first — most ideas fail on this, not execution.
+Here's how to find out quickly:
+
+1. Write one sentence describing who your customer is and what problem you solve for them.
+2. Find 5 people who match that description. Not friends — people who'd actually pay.
+3. Ask them: "Do you have this problem? How do you currently deal with it?"
+4. Do NOT pitch your solution yet. Just listen. If they describe your problem unprompted, that's signal.
+5. After 5 conversations, you'll know if this is real. If 3+ people have the problem badly, keep going.
+
+---
+
+## Edge Cases
+
+**User gives a very vague situation** ("I don't know what to do with my life")
+→ Start even broader: ask what *area* of life feels most stuck (work, relationships, health, purpose, finances)
+
+**User picks "something else"**
+→ Ask them to describe it briefly, then fit their answer into the next level of branching
+
+**User wants to explore multiple paths**
+→ Finish one path to the leaf, then offer: "Want to explore what the [other option] path looks like too?"
+
+**User is clearly in distress**
+→ Pause the navigation. Acknowledge first. Ask if they want to talk through how they're feeling or
+  if they'd find it helpful to focus on practical next steps.
+
+## Limitations
+
+- This skill helps structure uncertainty; it does not replace professional legal, medical, financial, or mental-health advice.
+- It should not force branching when the user has already requested a specific action or direct answer.
+- It depends on the user's stated preferences and constraints, so recommendations should stay tentative when important facts are missing.

package/bundled-skills/docs/integrations/jetski-cortex.md

@@ -1,9 +1,9 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,470+ skills."
+description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,480+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,470+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,480+ skills
 
 This guide shows how to integrate the `antigravity-awesome-skills` repository with an agent based on **Jetski/Cortex + Gemini** (or similar frameworks) **without exceeding the model context window**.
 
@@ -23,7 +23,7 @@ Never do:
 - concatenate all `SKILL.md` content into a single system prompt;
 - re-inject the entire library for **every** request.
 
-With 1,470+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,480+ skills, this approach fills the context window before user messages are even added, causing truncation.
 
 ---
 

package/bundled-skills/docs/integrations/jetski-gemini-loader/README.md

@@ -21,7 +21,7 @@ This example shows one way to integrate **antigravity-awesome-skills** with a Je
 - How to enforce a **maximum number of skills per turn** via `maxSkillsPerTurn`.
 - How to choose whether to **truncate or error** when too many skills are requested via `overflowBehavior`.
 
-This pattern avoids context overflow when you have 1,470+ skills installed.
+This pattern avoids context overflow when you have 1,480+ skills installed.
 
 Manifest contract references:
 

package/bundled-skills/docs/maintainers/repo-growth-seo.md

@@ -6,7 +6,7 @@ This document keeps the repository's GitHub-facing discovery copy aligned with t
 
 Preferred positioning:
 
-> Installable GitHub library of 1,470+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
+> Installable GitHub library of 1,480+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
 
 Key framing:
 
@@ -20,7 +20,7 @@ Key framing:
 
 Preferred description:
 
-> Installable GitHub library of 1,470+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Includes installer CLI, bundles, workflows, and official/community skill collections.
+> Installable GitHub library of 1,480+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Includes installer CLI, bundles, workflows, and official/community skill collections.
 
 Preferred homepage:
 
@@ -28,7 +28,7 @@ Preferred homepage:
 
 Preferred social preview:
 
-- use a clean preview image that says `1,470+ Agentic Skills`;
+- use a clean preview image that says `1,480+ Agentic Skills`;
 - mention Claude Code, Cursor, Codex CLI, and Gemini CLI;
 - avoid dense text and tiny logos that disappear in social cards.
 

package/bundled-skills/docs/maintainers/skills-update-guide.md

@@ -72,7 +72,7 @@ The update process refreshes:
 - Canonical skills index (`skills_index.json`)
 - Compatibility mirror (`data/skills_index.json`)
 - Web app skills data (`apps\web-app\public\skills.json`)
-- All 1,470+ skills from the skills directory
+- All 1,480+ skills from the skills directory
 
 ## When to Update
 

package/bundled-skills/docs/users/bundles.md

@@ -673,4 +673,4 @@ Found a skill that should be in a bundle? Or want to create a new bundle? [Open
 
 ---
 
-_Last updated: March 2026 | Total Skills: 1,470+ | Total Bundles: 37_
+_Last updated: March 2026 | Total Skills: 1,480+ | Total Bundles: 37_

package/bundled-skills/docs/users/claude-code-skills.md

@@ -12,7 +12,7 @@ Install the library into Claude Code, then invoke focused skills directly in the
 
 ## Why use this repo for Claude Code
 
-- It includes 1,470+ skills instead of a narrow single-domain starter pack.
+- It includes 1,480+ skills instead of a narrow single-domain starter pack.
 - It supports the standard `.claude/skills/` path and the Claude Code plugin marketplace flow.
 - It also ships generated bundle plugins so teams can install focused packs like `Essentials` or `Security Developer` from the marketplace metadata.
 - It includes onboarding docs, bundles, and workflows so new users do not need to guess where to begin.

package/bundled-skills/docs/users/gemini-cli-skills.md

@@ -12,7 +12,7 @@ Install into the Gemini skills path, then ask Gemini to apply one skill at a tim
 
 - It installs directly into the expected Gemini skills path.
 - It includes both core software engineering skills and deeper agent/LLM-oriented skills.
-- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,470+ files.
+- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,480+ files.
 - It is useful whether you want a broad internal skill library or a single repo to test many workflows quickly.
 
 ## Install Gemini CLI Skills

package/bundled-skills/docs/users/getting-started.md

@@ -1,4 +1,4 @@
-# Getting Started with Antigravity Awesome Skills (V11.7.0)
+# Getting Started with Antigravity Awesome Skills (V11.8.0)
 
 **New here? This guide will help you supercharge your AI Agent in 5 minutes.**
 

package/bundled-skills/docs/users/kiro-integration.md

@@ -18,7 +18,7 @@ Kiro is AWS's agentic AI IDE that combines:
 
 Kiro's agentic capabilities are enhanced by skills that provide:
 
-- **Domain expertise** across 1,470+ specialized areas
+- **Domain expertise** across 1,480+ specialized areas
 - **Best practices** from Anthropic, OpenAI, Google, Microsoft, and AWS
 - **Workflow automation** for common development tasks
 - **AWS-specific patterns** for serverless, infrastructure, and cloud architecture

package/bundled-skills/docs/users/usage.md

@@ -14,7 +14,7 @@ If you came in through a **Claude Code** or **Codex** plugin instead of a full l
 
 When you ran `npx antigravity-awesome-skills` or cloned the repository, you:
 
-✅ **Downloaded 1,470+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
+✅ **Downloaded 1,480+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
 ✅ **Made them available** to your AI assistant  
 ❌ **Did NOT enable them all automatically** (they're just sitting there, waiting)
 
@@ -34,7 +34,7 @@ Bundles are **curated groups** of skills organized by role. They help you decide
 
 **Analogy:**
 
-- You installed a toolbox with 1,470+ tools (✅ done)
+- You installed a toolbox with 1,480+ tools (✅ done)
 - Bundles are like **labeled organizer trays** saying: "If you're a carpenter, start with these 10 tools"
 - You can either **pick skills from the tray** or install that tray as a focused marketplace bundle plugin
 
@@ -212,7 +212,7 @@ Let's actually use a skill right now. Follow these steps:
 
 ## Step 5: Picking Your First Skills (Practical Advice)
 
-Don't try to use all 1,470+ skills at once. Here's a sensible approach:
+Don't try to use all 1,480+ skills at once. Here's a sensible approach:
 
 If you want a tool-specific starting point before choosing skills, use:
 
@@ -343,7 +343,7 @@ Usually no, but if your AI doesn't recognize a skill:
 
 ### "Can I load all skills into the model at once?"
 
-No. Even though you have 1,470+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
+No. Even though you have 1,480+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
 
 The intended pattern is: