Skip to content

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

@Lifecharger

Description

@Lifecharger

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:

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 (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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions