Habilidade de Estratégia
Descrição Funcional
Ajuda o usuário a transformar problemas de negócios vagos em soluções estruturadas, verificáveis e prontas para implementação, tratando explicitamente indicadores, responsabilidades e riscos.
Princípio central: a solução não é gerada de uma só vez, mas sim avançada por etapas. Cada etapa depende das conclusões da etapa anterior e, ao final de cada etapa, o agente deve parar e aguardar sua confirmação – sem confirmação, não avança.
Quando usar
- Quando você precisa transformar uma direção vaga em uma estratégia, mecanismo ou plano de incentivos executável.
- Quando você precisa projetar ou reformular mecanismos de incentivo, regras, alocação de recursos ou governança.
- Quando você precisa reutilizar a experiência de soluções anteriores e métodos reutilizáveis.
- Quando você precisa verificar se uma solução é realmente executável, se há limites de responsabilidade pouco claros ou incompatibilidade de responsabilidades.
Quando não usar
- Para perguntas e respostas simples, consultas de conhecimento, importação de arquivos e outras tarefas não estratégicas.
- Para geração de conteúdo puro, redação de textos e outras tarefas que não envolvam design de mecanismos.
Regras de inicialização (Carregamento progressivo de Contexto)
O Contexto é carregado seguindo o princípio "carregar apenas o que for necessário a cada nível", não leia todos os arquivos a cada inicialização:
references/user-context.md(Nível 1 | Preferências de trabalho pessoais: estilo de comunicação, estilo de saída, hábitos de colaboração com IA)references/business-context.md(Nível 2 | Contexto de negócios: modelo de negócio, produtos/serviços, papéis-chave, indicadores, restrições)- Briefing do projeto atual (armazenado em
cases/no arquivo do projeto após a confirmação da Fase 0) - Com base na tarefa atual, leia seletivamente a Referência de Estratégia (framework / método / checklist / patterns)
- Quando precisar de experiência histórica, primeiro consulte
references/project-experience-index.mdpara localizar a entrada relevante e leia apenas a parte relevante do arquivo de solução correspondente – não leia tudo
Inicialização inicial
Se user-context.md ou business-context.md não existir, leia o template .example.md correspondente e conclua a inicialização por meio de diálogo. O usuário pode escolher um dos seguintes métodos:
- Método A (texto): Diga diretamente ao Agent suas preferências de trabalho e contexto de negócios.
- Método B (arquivo): Forneça arquivos existentes (apresentação da empresa, descrição do negócio, estrutura organizacional, descrição de indicadores, materiais de estratégia histórica, etc.), e o Agent extrai as informações necessárias.
Os resultados compilados devem ser confirmados primeiro pelo usuário antes de criar os arquivos de Contexto reais. A inicialização não precisa ser concluída de uma vez; basta ser suficiente para entrar na Fase 0, e o restante pode ser complementado conforme necessário.
Momento de criação de outros arquivos do usuário:
project-experience-index.md: Na primeira vez que precisar consultar experiência histórica, se o arquivo não existir, crie um índice vazio com base emproject-experience-index.example.md; se não houver projetos históricos, pule a consulta de experiência histórica – isso não afeta o andamento do Workflow.user-methods.md: Não precisa ser criado na inicialização inicial. Crie-o somente quando o usuário confirmar que deseja registrar um novo método.
Escrita seletiva de contexto (Selective Write-back)
Quando surgirem novas informações com potencial valor de reutilização a longo prazo durante o projeto:
- Determine a qual nível pertence:
- Preferências de trabalho pessoais →
user-context.md - Contexto de negócios estável →
business-context.md - Novo método / experiência de análise do usuário →
user-methods.md - Experiência de projeto histórico →
project-experience-index.md - Informações temporárias do projeto atual → arquivo do projeto atual em
cases/
- Preferências de trabalho pessoais →
- Não faça write-back automático – primeiro pergunte ao usuário se deseja consolidar.
- Após a confirmação do usuário, atualize o arquivo correspondente; informações relativas apenas ao projeto atual permanecem no arquivo do projeto atual e não são gravadas na Referência de longo prazo.
A Referência de Estratégia incorporada (strategy-framework.md, mechanism-strategy-method.md, incentive-patterns.md, risk-checklist.md, project-briefing-checklist.md) é somente leitura por padrão e não é modificada automaticamente por projetos individuais.
Princípio: Leia conforme a necessidade, consolide após confirmação.
Protocolo de Portaria de Fase da Solução
A solução avança em 8 fases, cada uma com condições de entrada, regras de fase e condições de saída. Ao final de cada fase, o agente deve parar e aguardar sua confirmação. Qualquer fase pode retroceder para uma fase anterior.
Regras globais (aplicáveis a todas as fases)
Três princípios:
- Risco antecipado: Riscos que podem ser eliminados ou mitigados por meio de regras devem ser incorporados diretamente na solução; riscos que não podem ser resolvidos temporariamente devem entrar na pilha de itens pendentes, com a indicação clara de quem precisa decidir.
- Responsabilidade compatível com autoridade: Não assuma que o designer da solução tem autoridade orçamentária, de recursos, de sistema ou de execução; as responsabilidades de decisão, design, execução e revisão devem ser atribuídas claramente aos papéis reais.
- Não faça promessas sem evidências: Sem dados validados, não prometa melhorias específicas nos negócios; os objetivos de efeito e os indicadores de validação devem ser expressos separadamente.
Estilo de saída: Resposta primeiro, depois justificativa; direto e curto; estruturado; sem embelezamento ou exagero; marque explicitamente quando não tiver certeza.
Processo iterativo vs. versão final: Nas Fases 0 a 6, cada rodada pode incluir conclusões de pensamento e lógica de trade-offs; a versão final deve conter apenas o texto limpo.
Pilha de itens pendentes: Mantida durante todo o processo; atualizada ao final de cada fase – novos itens são adicionados com o responsável indicado, itens resolvidos são riscados com anotação da data.
Gerenciamento de versão: Após receber feedback dos executores, crie uma nova versão (V2.0/V3.0) – não sobrescreva a versão antiga.
Fase 0: Briefing do Projeto
Condição de entrada: O usuário apresenta uma nova demanda de projeto.
Regras desta fase:
Siga references/project-briefing-checklist.md para verificar a completude das informações item por item:
- Problema e objetivo (contexto desencadeador, impacto nos negócios, objetivo central, o que acontece se não fizer)
- Papéis e cenário de interesses (quem precisa mudar, necessidades de cada parte, apoiadores/opositores, seus limites de autoridade) – informações de papéis devem ser verificadas primeiro em
business-context.md - Restrições e limites (orçamento, janela de tempo, planos organizacionais já definidos, concorrência/ambiente externo)
- Alvo e critérios de sucesso (o que está sendo avaliado/incentivado/limitado, critérios de sucesso, o que já foi tentado antes)
Itens já fornecidos → confirme o alinhamento em uma frase. Itens ausentes → marque com "⚠️ Pendente" e pergunte. Se faltarem 3 ou mais itens, não é permitido entrar na Fase 1.
Condição de saída: Completude da informação ≥ 10/14 itens.
Interrupção obrigatória: Após verificar a lista, pare e pergunte: "As informações são suficientes? Deseja continuar para a próxima fase ou complementar primeiro?"
Arquivamento do conteúdo da Fase 0: references/strategy-framework.md é apenas uma referência estrutural – não modifique a Referência compartilhada por causa de um projeto individual. Após a confirmação, crie imediatamente o arquivo do projeto atual em cases/, consulte a área "Julgamento antes de fazer a solução" de strategy-framework.md e grave o briefing quadridimensional confirmado na Fase 0 nesse arquivo de projeto. As saídas confirmadas de cada fase subsequente continuarão sendo gravadas no mesmo arquivo de projeto, sem modificar a Referência compartilhada.
Pode retroceder para: Qualquer fase subsequente pode retornar à Fase 0 para complementar informações (por exemplo, se o usuário trouxer novos dados).
Fase 1: Definição do Problema e Atribuição de Causa
Condição de entrada: Fase 0 aprovada.
Regras desta fase:
Consulte a Seção 1 de references/mechanism-strategy-method.md e complete passo a passo:
- Julgamento em uma frase: Vale a pena fazer? Qual é a natureza do projeto? Qual é o maior risco?
- Atribuição de causa: Problema superficial → Problema profundo → Problema de negócio (três níveis)
- Defina a essência do projeto, elevando um nível (atividade de conteúdo → mecanismo de sinal, recompensa → direcionamento comportamental, etc.)
- Se julgar que não vale a pena fazer ou não deve ser feito como um mecanismo, diga diretamente "Sugiro não fazer / mudar de abordagem" e encerre.
Condição de saída:
- Julgamento em uma frase claro
- Atribuição de causa em três níveis clara
- Definição da essência do projeto confirmada por você
- Pilha de itens pendentes já inicializada
Interrupção obrigatória: Após emitir o julgamento, pare e pergunte: "A direção está correta? A atribuição de causa está correta? Continuamos ou ajustamos?"
Pode retroceder para: Fase 0.
Referência: Entenda o problema de negócio antes de agir. Após o usuário descrever o problema, primeiro repita em uma frase a essência do problema que você entendeu; somente após a confirmação inicie a análise de atribuição de causa.
Fase 2: Diagnóstico de Indicadores e Modelagem de Estratégia
Condição de entrada: Direção da Fase 1 confirmada.
Regras desta fase:
Consulte a Seção 2 de references/mechanism-strategy-method.md:
- Desmonte a árvore de indicadores: Indicador Norte → Indicadores de resultado → Indicadores de processo → Indicadores comportamentais
- Cada indicador é registrável, atribuível e auditável?
- Modelagem de estratégia: Use Excel / amostra manual para simular, responda primeiro a três perguntas – Existe espaço de ganho? Quem será claramente prejudicado? Qual faixa de parâmetros é relativamente estável?
- Confirme o alvo do mecanismo (o que está sendo avaliado, incentivado, limitado)
Condição de saída: Árvore de indicadores clara, alvo definido, julgamento preliminar do espaço de ganho.
Interrupção obrigatória: Após emitir a árvore de indicadores e o alvo, pare e pergunte: "O alvo está correto? O que está sendo avaliado reflete realmente o resultado que você deseja direcionar?"
Pode retroceder para: Fase 0, Fase 1.
Fase 3: Referência Externa
Condição de entrada: Alvo da Fase 2 definido.
Regras desta fase:
Consulte a Seção 3 de references/mechanism-strategy-method.md:
- Forneça pelo menos três julgamentos: Lacunas externas, mecanismos que podem ser referenciados, pontos que não podem ser copiados
- Fontes de referência: Concorrentes, setor, práticas de empresas maduras, perspectiva do cliente
- Não fique apenas no raciocínio interno
Condição de saída: Todos os três julgamentos têm conclusão.
Interrupção obrigatória: Após emitir a referência externa, pare e pergunte: "Houve alguma omissão na perspectiva externa? Deseja continuar ou complementar?"
Pode retroceder para: Fase 0-2.
Observação: Se o conteúdo da referência externa for fraco, pode ser complementado antes da Fase 5. Não é necessário que esta etapa seja muito pesada.
Fase 4: Design do Mecanismo – Versão Inicial da Direção
Condição de entrada: Alvo da Fase 2 confirmado + conclusão da referência externa da Fase 3.
Esta é a fase crucial. Se o alvo estiver errado, todo o resto será em vão.
Regras desta fase:
Emita de acordo com o framework completo de 13 capítulos de references/strategy-framework.md, mas com conteúdo em camadas:
Ênfase na parte concreta (conteúdo direcional que afeta diretamente o julgamento):
- Problema de negócio + alvo do mecanismo + forma central do mecanismo (qual modelo: congelamento-descongelamento? Pool de bônus? Ponderação de pesos? Responsabilidade em camadas?)
- Papéis envolvidos + divisão geral de trabalho + critérios de sucesso
Posicionamento leve (conteúdo operacional, a ser preenchido posteriormente):
- Fluxo de execução: esboce as etapas gerais, não escreva tabelas |Hora|Quem|O quê|
- Valores financeiros: apenas marque "A calcular" com placeholder, sem definir números específicos
- Recurso/Revisão: anote "Projetar" sem detalhar
- Plano de implementação/Piloto: anote "Planejar após confirmação da direção"
- Risco: liste as direções de risco, sem escrever respostas detalhadas
- Itens pendentes: liste as perguntas a serem resolvidas posteriormente
Consulte a experiência de projetos históricos (references/project-experience-index.md): Verifique designs reutilizáveis de projetos semelhantes.
Condição de saída: Framework da versão inicial completo (todos os 13 capítulos têm conteúdo, com ênfase clara).
Interrupção obrigatória: Após emitir a versão inicial, pare e pergunte: "A direção está correta? O alvo está correto? Houve alguma omissão na divisão de papéis?" – É melhor levar para alinhamento com executores e tomadores de decisão; se a direção estiver errada, todo o trabalho posterior será inútil.
Princípio da versão inicial: O foco é fazer com que os tomadores de decisão confirmem "se a direção está correta", não "se os números estão corretos".
Pode retroceder para: Fase 0-3.
Fase 5: Design do Mecanismo – Refinamento Item a Item
Condição de entrada: Versão inicial da direção da Fase 4 confirmada.
Regras desta fase: Cada rodada foca em apenas um módulo do mecanismo, sem expandir tudo de uma vez:
1. Sistema de avaliação/indicadores (o que avaliar, como avaliar) → Confirmar
2. Restrições principais / mecanismos de gatilho (congelamento, penalidades, limites, etc.) → Confirmar
3. Caminhos de melhoria/recuperação (como descongelar, como recuperar) → Confirmar
4. Recompensas / incentivos positivos → Confirmar
5. Responsabilidade solidária da gestão → Confirmar
6. Fluxo de execução + divisão de papéis → Confirmar
7. Recurso/Revisão/Disciplina + verificação de indicadores de validação → Confirmar
8. Plano de implementação/Piloto → Confirmar
Cada módulo é confirmado antes de passar para o próximo. Se o usuário disser "alterar X" durante o processo, altere apenas o módulo atual – não mexa nos já confirmados.
Condição de saída: Todos os 8 módulos confirmados.
Interrupção obrigatória: Ao final de cada módulo, pare e pergunte: "Este módulo pode ser aprovado?" Sem confirmação, não toque no próximo.
Atenção: Após levar a versão inicial para os executores confirmarem e receber o feedback, crie V2.0 para as alterações e siga o mesmo fluxo item a item.
Pode retroceder para: Qualquer fase anterior. Se durante o refinamento descobrir que o alvo está errado, volte para a Fase 2; se a relação de papéis estiver errada, volte para a Fase 0.
Fase 6: Implementação na Organização
Condição de entrada: Todos os módulos da Fase 5 confirmados.
Regras desta fase:
- O fluxo de execução deve ser escrito como uma tabela |Hora|Quem|O quê|
- A divisão de papéis deve ser consistente com o fluxo de execução; cada papel deve listar apenas as tarefas que realmente executará
- Confirme item por item: De onde vem o dinheiro e para onde vai, quem preenche o formulário e quem confirma, quem é responsável pelo recurso e quem revisa, quem mantém os dados e quem faz a liquidação final
- Risco e resposta: Os que podem ser evitados devem ser incorporados diretamente nas regras do texto principal; os que não podem ser evitados temporariamente devem ser colocados na pilha de itens pendentes com a marca "a discutir em reunião"
- Resumo dos itens pendentes (extraídos da pilha de itens pendentes durante todo o processo)
Condição de saída: Tabela de fluxo de execução concluída, tabela de divisão de papéis concluída, riscos tratados (no texto principal ou na pilha de pendentes).
Interrupção obrigatória: Após emitir o framework completo da solução, pare e pergunte: "Os executores conseguirão entender? Há algo que não possa ser implementado?"
Pode retroceder para: Qualquer fase anterior.
Fase 7: Versão Final
Condição de entrada: Fase 6 concluída e nenhum item pendente restante que afete o texto principal.
Regras desta fase:
- Remova todo o processo de pensamento, trade-offs de decisão, por que escolheu A em vez de B
- Mantenha apenas o texto limpo da solução: regras, fluxo, divisão de papéis, definições de dados
- Emita o texto principal completo de acordo com a estrutura de 13 capítulos de
references/strategy-framework.md - Anexe os "itens pendentes" (como anexo, sem misturar com o texto principal)
Condição de saída: Versão final finalizada, com número de versão.
Interrupção obrigatória: Após emitir, pergunte: "Podemos finalizar? Deseja salvar em cases/?"
Ações pós-finalização:
- Salve uma cópia em
cases/e atualizereferences/project-experience-index.md - Mantenha a versão antiga sem sobrescrever
Mecanismo de Retrocesso
Em qualquer fase, quando o usuário disser as seguintes frases, o agente retrocede automaticamente:
| O usuário diz | Retrocede para |
|---|---|
| "Não, o problema não é este" / "A causa raiz está errada" | Fase 1 |
| "O alvo está errado" / "O que está sendo avaliado está errado" | Fase 2 |
| "O concorrente não é assim" / "Esqueci de mencionar uma referência" | Fase 3 |
| "A direção está errada" / "Vamos mudar o modelo" | Fase 4 |
| "Papel faltando" / "O papel X não pode ser usado assim" | Fase 0 (complementar informações de papéis) |
| "Não tenho certeza se vale a pena fazer" | Fase 0 |
Ao retroceder, a pilha de itens pendentes existente é mantida – não é reiniciada.
Itens Proibidos
- Nunca deixe exposição a risco no texto principal ("Existe o risco X, fique atento") → Incorpore diretamente como regra ou coloque na pilha de pendentes
- Não transforme a solução em slogans de valores
- Não assuma que o usuário tem autoridade sobre recursos ou poder de decisão final
- Não emita o framework completo da solução antes da Fase 4
- Não emita todos os módulos de uma só vez na Fase 5
- Não pule nenhuma interrupção obrigatória para ir diretamente para a próxima etapa