1Click Ecom PDP Skill: an agent skill that writes Amazon image packs, with one catch

What the skill actually automates, and who it is written for

Listing a product on Amazon US means producing a main image set and a detail page set that share a visual identity and English copy. That is normally a designer plus a copywriter plus a round of revisions. This repository targets the part of that work that can be templated: the README states the skill takes "what product you're selling" and "who the target audience is" and returns a complete set of ready-to-publish product images, 5 main images and 7 to 9 detail page images by default. The intended user is not a designer. It is a seller or operator who already talks to an agent all day and wants the agent to produce the assets. The README's own example instruction is conversational: "Use ecom-pdp to create an Amazon US PDP image pack for this product: Output 5 main images + 8 detail page images." If your workflow has no agent in it, the skill has no entry point.

The pipeline: context completion, prompt writing, then image calls

The README describes a multi-level context completion step that fills in missing information by weight, with user input ranked above attachments, and the truncated text stops there. What is visible beyond that is the shape of the execution: the agent writes English (US) marketing copy and plans the layout structure, then calls image generation tools. The command line surface exposes the seams. A run can be forced into --mode prompt, which writes a strategy file instead of an image, and it can be pointed at a --prompt-file or given an inline --prompt, with a --job-dir collecting the output and --asset-type labelling what is being produced (main, angle-sheet, and so on). The consistency claim rests on a separate asset type: the README shows an "angle sheet" generated from a reference image with --image product.png, which is presumably what keeps the product subject stable across the pack. That is a sensible design, because passing a reference image is the only mechanism the README documents for holding the subject still.

Getting it running: install, verify, configure

Installation is a file copy, not a package install. The README's manual path assumes an agent that reads from ~/.codex/skills and gives: mkdir -p ~/.codex/skills/ecom-pdp followed by rsync -a --exclude .git --exclude .env --exclude "generated-images/" ./ ~/.codex/skills/ecom-pdp/. The verification step is python3 ~/.codex/skills/ecom-pdp/scripts/generate_image.py --help. Generation needs credentials, copied from the template with cp .env.example .env and then filled in with three keys: IMG_BASE_URL (the example is https://api.openai.com/v1), IMG_MODEL (gpt-image-1.5) and IMG_API_KEY. The README notes the script also reads common variables such as OPENAI_API_KEY. One detail worth flagging: the README says the generation script is "pure and relies only on standard libraries", so there is no requirements.txt to pin and no dependency tree to audit, but it also means the script is doing its own HTTP calls rather than going through an SDK.

The failure mode is silent: no key, no images

The README is explicit that if the API is not configured, the system will only output executable Prompts. For an agent-driven skill this is the most likely first-run experience, and it is easy to misread. You ask for 5 main images and 8 detail images, you get back a set of well-formed prompt files in generated-images/, and nothing tells you an image was supposed to appear. The --mode prompt flag makes this an intentional mode rather than an error, which is reasonable for review workflows, but it means the success signal is the presence of image files, not the absence of an error. The second constraint is scope. The README frames the output as English (US) copy tailored for channels like Amazon, and the workflow section names Amazon, standalone sites and TikTok Shop. Nothing in the documentation describes localisation of the copy itself, so treat the English output as fixed. A third boundary: the skill plans and calls an image model, so the visual quality ceiling is whatever IMG_MODEL you point it at, not the skill.

Where it sits next to a plain image-generation workflow

The obvious alternative is not another repository, it is the direct route: write your own prompts and call the same image API yourself, or use a hosted product-photography tool that wraps the model. The difference is where the structure lives. With a direct API call you supply one prompt and get one image, and the consistency between the main image and the detail page images is your problem. This skill moves that structure into files: a --job-dir per pack, an --asset-type per image role, a prompt-file per asset, and an angle sheet derived from a reference image. That is genuinely different from ad-hoc prompting, and it is the reason the output is a pack rather than a picture. The cost is that you inherit the skill's layout and copy conventions, which the README describes only as "built-in blockbuster logic" without publishing the templates. If your brand has its own image rules, you are editing someone else's prompt structure rather than starting clean.

Maintenance, licence and the upgrade question

The repository is not archived, and the last push was on 2026-05-16. There are no releases retrieved, so there is no version number to pin and no changelog to read before upgrading. Upgrades in practice mean re-running the rsync from the repository root, which will overwrite local edits to scripts and prompts while leaving .env and generated-images/ alone, since both are excluded. If you tune the prompt templates, keep those edits outside the skill directory or you will lose them on the next sync. The licence field is unknown. The README does not state a licence, and there is no LICENSE reference in the text. That matters more here than for a library you import: the skill writes marketing copy and generates commercial product images, and the terms under which you may redistribute the prompts, ship the script inside a product, or claim rights over the generated output are simply not documented. Treat the licence as unverified until you find the actual file.

The ttoh.app section is an ad, and you can ignore it

Roughly a third of the README is devoted to ttoh.app, described as an independent TikTok ad offer hub indexing ad credits, coupons and landing page entrances by country. The README is candid that it "is not a required dependency for this project" and that the skill is sufficient if you only need PDP image packs. Read it as a cross-promotion, not as architecture. It does tell you something about the author's intended audience, though: sellers running cold-start tests on TikTok traffic who care about initial budget. If that is you, the link is there. If you are producing Amazon listings, it adds nothing to the install, the configuration or the output, and skipping it costs you nothing.

Editorial conclusion

Adopt it if you already run an agent framework such as Claude Code or Codex, you sell on Amazon US or a similar English-language channel, and you have an OpenAI-compatible image endpoint you are willing to point at a script. Do not adopt it if you need a hosted UI, multi-user asset management, or a licence you can verify before shipping: the repository does not state one. Verify two things first: that scripts/generate_image.py --help runs under your Python 3.10+ interpreter, and that your .env IMG_BASE_URL, IMG_MODEL and IMG_API_KEY values actually return an image, because until then the skill only produces text prompts, not the pack.

Official sources

1. coolqoo/1click-ecom-detailpage on GitHub
2. Issues
3. README