CommunityImagemgithub.com

hbzheng0942/greybox-host-bridge

Roteia a criação de greybox, revisão de gameplay e trabalhos artísticos através da CLI Python compartilhada do WorkBuddy, incluindo modelos DeepSeek sem ferramentas de geração de imagens.

O que é greybox-host-bridge?

Esta skill permite que agentes de IA, como Claude Code, Cursor ou Codex, executem um fluxo de trabalho unificado de desenvolvimento de jogos através da CLI Python do WorkBuddy. Ela gerencia a criação de greybox (protótipos), revisões de gameplay e produção de arte, suportando modelos como DeepSeek mesmo quando ferramentas de geração de imagens não estão disponíveis. A skill atua como uma ponte entre o agente e o ambiente de desenvolvimento, usando um prefixo de comando comum (`python "{{SKILL_ROOT}}/scripts/greybox.py"`) sem exigir Node.js, MCP ou troca de modelos. Ela fornece um fluxo de trabalho estruturado com etapas para interpretar intenções, configurar o host (`host setup`), usar comandos de greybox (`greybox init`, `build`, etc.), gerenciar referências de modelagem e processar tarefas de arte. O sistema é particularmente útil para cenários de desenvolvimento de jogos que exigem coordenação entre design de greybox, ajuste de gameplay e produção de arte, com recursos para alternância de contexto, inspeção de tarefas e comparação de cenas. A skill enfatiza a preservação do estado do projeto, histórico de aprovações e o uso de ferramentas nativas em vez de serviços externos, a menos que seja explicitamente configurado.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/hbzheng0942/grey2art/tree/main/skills/greybox-to-multistyle-art/connectors/workbuddy/skills/greybox-host-bridge

Installed? Explore more Imagem skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Leia {{SKILL_ROOT}}/SKILL.md para o fluxo de trabalho de produção e suas decisões humanas. Use python "{{SKILL_ROOT}}/scripts/greybox.py" como prefixo de comando comum. Não é necessário Node, MCP ou troca de modelo. Este wrapper é opcional: o WorkBuddy também pode ler a Skill completa e executar sua CLI diretamente. Use o prefixo de comando retornado pela configuração; ele registra o Python real e a identidade do pacote verificada.

