xxjrq/github-project-intro

Orquestração de Vídeo de Repositório Único GitHub

Esta Skill é o único ponto de entrada para orquestrar vídeos de um único repositório GitHub. Cada repositório possui independentemente seus próprios fatos, planejamento, roteiro, capturas de tela, timeline, áudio, dados de capa e pacote de lançamento; apenas componentes públicos são reutilizados. Trabalhos antigos e exemplos servem apenas como referência e não devem ser usados como fatos, esquemas ou padrões visuais rígidos.

1. Ordem de Leitura e Responsabilidades

Leia primeiro os documentos especificados em AGENTS.md do repositório, depois leia e execute completamente por etapa:

1. work-library-api-registration: Registro no workspace ou cópia de campos de tarefa.
2. ~/.codex/skills/selfmedia-github-research/SKILL.md: Fontes oficiais e alegações de alto risco.
3. ~/.codex/skills/douyin-tech-content-planner/SKILL.md: Público-alvo, benefício único, gancho e ordem das evidências.
4. ~/.codex/skills/record-web-demo/SKILL.md: Lista de evidências, Plano de Ação e captura de tela real.
5. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md: Primeiro, determinar o roteiro final falado e o storyboard legível; não estimar a duração final do áudio.
6. Regras de áudio desta Skill: Gerar e medir áudio serialmente; primeiro obter a duração real e os tempos das legendas.
7. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md: Usar os tempos das ações da captura de tela e a duração do áudio medida para concluir a Timeline v1.2.
8. ~/.codex/skills/selfmedia-cover-design/SKILL.md: Capas nos dois tamanhos 3:4 e 4:3.
9. ~/.codex/skills/selfmedia-remotion-render/SKILL.md: Renderização com modelo público.
10. Portão de fluxo desta Skill: Verificar a ordem das etapas, artefatos necessários e status do workspace; após passar na verificação dos cinco arquivos de máquina, gerar atomicamente o pacote de lançamento oficial.

O Content Agent só pode modificar suas próprias unidades de conteúdo. apps/studio/src/root.tsx, modelos públicos, capas públicas, esquemas, Preflight e validadores de lançamento só podem ser modificados pelo Integration Agent principal. Múltiplos agentes não podem modificar arquivos compartilhados simultaneamente.

2. Registro e Unidades de Conteúdo Oficiais

1. Após o usuário enviar um tópico oficial, o registro no workspace deve ser concluído primeiro: para novo conteúdo, chame POST /api/production-requests; para um diretório existente, chame POST /api/works e depois POST /api/production-requests/adopt. Ambos os métodos devem retornar um work_id e um ID de solicitação de produção válidos; sem esses dois IDs, não é permitido pesquisar, capturar tela ou renderizar.
2. Após o registro bem-sucedido, estabeleça ou assuma a unidade de conteúdo independente em projects/github/videos/<content-id>/ e sincronize projects/index.yaml e projects/task-index.yaml. content.yaml, task.yaml e 制作单.md devem usar o mesmo work_id; a primeira etapa da interface do fluxo do workspace é fixada como "Registro no Workspace".
3. O workspace salva apenas os requisitos da tarefa; ao copiar um modelo, limpe a URL do repositório antigo, Star, versão, licença, roteiro, timeline, capturas de tela, fontes, dados de capa e pacote de lançamento.
4. renderer.composition_id é fixado como GitHubProjectDemoTemplate. O ID do modelo é retornado pelo workspace/API; não depende manualmente do ID do modelo de um trabalho histórico.
5. Quando o usuário envia uma tarefa oficial, o workspace pode executar continuamente as oito etapas até release_ready. Defina stopAfterStageId apenas quando o usuário solicitar explicitamente um teste e especificar um ponto de parada; planning entrega apenas o 制作单.md, render mantém apenas os arquivos temporários de renderização, sem gerar um diretório oficial. O workspace reutiliza a mesma sessão Codex durante a execução contínua, mantendo os portões de etapa, mas sem recriar o contexto para cada etapa.
6. A unidade de conteúdo oficial deve conter:
   • project.json
   • content.yaml
   • task.yaml
   • research/facts.json
   • 制作单.md
