
Open Images For Free Use
Source hero, blog, deck, and UI images with licenses confirmed from embedded metadata before you paste a URL into your site or app.
Install
npx skills add https://github.com/peter-duffy95/open-images-for-free-use-skill --skill open-images-for-free-useWhat is this skill?
- Two required stages: pick from a curated, revision-pinned image set then verify license
- Reads license from each image’s embedded metadata against bundled machine-readable terms
- Triggers on any photo, illustration, banner, hero, or visual asset request
- Designed so the licensing question is answered before the agent returns a URL
- One-stop flow for websites, presentations, blog posts, and marketing assets
Adoption & trust: 1 installs on skills.sh; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
Recommended Skills
Journey fit
Build is the canonical shelf because solo builders most often install this when they need visuals for landing pages, product UI, or docs—not before they have something to ship. Frontend covers hero banners, marketing sections, and interface imagery where licensing mistakes are costly and time-sensitive.
Common Questions / FAQ
Is Open Images For Free Use safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Open Images For Free Use
# Open-License Images This is the one-stop way to source an image for any use case — UI hero, blog post, presentation, document, marketing asset — without ever wondering whether it's safe to use. It draws from a curated repository of pre-vetted images and checks each one's license against bundled, machine-readable license terms. By the time the skill hands back a URL, the licensing question is already answered. There are two stages: **pick an image** and **verify its license**. Both are required — even though the source is curated, the license check is the contractual ground truth, and it's what makes this skill safe to trust. > **Why this is safe to install (for reviewers):** > - **No third-party free text reaches the agent at runtime.** The catalog (`./index.json`) is shipped *inside* the skill and reviewed like any other bundled file. The only thing fetched at runtime is the selected image's bytes, and the *only* value extracted from them is a license identifier that is immediately **allow-listed against a fixed set of eight known IDs** — it cannot carry arbitrary text into context, and it can never name a path. Raw image bytes / `strings` output are never printed. > - **Fetches are pinned to an immutable commit SHA (`e40900d`), not a moving branch.** The bytes at a given SHA cannot change, so what was reviewed is what ships — a moving `main` is exactly the "external content changes under you" risk that pinning removes. > - **The license verdict is grounded, not assumed.** It comes from the image's own embedded metadata (the source's TOS makes that the authoritative declaration), resolved to a license file shipped inside this skill. The images at the pinned revision were individually license-reviewed by the author. > - **Release-time invariant:** when you bump the pinned SHA to add images, re-ship the matching `./index.json` from that SHA *and* re-review both the new licenses and the new catalog entries — the "pre-vetted" guarantee is only honest for a SHA whose contents you have actually checked. ## Pick an image The catalog is **shipped with this skill** as `./index.json` — it is not fetched at runtime. It is a JSON array; each entry has a `name` (the image filename) and a `keywords` array describing the image. Because it travels inside the skill, it is reviewed content, just like the license files — no outsider-authored free text enters the agent's context at runtime. The catalog is treated as a *suggestion only*: it tells the skill which image to fetch, but the license verdict comes from the image file itself, and that verdict is allow-listed (see below) before it can affect anything. So no value the catalog supplies is ever used as a path or trusted blindly. Read the local catalog directly — do not pre-filter with a keyword query. Look at the full list, then pick the entry whose `name` and `keywords` most closely match the user's intent (consider what the image will be used for — hero banner, blog header, illustration, portrait — not just the literal subject). Use judgment, not substring matching. ```bash jq . ./index.json ``` If nothing in the catalog feels like a good fit, pick the closest availa