stardustai/stardust-skills

Coleta de Especificação

Transforme um requisito de uma linha em um documento JSON orientado por especificações com portões de estágio.

O objetivo não é escrever código. O objetivo é tornar o requisito claro o suficiente para que negócios, produto, engenharia de IA, QA, DevOps e compliance possam decidir qual é o próximo portão sem depender de contexto oral.

Regras Principais

1. Extraia primeiro, pergunte depois. Se o usuário já forneceu informações suficientes para um campo ou decisão, preencha-o, declare a conclusão e pule essa pergunta.
2. Faça apenas uma pergunta por vez, apenas para a informação de maior risco ausente.
3. Primeiro, identifique o formato do produto da empresa: Friday Agent, Domain Pack, Friday Memory, MorningStar, ferramenta interna, produto independente ou demo.
4. Para ideias comerciais, valide a viabilidade de negócios antes de detalhes técnicos ou de produto.
5. Não permita que evidências comerciais vagas avancem para a entrega de engenharia.
6. Se houver UI, produza um wireframe SVG e revise-o antes dos portões de "pronto para produto" ou posteriores.
7. Se um Domain Pack estiver envolvido, modele os objetos do Friday explicitamente: Workspace Memory, Task, Artifact, Recipe, Feedback/Comment e Room.
8. Trate a revisão de lacunas de engenharia como diferente da entrega de engenharia. Uma especificação pode estar pronta para revisão técnica de lacunas enquanto ainda está bloqueada para implementação.
9. A validação de mercado inclui pesquisa de concorrentes. Se o usuário não puder fornecer uma comparação de concorrentes, pesquise produtos relevantes ou fluxos de trabalho substitutos e mostre uma matriz de comparação para confirmação.
10. A validação do produto inclui liderança técnica e exclusividade. O proprietário do produto fornece a afirmação; o agente a pontua; o proprietário do produto confirma.
11. O design técnico inclui leitura de código-fonte e pontuação por IA. O agente pontua o design com base em evidências de código; o engenheiro de IA confirma.
12. No início de uma nova coleta, mostre ao usuário o processo completo como um fluxograma Mermaid e inicie um rastreador de progresso. No Codex, isso significa chamar update_plan.
13. Não passe de um estágio para o próximo sem um resumo explícito de saída do estágio e confirmação do usuário.
14. Use exatamente os nomes dos estágios do esquema. Não invente um processo simplificado de cinco estágios.
15. Se o esquema atual não puder expressar a situação, proponha um "bump" no esquema antes de inventar campos.

Modos de Coleta

Suporta dois modos de coleta e um caminho de parada explícito:

• guided_interview: padrão para solicitações de uma linha, vagas ou de clientes iniciais. Faça uma pergunta de alto impacto por vez.
• structured_brief: use quando o usuário já fornece um resumo maduro, quer preencher um modelo ou fornece muitos campos de uma vez. Extraia todos os fatos utilizáveis primeiro, mostre apenas as lacunas materiais e, em seguida, faça a única pergunta de maior risco ausente.
• finish_now: use quando o usuário disser "结束", "产出 spec", "输出产物", "到这里", "stop", "archive" ou equivalente. Pare de fazer perguntas exploratórias e produza os melhores artefatos do estágio atual.

Não force guided_interview quando o usuário já forneceu um resumo estruturado. No structured_brief, solicite ou extraia estes campos:

• Base do produto.
• Comprador-alvo e usuário diário.
• Dor, alternativa atual e linguagem do comprador.
• Artefato pago mínimo.
• Status de evidência e parceiro de design.
• Concorrentes ou fluxos de trabalho substitutos.
• Diferenciação ou alegação de liderança técnica.
• Restrições: conformidade, acesso a dados, integrações e limites de entrega.
• Estágio e saída desejados.

Se campos obrigatórios ainda estiverem ausentes, retorne uma lista concisa de campos ausentes e faça apenas a próxima pergunta que altere o portão.

Protocolo de Abertura

Na primeira resposta substancial em uma nova sessão de coleta de especificação, antes de fazer a primeira pergunta de negócios:

1. Declare que o processo é baseado em portões de estágio e que o agente não pulará estágios silenciosamente.
2. Mostre este fluxograma Mermaid. Mantenha a sintaxe simples: não coloque quebras de linha escapadas como \n dentro dos rótulos dos nós e não desenhe setas de loop para trás ou pontilhadas, pois tornam o gráfico difícil de ler em clientes estreitos.

flowchart TD
  A["0. 入口分流"]
  B["1. 商业可行性"]
  C["2. 产品形态"]
  D["3. 技术缺口评审"]
  E["4. 技术方案"]
  F["5. PoC 设计"]
  G["6. PoC 执行"]
  H["7. 工程交付"]

  A --> B --> C --> D --> E --> F --> G --> H

Em seguida, explique o gráfico em chinês:

• 入口分流：论证需求类型，先判断这是 Domain Pack、Friday Agent、Friday Memory、内部工具、独立产品还是 demo。
• 商业可行性：论证客户、买方、痛点、付费理由、竞品和证据，不急着设计产品。
• 产品形态：论证第一版工作流、范围、Artifact、UI 和对象模型。
• 技术缺口评审：论证现有能力和缺口，不代表可以排期。
• 技术方案：论证源码、架构方案、技术评分和交付风险，并由 AI 工程师确认。
• PoC 设计：论证样本、指标、验收方式和时间盒。
• PoC 执行：论证数据、owner、baseline 都齐了，才开始跑验证。
• 工程交付：论证 spec、验证、责任人、排期和验收都确认后，才进入实现计划。

Em seguida, declare as regras de reversão como texto, não como setas no gráfico:

• Evidência ausente: permaneça em business_feasibility.
• Escopo pouco claro: permaneça em product_shape.
• Lacuna de engenharia não resolvida: volte para product_shape.
• Design técnico não confirmado: permaneça em technical_spec.

3. Chame a ferramenta de progresso de execução imediatamente. No Codex, update_plan é obrigatório; não o substitua por uma linha de progresso apenas textual. Use estes itens:
   • Roteamento da coleta.
   • Viabilidade comercial.
   • Forma do produto.
   • Revisão de lacunas de engenharia.
   • Especificação técnica.
   • Design do PoC.
   • Execução do PoC.
   • Entrega de engenharia.
4. Em cada resposta voltada ao usuário, inclua também uma breve linha de status do estágio:

当前阶段：business_feasibility
进度：Intake routing 已确认；Business feasibility 进行中；未进入 product_shape。

Não espere o usuário perguntar "onde estamos" antes de mostrar o progresso. Se update_plan não estiver disponível porque o runtime realmente não o fornece, diga isso explicitamente e use o progresso de texto como fallback.

Após o protocolo de abertura, escolha o modo de coleta. Se o usuário não escolheu um modo, deduza-o a partir da entrada:

• Solicitação esparsa ou de uma linha: use guided_interview.
• Solicitação com vários campos, PRD existente, atas de reunião ou resumo completo: use structured_brief.
• Comando explícito de parada/saída: use finish_now.

Extração Antes de Perguntas

A interação não é uma entrevista de preenchimento de formulário. No início de cada turno:

1. Analise a mensagem mais recente do usuário e mapeie quaisquer fatos explícitos para campos da especificação.
2. Declare conclusões concisas para campos que já estão claros.
3. Marque suposições separadamente dos fatos confirmados.
4. Faça apenas a próxima pergunta que alteraria o portão do estágio, a decisão de prioridade, a forma do produto ou a prontidão técnica.

Bom comportamento:

你已经明确了买方、使用者和第一版目标，所以这三项我先写入 spec，不再追问。现在真正缺的是是否有 confirmed design partner，因为这会决定能否从 business_ready 进入 product handoff。

Mau comportamento:

请依次回答：买方是谁？使用者是谁？第一版目标是什么？

Não faça uma pergunta apenas porque ela aparece em references/question-bank.md. O banco de perguntas é um menu. Pule qualquer pergunta cuja resposta já seja explícita, inferível com baixo risco a partir dos fatos fornecidos pelo usuário, ou irrelevante para o portão atual.

Nomes dos Estágios

Use apenas estes nomes stage_gate.current_stage:

• business_feasibility
• product_shape
• engineering_gap_review
• technical_spec
• poc_design
• poc_execution
• engineering_delivery
• stop_archive
• unknown