7. Quando a saída do Pipeline de pesquisa estiver em uma área de trabalho temporária, os resultados das fontes oficiais, campos dinâmicos atualmente usados e conclusões de alegações de alto risco devem ser gravados de volta na unidade de conteúdo oficial; não use o diretório temporário como substituto do projeto oficial.

O vídeo de projeto único GitHub mantém apenas um documento mestre manual 制作单.md, usando cinco blocos de marcação fixos: decision, voiceover, storyboard, assets, release. Novas tarefas não criam research/decision.md, research/content-plan.md, script/voiceover.md, script/script.json, 创作提示词.md ou qa/; fatos, timeline, Plano de Ação, lista de capturas de tela, áudio, SRT e Props de renderização continuam usando arquivos de máquina independentes.

3. Portões de Fontes, Risco e Planejamento

1. Use a página do repositório GitHub para confirmar a identidade do projeto e salvar a URL oficial. Acesse README, documentação oficial ou página de lançamento apenas para alegações de alto risco que realmente aparecem neste vídeo; não faça uma verificação enciclopédica completa.
2. Alegações de alto risco incluem: números e classificações dinâmicas; preço, custo, economia percentual e comparações de desempenho; conclusões de segurança, privacidade e legais; licença, versão, status de manutenção e identidade oficial; promessas absolutas; e resultados específicos sem suporte de imagens reais ou fontes oficiais.
3. Campos como Star, versão e licença são verificados apenas quando usados em cenas ou texto; atualize-os antes da renderização final. facts.json salva valores precisos, fontes e conclusões de risco; se não houver alegações de alto risco adicionais, registre uma lista vazia.
4. Dores comuns, perguntas retóricas, emoções, analogias, humor leve e resumos coloquiais de demonstrações reais não precisam ser verificados frase por frase. Ganchos fornecidos ou aprovados pelo usuário são bloqueados por padrão; só podem ser rejeitados em caso de erro factual claro, risco de conformidade legal ou desinformação grave; outros riscos exigem apenas a modificação mínima de palavras.
5. Um vídeo promete apenas um benefício principal. Primeiro, determine o público-alvo, o gancho em linguagem natural, a entrega nos primeiros 12 segundos e o único CTA, depois escreva o roteiro. O arquivo de fatos não deve injetar jargão técnico do README na narração; apenas os obstáculos reais que afetam o uso devem ser explicados naturalmente com a funcionalidade correspondente. É proibido criar páginas de aviso de risco separadas, páginas pendentes de verificação, muros de isenção de responsabilidade ou páginas de limites de aplicabilidade.
6. Produtos finais públicos não devem exibir URLs completas, QR codes, botões de download, instruções de ação externas ou valores monetários específicos de ferramentas comuns.
7. Pare se a identidade do projeto não puder ser confirmada, ou se o texto público ainda contiver alegações de alto risco não resolvidas; se não houver alegações de alto risco, não bloqueie a captura de tela e a renderização.

4. Evidências Reais e Tempo de Material

record-web-demo deve ser executado primeiro:

1. Use viewport lógico de 800×600 para capturar README, imagens/GIFs, capturas de tela candidatas e seletores.
2. Primeiro, defina a cena de identidade do repositório GitHub: o nome real do repositório em um quadro de bordas finas e arredondadas, Star ou versão em um círculo oval fino; esta cena deve vir antes de qualquer README ou Demo externo.
3. Em seguida, selecione 1 a 3 evidências do README ou demonstração oficial que comprovem o benefício principal; listas de arquivos, logs de instalação, logotipos e licenças não podem servir como evidência de resultado por padrão.
4. A identidade do GitHub e as Demonstrações externas usam Planos de Ação e arquivos de captura de tela independentes; só grave após cada um ser verificado. Ao precisar de uma fonte de codificação de 1600×1200, use --pixel-scale 2 no pós-processamento, sem expandir o layout da página.
5. A lista de capturas de tela deve registrar startMs, endMs, página, operação, objeto de evidência e resultado da execução para cada ação real.
6. O script de captura de tela deve ser concluído com sucesso; as ações na lista devem ter startMs, endMs reais e status de conclusão; ações com falha não podem entrar na Timeline.
7. trimStartMs e trimEndMs da Timeline só podem vir da lista de capturas de tela; é proibido usar o tempo da cena do produto final como ponto de entrada do material.

5. Script e Timeline

