opencode-skills-collection 4.0.0 → 4.0.1

package/bundled-skills/cloudflare-security-audit/references/RECONNAISSANCE.md

@@ -0,0 +1,46 @@
+# Reconnaissance
+
+### Phase 1: Understand the application
+
+Before looking for bugs, understand what you're auditing. This requires depth, not just a directory listing. Launch **multiple `research` agents in parallel** to map different aspects of the codebase:
+
+**Agent 1a: Overview, tech stack, and comparable baseline**
+```
+Explore the codebase at <path>. Answer:
+1. What is this application? What kind of software? (web app, API, CLI tool, library, daemon, desktop app, mobile backend, etc.)
+2. Who uses it and how? (end users, developers, operators, other services)
+3. What's the tech stack? (languages, frameworks, databases, runtime, deployment model)
+4. What comparable mainstream software exists? What security tradeoffs does the comparable accept?
+5. What's the high-level directory structure?
+Return specific file paths for key entry points.
+```
+
+**Agent 1b: Trust boundaries and access control**
+```
+Explore the codebase at <path>. Find and read ALL code related to:
+1. Trust boundaries — where does untrusted input enter the system? (HTTP requests, CLI args, file reads, IPC, message queues, environment variables, config files, etc.)
+2. Authentication — how do callers prove identity? (sessions, tokens, API keys, mTLS, Unix sockets, etc.) If there's no authentication, note that.
+3. Authorization — how are permissions enforced? (middleware, decorators, capability checks, file permissions, etc.) If there's no authorization model, note that.
+4. Privilege separation — does the code run as root? Drop privileges? Use sandboxing? Fork workers?
+5. Any bypass mechanisms (dev-only modes, test helpers, setup flows, debug flags)
+Return the trust model: who are the actors, what can each do by design, and which code enforces it. Include specific file paths and line numbers.
+```
+
+**Agent 1c: Input surface inventory**
+```
+Explore the codebase at <path>. Produce a complete inventory of where external input enters the system:
+1. Network-facing surfaces (HTTP endpoints, gRPC services, WebSocket handlers, TCP/UDP listeners, etc.) — list each with method/verb and purpose
+2. File-based input (file uploads, config file parsing, log ingestion, import/export, etc.)
+3. IPC and inter-service input (message queues, shared memory, Unix sockets, environment variables, CLI arguments)
+4. User-generated content surfaces (anywhere users provide content that is stored and later rendered, served, or processed)
+5. External integrations (OAuth, webhooks, third-party APIs, plugin loading, dynamic code execution)
+6. All places where input reaches dangerous sinks (SQL/query builders, HTML/template output, file paths, shell commands, deserialization, eval, dynamic imports)
+Return specific file paths. Be exhaustive.
+```
+
+Collect all three agents' outputs and synthesize them into `<output-dir>/architecture.md`:
+- 1-2 page structured summary covering application type, tech stack, trust model, input surfaces, and baseline comparable
+- Include the key file paths from all agents — these become the starting points for Phase 2
+- This document is injected verbatim into every Phase 2 agent prompt
+
+If Phase 1 agents reveal the codebase is larger or more complex than expected (e.g., plugin system, multi-tenant architecture, complex auth chains, multiple deployment targets), launch additional `research` agents to map those areas before proceeding. The quality of Phase 2 depends entirely on the quality of Phase 1.

package/bundled-skills/cloudflare-security-audit/references/VALIDATION-AND-REPORTING.md