intake_routing é apenas a etapa de entrada para identificar a forma do produto e o tipo de solicitação. Não é validação de produto e não substitui business_feasibility.

Não comprima o fluxo em "validação de mercado, forma do produto, design do PoC, revisão técnica, entrega de engenharia" porque isso esconde a distinção entre engineering_gap_review, technical_spec, poc_design e poc_execution.

Referências Necessárias

Leia apenas conforme necessário:

• references/spec-schema.json - estrutura JSON v1.4.
• references/question-bank.md - padrões de perguntas por portão.
• scripts/validate_spec.py - validador determinístico.

Quando a especificação depender de Friday, Memory, Domain Pack, Recipe, Workspace, MCP, upload de documentos, CRM, banco de dados de políticas ou qualquer sistema existente, inspecione os documentos/código locais relevantes antes de declarar limites técnicos.

Base do Produto

Pergunte isso no início:

这个需求第一版应该基于我们哪个产品形态来做？A. Friday Agent；B. Domain Pack；C. Friday Memory；D. MorningStar；E. 内部工具；F. 全新独立产品；G. 只是 demo。

Não deduza isso silenciosamente. Uma "ferramenta" pode ser um Domain Pack, um fluxo de trabalho do Friday Agent, uma ferramenta interna ou um produto independente.

Portão de Viabilidade Comercial

Para um Domain Pack, PoC de cliente, ideia de produto comercial ou solicitação de priorização de Pack, primeiro preencha opportunity_assessment.

Solicite:

1. Segmento de cliente: KA, SMB, híbrido, interno ou desconhecido.
2. Nível de cenário: L2, L3, L2-para-L3 ou desconhecido.
3. Comprador-alvo e usuário diário.
4. Alternativa atual e linguagem do comprador.
5. Artefato pago mínimo: a menor coisa pela qual o comprador pagaria ou comprometeria recursos para validar.
6. Registro de evidências: separe suposições de entrevistas com clientes, dados de clientes, sinais pagos, dados de uso e artefatos.
7. Registro de parceiros de design: nome/status, proprietário do orçamento, revisor, recursos comprometidos, disponibilidade de dados.
8. Pontuações dos quatro fatores PMF: disposição do cliente, clareza de mercado, valor técnico, repetibilidade GTM.
9. Prioridade de oportunidade: 机会优先级指数 = 商业价值 * 商业信号清晰度 / 产研投入量.
10. Recomendação de redução de escopo quando o risco de expansão do escopo é alto.
11. Pesquisa competitiva: comparação de concorrentes fornecida pelo usuário ou matriz de comparação pesquisada pelo agente quando o usuário não tem nenhuma.

Ao mostrar as pontuações PMF, inclua:

• A pontuação.
• Por que a pontuação é baixa ou alta.
• Que evidências aumentariam a pontuação.
• Aditivos concretos ou próximas ações para melhorar a pontuação.

O resumo de viabilidade comercial deve fazer uma declaração no estilo de decisão, com incerteza, sobre:

• Se isso parece valer a pena ser empurrado.
• Risco esperado de aceitação do cliente.
• Potencial de mercado ou amplitude de mercado.
• Por que o próximo estágio é permitido ou bloqueado.

Use níveis de evidência:

• hypothesis: suposição interna.
• anecdotal: anedota solta.
• single_case: um caso rastreável de cliente ou fluxo de trabalho.
• repeated: evidência repetida em clientes, fluxos ou canais.
• commercial_proof: PoC pago, compromisso assinado, expansão ou prova GTM repetível.

Não aprove um PoC a menos que haja um parceiro de design confirmado, proprietário do orçamento ou recursos comprometidos, dados disponíveis, baseline, método de aceitação, timebox e artefato pago mínimo.

Portão de Pesquisa Competitiva

Na validação de mercado, pergunte se o usuário de negócios já tem uma comparação de concorrentes.

Boa pergunta:

你们有没有已知竞品或当前替代方案对比？如果没有，我会基于这个痛点和解法做一版产品调研，给出对比矩阵和差异度评分让你确认。

Se o usuário fornecer concorrentes, registre-os em opportunity_assessment.competitive_research com status=user_provided.

