← All needs

[Feature Contribution] tools/ — vendor asset-generator backends (branch ready)

Hi! Following the pattern from #14 and #19 — opening this as an issue first since repo PRs are gated to collaborators. I've prepared a **`tools/`** folder contribution with Python CLI wrappers for the paid vendor APIs that the `/asset-spec` workflow produces prompts for. Branch is ready on my fork, you can review the diff here: **https://github.com/Donchitos/Claude-Code-Game-Studios/compare/main...Lifecharger:Claude-Code-Game-Studios:add-vendor-tools** ## What it adds A new top-level `tools/` folder with: | Subfolder | Files | Purpose | |---|---|---| | `tools/meshy/` | 10 scripts | Meshy AI — text/image → 3D, auto-rig, animate, retexture, remesh | | `tools/pixellab/` | 7 scripts | PixelLab — text → pixel sprites, UI elements, backgrounds (6 presets), image → pixel art, inpaint | | `tools/tripo/` | 5 scripts | Tripo3D — official `tsk_*` SDK client + generate / rig / animate / full pipeline | | `tools/extract/` | 2 scripts | BiRefNet GPU frame extraction + u2net batch | | `tools/media/` | 3 scripts | `pad_image`, `video_to_frames`, `png_to_pixel_array` | | `tools/blender/` | 1 script | Headless Blender FBX auto-splitter | | `tools/pixel_guy/` | Flutter desktop app + Python pipeline | Sprite curator with a detailed `SETUP.md` covering CUDA onnxruntime, BiRefNet/u2net model downloads, and per-OS build steps | Plus `tools/README.md` (top-level tour), per-vendor READMEs, and a pinned `requirements.txt`. **Total:** 173 files, ~17k lines, ~1.5 MB. Pixel Guy source only — no build artifacts or generated content. ## How it connects to your existing skills Your `/asset-spec` skill already produces structured per-asset specs with generation prompts tuned for generic AI image tools (the skill says "Midjourney/Stable Diffusion style" as the format hint), and `/art-bible` defines the visual identity anchor those specs reference. This PR adds an **executable bridge** for that workflow when the target generator is one of the vendors I've wired up — PixelLab (pixel art), Meshy AI (3D), or Tripo3D (3D). Instead of Claude asking the user to run an image tool manually after reading the spec, Claude can invoke the generator directly from a `Bash` tool call: 1. `/asset-spec` writes `design/assets/specs/characters/hero-idle.md` with the visual brief + generation prompt 2. A sprint story says "generate the hero-idle asset from its spec" 3. Claude reads the spec, runs: `python tools/pixellab/pixellab_generate_image.py --prompt "..." -W 256 -H 256 -o assets/characters/hero-idle.png` 4. Done. The scripts are also useful as **standalone CLI utilities** outside any skill — just call them directly from Bash, CI, or batch runs. They don't assume `/asset-spec` exists. ## Key handling All clients use **env-var-first + local-config fallback**: 1. `MESHY_API_KEY` / `PIXELLAB_SECRET` / `TRIPO_API_KEY` / `GEMINI_API_KEY` env var 2. `tools/{vendor}/config.json` (gitignored) with `{ "api_key": "..." }` No config files committed. `.gitignore` entries added for `tools/*/config.json` and all Flutter generated artifacts under `tools/pixel_guy/`. ## License All files contributed under **MIT** (matching CCGS). Originally authored for [Auto Game Builder](https://github.com/Lifecharger/auto-game-builder) (GPLv3) and explicitly dual-licensed under MIT for this contribution. ## What I'm asking 1. **Would this shape of contribution fit where you want CCGS to go?** Adding 17k lines of Python under a new `tools/` folder is a meaningful shift for a repo that's been pure-Markdown + pure-skills so far. Completely fine if the answer is "no thanks" — the scripts are useful to me regardless. 2. **If yes, would you prefer the whole thing in one PR, or split** (e.g., just `tools/meshy/` + `tools/pixellab/` as a first PR, defer `tools/pixel_guy/` to later)? 3. **If yes, how do you want to handle the PR creation under the collaborator restriction?** Invite me as a temporary collaborator so I can `gh pr create`, or some other workflow you use for contributors? Take it or leave it — no pressure either way. Thanks for building CCGS.