@@ -0,0 +1,109 @@
+# Validation, Reporting, and Verification
+
+### Phase 3: Validate findings
+
+Collect all findings from Phase 2 agents and **consolidate duplicates first**. Phase 2 deliberately overlaps agent scopes, so the same issue is frequently reported by more than one hunter — merge findings that share a root cause before validating, or you'll validate and report the same bug multiple times. For each remaining finding, launch a **separate `research` validation agent** that tries to disprove it. The hunting agents are biased toward finding things; the validation agents are biased toward killing false positives. This adversarial step is critical.
+
+For findings from the same attack surface, batch them into one validation agent. Launch validation agents in parallel where they cover independent areas.
+
+Each validation agent prompt should:
+1. State the specific finding being validated (title, claimed attack, claimed impact)
+2. Ask the agent to read the exact code paths and verify each step of the trace
+3. Ask it to apply these tests (the adversarial, Phase 3 form of the canonical validation rules in [HUNTING.md](HUNTING.md) — here a separate agent tries to make each one fail):
+
+**Validation tests:**
+1. **Exploitation test**: Read the actual code at each step of the trace. Does the data flow work as claimed? Can you construct the exact input (HTTP request, CLI invocation, API call, crafted file, etc.) that triggers this?
+2. **Impact test**: What does the attacker actually get? If the answer is "they learn field names" or "they cause an error", that's not meaningful impact — not a finding on its own (at most a building block for a chain).
+3. **Baseline test**: Does the identified comparable have the same pattern? If yes, has it been exploited? If never exploited in years of production use, understand why before reporting.
+4. **Mitigation test**: Is there another layer that prevents exploitation? Check middleware, database constraints, framework defaults.
+5. **Parser/runtime behavior test**: If the exploit depends on how a parser or runtime handles specific input, verify against the actual spec or implementation — do not reason from intuition.
+
+Tell each validation agent:
+
+```
+Your job is to DISPROVE this finding. Read the actual source code at every step. If you cannot disprove it, confirm it with the exact code that makes it exploitable. Return one of:
+- "CONFIRMED: [explanation of why it's real, with code evidence]"
+- "REJECTED: [explanation of what the finding got wrong, with code evidence]"
+```
+
+**Kill false positives aggressively, but don't kill real findings.** A short report with 3 real findings is worth more than a long report with 30 theoretical ones. An honest "nothing found" is valid — but push hard before reaching that conclusion.
+
+### Phase 4: Report
+
+Write the report to the output directory established in Setup.
+
+**Output files:**
+
+1. `REPORT.md` -- Main report with:
+   - One-paragraph executive summary (honest assessment of security posture)
+   - Identified baseline and how this application compares
+   - Findings table (severity, title, one-line description)
+   - Each finding with: file path, concrete attack scenario, impact, recommended fix
+   - Hardening notes section (defense-in-depth suggestions, NOT findings)
+   - Positive patterns section (what the codebase does well -- this calibrates trust in the audit)
+
+2. `FINDINGS-DETAIL.md` -- For each finding rated MEDIUM or above:
+   - Complete data flow from input to sink with file:line references
+   - Exact HTTP request(s) to trigger
+   - What the attacker gets
+   - How the baseline comparable handles the same scenario
+
+Keep it short. If the report is longer than the codebase deserves, you're padding.
+
+### Phase 5: Structured output and schema check
+
+For every finding that survived Phase 3 validation, produce a structured JSON object conforming to the schema defined in `../resources/report-schema.json` (read it via the Read tool before writing output). Write the result to `<output-dir>/findings.json`.
+
+The schema supports two verdict types via `oneOf`:
+- **`confirmed`** — a validated vulnerability with full trace, execution, and remediation
+- **`rejected`** — a finding that was investigated and determined to be factually incorrect
+
+**Before writing `findings.json`:**
+
+1. Read `../resources/report-schema.json`. Follow it exactly — `additionalProperties: false` is enforced, so extra fields will make the output invalid.
+2. For each finding, populate every required field. If you cannot fill `trace` with real file paths and line numbers verified against the source, the finding is not sufficiently verified — go back and verify it or reject it. Mind the required fields that aren't self-evident: `intended_behavior` (what the code is *supposed* to do, so the defect is legible), `confidence` (`low`/`medium`/`high`, with a reason), and the `severity` object (`likelihood`/`impact`/`overall_severity`). All `severity` scores use the schema's **lowercase** enum — `informational`/`low`/`medium`/`high`/`critical`; the UPPERCASE tiers in SKILL.md and REPORT.md are prose labels, not valid JSON values.
+3. Validate `<output-dir>/findings.json` against `../resources/report-schema.json` with a trusted JSON Schema validator already available in the user's environment. Do not install or execute a new validator without approval. This is a structural check only — it confirms the JSON conforms to the schema, not that the findings are correct. Factual verification is Phase 6's job. Fix any failures before proceeding.
+
+### Phase 6: Independent verification
+
+The structured output from Phase 5 forces self-validation, but the same agent that wrote the finding also wrote the JSON — it won't catch its own blind spots. This phase uses a fresh agent to independently verify every claim in `findings.json`.
+
+Launch **one `research` agent per confirmed finding** via the Task tool, all in parallel. Each agent gets exactly one finding from `findings.json` and verifies it independently. Give each agent the JSON object for its finding and this prompt:
+
+```
+You are an independent verifier. You did NOT write this finding. Your job is to read the actual source code and verify that every factual claim is correct.
+
+1. Read the file and line number cited in EVERY trace step. Verify:
+   - The file exists at that path
+   - The line number matches the described code
+   - The scope (function name) is correct
+   - The description accurately reflects what the code does
+
+2. Verify the root_cause statement by reading the cited file and confirming the described defect exists.
+
+3. Verify the execution payloads would actually work, in terms that fit the target:
+   - Does the entry point exist as claimed — the endpoint/URL, CLI command, exported function, syscall/ioctl, message handler, or tool the attacker invokes?
+   - Does the invocation match — HTTP method, argument shape, call signature, or message format?
+   - Would the input survive validation and parsing on the real code path?
+   - Would the relevant authentication, authorization, or ownership check pass as described?
+
+4. Verify conditions are complete — are there prerequisites the finding missed?
+
+5. Check the remediation code_changes — would the fix actually prevent the attack without breaking normal functionality?
+
+6. Verify `intended_behavior` accurately states what the code should do, and that `confidence` matches the strength of the evidence — don't leave `high` on a claim you couldn't fully trace.
+
+Return one of:
+- "VERIFIED" — all claims checked out against the source
+- "CORRECTED: [field]: [what was wrong] → [what it should be]" — factual error in a specific field
+- "REJECTED: [reason]" — the finding is fundamentally wrong
+```
+
+Apply the agent's corrections:
+- **VERIFIED** findings: no changes needed
+- **CORRECTED** findings: update the specific fields in `findings.json`, re-run the schema validation script
+- **REJECTED** findings: change their `verdict` to `"rejected"` with the agent's reason, or remove them entirely
+
+After applying corrections, reconcile the prose deliverables: update `REPORT.md` and `FINDINGS-DETAIL.md` so they match the final `findings.json`. Remove or amend any finding the verification gate rejected or corrected — the human-readable report and the machine-readable output must not disagree.
+
+This is the final quality gate. Do not skip it.