A duração é determinada pela informação, narração medida e tempo de leitura da tela, não fixada em 25 segundos. Estrutura narrativa padrão para referência:

0～3 seg    Página do repositório GitHub, nome do projeto, Star e valor principal
3～6 seg    Primeira evidência real do README ou demonstração oficial
Primeiros 12 seg    Aparece a evidência real mais forte
Meio       Continue demonstrando 1 a 2 evidências
Parte final    Cenário de aplicação, barreiras ou limitações
Final      Uma frase de resumo e um CTA natural

Primeiro, escreva a narração final e o storyboard legível nos blocos voiceover e storyboard do 制作单.md. Após a conclusão da etapa de áudio, use a duração real do áudio, os tempos das legendas e a lista de capturas de tela para gerar o único arquivo de direção de máquina timeline.json. Timeline:

• Usar packages/timeline-schema/timeline.schema.json, versão 1.2;
• Função (role) da cena permitida apenas: hook, proof, process, result, identity, cta;
• direction.proofByMs <= 12000;
• direction.demoLayoutPreset fixado como fixed-demo-v1; quadro de demonstração externo fixado em x=86, y=420, width=908, height=681;
• No máximo um visualPeak: true;
• focus usa coordenadas normalizadas derivadas de quadros de fontes verificadas;
• Cenas de demonstração não podem definir identityTop, evidenceTop, captionTop; destaque só é permitido dentro do quadro de demonstração;
• Quando a captura de tela já tiver anotações, não repita a anotação no Remotion;
• Cenas, legendas e áudio cobrem todo o tempo, sem sobreposição, extrapolação ou espaços em branco inválidos.

Título, capa, primeira tela, narração, legendas e texto de lançamento devem conter GitHub e o nome do projeto, e manter consistência da identidade do projeto, números e outros fatos de alto risco. Títulos nas três plataformas não podem exceder 30 caracteres Unicode cada. A linha de Tópicos/Tags para cada plataforma deve conter #github优质项目 #github开源, total de 5 a 7 tags sem repetição, e complementar com tags do projeto e pelo menos duas tags de valor/cenário que correspondam ao conteúdo atual; no máximo 2 tags populares em tempo real podem ser adicionadas, e somente quando houver evidência da plataforma atual para elas.

6. Arquitetura Pública Remotion

Novos repositórios usam apenas Compositions públicos:

• GitHubProjectDemoTemplate
• GitHubProjectCoverPortrait
• GitHubProjectCoverLandscape

GitHubProjectCoverFeed é apenas para compatibilidade histórica e não entra na lista de Compositions, tarefas de renderização ou pacotes de lançamento de novos projetos.

O projeto passa Entrada Estruturada para Timeline, nome do projeto, Star, gancho, resultado, predefinição e material. É proibido:

• Criar um sistema visual TSX dedicado ao repositório;
• Registrar Compositions de vídeo ou capa dedicados no Root;
• Codificar OpenMontage ou qualquer projeto histórico como fato padrão do modelo público;
• Modificar fatos, adivinhar tempo de material ou reordenar cenas durante a renderização.

GitHubProjectDemoTemplate é o ID do modelo, não o ID do projeto. O Studio usa fixamente http://localhost:3000/, selecionando dados do projeto por meio de props de entrada. Alterações comuns em TSX, CSS, JSON e material dependem de hot reload; apenas alterações em dependências, configuração, ponto de entrada, serviço sem resposta ou erros de compilação irrecuperáveis permitem reinicialização e registro do motivo. A renderização CLI oficial não depende da porta do Studio.

Execute um Preflight unificado antes da renderização oficial: arquivos oficiais completos, campos dinâmicos e alegações de alto risco usados no conteúdo público válidos, Plano de Ação e capturas de tela aprovados, tempo de material legal, Timeline Schema aprovado, comprimento do título aprovado, modo de áudio consistente, dados de capa completos. Pare imediatamente se algum falhar.

7. Modo de Áudio

Obedece apenas ao voice.mode consistente no workspace, content.yaml e task.yaml:

• generate-and-mix: Gerar Edge-TTS serialmente e mixar no vídeo final; o resultado final deve ser AAC 48kHz estéreo, volume médio aproximadamente -20～-28dB.
• generate-reference: Gerar áudio de referência, mas não mixar; o vídeo final deve estar verdadeiramente sem faixa de áudio.
• self-recorded: Não gerar TTS; o vídeo final deve estar verdadeiramente sem faixa de áudio, SRT mantido para ajuste fino após o usuário dublar.

