give-me-tips - explique qualquer dica do senpi, em profundidade

Propósito

O Senpi mostra dicas ao usuário: dicas de inicialização, dicas de trabalho e linhas Tip: injetadas por componentes omo. Quando o usuário pergunta sobre qualquer uma delas - "o que foi aquela linha Tip:", "o que significa essa dica", "como funciona esse recurso" - esta habilidade produz uma explicação PROFUNDA dessa dica exata, no idioma DO USUÁRIO (corresponda ao idioma em que ele perguntou, sempre).

Específico sobre genérico, sempre. "Ele tenta novamente em caso de falha" é uma falha desta habilidade. "Ele detecta a recusa dos stopDetails no evento message_end do assistente, controla a categoria architect em seu .omo/omo.json e só então injeta a diretiva" é o padrão. O usuário perguntou porque a dica o deixou curioso; recompense essa curiosidade com o mecanismo real, não um resumo do texto da dica que ele já leu.

Consulte a lista de dicas ativa PRIMEIRO

Nunca explique de memória. Obtenha a verdade absoluta do que as dicas existem:

1. Execute o flag de listagem de dicas do comando em que este produto está instalado: omo --list-tips sob OmO Native (instalações omo-ai; o ambiente de sessão carrega OMO_NATIVE=1 e OMO_BIN), ou senpi --list-tips sob uma instalação senpi simples. Nunca escreva senpi em uma máquina OmO Native: gerenciadores de pacotes vinculam apenas o binário de nível superior omo, então senpi não está no PATH lá. Se o comando da marca também não estiver no PATH (lançamentos bunx/npx), invoque o lançador para o qual a variável OMO_BIN aponta: "$OMO_BIN" --list-tips. O comando imprime JSON: [{id, text, requiresCommand?}]. Corresponda à dica do usuário com esta lista por ID ou por fragmento de texto.
2. Se o flag não estiver disponível nesta versão do senpi, recorra à leitura direta das fontes do catálogo em packages/coding-agent/src/modes/interactive/tips/catalog/ dentro do pacote @code-yeongyu/senpi instalado (encontre-o pelo caminho de instalação do senpi ou node_modules) ou em um clone local de code-yeongyu/senpi.

Então - e esta é a parte que a maioria das explicações erra - as dicas disponíveis DIFEREM por usuário. O catálogo é o superconjunto; o que ESTE usuário pode realmente ver é controlado por:

• o toggle tips no diretório do agente senpi settings.json (as dicas podem estar completamente desativadas),
• tipsHistory nas mesmas configurações/estado, que controlam a rotação de cooldown para que uma dica que o usuário viu recentemente não reapareça por um tempo,
• controle requiresCommand: uma dica vinculada a um comando só aparece quando esse comando está disponível,
• disponibilidade de atalhos de teclado: algumas dicas referenciam atalhos que a configuração do usuário pode não ter.

Leia o diretório do agente senpi settings.json (e seu estado de histórico de dicas) ANTES de explicar, e diga ao usuário quais dicas ele pessoalmente pode encontrar e por quê - não o catálogo completo como se todos vissem tudo.

Verifique antes de explicar

Nunca invente comportamento. Uma dica é uma promessa de uma linha; a verdade vive no código. Antes de escrever a explicação, leia a implementação real do recurso:

• o próprio senpi: code-yeongyu/senpi, sob packages/coding-agent/ (o catálogo de dicas fica em packages/coding-agent/src/modes/interactive/tips/catalog/; os recursos para os quais as dicas apontam ficam nos pacotes circundantes),
• componentes omo: code-yeongyu/oh-my-openagent, sob packages/omo-senpi/.

Cite os caminhos de arquivo concretos que você leu em sua explicação. Se o código e o texto da dica discordarem, o código vence - diga isso e mostre o que ele realmente faz.

Tom: GABAR-SE

Essas dicas existem porque alguém projetou algo genuinamente impressionante, e um resumo plano em documentação trai isso. Comece com a engenharia mais impressionante por trás da dica - a detecção inteligente, a corrida que teve que ser fechada, a máquina de estados escondida sob uma frase - e mostre-a. O usuário deve terminar a explicação sentindo que fez um tour pela sala de máquinas, não que leu um adesivo. Mecânica concreta sobre adjetivos: nomeie os eventos, os controles, os caminhos de arquivo, a ordem exata das operações.

A dica Fable-5-refusal especificamente

Quando o usuário perguntar sobre a dica que aparece após uma recusa do Fable 5 ("Fable 5 refused, but its refusals should not wear you down..."), explique o pipeline completo de fallback-architect, citando packages/omo-senpi/src/components/fallback-architect/:

1. Detecção de recusa (detection.ts): o componente monitora eventos message_end e aplica a mesma semântica de recusa que o próprio classificador de retentativas do senpi usa - stopReason verificado PRIMEIRO (então um abort ou stop normal carregando stale stopDetails nunca pode se disfarçar de recusa), então

…