package/bundled-skills/cloudflare-security-audit/references/WEB-PROTOCOL-AND-AUTH.md

@@ -0,0 +1,85 @@
+# HTTP-Protocol and Authentication Hunting
+
+#### When to use this file
+
+Reach for this file when the target speaks HTTP at a layer where parsing, caching, or identity decisions happen: reverse proxies, CDNs, API gateways, load balancers, custom HTTP servers and parsers, and any app that builds responses or URLs from request metadata — and whenever it implements or consumes an auth protocol (sessions, JWTs, OAuth/OIDC, SAML, or password-reset flows). These are the classes `ATTACK-CLASSES.md` treats only in passing: the injection class covers *content*, but not the request/response framing or the identity-token machinery, which have their own specific, high-hit-rate bug patterns.
+
+Use alongside `ATTACK-CLASSES.md`. Access control there answers "is the check present and correct"; this file answers "can the attacker forge, replay, or confuse the identity the check runs on, or desync the request the check applies to."
+
+Pick the relevant classes based on Phase 1; split per subsystem (framing/proxy layer, token verification, session store) for large targets. A pure single-server app behind a managed CDN has little smuggling surface; a custom proxy or a service that trusts `X-Forwarded-*` has a lot.
+
+## Core discipline (include in every agent prompt for this domain)
+
+```
+- Framing bugs live in DISAGREEMENT, not in one parser. Request smuggling and cache poisoning exist because two components interpret the same bytes differently. Find the two components and the byte they disagree on; a single correct parser in isolation is not the finding.
+- A signature you don't verify is decoration. For every token (JWT, SAML, cookie), find the exact line that verifies the signature AND the claims that apply to that token type (for JWT/OIDC: exp, aud, iss, nonce) — and that the algorithm is pinned server-side, not read from the token header. "It's signed" means nothing if nothing checks the signature with the right key and algorithm.
+- Every use of Host, X-Forwarded-*, Forwarded, or a request-derived URL is a trust decision. Trace it to what it controls: a reset link, a cache key, a redirect, an access check.
+- Reflected input in a security-relevant response field (Set-Cookie, Location, cache key, an absolute URL sent to a victim) — trace it to a cross-user impact (poisoned cache entry, redirect or token sent to a victim, cookie set in another context) even when it isn't classic XSS.
+```
+
+## HTTP request-framing attack classes (subagent_type: `general`)
+
+**Request smuggling / desync**
+A discrepancy in how two components (front proxy vs back-end, or HTTP/2 front vs HTTP/1.1 back) resolve message length. Classic forms: CL.TE, TE.CL, TE.TE (obfuscated `Transfer-Encoding`), and H2 downgrade (H2.CL / H2.TE) where an HTTP/2 front-end forwards to an HTTP/1.1 back-end and the injected `Content-Length`/`Transfer-Encoding` or CRLF in a header value survives. Audit angle: any component that parses HTTP messages itself, forwards requests, or normalizes headers. Look for lenient length handling (accepting both CL and TE, tolerating whitespace/casing/duplicates in `Transfer-Encoding`), and CRLF-in-header-value passthrough on the HTTP/2→1.1 hop. The prize is a request prefix that gets glued onto the *next* user's request.
+
+**Web cache poisoning (unkeyed input)**
+An input influences the response but is not part of the cache key, so the attacker's response is stored and served to others. Find the cache key construction, then find every input that changes the response body/headers but is absent from that key — `X-Forwarded-Host`, `X-Forwarded-Scheme`, custom headers, cookies stripped from the key, or a query param the key normalizes away. Reflected unkeyed input that lands in the cached body (a poisoned script src, an `<base href>` from `X-Forwarded-Host`) is stored XSS against every cache consumer.
+
+**Cache deception**
+Path/extension confusion that makes a dynamic, per-user page get cached as if it were a static asset (`/account/profile.css`, `/api/me;.js`, path-parameter tricks). The back-end serves the user's private page; the cache stores it under a path the attacker can then request. Trace how the cache decides "is this cacheable" versus how the app routes the path — the gap is the bug.
+
+**Host-header and forwarded-header trust**
+`Host` / `X-Forwarded-Host` used to build absolute URLs, routing, or cache keys. The highest-impact sink is password-reset / verification link construction: attacker sets the header, the victim receives a link to the attacker's domain, clicks, and leaks the token. Also: authentication or routing decisions keyed on a spoofable forwarded header.
+
+**CRLF / response header injection**
+User input reflected into a response header (`Location`, `Set-Cookie`, custom headers) with unescaped CR/LF, letting the attacker inject headers or split the response. Trace user input into any header-setting call; confirm the framework doesn't already strip CR/LF (many do — verify first, see #5).
+
+## Authentication-protocol attack classes (subagent_type: `general`)
+
+First establish which role the target plays — it determines whose duty each control is. `redirect_uri` allowlisting, PKCE enforcement, authorization-code issuance, and assertion signing belong to the **authorization server / IdP**; a **relying-party client** legitimately sends its own `redirect_uri` and consumes tokens, so do not report "no `redirect_uri` allowlist" or "issues codes without PKCE" against a client. Token *verification* defects (below) apply to whichever side validates the token.
+
+**JWT verification defects**
+The densest source of auth bypasses. Check, in the verification code:
+- **`alg` confusion** — `alg: none` accepted, or RS256→HS256 where the server verifies an attacker-forged HS256 token using the *public* key as the HMAC secret. Find where the algorithm is chosen: is it taken from the token header (attacker-controlled) or pinned server-side?
+- **Decode without verify** — code that reads claims from a decoded token but never calls the verify function, or ignores its return/exception.
+- **Missing claim checks** — `exp` (expiry), `nbf`, `aud` (audience — token for service A replayed at service B), `iss` (issuer). A signature check without claim checks is half a check.
+- **Key-selection injection** — `kid`, `jku`, or `x5u` header taken from the token: `kid` used in a file path (traversal) or SQL (injection) to fetch the key, or `jku` pointing at an attacker-hosted JWK Set / `x5u` at an attacker-hosted X.509 cert chain. Attacker names the key that verifies their own forgery.
+- **Weak/shared secret** — HMAC secret that's a guessable string or shared across trust domains.
+
+**OAuth / OIDC flow defects**
+- **`redirect_uri` validation** — substring/prefix matching, open-redirect on an allowlisted host, or `redirect_uri` not bound to the client. Leaks the authorization code to the attacker.
+- **Missing/weak `state`** — no CSRF token on the callback → login CSRF / forced-login / session fixation of the OAuth flow. (`state` is a session-binding/CSRF control; authorization-code injection is prevented by PKCE and the OIDC `nonce`, not by `state` — don't conflate them.) Confirm `state` is generated, bound to the session, and verified on return.
+- **PKCE** — missing on public clients, or `code_verifier` not actually checked against `code_challenge`.
+- **`id_token` validation** — audience, issuer, signature, and `nonce` all verified? A token minted for another client accepted here is account takeover.
+- **Mix-up / IdP confusion** — multi-IdP flows where the response isn't bound to the IdP the request went to.
+
+**SAML assertion defects**
+- **Signature wrapping (XSW)** — a signed assertion plus an injected unsigned one; the verifier checks the signature on one element but reads identity from another. Find the gap between "what is signature-verified" and "what is read as the authenticated identity."
+- **Signature exclusion** — unsigned assertions accepted, or signature verification skippable via a flag/empty-signature path.
+- **XXE / DTD** in the XML parser processing assertions.
+- **Comment truncation** — a comment inserted into the signed NameID (`admin@company.com<!---->.attacker.com`) that canonicalization strips before the signature check (so it still validates) but that truncates identity extraction to the pre-comment text (`admin@company.com`, the victim). Same root as XSW: the bytes the signature covers ≠ the bytes read as identity.
+- **Missing replay / binding checks** — even with a valid signature, is the assertion bound and fresh? Check `NotBefore`/`NotOnOrAfter` (validity window), `Recipient`/`Audience` (assertion minted for *this* SP, not replayed from another), `InResponseTo` (bound to a real outstanding request — blocks unsolicited-response injection), and one-time-use (a replayed assertion rejected). The signature checks above prove the assertion wasn't forged; these prove it wasn't stolen and replayed.
+
+**Session-management defects**
+- **Fixation** — session identifier not rotated on privilege change (login, step-up auth). Attacker fixes a known ID, victim authenticates into it.
+- **Weak invalidation** — session/token still valid after logout, password change, or revocation; server-side state not cleared (especially stateless JWT sessions with no revocation list).
+- **Predictable identifiers** (non-CSPRNG session IDs an attacker can guess/derive), or an overly broad cookie `Domain` that leaks the session cookie to an attacker-controlled sibling subdomain. (Bare "cookie could be shorter-lived" with no leakage path is a hardening note, not a finding.)
+
+**Password-reset / account-recovery defects**
+- Token not cryptographically bound to the user (reset A's token, use it on B), predictable/short token, no single-use or expiry, token leaked via `Host` header (see above) or `Referer`, or a race that mints multiple valid tokens. Recovery flows are frequently the weakest path to the strongest impact (account takeover).
+
+## Universal moves (apply across the above)
+
+- **Diff duplicated request paths side by side.** Where the code has more than one thing that parses or forwards HTTP (a middleware plus the framework, a normalizer plus the router, a legacy API version plus the current one), read them together and feed each the same ambiguous bytes on paper. Divergence is the smuggling/desync bug.
+- **Walk the whole token lifecycle.** Issue → store → transmit → verify → refresh → revoke. The bugs live in the transitions the happy path skips: a session still valid after logout, a refresh that never re-checks revocation, a reset token that survives a password change.
+- **Enumerate every door to the same identity.** SSO, password login, API key, password reset, impersonation — each is a parallel path that mints a session. The weakest one sets the account's real security; a hardened login means nothing if reset is trivial.
+- **Audit the compat/fallback path.** A legacy endpoint version, a deprecated header, or a "for old clients" branch that skips a guard the main path added. Old auth code is where the reverted or forgotten check hides.
+
+## Validation rules (apply before reporting ANY finding here)
+
+1. **Source-visibility gate — this domain lives partly outside the repo.** Framing bugs (proxy chain), cache poisoning/deception (cache-key config), secret strength, and token entropy frequently depend on components, config, or values NOT in the audited tree. If confirming the bug requires a component/config/secret you cannot read, it is **unverifiable from source: flag it "requires deployment testing" and do NOT report it as a confirmed finding.** "Downgrade" is not enough — an unconfirmable HIGH reported as a MEDIUM is still a false positive.
+2. **For framing/cache findings, name both components and the divergent parse.** "The Go net/http back-end accepts a bare-LF `Transfer-Encoding` that the front proxy treats as CL" — not "smuggling may be possible." A single server with no proxy in front has no smuggling surface. If you've confirmed only the in-repo half (the back-end genuinely mishandles a specific ambiguous input — bare-LF `Transfer-Encoding`, duplicate CL), record it as a lead with the exact bytes — "requires paired front-end testing" — a real observation, not a severity-rated finding.
+3. **For token findings, cite the verification line and what it fails to check.** Point at the `verify`/`decode` call and the missing `alg` pin / `aud` check / signature step. A forged-token claim requires showing the server would accept the forgery, not just that JWTs are in use. Establish the client-vs-server role first — don't fault a client for controls the server owns.
+4. **Prove the cross-user impact.** Show the payload reaching a victim's response (cache), request (smuggling), session (fixation), or inbox (reset link). Attacker-only effects are not findings: a `Host` header reflected into a self-referential link the victim never receives out-of-band is a hardening note; a `Host` header controlling a reset link emailed to the victim is a finding.
+5. **Verify the framework AND the library default don't already handle it.** Many stacks strip CR/LF from headers, rotate sessions on login, and key caches on `Host` by default; JWT libraries increasingly reject `alg:none` and require an explicit algorithm list — check the library and version, and if you cannot determine the default, treat it as unverifiable rather than assuming it's vulnerable. Only report secret/RNG weakness when the code itself sets a hardcoded/short/derivable value or uses a non-CSPRNG. Confirm the specific defense is absent — do not report a gap the framework or library already closes.
+6. **Return ONLY confirmed findings** with the divergent parse or the skipped verification step and the cross-user impact — or "No exploitable protocol/auth issues found" if that's honest.

package/bundled-skills/cloudflare-security-audit/resources/report-schema.json

@@ -0,0 +1,210 @@
+{
+  "$comment": "Single source of truth for findings.json structure (see SKILL.md Phase 5). Validate findings directly against this schema so there is no second copy of these rules to keep in sync.",
+  "output_schema": {
+    "oneOf": [
+      {
+        "type": "object",
+        "description": "Confirmed vulnerability — provide the complete, independently verified report.",
+        "properties": {
+          "verdict": {
+            "type": "string",
+            "const": "confirmed"
+          },
+          "title": {
+            "type": "string",
+            "description": "A concise, standard title for the vulnerability."
+          },
+          "description": {
+            "type": "string",
+            "description": "Comprehensive explanation of the vulnerability. Include any reproduction details (proof-of-concept input, configuration, observed output or crash) here."
+          },
+          "root_cause": {
+            "type": "string",
+            "description": "One sentence using the template: '[function_or_component] in [file] does not [missing action], allowing [consequence]'. MUST include the function/component name and file name where the defect exists."
+          },
+          "intended_behavior": {
+            "type": "string",
+            "description": "What was the developer trying to build? Explain the intended, non-vulnerable business logic."
+          },
+          "trace": {
+            "type": "array",
+            "minItems": 2,
+            "items": {
+              "type": "object",
+              "properties": {
+                "kind": {
+                  "type": "string",
+                  "enum": ["entrypoint", "propagation", "sink"]
+                },
+                "file": {
+                  "type": "string",
+                  "description": "Exact file path relative to repository root."
+                },
+                "line": {
+                  "type": "integer"
+                },
+                "scope": {
+                  "type": "string",
+                  "description": "Bare function or method name. No parentheses, no arguments."
+                },
+                "description": {
+                  "type": "string",
+                  "description": "Factual description of the state change or data movement."
+                }
+              },
+              "required": ["kind", "file", "line", "scope", "description"],
+              "additionalProperties": false
+            },
+            "description": "Sequential code trace from entrypoint to sink, verified against actual source code. The first step must be kind 'entrypoint', the last must be kind 'sink', and any intermediate steps must be kind 'propagation' (enforced by the validator)."
+          },
+          "conditions": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "properties": {
+                "kind": {
+                  "type": "string",
+                  "enum": ["authentication_level", "authorization_role", "user_interaction", "system_configuration", "network_routing", "environmental_dependency", "data_state", "timing_dependency", "third_party_dependency"]
+                },
+                "description": {
+                  "type": "string"
+                }
+              },
+              "required": ["kind", "description"],
+              "additionalProperties": false
+            },
+            "description": "Factual prerequisites for exploitation. Empty array if exploitable by default."
+          },
+          "execution": {
+            "type": "object",
+            "properties": {
+              "attacker_perspective": {
+                "type": "string",
+                "description": "Who is the attacker and their starting point."
+              },
+              "payloads": {
+                "type": "array",
+                "items": {
+                  "type": "string"
+                },
+                "description": "Specific malicious inputs, HTTP requests, or scripts."
+              },
+              "instructions": {
+                "type": "array",
+                "items": {
+                  "type": "string"
+                },
+                "description": "Linear array of all attacker actions from setup through exploitation."
+              },
+              "expected_result": {
+                "type": "string",
+                "description": "Observable outcome confirming successful exploitation."
+              }
+            },
+            "required": ["attacker_perspective", "payloads", "instructions", "expected_result"],
+            "additionalProperties": false
+          },
+          "remediation": {
+            "type": "object",
+            "properties": {
+              "strategy": {
+                "type": "string",
+                "description": "High-level explanation of the fix."
+              },
+              "code_changes": {
+                "type": "array",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "file_name": {
+                      "type": "string"
+                    },
+                    "fixed_code": {
+                      "type": "string"
+                    }
+                  },
+                  "required": ["file_name", "fixed_code"],
+                  "additionalProperties": false
+                }
+              }
+            },
+            "required": ["strategy"],
+            "additionalProperties": false
+          },
+          "severity": {
+            "type": "object",
+            "properties": {
+              "likelihood": {
+                "type": "object",
+                "properties": {
+                  "score": {
+                    "type": "string",
+                    "enum": ["informational", "low", "medium", "high", "critical"]
+                  },
+                  "reason": {
+                    "type": "string"
+                  }
+                },
+                "required": ["score", "reason"],
+                "additionalProperties": false
+              },
+              "impact": {
+                "type": "object",
+                "properties": {
+                  "score": {
+                    "type": "string",
+                    "enum": ["informational", "low", "medium", "high", "critical"]
+                  },
+                  "reason": {
+                    "type": "string"
+                  }
+                },
+                "required": ["score", "reason"],
+                "additionalProperties": false
+              },
+              "overall_severity": {
+                "type": "string",
+                "enum": ["informational", "low", "medium", "high", "critical"]
+              }
+            },
+            "required": ["likelihood", "impact", "overall_severity"],
+            "additionalProperties": false
+          },
+          "confidence": {
+            "type": "object",
+            "properties": {
+              "score": {
+                "type": "string",
+                "enum": ["low", "medium", "high"]
+              },
+              "reason": {
+                "type": "string",
+                "description": "Why you scored the confidence this way. Mention any missing files, complex routing, or ambiguous data flows."
+              }
+            },
+            "required": ["score", "reason"],
+            "additionalProperties": false
+          }
+        },
+        "required": ["verdict", "title", "description", "root_cause", "intended_behavior", "trace", "conditions", "execution", "remediation", "severity", "confidence"],
+        "additionalProperties": false
+      },
+      {
+        "type": "object",
+        "description": "Rejected finding — the described behavior is factually incorrect or the code path does not exist.",
+        "properties": {
+          "verdict": {
+            "type": "string",
+            "const": "rejected"
+          },
+          "reason": {
+            "type": "string",
+            "description": "Explain which specific claims in the finding are factually wrong (e.g., code path doesn't exist, mitigation prevents the described flow, trace is incorrect)."
+          }
+        },
+        "required": ["verdict", "reason"],
+        "additionalProperties": false
+      }
+    ]
+  }
+}