Para casos de arte de longa duração, fixe a entrada real no PLAN existente usando task-context pin e continue com task-context run; leia {{SKILL_ROOT}}/references/task-context.md. Refaça a verificação após uma transferência ou mudança de modelo/ferramenta. Reporte fatos de modelo/esquema indisponíveis como desconhecidos. task-context inspect distingue cópias instaladas e cada rota de recuperação de legado/executor do ledger original; nunca recrie trabalhos pagos para adequá-los ao executor mais recente.

  1. Leia a tarefa atual por intenção, estado observado e endpoint solicitado. Use intent route --file REQUEST --project PROJECT para roteamento estruturado de solicitações. Discussão permanece discussão; solicitações de greybox usam como padrão um endpoint de greybox; continue usa registros de tarefa originais. Execute host setup --host workbuddy --scope greybox --project PROJECT para trabalho de greybox, ou host setup --host workbuddy --scope art --project PROJECT --capability-report REPORT --session-id SESSION para o ramo de arte/imagem. A configuração resolve a raiz real do projeto nativo e retorna o prefixo do comando. Vincule evidências de invocação nativas atuais do ImageGen quando disponível; nenhum perfil de API é então necessário. A descoberta de ferramentas sozinha é insuficiente. Serviços de imagem e ferramentas não relacionadas não são pré-requisitos do greybox. Para trabalho de cena Blender, use host setup --host workbuddy --scope spatial --engine blender --operation create|edit|review --project SOURCE_OR_WORKSPACE quando a preparação da CLI for necessária; operações nativas bpy/CLI/MCP disponíveis podem então seguir a rota espacial. A configuração é apenas prontidão; a descoberta de aplicação não inspeciona uma cena. Um endpoint espacial puro não precisa de projeto de jogo ou fornecedor.

  2. Para criação/revisão de greybox Godot/Unity, leia {{SKILL_ROOT}}/references/greybox-authoring.md e use greybox init/build/play/validate/status/handoff; pare no endpoint solicitado. Para o ramo de arte, se a geração estiver faltando, leia {{SKILL_ROOT}}/references/image-services.md e configure o serviço de imagem escolhido pelo usuário com image configure. Vincule seu nome não secreto usando host configure --host workbuddy --image-profile NAME.

  3. Para novas referências de modelagem S7, leia {{SKILL_ROOT}}/references/modeling-references.md, registre cada asset e suas visualizações uma vez, e execute boards workbuddy start --file REGISTRY --project PROJECT --workspace WORKSPACE. Isso compila os jobs de página e registra/instala seus guard S7 com escopo. Execute sua sonda Bash nativa exata e inofensiva, então boards workbuddy bind com o esquema de ferramenta nativa atual. Consuma os jobs retornados; boards workbuddy claim escreve os argumentos exatos prontos para chamada e reserva o teto de gastos existente. Um único planejado segue este mesmo caminho e precisa de sua razão calculada ou obtida. Registre o resultado original, então corte/reveja através de boards production; um slot ruim não apaga irmãos bons, e ROIs corrigidos criam tentativas de corte sem regenerar. Um novo chat renova a sonda gratuita e preserva chamadas pendentes originais. Para um perfil de imagem escolhido, consuma as requisições de página exatas preparadas através do ledger de serviço configurado existente. Não reduza os requisitos de qualidade ou submeta uma chamada incerta novamente.

  4. Quando o ramo ativo produzir imagens, abra a imagem local real retornada através da ferramenta de leitura de pixels do host atual. Apresente esse arquivo usando a UI de imagem suportada pelo host. O sucesso da CLI não estabelece nenhuma das capacidades. Vincule ferramentas exatas atuais e evidências no relatório de capacidade da sessão. A revisão de greybox usa suas visualizações nativas capturadas e não requer geração de imagem.

  5. Continue os comandos para a rota atual e endpoint solicitado. Entregue e pare após a transferência de greybox quando stop_at for greybox; entre na arte apenas quando solicitado. Preserve o estado original do projeto e o histórico de aprovações. A delegação é opcional; a concorrência de múltiplas tarefas de imagem/modelo usa o executor comum descrito em {{SKILL_ROOT}}/references/execution-contract.md. Ferramentas nativas permanecem orientadas ao agente, a menos que uma ponte independente real seja verificada; trabalhadores de API podem continuar enquanto a conexão do modelo estiver parada.

Antes do H3, compare o conceito aprovado com a sonda de cena inteira atual via scene-review --help. No H4, novos contratos de produção exigem evidência de comparação de recurso/visualização atual. Leia {{SKILL_ROOT}}/references/scene-comparison.md; use lacunas observadas para reparar ambiente, formas principais, luz e contato antes da expansão. A cobertura de evidência válida nunca fornece a aceitação visual do usuário.

Comandos retornam JSON; comandos com falha retornam um código diferente de zero. Use --help de cada comando para opções exatas atuais. Mantenha credenciais na configuração local ou no ambiente configurado, nunca no chat, em arquivos de conector ou registros portáteis de projeto. Uma credencial de serviço é necessária apenas para o serviço escolhido; a inicialização do conector não faz login em um provedor ou cria uma tarefa paga.

Somente quando a operação atual precisar de Lux, execute host setup --host workbuddy --scope runtime --runtime lux. Ele prepara/reutiliza o runtime privado fixado e pode se recuperar de uma sonda venv/ensurepip com falha usando um interpretador compatível existente. Ele não consulta fornecedores ou submete geração. Preserve seu caminho Python retornado entre comandos. Um --python explícito nunca é substituído silenciosamente.

Habilidades Relacionadas