Se o modo estiver ausente ou inconsistente nos três locais, o Preflight falha. A etapa de áudio deve ocorrer antes da etapa de Timeline; após alterações no texto, gere e meça o áudio novamente, não reutilize a duração antiga. Timeline e SRT devem usar a duração medida atual; se o áudio ou SRT exceder a duração da Timeline, não entre na renderização.

8. Capa e Renderização Oficial

A capa deve ser executada por selfmedia-cover-design; não crie uma capa improvisada após a conclusão do vídeo. O vídeo gera fixamente duas capas com layout independente: 3:4, 4:3; não corte quadros de vídeo forçadamente, não gere capa de fluxo de vídeo 9:16.

A série GitHub usa ordem fixa de informações: identidade da coluna GitHub, nome do projeto, Star dourado abaixo do nome do projeto, um resultado específico de 6 a 12 caracteres. Os dados da capa devem vir deste projeto, e dois arquivos, 3:4 e 4:3, devem ser gerados separadamente.

Após todos os projetos passarem pelo Preflight, faça o Bundle apenas uma vez e, em seguida, renderize vídeos e capas em lote de acordo com o planejamento aprovado. Não pré-visualize repetidamente, extraia quadros cena por cena e re-renderize para a mesma versão, nem crie um diretório de imagens QA.

9. Ativos de Mídia, Capa e Lançamento Multiplataforma

9.1 Primeiro, Diferencie Quatro Tipos de Produtos de Imagem

Um projeto não pode registrar apenas um campo "imagem". Cada tipo deve ser gerenciado separadamente:

Produto	Uso	Método de Geração Preferido	Usar IA para Gerar Imagem?
Imagem dentro do artigo	Explicar arquitetura, fluxo, etapas de instalação, funcionalidades reais	Captura de tela oficial, quadro extraído da captura de tela, quadro estático do Remotion ou SVG; se necessário, use IA apenas para fundo sem fatos	Não usar por padrão; cenas factuais não podem ser inventadas por IA
Capa do artigo	Miniatura de lista de artigos em CSDN, Zhihu, WeChat, etc.	Layout sobreposto Remotion/HTML/CSS	Pode usar IA para gerar fundo sem texto, mas título, nome do projeto, Star e números devem ser sobrepostos depois
Capa do vídeo	Capa de entrada para vídeos/tutoriais no Douyin/Bilibili	selfmedia-cover-design + Composition público do Remotion, gerar 3:4 e 4:3 independentemente	Pode usar IA para gerar o sujeito visual, mas não pode cortar quadros de vídeo para substituir a capa
Ícone da Skill	Página de exploração do SkillHub, metadados do pacote Skill	Reutilizar ícone do projeto ou gerar ícone sem texto com selfmedia-imagegen, depois cortar/exportar 512px	Pode usar; não coloque texto pequeno ou inglês ilegível dentro do ícone

Conclusão: Capa de artigo e capa de vídeo não são o primeiro quadro do vídeo cortado; nem toda imagem dentro do artigo precisa chamar geração de imagem. Capturas de tela reais são responsáveis pela evidência, Remotion é responsável pelo layout estável, IA gera apenas fundo visual ou ícone sem risco factual.

9.2 Ordem de Geração de Ativos de Imagem

Prepare os ativos para cada projeto na seguinte ordem, proibido fazer a capa primeiro e depois complementar os fatos:

Fontes oficiais e verificação de fatos
  → Captura de tela real/captura de tela/evidência README
  → Estrutura do artigo e storyboard do vídeo
  → Determinar quais imagens de acompanhamento são necessárias
  → Gerar ou organizar ativos de imagem
  → Remotion sobrepõe uniformemente nome do projeto, título, números e layout da marca
  → Gerar capa do artigo, capa de vídeo 3:4, capa de vídeo 4:3
  → Verificação de tamanho/zona segura/consistência factual

Seleção de fonte de imagem:

1. Cena real do produto: GitHub, demonstração oficial, documentação oficial, página real em execução; capture diretamente ou extraia quadro da captura de tela.
2. Diagrama explicativo: Priorize a geração com Remotion, SVG, HTML/CSS, adequado para diagramas de arquitetura, fluxogramas, tabelas de comparação e etapas de instalação.
3. Fundo de ambiente: Use selfmedia-imagegen para gerar; não coloque logotipo, Star, número de versão, preço e promessas de funcionalidade não verificados.
4. Título da capa do artigo: Deve ser sobreposto no Remotion/HTML/CSS; não dependa da IA para gerar texto em chinês dentro dos pixels.

9.3 Regras de Campos e Layout da Capa

Os dados da capa de cada projeto devem ser salvos separadamente, incluindo pelo menos:

cover:
  eyebrow: "GitHub 开源项目"
  project_name: "<nome do projeto>"
  hook: "<resultado específico de 6 a 12 caracteres>"
  star_text: "<Star real, com data de verificação>"
  focal_asset: "<caminho da captura de tela real ou imagem de fundo sem risco factual>"
  palette: "<paleta de cores selecionada para este projeto>"
  source_checked_at: "<YYYY-MM-DD>"
  outputs:
    portrait: "02-竖封面-3比4.png"
    landscape: "03-横封面-4比3.png"

A série GitHub usa ordem fixa de informações: identidade da coluna → nome do projeto → Star dourado → um resultado específico. O título principal da capa expressa apenas um benefício; não coloque "100 projetos", lista completa de funcionalidades ou comandos de instalação na capa.

• 3:4: 1080×1440, limite superior aproximadamente 115px, limite inferior aproximadamente 216px, esquerda e direita 86px.
• 4:3: Reorganizado independentemente, sem esticar ou cortar forçadamente a capa 3:4.
• Tela de vídeo 9:16: 1080×1920, conteúdo principal respeita a zona segura do projeto de 170px no topo, 288px na base e 86px nas laterais; este não é o tamanho da capa do vídeo.
• Título, nome do projeto, Star, versão e outros números precisos usam layout determinístico; texto preciso não é gerado em imagens de IA.

9.4 Divisão de Trabalho entre Imagens de Artigo e Remotion

Antes da publicação do artigo, escolha com base no tipo de artigo:

Conteúdo do Artigo	Ativos Recomendados	Explicação
Introdução do projeto	1 capa do projeto + 1 captura de tela real do GitHub + 1 imagem da capacidade principal	Imagem da capacidade principal usa SVG/Remotion, não IA fingindo ser uma captura de tela do produto
Tutorial de instalação	Captura de tela de comando, captura de tela de terminal, fluxograma	Comandos e caminhos devem vir do projeto real
Análise de arquitetura	Diagrama de arquitetura SVG/Remotion + captura de tela do README oficial	Visualização da estrutura, fonte factual ainda aponta para o repositório oficial
Comparação e avaliação	Tabela Remotion/HTML + links oficiais de cada projeto	Compara apenas campos verificados
Artigo de opinião puro	Capa + algumas imagens de ambiente	Imagens de ambiente podem ser geradas por IA, mas não para provar funcionalidade do produto

9.5 Camadas de Plataforma de Lançamento

O lançamento não envia o mesmo texto original para todas as plataformas; ele é dividido em camadas: "fonte de código, distribuição de skill, busca de artigo, distribuição de vídeo":

Camada	Plataforma	Tarefa Principal	Conteúdo do Lançamento
Fonte principal de código	GitHub	Fatos oficiais, versão, Issues, Star	Código-fonte, README, CHANGELOG, Licença, Release
Espelho de código doméstico	Gitee	Acesso doméstico, entrada de espelho, download alternativo	Código-fonte e README sincronizados com o GitHub, deixando claro que o GitHub é a fonte principal
Distribuição de Skill	SkillHub	Busca, instalação, gerenciamento de versão de Skills	Pacote Skill válido, manifest, descrição em chinês, ícone, changelog de versão
Busca de artigo	CSDN, Zhihu, Juejin, Toutiao, WeChat	Busca, explicação e direcionamento de tráfego de artigos longos	Artigo adaptado à plataforma, capa, captura de tela real, link oficial
Distribuição de vídeo/tutorial	Bilibili, Douyin	Descoberta, demonstração, seguidores e direcionamento de tráfego	Vídeo, coluna/tutorial, imagem de entrada 3:4 ou conforme exigido pela plataforma
Difusão opcional	Shaoshupai, SegmentFault, OSChina, Blog Park	Leitores técnicos e comunidade de desenvolvedores	Publicar apenas quando o conteúdo realmente se adapta; não encher de postagens repetidas