package/bundled-skills/comfyui-gateway/references/troubleshooting.md

@@ -963,7 +963,7 @@ has expired" }`.
 
 ```bash
 # 1. Decode the JWT to check expiration (without verification)
-echo "<your-token>" | cut -d'.' -f2 | base64 -d 2>/dev/null | jq '.exp'
+echo "<your-token>" | cut -d'.' -f2 | base64 -d 2>/dev/null | jq '.exp' # security-allowlist: local JWT inspection, no code execution
 
 # 2. Compare with current time
 date +%s

package/bundled-skills/commit/SKILL.md

@@ -22,7 +22,7 @@ Before committing, always check the current branch:
 git branch --show-current
 ```
 
-**If you're on `main` or `master`, you MUST create a feature branch first** — unless the user explicitly asked to commit to main. Do not ask the user whether to create a branch; just proceed with branch creation. The `create-branch` skill will still propose a branch name for the user to confirm.
+**If you're on `main` or `master`, you MUST create a feature branch first** — unless the user explicitly asked to commit to main and the server permits direct pushes. A user request does not bypass protected-branch rules; when the remote rejects direct updates, use the repository's required pull-request path. Do not ask the user whether to create a branch; just proceed with branch creation. The `create-branch` skill will still propose a branch name for the user to confirm.
 
 Use the `create-branch` skill to create the branch. After `create-branch` completes, verify the current branch has changed before proceeding:
 
