opencode-skills-collection 4.0.1 → 4.0.3

package/bundled-skills/diagnose-android-overheating/references/evidence-and-interpretation.md

@@ -0,0 +1,168 @@
+# Evidence and Interpretation
+
+Use this reference after the core skill has established device authorization, symptom context, and a safety screen. Commands are read-only unless a section explicitly says otherwise.
+
+## Contents
+
+1. Evidence quality
+2. Thermal and battery baseline
+3. Symptom branches
+4. Correlation guide
+5. Controlled Batterystats capture
+6. Bugreport privacy
+7. Official references
+
+## Evidence Quality
+
+Prefer evidence in this order:
+
+1. a controlled comparison that changes only one plausible cause;
+2. a timestamped trend spanning cool-to-hot or hot-to-cool behavior;
+3. two independent system signals from the same window;
+4. a single system snapshot;
+5. user recollection without device evidence.
+
+Do not elevate a lower-quality signal merely because it names an app or subsystem.
+
+## Thermal and Battery Baseline
+
+Capture the full service outputs before extracting fields:
+
+```bash
+adb -s <serial> shell dumpsys battery
+adb -s <serial> shell dumpsys thermalservice
+adb -s <serial> shell dumpsys cpuinfo
+adb -s <serial> shell top -n 1
+adb -s <serial> shell dumpsys power
+```
+
+Interpretation rules:
+
+- `dumpsys battery` describes battery and charging state. Its temperature field is commonly expressed in tenths of a degree Celsius, but verify the device's representation instead of blindly dividing.
+- `dumpsys thermalservice` is most useful on Android 10 and later. Some OEMs omit detailed sensors, expose only severity, or restrict output.
+- Framework thermal status ranges from `0` (none) through `6` (shutdown) on implementations that expose the standard service. `2` means moderate, `3` severe, `4` critical, and `5` emergency thermal stress.
+- Sensor readings are not interchangeable. Battery, skin, CPU, GPU, modem, and USB sensors describe different locations and policies.
+- OEM thresholds differ. Never declare a universal safe temperature from one raw value.
+- Thermal throttling is a response to heat, not automatically its cause.
+
+If `top -n 1` is rejected, inspect `adb -s <serial> shell top --help` and use only a syntax supported by that device. Do not install BusyBox or request root as a fallback.
+
+## Symptom Branches
+
+### Idle or Screen-Off Heat
+
+```bash
+adb -s <serial> shell dumpsys batterystats
+adb -s <serial> shell dumpsys batterystats --history
+adb -s <serial> shell dumpsys power
+adb -s <serial> shell dumpsys alarm
+adb -s <serial> shell dumpsys jobscheduler
+adb -s <serial> shell dumpsys sensorservice
+adb -s <serial> shell dumpsys location
+adb -s <serial> shell dumpsys deviceidle
+```
+
+Look for duration and recurrence, not merely presence. A scheduled alarm, registered sensor, or listed job can be normal. Correlate it with screen-off time, wakeups, process activity, network traffic, and the heat window.
+
+### App-Specific Heat
+
+First identify the exact package without guessing from the display name. Then inspect it:
+
+```bash
+adb -s <serial> shell dumpsys cpuinfo
+adb -s <serial> shell dumpsys meminfo <package>
+adb -s <serial> shell dumpsys package <package>
+adb -s <serial> shell dumpsys jobscheduler <package>
+adb -s <serial> shell dumpsys gfxinfo <package>
+```
+
+Package memory is not a heat measurement. High memory can contribute to pressure or churn, but sustained CPU/GPU, radios, camera, sensors, or charging usually provide a stronger causal path.
+
+### Cellular, Weak-Signal, or 5G Heat
+
+```bash
+adb -s <serial> shell dumpsys telephony.registry
+adb -s <serial> shell dumpsys connectivity
+adb -s <serial> shell dumpsys wifi
+adb -s <serial> shell dumpsys batterystats
+adb -s <serial> shell getprop | grep -iE 'radio|baseband'
+```
+
+Redact phone numbers, subscriber identifiers, network names, and addresses. Look for a repeated association among poor signal, handovers or radio activity, higher battery drain, and the heat timeline. Confirm with a same-workload Wi-Fi or airplane-mode window when safe and acceptable to the user.
+
+Do not change preferred network type from a copied bitmask. Slot IDs, carrier policy, radio capabilities, and command availability vary by device and Android build.
+
+### Charging Heat
+
+```bash
+adb -s <serial> shell dumpsys battery
+adb -s <serial> shell dumpsys usb
+adb -s <serial> shell dumpsys thermalservice
+```
+
+Record plugged source, charging status, battery level, workload, charger, cable, case, and ambient conditions. A USB debugging cable can itself change the result. Do not simulate unplugging with `dumpsys battery set`; that changes framework state without reproducing the physical charging condition.
+
+### Camera, Navigation, Gaming, Video, or Tethering
+
+Collect the thermal baseline plus only the relevant services:
+
+```bash
+adb -s <serial> shell dumpsys media.camera
+adb -s <serial> shell dumpsys media.metrics
+adb -s <serial> shell dumpsys location
+adb -s <serial> shell dumpsys sensorservice
+adb -s <serial> shell dumpsys connectivity
+adb -s <serial> shell dumpsys wifi
+adb -s <serial> shell dumpsys display
+adb -s <serial> shell dumpsys SurfaceFlinger
+```
+
+Service names and permissions vary. Record unsupported services rather than replacing them with root-only commands.
+
+## Correlation Guide
+
+| Observation | Stronger interpretation | Required counter-check |
+| --- | --- | --- |
+| Rising thermal severity and sustained package CPU | App/process workload may drive heat | Repeat sample; compare with app inactive |
+| Heat plus poor signal and mobile-radio activity | Modem/radio loop may contribute | Same workload on stable Wi-Fi or airplane mode |
+| Heat while idle plus long partial wakelock | Background work may prevent sleep | Match wakelock duration to screen-off heat window |
+| Heat only while physically charging | Charging path or charge-plus-load may contribute | Safe unplugged comparison with workload controlled |
+| Severe thermal state but low visible app CPU | GPU, modem, camera, charging, kernel, or hardware remains plausible | Inspect matching subsystem and OEM blind spots |
+| Battery drain without thermal escalation | Energy use may be real but insufficient to cause thermal stress | Compare temperature trend and workload duration |
+| High temperature with no exposed activity | Hardware fault or inaccessible vendor activity remains possible | Safe mode/OEM diagnostics or qualified service |
+
+## Controlled Batterystats Capture
+
+Resetting Batterystats erases the existing collection window. Do it only after preserving the original output and obtaining approval for a fresh experiment.
+
+Official Android guidance uses this sequence:
+
+1. save current Batterystats or a bugreport if needed;
+2. reset Batterystats;
+3. disconnect the USB cable so the device runs on battery;
+4. reproduce a defined workload for a defined duration;
+5. reconnect and export Batterystats or a bugreport;
+6. compare the captured window with a control window.
+
+Do not run the reset merely to make output shorter. Record that the reset occurred because it changes the evidence base.
+
+## Bugreport Privacy
+
+`adb bugreport <local-path>.zip` creates a broad diagnostic archive. Before running it:
+
+- explain that it may include identifiers, accounts, app usage, notifications, networks, logs, and recent system activity;
+- choose a private local path with the user;
+- do not upload or transmit the archive without separate approval;
+- extract only the evidence needed for the diagnosis;
+- redact sensitive fields before sharing excerpts;
+- follow the user's retention or deletion preference.
+
+## Official References
+
+- [Android dumpsys documentation](https://developer.android.com/tools/dumpsys)
+- [Profile battery usage with Batterystats and Battery Historian](https://developer.android.com/topic/performance/power/setup-battery-historian)
+- [Analyze power use with Battery Historian](https://developer.android.com/topic/performance/power/battery-historian)
+- [AOSP thermal mitigation](https://source.android.com/docs/core/power/thermal-mitigation)
+- [Android Thermal API](https://developer.android.com/games/optimize/adpf/thermal)
+- [System restrictions on background tasks](https://developer.android.com/develop/background-work/background-tasks/bg-work-restrictions)
+- [Android developer options](https://developer.android.com/studio/debug/dev-options)

package/bundled-skills/ditto/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: ditto
+description: "Use when a user asks to mine or update a private, evidence-backed work profile from local Claude Code, Codex, Copilot CLI, or OpenCode sessions."
+category: agent-behavior
+risk: critical
+source: community
+source_repo: ohad6k/ditto
+source_type: community
+date_added: "2026-07-14"
+author: ohad6k
+tags: [personalization, context-engineering, session-mining, agent-memory]
+tools: [claude, cursor, gemini, codex-cli]
+license: "MIT"
+license_source: "https://github.com/ohad6k/ditto/blob/v0.3.6/LICENSE"
+---
+
+# Ditto
+
+## Overview
+
+Ditto mines only the user's words from real local coding-agent session logs and
+turns repeated, supported patterns into private work, design, and writing
+profiles. It keeps dated session receipts, rejects authored rules and memory as
+source evidence, and requires approval before model-backed mining begins.
+
+This standalone skill routes a compatible, already-installed Ditto runtime.
+Native namespaced routing is available through the upstream Ditto plugin.
+
+## When to Use This Skill
+
+- Use when the user explicitly asks to set up, run, update, re-mine, or deepen Ditto.
+- Use when the user wants an agent profile derived from real coding-session history rather than a questionnaire or rules file.
+- Use when native `ditto:mine` is unavailable and the user already has a compatible Ditto runtime installed.
+
+Do not trigger this skill merely because personalization might be useful. Mining
+requires an explicit user request.
+
+## How It Works
+
+### 1. Resolve an installed runtime
+
+Ask the user for the path to an existing, trusted Ditto runtime, or use the
+native upstream plugin when it is already installed. Retain the exact Python 3
+executable path as `PYTHON3`, the runtime path as `DITTO_PY`, and its matching
+`MINING_PROMPT.md` path. Confirm the installed version and source before use.
+
+Do not download or install executable code as part of this skill. If Ditto is
+not installed, stop and direct the user to the upstream installation guidance;
+installation is a separate, explicit decision.
+
+### 2. Show the read-only mining plan
+
+Mine only real user-authored sessions. Never synthesize a profile from
+`AGENTS.md`, `CLAUDE.md`, memory files, rules files, or a typed self-description.
+
+Run the full-history quality-default preflight:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin preflight
+```
+
+Show the user the valid session count, post-dedupe source tokens, selected source
+tokens, cache hits, planned worker calls, and planned reducer calls. Wait for
+explicit approval of this displayed plan before any model-backed work.
+
+If the user explicitly asks for a quick preview, add `--preview` and say exactly:
+
+> Quick preview creates a starter profile from selected history, not the full profile.
+
+Never present preview as the default or as equivalent to the full-history result.
+
+### 3. Prepare the approved run
+
+Retain the displayed `approval_hash`, then prepare with the exact approved mode.
+For the full-history plan, run:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin prepare --approved-plan-hash HASH
+```
+
+For an approved quick-preview plan, preserve preview mode explicitly:
+
+```bash
+"$PYTHON3" "$DITTO_PY" plugin prepare --preview --approved-plan-hash HASH
+```
+
+If the hash changes, show the new plan and obtain approval again. Retain the
+returned `run_id`, assigned segment and report paths, and `pack_path`.
+
+### 4. Mine and validate evidence
+
+For every uncached selected segment, run one worker over only that segment and
+the per-segment contract in the resolved `MINING_PROMPT.md`. Cache each JSON
+report with `plugin cache-report` and stop on rejection.
+
+Run one strongest-available reducer over only the validated reports and reducer
+contract. Write the complete pack to `pack_path`, validate it, and activate only
+the validated pack with `plugin activate`.
+
+### 5. Verify and report
+
+Run `plugin status`, render the profile card, and report:
+
+- active version and core profile path
+- active and inactive domains
+- selected source tokens and actual worker/reducer passes
+- cache reuse
+- card path
+- any exact targeted-deepen instruction
+
+If the current host already has the native Ditto plugin, do not create a
+competing direct profile installation.
+
+## Examples
+
+### Full-history setup
+
+```text
+User: run ditto on my coding history
+Agent: resolves the pinned runtime, shows the read-only full-history plan, and
+waits for explicit cost approval before starting any mining workers.
+```
+
+### Explicit quick preview
+
+```text
+User: give me a cheap ditto preview first
+Agent: runs preflight with --preview, labels it as a starter profile, and waits
+for approval of the displayed preview plan.
+```
+
+## Best Practices
+
+- Keep raw sessions, caches, receipts, and generated profiles private by default.
+- Report exact observed counts and paths; never estimate provider billing or coverage.
+- Preserve the approval hash and mode through the complete run.
+- Stop on validation failure instead of activating a partial profile.
+- Share the card or a short trait, not the full private profile or receipt appendix.
+
+## Limitations
+
+- Ditto models working behavior; it does not make the underlying model smarter.
+- Sparse or repetitive histories can leave design or writing domains inactive.
+- Provider system prompts, tool traffic, and billing overhead are outside Ditto's exact token accounting.
+- Quick preview has lower recall than the full-history quality default.
+- Automatic work, design, and writing routing requires the upstream native plugin.
+
+## Security & Safety Notes
+
+- This skill does not download executable code; it requires an existing trusted Ditto installation.
+- Extraction, redaction, caches, and generated profiles stay local. Selected redacted text is processed by the model provider the user chooses.
+- Redaction is best-effort. Tell the user to inspect private output before sharing it.
+- Never upload session logs or full profiles to a third party without explicit user approval.
+- Installation itself schedules no mining model calls; every prepared mining mode still requires approval of its displayed plan.
+
+## Common Pitfalls
+
+- **Problem:** No eligible sessions are found.
+
+  **Solution:** Report the supported source locations that were checked and ask whether the user has retained or exported session history.
+
+- **Problem:** The approval hash changed.
+
+  **Solution:** Do not reuse the old approval. Show the updated plan and obtain approval again.
+
+- **Problem:** A cached or reduced report fails validation.
+
+  **Solution:** Stop, preserve the failure evidence, and never activate the incomplete pack.
+
+## Related Skills
+
+- `@agenttrace-session-audit` - Use for cost, latency, failure, and health analysis of coding-agent sessions.
+- `@agent-memory` - Use for explicit persistent knowledge storage rather than evidence-based profile mining.

package/bundled-skills/docs/contributors/quality-bar.md

@@ -47,7 +47,7 @@ A list of known edge cases or things the skill _cannot_ do.
 
 If a skill includes command examples, remote fetch steps, secrets, or mutation guidance, the PR must document the risk and pass `npm run security:docs` in addition to normal validation.
 
-For pull requests that add or modify `SKILL.md`, GitHub also runs the automated `skill-review` workflow. Treat that review as part of the normal PR quality gate and address any actionable findings before merge.
+For pull requests that add or modify `SKILL.md`, GitHub also runs the automated `skill-review` workflow. Treat that review as part of the normal PR quality gate and address any actionable findings before merge. A successful result is reused when a later push has the identical changed-skill content; if Tessl credits are unavailable, the workflow records `manual-review-required` for exact-head maintainer attestation instead of pretending an automated review passed.
 Automated checks are necessary, but they do **not** replace manual reviewer judgment on logic, safety, and likely failure modes.
 
 `npm run security:docs` enforces a repo-wide scan for:

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

@@ -1,9 +1,9 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,958+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,965+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,958+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,965+ skills
 
 This guide shows how to integrate the `agentic-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,958+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,965+ 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 **agentic-awesome-skills** with a Jetski
 - 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,958+ skills installed.
+This pattern avoids context overflow when you have 1,965+ skills installed.
 
 Manifest contract references:
 

package/bundled-skills/docs/maintainers/merge-batch.md

@@ -31,12 +31,13 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 `merge:batch` will:
 
 - refresh the PR body when the Quality Bar checklist is missing
-- close and reopen the PR if stale metadata needs a fresh `pull_request` event
+- record the existing workflow-run generation, then close and reopen the PR if stale metadata needs a fresh `pull_request` event
 - fetch the exact base/head objects and classify the complete raw Git diff
 - recompute changed-skill evidence with evaluator code materialized from the trusted `main` commit
 - reject incomplete evidence coverage, deterministic quality/security/provenance regressions, and base/head drift
-- approve fork runs waiting on `action_required` only when every path, mode, object, size, and workflow identity is allowlisted
-- wait for the fresh required checks on the current head SHA
+- for external PRs, poll for asynchronously-created fork runs and approve only post-reopen runs waiting on `action_required` when every path, mode, object, size, and workflow identity is allowlisted
+- for same-repository maintainer PRs, allow repository-wide source changes while still enforcing trusted changed-skill evidence, exact-head review, required checks, branch protection, and immutable PR identity
+- wait only for check suites belonging to the post-reopen workflow generation; older runs on the same head SHA cannot satisfy or fail the gate
 - call GitHub's immediate squash-merge endpoint and continue only when it reports `merged: true`
 - pull the protected `main`; its trusted workflow opens a canonical-sync bot PR for generated artifacts and contributor credits when needed
 
@@ -44,7 +45,7 @@ Use `--dry-run` to exercise local classification without approving a run or merg
 
 - PR body normalization against the repository template
 - stale PR metadata refresh
-- required-check polling for the current PR head
+- generation-bound required-check polling for the current PR head
 - handoff of post-merge contributor and artifact drift to the canonical-sync PR lane
 
 ## What It Does Not Automate
@@ -64,7 +65,7 @@ Stop and switch to the manual playbook when:
 - the PR is `CONFLICTING`
 - `merge:batch` reports a check failure that needs source changes, not maintainer automation
 - the PR needs a manual README credits decision
-- the local diff contains a symlink, gitlink, executable mode, unknown path/type, oversized blob, or other non-allowlisted change
+- an external PR's local diff contains a symlink, gitlink, executable mode, unknown path/type, oversized blob, or other non-allowlisted change
 - the workflow run cannot be bound to the intended PR number, current head SHA, `pull_request` event, and trusted workflow definition
 - fork approval or branch permissions are missing
 - effective strict protection for `main` cannot be proven

package/bundled-skills/docs/maintainers/pr-autonomy.md

@@ -51,12 +51,12 @@ A successful `manual-review-required` check means only that the requirement was
 
 ## Maintainer Recalculation
 
-`merge:batch` must bind workflow approval and human attestation to one full head SHA. Before approving a waiting fork run, it independently:
+`merge:batch` must bind workflow approval and human attestation to one full head SHA. When it refreshes a PR body by closing and reopening the PR, it also records the pre-refresh workflow-run IDs and accepts checks only from post-refresh check suites. A shared head SHA is not sufficient evidence of freshness because multiple `pull_request` events can exist for the same commit. Before approving a waiting fork run, it independently:
 
 1. captures base and head object IDs;
 2. fetches those objects without checking out pull-request code;
 3. computes a complete NUL-delimited raw Git diff with full object IDs and modes;
-4. rejects unsafe paths, modes, symlinks, gitlinks, executable files, unknown types, oversized blobs, incomplete metadata, or non-allowlisted workflows;
+4. for external PRs, rejects unsafe paths, modes, symlinks, gitlinks, executable files, unknown types, oversized blobs, incomplete metadata, or non-allowlisted workflows;
 5. verifies workflow event, workflow identity, pull-request number, and head SHA;
 6. recomputes changed-skill evidence over the exact merge-base-to-head record set and requires one-to-one coverage of every skill-content Git record;
 7. rejects operational errors, malformed evidence, incomplete snapshots, score-component regressions, provenance identity regressions, or any other deterministic blocker;
@@ -64,6 +64,8 @@ A successful `manual-review-required` check means only that the requirement was
 
 A real merge also requires effective server-side protection for `main`: the four exact GitHub-Actions-owned checks (`pr-policy`, `pr-evidence`, `source-validation`, and `artifact-preview`), strict up-to-date enforcement, pull-request-only changes, administrator enforcement, no applicable ruleset bypass actors, and no merge queue. If that enforcement cannot be proven, `merge:batch` refuses non-dry-run operation. Base drift is never retried with stale evidence; the batch must be rerun from the new tuple. Pre-existing auto-merge state is rejected, and the immediate GitHub merge endpoint must return `merged: true` before post-merge work begins.
 
+Same-repository maintainer PRs may legitimately change repository-wide policy, tooling, workflows, or documentation, so the fork content allowlist does not apply to them. They remain bound to the protected branch, trusted-base evidence evaluator, exact PR/base/head tuple, semantic-review requirements, and required checks. Missing or mismatched head-repository identity is treated as external and therefore fails closed under the fork allowlist.
+
 For canonical `SKILL.md` or allowlisted supporting skill-content changes, the maintainer supplies `--reviewed-head <full-sha>`. A stale, abbreviated, or mismatched SHA fails closed. The Skill Review check itself is required only for `SKILL.md` changes because that workflow is path-filtered; support-only changes still require the exact-SHA human attestation.
 
 Deletions, copies, ambiguous moves, and all canonical skill-content changes remain manual-only in this stage even when deterministic evidence contains no regression. A passing ratchet is not semantic approval and never makes a skill eligible for automatic merge.

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,958+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
+> Installable GitHub library of 1,965+ 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,958+ 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,965+ 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,958+ Agentic Skills`;
+- use a clean preview image that says `1,965+ 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,958+ skills from the skills directory
+- All 1,965+ skills from the skills directory
 
 ## When to Update
 

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

@@ -1060,4 +1060,4 @@ Found a skill that should be in a bundle? Or want to create a new bundle? [Open
 
 ---
 
-_Last updated: June 2026 | Total Skills: 1,958+ | Total Bundles: 58_
+_Last updated: June 2026 | Total Skills: 1,965+ | Total Bundles: 58_

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,958+ skills instead of a narrow single-domain starter pack.
+- It includes 1,965+ 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/faq.md

@@ -423,7 +423,7 @@ Common fixes:
 
 ### My PR triggered the `skill-review` automated check. What is it?
 
-Since v8.0.0, GitHub automatically runs a `skill-review` workflow on any PR that adds or modifies a `SKILL.md` file. It reviews your skill against the quality bar and flags common issues — missing sections, weak triggers, or risky command patterns. The workflow now uses Tessl Review; fork PRs may need maintainer manual review when GitHub withholds repository secrets.
+Since v8.0.0, GitHub automatically runs a `skill-review` workflow on any PR that adds or modifies a `SKILL.md` file. It reviews your skill against the quality bar and flags common issues — missing sections, weak triggers, or risky command patterns. The workflow now uses Tessl Review; fork PRs may need maintainer manual review when GitHub withholds repository secrets. Successful reviews are keyed to the changed skill content, so unrelated pushes and base-branch refreshes reuse the result without spending more Tessl credits. If the monthly credit quota is unavailable, the workflow requests an exact-head maintainer review rather than returning a false automated pass.
 
 **If it reports findings:**
 

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,958+ files.
+- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,965+ 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 Agentic Awesome Skills (V14.4.0)
+# Getting Started with Agentic Awesome Skills (V14.6.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,958+ specialized areas
+- **Domain expertise** across 1,965+ 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 agentic-awesome-skills` or cloned the repository, you:
 
-✅ **Downloaded 1,958+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
+✅ **Downloaded 1,965+ 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,958+ tools (✅ done)
+- You installed a toolbox with 1,965+ 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,958+ skills at once. Here's a sensible approach:
+Don't try to use all 1,965+ 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,958+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
+No. Even though you have 1,965+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
 
 The intended pattern is:
 

package/bundled-skills/docs/users/visual-guide.md

@@ -34,7 +34,7 @@ agentic-awesome-skills/
 ├── 📄 CONTRIBUTING.md                  ← Contributor workflow
 ├── 📄 CATALOG.md                       ← Full generated catalog
 │
-├── 📁 skills/                          ← 1,958+ skills live here
+├── 📁 skills/                          ← 1,965+ skills live here
 │   │
 │   ├── 📁 brainstorming/
 │   │   └── 📄 SKILL.md                 ← Skill definition
@@ -47,7 +47,7 @@ agentic-awesome-skills/
 │   │   └── 📁 2d-games/
 │   │       └── 📄 SKILL.md             ← Nested skills also supported
 │   │
-│   └── ... (1,958+ total)
+│   └── ... (1,965+ total)
 │
 ├── 📁 apps/
 │   └── 📁 web-app/                     ← Interactive browser
@@ -100,7 +100,7 @@ agentic-awesome-skills/
 
 ```
                     ┌─────────────────────────┐
-                    │  1,958+ SKILLS          │
+                    │  1,965+ SKILLS          │
                     └────────────┬────────────┘
                                  │
         ┌────────────────────────┼────────────────────────┐
@@ -201,7 +201,7 @@ If you want a workspace-style manual install instead, cloning into `.agent/skill
 │   ├── 📁 brainstorming/                 │
 │   ├── 📁 stripe-integration/            │
 │   ├── 📁 react-best-practices/          │
-│   └── ... (1,958+ total)                │
+│   └── ... (1,965+ total)                │
 └─────────────────────────────────────────┘
 ```
 

package/bundled-skills/finishing-a-development-branch/SKILL.md

@@ -49,9 +49,11 @@ git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
 
 Or ask: "This branch split from main - is that correct?"
 
+Read `AGENTS.md` and maintainer documentation, then inspect effective protection for the base branch. If pull requests or required checks are enforced, mark local merge as unavailable and use the repository's guarded PR/merge workflow. In `agentic-awesome-skills`, defer maintainer merges to `antigravity-maintainer-batch-release` and `npm run merge:batch`.
+
 ### Step 3: Present Options
 
-Present exactly these 4 options:
+For an unprotected base branch, present exactly these 4 options:
 
 ```
 Implementation complete. What would you like to do?
@@ -66,10 +68,14 @@ Which option?
 
 **Don't add explanation** - keep options concise.
 
+For a protected base branch, do not offer local merge. Present only push/create PR, keep as-is, and discard, while preserving the same confirmation rule for discard.
+
 ### Step 4: Execute Choice
 
 #### Option 1: Merge Locally
 
+Use this option only after proving that repository policy and server-side protection permit local integration into the base branch. Otherwise stop and route through Option 2.
+
 ```bash
 # Switch to base branch
 git checkout <base-branch>