bggg-skills: a Codex skill collection for image, video and data pipelines

What bggg-skills actually is: a directory of Codex skills, not a library

The repository is a collection of Codex skills published by BGGG. Each skill is a self-contained directory, and the README states that a skill can be copied or symlinked into ~/.codex/skills/ to be used. There is no single package to install and no shared runtime: the unit of distribution is the directory.

The scope is narrower than the name suggests, but in a useful way. The current skills split into three groups. Creative conversion covers bggg-creator-image2psd (images to editable layered PSD, with Codex/imagegen-assisted layer splitting, full-canvas PNG layer export, color separation, white-to-transparent conversion, and pure Python PSD writing) and bggg-creator-image2ppt (images, screenshots, HTML or SVG designs to editable PPTX, with component rebuilding, text box restoration and native shape reconstruction). TikTok work covers search, download, readvideo, cut and capcut, plus a larger tiktok-gemini-video-workflow. Data collection covers Amazon comments, Reddit search results and comment trees, and X posts, with sif-keyword-scout and sif-keyword-tracker handling Amazon Sif keyword tables and reports.

The audience is therefore specific: people who already use Codex and want a starting point for media conversion or social data collection, rather than Python developers looking for an importable module. The README also invites contributions and gives a recommended skill layout, so the collection is meant to grow.

How a skill is structured and how Codex picks it up

The repository layout is the mechanism. A skill directory typically contains SKILL.md, README.md, README_EN.md, scripts/, references/, assets/, evals/ and projects/. The README explains the division: SKILL.md is what Codex reads for triggering and execution, the two README files are for humans, scripts/ holds deterministic scripts, references/ holds material read on demand, and projects/ holds run outputs that are not committed.

That split matters when you debug. If a skill misbehaves, the trigger and the execution instructions live in SKILL.md, while the actual work is done by scripts. The repository keeps only a .gitkeep in projects/, and the TikTok skills additionally ignore downloaded videos, screenshots, CSV/JSON research bundles, subtitles, transcripts and CapCut drafts. So the repository you clone is mostly instructions and scripts, and everything heavy lands in your working copy.

The naming is inconsistent in a way worth noting. Most directories use a bggg- prefix, but tiktok-gemini-video-workflow, sif-keyword-scout, sif-keyword-tracker, web-access and xquik-x-research do not. web-access is not BGGG's own work: the README describes it as a third-party MIT skill provided by eze-is/web-access, optionally used in the Sif workflow for browser CDP export. One top-level entry, ngs-amazon-image-studio, appears in the repository listing but is not described in the README's skill list, so treat it as undocumented.

Installing bggg-skills and running a first skill

Installation is a clone plus a copy. The README gives these commands to get the repository and place skills into the Codex skills directory:

git clone https://github.com/binggandata/bggg-skills.git
cd bggg-skills

mkdir -p ~/.codex/skills
cp -R bggg-creator-image2psd ~/.codex/skills/
cp -R bggg-creator-image2ppt ~/.codex/skills/
cp -R bggg-tiktok-search bggg-tiktok-downloader ~/.codex/skills/
cp -R bggg-tiktok-readvideo ~/.codex/skills/
cp -R bggg-tiktok-cut bggg-tiktok-capcut ~/.codex/skills/
cp -R sif-keyword-scout sif-keyword-tracker web-access ~/.codex/skills/
cp -R xquik-x-research ~/.codex/skills/
cp .sif-config.example.json ~/.codex/skills/

After the copy, the skill directories should appear under ~/.codex/skills/. During development the README suggests symlinks instead, so edits in the clone are picked up without recopying:

ln -s "$PWD/bggg-creator-image2psd" ~/.codex/skills/bggg-creator-image2psd
ln -s "$PWD/bggg-creator-image2ppt" ~/.codex/skills/bggg-creator-image2ppt
ln -s "$PWD/bggg-tiktok-search" ~/.codex/skills/bggg-tiktok-search
ln -s "$PWD/bggg-tiktok-downloader" ~/.codex/skills/bggg-tiktok-downloader
ln -s "$PWD/bggg-tiktok-readvideo" ~/.codex/skills/bggg-tiktok-readvideo
ln -s "$PWD/bggg-tiktok-cut" ~/.codex/skills/bggg-tiktok-cut
ln -s "$PWD/bggg-tiktok-capcut" ~/.codex/skills/bggg-tiktok-capcut
ln -s "$PWD/sif-keyword-scout" ~/.codex/skills/sif-keyword-scout
ln -s "$PWD/sif-keyword-tracker" ~/.codex/skills/sif-keyword-tracker
ln -s "$PWD/web-access" ~/.codex/skills/web-access
ln -s "$PWD/xquik-x-research" ~/.codex/skills/xquik-x-research
cp .sif-config.example.json ~/.codex/skills/

Dependencies are per skill, not global. The README says that if a skill directory contains scripts/requirements.txt, install it, and gives these two examples:

python3 -m pip install -r ~/.codex/skills/bggg-creator-image2psd/scripts/requirements.txt
python3 -m pip install -r ~/.codex/skills/bggg-creator-image2ppt/scripts/requirements.txt