@@ -168,5 +168,6 @@ Reason: Caused performance regression in production.
 
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
+- Direct-to-main instructions remain subordinate to server-side branch protection and required checks.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
 - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

package/bundled-skills/deepapi/SKILL.md

@@ -24,13 +24,13 @@ version: b17ad5148ab7
 
 Use this skill when the user asks you to scrape public web data or draft/read/send email through DeepAPI.
 
-## Staying Up To Date
+## Version Pinning
 
-- Your installed copy's version is the `version` value in the frontmatter above.
-- If a request fails unexpectedly, fetch https://deepapi.co/deepapi-skill/VERSION.txt — public, no auth, a few bytes.
-- If it differs from this file's version, fetch https://deepapi.co/deepapi-skill/SKILL.md and overwrite this file with it.
-- Every API response includes `skillVersion`. If it differs from this file's version, refresh the same way.
-- Only ever fetch this skill from https://deepapi.co.
+- The installed copy is pinned to the `version` value in the frontmatter above.
+- If a request or API response reports a different `skillVersion`, report the mismatch and
+  stop. Do not fetch, overwrite, or otherwise self-update this `SKILL.md`.
+- Updates must arrive through the reviewed repository release process, with explicit user
+  approval for any package or repository update.
 
 ## Required Environment
 

