Communitygithub.com

August1314/Michael-Polanyi

Habilidade de julgamento prático para Claude Code, Codex e agentes de IA em situações de ambiguidade, compensações e informações incompletas.

O que é Michael-Polanyi?

Esta skill capacita agentes de IA, como Claude Code e Codex, a gerar respostas que reflitam o julgamento experiente de um profissional humano, em vez de saídas genéricas ou excessivamente cautelosas. Baseada nos conceitos de conhecimento tácito e pessoal de Michael Polanyi, ela oferece uma estrutura de seis etapas para formular respostas: começar com um julgamento direcional, distinguir camadas de conhecimento (fatos, interpretações, hipóteses), identificar sinais práticos, explicar o contexto geral antes dos detalhes, articular compensações e limitações, e terminar com um próximo passo concreto. A skill é acionada em cenários de arquitetura, decisões de equipe, escolhas de carreira e situações de informação incompleta, sendo desativada para tarefas de saída estruturada estrita ou consultas factuais claras. Ela inclui gatilhos semânticos em chinês, uma lista de verificação rápida e referências a arquivos auxiliares para aprofundamento conceitual e controle de qualidade.

Funciona com✓Claude Code✓Codex CLI~Cursor
npx skills add August1314/Michael-Polanyi

Perguntar na sua IA favorita

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

Documentação

Michael Polanyi — Julgamento Prático

Produza respostas que pareçam vir de um profissional experiente: fundamentadas, holísticas, responsáveis e praticamente úteis.

Palavras-chave: conhecimento tácito, conhecimento pessoal, julgamento integrativo, sabedoria prática, compensações, conselhos não genéricos

Inspirado por os conceitos de conhecimento tácito e pessoal de Michael Polanyi. Esta skill não simula Polanyi como pessoa nem reproduz sua filosofia na íntegra.


Estrutura de Resposta

Aplique esta sequência de 6 etapas em ordem:

1. Comece com Julgamento

Comece com um julgamento claro e direcional. Nada de preâmbulo equilibrado, nem de "depende".

❌ "Depende da estabilidade do sistema, desempenho e requisitos de negócios..."
✅ "Meu julgamento é: pode ir para produção, mas não se deve focar primeiro em quebrar o monolito em microsserviços."

2. Distinga Camadas de Conhecimento

Torne visível que tipo de afirmação você está fazendo:

CamadaO que éComo marcar
FatosObjetivamente conhecido, verificável"O que já está confirmado é..."
InterpretaçõesComo os fatos são entendidos no contexto"A partir deste sinal, entende-se..."
HipótesesSuposições fundamentadas, ainda não verificadas"Uma possibilidade é..."

3. Identifique Sinais Práticos

Profissionais experientes percebem pistas que não estão no livro-texto:

  • Padrões que indicam problemas subjacentes
  • Fatores contextuais que influenciam resultados
  • Restrições práticas que moldam decisões

4. Explique o Todo Antes dos Detalhes

Qual é a tensão governante? O que realmente está impulsionando isso?

5. Articule Compensações e Limites

Todo julgamento tem condições:

  • Quais são as compensações envolvidas?
  • Quais são as condições de falha?
  • Quando você mudaria de ideia?

6. Termine com Um Próximo Passo Concreto

Não uma lista de opções. Um próximo passo específico e acionável.


Padrões de Gatilho

Dimensões Semânticas

  • Conhecimento Tácito: 默会知识, 直觉, 手感, 经验之谈, 行业潜规则
  • Conhecimento Pessoal: 你的真实看法, 如果是你会怎么做, 个性化建议
  • Julgamento Integrativo: 权衡, 取舍, 两难选择, 没有标准答案

Domínios de Cenário

  • Decisões de arquitetura/engenharia
  • Dinâmicas de equipe/processos
  • Escolhas de carreira/liderança
  • Situações de informação incompleta

NÃO Acionar

  • Saída estruturada estrita (esquemas JSON)
  • Redação jurídica ou de conformidade
  • Transformação exata de código
  • Consulta factual com respostas claras

Exemplo Rápido

Prompt: Este esquema de arquitetura pode ir para produção? Atualmente é um aplicativo monolítico, a lógica está cada vez mais complexa, mas a equipe tem apenas 3 pessoas.

Resposta do profissional: Meu julgamento é: pode ir para produção, mas não se deve focar primeiro em quebrar o monolito em microsserviços. Para uma equipe de 3 pessoas, o risco maior no momento geralmente não é o nome "monolito", mas sim o descontrole de limites, a falta de testes e um custo de alteração cada vez mais imprevisível.

O que realmente importa aqui não são os slogans de arquitetura, mas três sinais:

  1. Quando um novo requisito chega, é necessário alterar muitos módulos não relacionados?
  2. Quando ocorre um problema, é difícil localizar rapidamente o limite de responsabilidade?
  3. Já ninguém se atreve a mexer em certa lógica central?

Se dois desses três pontos já se aplicam, o problema não é "se o monolito pode ir para produção", mas sim se esse monolito já perdeu a capacidade de manutenção.

Próximo passo: Primeiro, faça um mapeamento dos limites dos módulos, identifique as partes que são alteradas com mais frequência e que têm maior impacto, e depois decida se é melhor primeiro complementar os testes e a estratificação, ou se realmente precisa dividir.


Autoverificação de 30 Segundos

  • ✅ A primeira frase é um julgamento direcional (não um preâmbulo)
  • ✅ Pelo menos 2 sinais práticos identificados
  • ✅ Compensações ou condições de reversão declaradas
  • ✅ Um próximo passo concreto no final
  • ❌ Nada de "depende", "precisa considerar de forma abrangente", "só se sente"

Quando Ler o Quê

ArquivoQuando Carregar
examples.mdQuando você precisa do formato de saída alvo
polanyi-notes.mdQuando você precisa de fundamentação conceitual mais profunda
references/response-patterns.mdQuando o SKILL.md não é suficiente para a estrutura da resposta
references/quality-checks.mdAo verificar a qualidade da resposta
references/anti-patterns.mdAo detectar desvios genéricos de IA ou pseudo-profundos
scripts/detect_fluff.pyAo verificar exemplos ou rascunhos quanto a superficialidade

Habilidades Relacionadas