The Sif keyword workflow has its own dependency set, installed separately:

python3 -m pip install pandas openpyxl matplotlib python-docx numpy

For the Sif workflow there is a first-run step. The README states that on the first run of sif-keyword-scout, the agent copies .sif-config.example.json to a local .sif-config.json and asks for the report output directory. Neither .sif-config.json, the Sif export tables, nor the Word and Excel outputs are committed to the repository. A first real use therefore looks like: copy the skill, install its requirements, then let the agent create the local config before pointing it at your Sif export. The README does not document a rollback path if a skill run produces bad output, other than deleting files from projects/.

Where the collection is thin: dependencies, credentials and undocumented skills

The biggest practical limitation is that the README describes skills but not their failure modes. Several skills depend on things outside the repository. bggg-tiktok-downloader uses yt-dlp, and the README notes that when a single video fails it falls back to tikwm. bggg-tiktok-cut uses FFmpeg and a JSON edit plan. bggg-tiktok-search, bggg-data-x and bggg-tiktok-search reuse a logged-in local Chrome session, which means the skill inherits whatever state that browser profile is in. None of these external tools are pinned to a version in the README, so an upgrade of yt-dlp or FFmpeg can change behavior without the repository changing at all.

Credentials are another boundary. xquik-x-research is described as API-key-only, and web-access is a third-party skill used for browser CDP export. The README does not describe how keys are stored or rotated, and it does not list a secrets file other than .sif-config.example.json for the Sif workflow. If you need an auditable credential story, this repository does not provide one.

The documentation is also uneven. The README lists fourteen skills, but the repository listing includes ngs-amazon-image-studio, which the README does not mention. Some skills have a full internal structure with SKILL.md, README.md, README_EN.md, scripts/, references/, assets/, evals/ and projects/; others are listed only by name in the repository tree. bggg-skill-taotie, the skill evolver that compares and absorbs advantages from other skills, ships with SKILL.md, README.md, INSTALL.md, references/ and evals/ but no scripts/ directory, which suggests it is instruction-driven rather than script-driven. That is a design choice, not a defect, but it means behavior depends on the model following instructions rather than on deterministic code.

How it compares with a conventional Python media library

The natural alternative is a Python library that you import, such as a PSD writer or a PPTX generator, and call from your own code. The difference is where the logic lives. A library gives you functions with signatures, versioned releases and a test suite you can run; bggg-skills gives you SKILL.md instructions plus scripts, and the orchestration happens inside Codex. If you want to convert one image to PSD inside a larger pipeline you control, a library is the better fit, because you can pin a version and assert on the output.

If your work is exploratory and you want the agent to make judgment calls, for example splitting an image into layers, rebuilding a component from a screenshot, or deciding which TikTok frames matter, the skill form is the point. bggg-tiktok-readvideo turns a video into metadata, transcript, scene, keyframe, contact sheet and timeline that Codex can read, which is a preparation step for a model rather than a fixed API. The same logic applies to bggg-skill-taotie, which has no equivalent in a normal library because its job is to improve other skills by comparison and analysis.

The trade-off is reproducibility. A library fails with an exception; a skill can fail by producing a plausible but wrong PSD or PPTX, and the README does not describe validation steps for the creative conversions. The evals/ directories exist in the layout, but the README does not explain what they contain or how to run them, so you cannot rely on them as a regression suite from the documentation alone.

Maintenance, licensing and what the repository does not tell you

The repository is not archived, and the last push was on 2026-08-13. There are no releases in the repository, so there is no version number to pin and no changelog to read. Upgrading means pulling main and recopying or relinking the skill directories, then reinstalling any scripts/requirements.txt that changed. Because the skills are copied rather than installed as packages, a stale copy in ~/.codex/skills/ will keep working with old instructions until you overwrite it. That is the main upgrade cost, and it is manual.

The licence is MIT, at the repository root. Two implications follow from the README rather than from legal analysis. First, web-access is described as a third-party MIT skill from eze-is/web-access, so its provenance differs from the BGGG-authored skills even though the licence identifier matches. Second, the README states that .sif-config.json, Sif export tables and Word/Excel outputs are not committed, and that TikTok downloads, screenshots, CSV/JSON research bundles, subtitles, transcripts and CapCut drafts are ignored. The repository therefore does not ship data, and any data you generate stays in your working copy under projects/. Whether that data can be redistributed is a question about the source platform's terms, not about this repository's MIT licence.

Editorial conclusion

Adopt bggg-skills if you already run Codex and want ready-made workflows for image conversion, TikTok research and cutting, or Amazon and Reddit data collection, and you accept that each skill is installed by hand. Do not adopt it if you need a packaged Python library with versioned releases, or if you cannot install per-skill requirements and external tools. Before committing, verify the dependencies of the specific skill you want: check whether its scripts/requirements.txt exists, and confirm that third-party tools such as yt-dlp and FFmpeg are available, because the README does not document rollback or a versioning scheme for the collection.

Frequently asked questions

Official sources

1. binggandata/bggg-skills on GitHub
2. Issues
3. License: MIT
4. README