package/bundled-skills/docs/README.md

@@ -10,7 +10,7 @@
 - [`users/codex-cli-skills.md`](users/codex-cli-skills.md)
 - [`users/gemini-cli-skills.md`](users/gemini-cli-skills.md)
 - [`users/ai-agent-skills.md`](users/ai-agent-skills.md)
-- [`users/antigravity-awesome-skills-vs-awesome-claude-skills.md`](users/antigravity-awesome-skills-vs-awesome-claude-skills.md)
+- [`users/agentic-awesome-skills-vs-awesome-claude-skills.md`](users/agentic-awesome-skills-vs-awesome-claude-skills.md)
 - [`users/best-claude-code-skills-github.md`](users/best-claude-code-skills-github.md)
 - [`users/best-cursor-skills-github.md`](users/best-cursor-skills-github.md)
 - [`users/bundles.md`](users/bundles.md)

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

@@ -1,6 +1,6 @@
 # 🏆 Quality Bar & Validation Standards
 
-To transform **Antigravity Awesome Skills** from a collection of scripts into a trusted platform, every skill must meet a specific standard of quality and safety.
+To transform **Agentic Awesome Skills** from a collection of scripts into a trusted platform, every skill must meet a specific standard of quality and safety.
 
 ## The "Validated" Badge ✅
 