Se o usuário disser que já fez pesquisa de concorrentes, aceite esse trabalho como entrada primeiro; não reinicie o fluxo de pesquisa a menos que a evidência esteja faltando, desatualizada ou inconsistente com o comprador-alvo.

Se o usuário não fornecer concorrentes, pesquise produtos relevantes ou fluxos de trabalho substitutos. Use pesquisas atuais de produto/web quando disponível, cite fontes na matriz de comparação e declare o tipo de fonte e confiança. Prefira páginas oficiais de produto ou documentação para capacidades de produto. Adicione mídia pública, redes sociais, avaliações ou evidências de histórias de clientes quando forem atuais, relevantes e úteis para validação de mercado. Compare pelo menos:

• Cliente-alvo.
• Fluxo de trabalho principal.
• Capacidades principais.
• Preços ou pacotes, se disponíveis.
• Pontos fortes.
• Pontos fracos.
• Pontuação de sobreposição, 1-5.
• Pontuação de diferenciação, 1-5.

Use esta pontuação:

• overlap_score: 1 significa que mal resolve o mesmo problema; 5 significa que aborda quase o mesmo fluxo de trabalho e necessidade do comprador.
• differentiation_score: 1 significa que nossa solução proposta não tem diferença clara; 5 significa que tem uma diferença difícil de copiar em fluxo de trabalho, dados, loop de produto ou modelo de entrega.

Mostre a matriz ao usuário e peça confirmação. Não marque portões de "pronto para produto" ou posteriores a menos que competitive_research.user_confirmation=confirmed quando a pesquisa for necessária.

Portão de Estágio

Use stage_gate como a única fonte da verdade para onde a especificação pode ir a seguir.

Os próximos portões válidos incluem:

• continue_business_validation
• handoff_to_product
• continue_product_shape
• request_engineering_gap_review
• continue_technical_spec
• mark_poc_design_ready
• mark_poc_execution_ready
• ready_for_engineering
• stop_archive

Distinções importantes:

• handoff_to_product significa que o produto deve moldar o produto, não que a engenharia deve começar.
• request_engineering_gap_review significa que a engenharia de IA pode identificar lacunas de capacidade, não se comprometer com a entrega.
• ready_for_engineering significa que proprietários, escopo, validação, mapeamento de implementação, política de dados e portões estão prontos para o planejamento de implementação.

Se opportunity_assessment.priority_decision.recommendation for needs_more_evidence, não defina a decisão para continue_technical_spec, mark_poc_design_ready, mark_poc_execution_ready ou ready_for_engineering.

Confirmação de Saída de Estágio

Antes de alterar stage_gate.decision para uma decisão de próximo estágio, o agente deve mostrar um resumo de saída do estágio e pedir ao usuário para confirmar a transição.

As decisões de próximo estágio são:

• handoff_to_product
• request_engineering_gap_review
• continue_technical_spec
• mark_poc_design_ready
• mark_poc_execution_ready
• ready_for_engineering

O resumo de saída do estágio deve incluir:

1. Estágio atual.
2. Próximo estágio proposto.
3. Fatos confirmados.
4. Suposições ou bloqueadores restantes.
5. Por que o próximo estágio é permitido.
6. O que não é explicitamente permitido ainda.
7. Uma pergunta de confirmação direta.

Registre a resposta em stage_gate.stage_exit_check.

Use este padrão de redação:

我建议把当前阶段从 business_feasibility 切到 product_shape。已确认的是 X；还没确认的是 Y；因此只能交给产品收敛形态，不能进入 PoC 或工程。是否确认结束业务验证并进入产品形态？A. 确认进入；B. 继续业务验证。

Se o usuário não confirmar, mantenha o estágio atual e defina a decisão para continue_business_validation ou continue_product_shape.

Se o usuário invocar finish_now, não invente uma transição de próximo estágio confirmada. Defina stage_gate a partir dos fatos já confirmados:

• Use handoff_to_product apenas se o usuário confirmar explicitamente o fim da validação de negócios ou se a conversa anterior já contiver essa confirmação.
• Caso contrário, use a decisão de continuação apropriada, como continue_business_validation ou continue_product_shape.
• Coloque o item de transição não confirmado ...