od-share-to-community (cenário)

Ativado pela ação de submissão "Compartilhar no OpenDesign" após a conclusão. O usuário acabou de terminar um trabalho neste projeto e quer enviá-lo como um plugin. Ele ainda não respondeu a nenhuma pergunta.

Resultado necessário

Produza uma pasta chamada generated-plugin/ no espaço de trabalho do projeto ativo. No mínimo:

• SKILL.md com frontmatter e instruções claras para o agente.
• open-design.json com metadados de plugin válidos: specVersion, name, version, description, modo, tipo de tarefa, entradas, além de quaisquer referências de pipeline / contexto que o fluxo de trabalho precise.
• plugin.repo é opcional durante a criação, mas não o omita silenciosamente: verifique gh --version e gh auth status, em seguida, prefira o login da conta local impresso pelo status de autenticação. Use gh api user --jq .login apenas como fallback quando o status de autenticação não expor um login. Se gh estiver faltando, não estiver logado, com limite de taxa ou não conseguir resolver um proprietário real, omita plugin.repo em vez de inventar um proprietário e relate explicitamente o problema de autenticação com gh auth refresh -h github.com -s repo,workflow, gh auth login -h github.com -s repo,workflow ou od plugin publish-repo generated-plugin --owner <github-login-or-org> como comandos de recuperação. Nunca escreva proprietários de placeholder como open-design-user, <vendor>, example-user, your-org ou your-username no manifesto final.
• examples/ e assets/ opcionais apenas quando ajudarem na revisão ou reutilização.

Derivar automaticamente do projeto — não pergunte ao usuário campos que os arquivos já respondem

O CWD (diretório de trabalho atual) do agente é a raiz do projeto OD do usuário. Antes de gerar qualquer coisa, leia o que já existe e infira o plugin a partir disso. Trate os arquivos do projeto como a fonte da verdade; o usuário não precisa redigitar coisas que você pode ver.

O que ler, nesta ordem, e o que tirar de cada um:

1. *.artifact.json (ou artifact.json) na raiz do projeto — tipo de tarefa, modo, o prompt que o usuário realmente executou, o arquivo que o agente produziu. Isso direciona od.taskKind, od.mode, o useCase.query padrão e o caminho de saída de exemplo.
2. brand-spec.md / DESIGN.md se presentes — voz, nome da marca, público. Incorpora-se à descrição e tags do plugin.
3. A lista de artefatos gerados no espaço de trabalho do projeto (o *.html, *.tsx, *.svg, etc. que o agente escreveu durante esta sessão) — escolha o mais recente / maior como useCase.exampleOutputs[0].path após copiá-lo em generated-plugin/examples/.
4. O primeiro prompt do usuário nesta conversa, se exposto pelo runtime — a descrição em linguagem natural do que ele queria. Incorpora-se a description e ao useCase.query padrão.

Escolha um ID de plugin estável a partir do que você derivou: letras minúsculas, números, hifens, underscores, pontos. Prefira algo que a especificação da marca ou os metadados do artefato sugiram em vez de inventar um.

Se um campo realmente não puder ser derivado (por exemplo, não existe artifact.json, nenhuma especificação de marca, o projeto é muito esparso), só então pergunte ao usuário — e emita um bloco <question-form> único e consolidado, não perguntas em prosa campo a campo. Defina os valores padrão a partir do que você conseguiu derivar para que o usuário possa aceitar os valores propostos diretamente na forma renderizada. <question-form> é a marcação de texto assistente renderizada pelo OpenDesign, não uma chamada de ferramenta nativa.

Valide o plugin localmente antes de relatar

Execute od plugin validate na pasta, depois od plugin pack para um tarball, e então od plugin install --source <absolute-folder-path> para confirmar que o caminho de instalação funciona.

Quando o trabalho acima for concluído

Escreva um único turno de resumo cobrindo: arquivos criados, status de od plugin validate, status de instalação / execução local e saída de od plugin pack. Então PARE.

NÃO encadeie os fluxos publish-repo / Open-Design-PR você mesmo

NÃO sugira comandos CLI de acompanhamento como od plugin publish, od plugin publish --to open-design, gh repo create, git init / git remote add / git push, ou qualquer outra conexão de publicação / repositório. O card do plugin-folder em Design Files já expõe três botões cujos prompts direcionam esses fluxos de ponta a ponta com os portões de autenticação corretos, fallbacks e regras de repetição incorporadas:

• Adicionar aos meus plugins — já satisfeito pela etapa od plugin install --source deste turno.
• Publicar repositório — cria / atualiza o repositório GitHub plugin.repo do autor através de uma sequência gh + git que o agente é instruído exatamente como executar.
• OpenDesign PR — abre um rascunho de PR contra nexu-io/open-design para o catálogo da comunidade.

…