package/bundled-skills/docs/contributors/security-guardrails.md

@@ -1,6 +1,6 @@
 # 🛡️ Security Guardrails & Policy
 
-Antigravity Awesome Skills is a powerful toolkit. With great power comes great responsibility. This document defines the **Rules of Engagement** for all security and offensive capabilities in this repository.
+Agentic Awesome Skills is a powerful toolkit. With great power comes great responsibility. This document defines the **Rules of Engagement** for all security and offensive capabilities in this repository.
 
 ## 🔴 Offensive Skills Policy (The "Red Line")
 

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

@@ -1,11 +1,11 @@
 ---
 title: Jetski/Cortex + Gemini Integration Guide
-description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,935+ skills."
+description: "Use agentic-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,958+ skills."
 ---
 
-# Jetski/Cortex + Gemini: safe integration with 1,935+ skills
+# Jetski/Cortex + Gemini: safe integration with 1,958+ 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**.
+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**.
 
 The common error seen in Jetski/Cortex is:
 
@@ -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,935+ skills, this approach fills the context window before user messages are even added, causing truncation.
+With 1,958+ skills, this approach fills the context window before user messages are even added, causing truncation.
 
 ---
 
@@ -277,4 +277,4 @@ To prevent recurrence:
 - Load skills **on demand** based on `@skill-id`.
 - Set clear limits (max skills per turn, token threshold).
 