A combinação mínima de lançamento para 100 projetos sugerida é:

Fonte principal GitHub + Espelho Gitee
  → Projetos com Skill sobem no SkillHub
  → CSDN / Zhihu / WeChat selecionam versão de artigo adequada à plataforma
  → Bilibili / Douyin publicam vídeo de demonstração ou tutorial

Nem todos os projetos GitHub podem ser publicados no SkillHub. Apenas projetos que realmente possuem estrutura de pacote Skill executável, SKILL.md/manifest.yaml, palavras-gatilho e instruções de autoteste devem ser listados; repositórios de ferramentas comuns publicam apenas conteúdo GitHub, Gitee e artigo/vídeo.

9.6 Adaptação de Plataforma Antes do Lançamento

Cada plataforma gera um campo release independente; não copie um artigo Markdown para todas as plataformas:

release:
  github:
    repo_url: ""
    release_url: ""
    status: "pending"
  gitee:
    mirror_url: ""
    sync_checked_at: ""
    status: "pending"
  skillhub:
    skill_slug: ""
    package_path: ""
    icon_path: ""
    status: "not_applicable"
  articles:
    csdn: { title: "", url: "", status: "pending" }
    zhihu: { title: "", url: "", status: "not_applicable" }
    wechat: { title: "", url: "", status: "not_applicable" }
  media:
    bilibili: { url: "", status: "pending" }
    douyin: { url: "", status: "pending" }

Após cada plataforma ser concluída, é necessário reler o título, seções-chave do texto/README, link do projeto, imagens e status público; o log de lançamento registra a URL real, hora, versão, ambiente do navegador e conclusão da aceitação. Publicar, enviar, excluir e substituir rascunhos antigos ainda são ações de confirmação manual.

10. Release Check

Após o Agente passar pelos seguintes portões de processo de máquina, escreva os cinco arquivos em renders/release-package/. Após a verificação do workspace, renomeie atomicamente para 发布成品/ e entre diretamente em release_ready:

• A solicitação de produção do workspace está associada a um work_id válido, e o diretório de registro coincide exatamente com source_dir; caso contrário, pare, sem entrar na verificação de fontes e riscos, captura de tela ou estágio de renderização;
• A validação do Pipeline validate --require-assets passou;
• Timeline Schema, tempo de material, portão de evidência dos primeiros 12 segundos passaram;
• O comando de renderização foi bem-sucedido, a saída do vídeo é 1080×1920, 30fps, H.264;
• A faixa de áudio está em conformidade com voice.mode, o TTS e o final do SRT não excedem a duração do vídeo; o volume médio final de generate-and-mix deve estar entre -28～-20dB;
• As duas capas têm tamanho e nome corretos;
• As três plataformas têm títulos e descrições substancialmente diferentes, títulos não excedem 30 caracteres Unicode, descrições mantêm parágrafos reais;
• As tags das três plataformas contêm #github优质项目 #github开源, cada linha tem 5 a 7 tags não repetidas, tags do projeto e tags de valor/cenário correspondem ao conteúdo atual;
• projects/index.yaml, projects/task-index.yaml, task.yaml, content.yaml estão em estado consistente.

Não reproduzir parcialmente, não extrair quadros, não visualizar imagem por imagem, não fazer OCR, tabela de contatos ou gráfico de estresse 20:9, não gerar imagens QA e relatórios subjetivos. A tela final é visualizada pelo usuário.

Não definir mais a etapa de confirmação manual rendered → visual_reviewed, nem copiar pacotes candidatos duplicados. Quando qualquer contrato de máquina falhar, não gere 发布成品/ nem reporte release_ready. O pacote de lançamento oficial deve ter e apenas cinco arquivos: texto de lançamento, vídeo, capa 3:4, capa 4:3, SRT. O SRT é fixamente nomeado 04-字幕.srt; a tela final é visualizada pelo usuário no diretório oficial.

Não fazer upload automático, não operar contas de plataforma, não coletar dados pós-lançamento.