-Following this pattern, Jetski/Cortex + Gemini can use the full `antigravity-awesome-skills` library safely, at scale, and within modern model context-window limits.
+Following this pattern, Jetski/Cortex + Gemini can use the full `agentic-awesome-skills` library safely, at scale, and within modern model context-window limits.

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

@@ -1,6 +1,6 @@
 # Jetski + Gemini Lazy Skill Loader (Example)
 
-This example shows one way to integrate **antigravity-awesome-skills** with a Jetski/Cortex‑style agent using **lazy loading** based on `@skill-id` mentions, instead of concatenating every `SKILL.md` into the prompt.
+This example shows one way to integrate **agentic-awesome-skills** with a Jetski/Cortex‑style agent using **lazy loading** based on `@skill-id` mentions, instead of concatenating every `SKILL.md` into the prompt.
 
 > This is **not** a production‑ready library – it is a minimal reference you can adapt to your own host/agent implementation.
 
@@ -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,935+ skills installed.
+This pattern avoids context overflow when you have 1,958+ skills installed.
 
 Manifest contract references:
 
@@ -53,7 +53,7 @@ import {
   Message,
 } from "./loader.mjs";
 
-const REPO_ROOT = "/path/to/antigravity-awesome-skills";
+const REPO_ROOT = "/path/to/agentic-awesome-skills";
 const SKILLS_ROOT = REPO_ROOT;
 const INDEX_PATH = path.join(REPO_ROOT, "skills_index.json");