CommunityEscrita e Ediçãogithub.com

TongyiDai/feishu-okr-drafter

飞书 OKR 草稿|按严格 OKR 标准写出有结果、有指标、有承接、有主责的高质量 OKR,并支持写入飞书、真实 @ 与保存核验。

O que é feishu-okr-drafter?

Este skill é um assistente especializado na criação e redação de OKRs (Objetivos e Resultados-Chave) dentro do ecossistema Feishu (Lark). Ele transforma múltiplas fontes de trabalho — como anotações, documentos, capturas de tela e resumos — em rascunhos de OKR de alta qualidade, seguindo padrões rigorosos de resultado, métricas e responsabilidade. O assistente prioriza a segurança e a precisão: ele só grava ou menciona colaboradores após autorização explícita do usuário, mantendo um modo somente leitura por padrão. Seu fluxo de trabalho envolve a leitura de contextos históricos (OKRs passados, menções, feedbacks) e a verificação de quatro relacionamentos-chave: conclusão do ciclo anterior, menções recebidas, menções feitas e OKRs do superior direto. Ao gerar rascunhos, ele aplica regras claras para escrever Objetivos (foco em alto valor, evitando tarefas rotineiras) e Resultados-Chave (mensuráveis, com prazos e responsáveis), e realiza uma verificação de qualidade antes de apresentar o resultado em uma estrutura padronizada. As operações de gravação no Feishu são feitas com cuidado, usando dry-runs, resolução de IDs de usuário e leitura de volta para confirmar o sucesso. O skill suporta interfaces de API e de navegador controlado para interagir com o Feishu.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add TongyiDai/feishu-okr-drafter

Installed? Explore more Escrita e Edição skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

Perguntar na sua IA favorita

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

Documentação

Rascunho de OKR no Feishu

Objetivo e Limites

Organizar fatos de trabalho de múltiplas fontes em OKRs do Feishu que sejam discutíveis, mensuráveis e alinháveis, e, após autorização explícita do usuário, gravar o rascunho e mencionar os colaboradores correspondentes. A interface serve para acelerar o processo; páginas do Feishu, documentos históricos, capturas de tela, conteúdo colado pelo usuário e resumos de trabalho também são entradas válidas. O padrão é primeiro realizar a análise e gerar o rascunho, sem criar, publicar ou modificar OKRs existentes.

Respeite três limites fundamentais:

  • Não preencher valores-alvo, linhas de base, prazos, responsáveis, resultados de negócios ou objetos de alinhamento que não existam; informações ausentes devem ser escritas como [a confirmar].
  • Reportar separadamente as ações de rascunho, gravação, salvamento e publicação; não declarar conclusão sem evidência de leitura de volta.
  • Ao lidar com dados sensíveis de receita, custo, cliente, pessoal ou estratégia, priorizar o uso de proporções, intervalos, taxas de conclusão ou expressões anonimizadas já confirmadas, e sinalizar as partes que requerem comunicação separada.

Fluxo de Trabalho

1. Determinar o Modo da Tarefa

Identificar o que o usuário deseja fazer:

  1. Gerar um novo rascunho a partir de anotações de trabalho;
  2. Reescrever um O/KR existente;
  3. Revisar a qualidade e o alinhamento;
  4. Gravar o rascunho no Feishu;
  5. Ajustar objetivos, KRs, pesos ou prazos em um ciclo.

Na ausência de intenção explícita de gravação, permanecer no modo somente leitura e rascunho.

2. Estabelecer Contexto e Caminhos de Dados

Primeiro, ler as descrições da versão atual de lark-shared e lark-okr. Ao precisar ler conteúdo do Feishu, executar a verificação de identidade, locatário e permissões:

lark-cli auth status --json --verify
lark-cli contact +get-user --as user

Em ambientes que suportam auth status --json --verify, é necessário confirmar identity=user e verified=true. Se a construção atual da CLI não tiver o subcomando auth, pode-se usar contact +get-user --as user para analisar o usuário atual; se precisar continuar no modo de rascunho, usar task +get-my-tasks --as user para provar que o user-context é legível. Antes de realmente gravar OKRs ou mencionar colaboradores, ainda é necessário confirmar o usuário e o locatário de destino.

Selecionar os caminhos de dados disponíveis na seguinte ordem; não tratar "interface indisponível" como ponto final da tarefa:

  1. Caminho de Interface/CLI: quando as permissões permitirem, usar a interface para ler em lote ciclos, O/KRs, indicadores, progresso e relações de alinhamento.
  2. Caminho de Página do Feishu: quando a interface estiver ausente, o escopo for insuficiente ou for necessário confirmar o estado de salvamento da página, usar control-in-app-browser. Priorizar assumir o controle da página de OKR que o usuário já tem aberta; se não houver página disponível, fazer apenas uma navegação clara para a entrada de OKR do Feishu. Ler com base na página visível, não adivinhar URLs, ordem de campos ou significados de botões.
  3. Caminho de Materiais do Usuário: ler textos, capturas de tela, documentos, atas de reunião, resumos de desempenho, autoavaliações H1 e retrospectivas de trabalho fornecidos pelo usuário.
  4. Caminho de Documentos do Feishu: pesquisar e ler documentos de definição, redação, alinhamento e exemplos de posições de OKR acessíveis no locatário atual.

Mesmo quando a interface for bem-sucedida, combinar com a página ou o texto original para verificar o estado crítico; quando a página for bem-sucedida, manter os fatos da página e não descartar evidências apenas porque não podem formar um ID de API.

Obter conforme necessário:

  • Ciclo de destino do usuário atual: okr +cycle-list;
  • O/KRs dentro de um ciclo: okr +cycle-detail;
  • Indicadores do O, indicadores do KR: objective.indicators list, key_result.indicators list;
  • Alinhamentos do O: objective.alignments list;
  • Registros de progresso relacionados: okr +progress-list;
  • Documentos do Feishu relacionados: pesquisar por OKR, definição, redação, alinhamento, assistente de preenchimento, priorizando ler normas e exemplos acessíveis no locatário atual.

O julgamento do ciclo deve ter como primeira condição a sobreposição entre datas de início/término e a data atual, e depois referenciar o estado do ciclo; quando o usuário não especificar claramente, não tratar o ciclo anual como o ciclo atual padrão.

Se o escopo dedicado para OKR estiver faltando, parar de tentar repetidamente cegamente e explicar o escopo ausente e seu impacto. Pode-se continuar gerando rascunhos com contexto limitado com base nos materiais de trabalho fornecidos pelo usuário e nos documentos do Feishu que têm permissão de leitura.

2.1 Usar Materiais Históricos

OKRs históricos são uma referência importante. Pelo menos verificar o ciclo mais recente concluído; quando possível, verificar ciclos anteriores, registros de progresso, pontuações, comentários, resumos de desempenho e autoavaliações H1.

Classificar o conteúdo histórico em quatro categorias:

  • Fatos concluídos: usar como linha de base, prova de capacidade ou evidência de caso; não copiar diretamente como novos KRs;
  • Itens de alta prioridade não concluídos ou recorrentes: tratar como possíveis linhas principais do ciclo atual, redefinindo resultados de fase;
  • Feedback repetido de superiores ou colegas: transformar em resultados de qualidade, colaboração ou mecanismos;
  • Capacidades já formadas mas ainda não replicadas: transformar em resultados de escalabilidade, padronização, execução independente por outros ou resultados de negócios.

Estabelecer um registro de fontes breve: fato → fonte → momento → função no novo O/KR → precisa de confirmação. Separar conquistas passadas de compromissos futuros.

2.2 Ler Quatro Tipos de Contexto de Relacionamento de OKR

Antes de escrever OKRs para o ciclo atual, verificar sempre os quatro tipos de relacionamento a seguir; na falta de interface, complementar via página de OKR do Feishu, captura de tela, conteúdo colado pelo usuário ou documentos acessíveis:

  1. Conclusão pessoal do ciclo anterior: comparar um a um os valores-alvo, progresso, pontuações, comentários e resultados reais dos O/KRs. Distinguir entre concluído, parcialmente concluído, não concluído, mudança de objetivo e evidência ausente; trazer apenas itens não encerrados que ainda fazem sentido para o ciclo atual ou novos resultados de fase.
  2. Menções recebidas no ciclo atual: coletar em quais O/KRs foi mencionado, por quem, qual a expectativa de colaboração, prazo de entrega e limites de responsabilidade. Classificá-los como candidatos a responsável principal, colaborador, itens a confirmar ou menções informativas; não tratar automaticamente uma menção como um compromisso.
  3. Menções feitas a outros no ciclo anterior: revisar a quem o usuário mencionou, os O/KRs correspondentes, o conteúdo da colaboração e se houve conclusão do ciclo. Identificar dependências contínuas, repetição de contatos, desajustes de colaboração e relacionamentos que podem ser consolidados em mecanismos; manter apenas as relações de colaboração que ainda são válidas para o ciclo atual.
  4. OKRs do superior direto: confirmar a identidade do superior direto, o ciclo atual, a ordem dos O/KRs, os resultados principais, a métrica e os limites de colaboração. Determinar se o O pessoal é um desdobramento, suporte, colaboração horizontal ou linha principal independente; quando o OKR do superior estiver ausente, o ciclo for incerto ou a identidade não puder ser verificada, marcar os limites e não inferir.

Estabelecer um registro de relacionamentos: tipo de relação → objeto de origem → O/KR → outra pessoa/colaborador → fato ou expectativa → tratamento no ciclo atual → já confirmado. Usar as quatro categorias de informações respectivamente como "resultados históricos", "entradas de colaboração", "retrospectiva de colaboração" e "desdobramento vertical", evitando misturar tudo em uma única lista de tarefas.

3. Coletar o Mínimo de Entradas Necessárias

Pelo menos confirmar: ciclo, função ou escopo de responsabilidade, resultados de negócios a serem alcançados, linha de base conhecida, valor-alvo ou critério de julgamento, principais partes colaboradoras, restrições e informações sensíveis.

Quando já houver OKRs de superiores ou da equipe, primeiro identificar:

  • Quais O's precisam ser desdobrados;
  • Quais KRs são colaboração entre pares;
  • Quais trabalhos são de responsabilidade principal do usuário e quais são de suporte;
  • Se o trabalho proposto pelo usuário se sobrepõe ou conflita com O's existentes.

Se houver um superior direto, o OKR do ciclo atual do superior direto é a referência principal para desdobramento vertical; OKRs da equipe, OKRs de pares e conteúdo de menções servem para complementar o escopo de desdobramento e os limites de colaboração. Menções recebidas, menções feitas e "parece relevante" só podem formar relacionamentos candidatos; somente quando o conteúdo, a responsabilidade principal, o ciclo e a confirmação de ambas as partes coincidirem, pode-se relatar como alinhado.

Quando faltarem entradas críticas, usar o mínimo de perguntas para complementar; se ainda não for possível confirmar, continuar produzindo, mas colocar explicitamente a incerteza em [a confirmar].

4. Gerar Rascunho

Redação do O

  • Focar em trabalhos de alta prioridade e alto valor, excluindo acúmulo de tarefas rotineiras; sugerir 3–5, permitindo menos quando o escopo de trabalho for estreito.
  • Escrever claramente a direção, o valor esperado e o horizonte de tempo; manter granularidade adequada, evitando frases de efeito ou listas de tarefas.
  • Manter certo desafio, evitando tratar "continuar fazendo" como um objetivo.
  • Para itens de longo prazo, dividir em resultados de fase para o ciclo atual.
  • Usar vocabulário de negócios que o leitor entenda na primeira leitura; manter nomes próprios já confirmados pela organização.

Quando o usuário listar vários projetos ou campanhas de uma vez, primeiro agrupar por resultado de negócio e depois decidir o número de O's. Nomes de projetos geralmente entram no KR, caminho de implementação ou coluna de evidência; só se tornam um O separado se representarem uma linha de resultado independente. Direções comuns de agrupamento incluem resultado para cliente/negócio, eficiência de processo ponta a ponta, productização e replicação, mecanismos organizacionais e influência.

Redação do KR

  • Cada O deve ter 3–5 KRs, cobrindo diferentes dimensões críticas de suporte.
  • Escrever primeiro o resultado e o estado, depois complementar o caminho de implementação necessário; evitar escrever apenas "concluído", "responsável", "impulsionar", "acompanhar".
  • Fornecer critérios de julgamento objetivos e observáveis, qualitativos ou quantitativos; após "melhorar", "otimizar", "aumentar", complementar o ponto de partida, ponto de chegada ou condição de aceitação.
  • Especificar o prazo dentro do ciclo; quando o valor-alvo for desconhecido, manter [valor-alvo a confirmar].
  • Quando for necessária colaboração, indicar o responsável principal, colaboradores e os limites de responsabilidade; geralmente não mais que 4 colaboradores principais.
  • Se for necessário explicar a direção do KR, usar um subtítulo curto, por exemplo 【Valor para o Cliente】, 【Eficiência de Processo】, evitando misturar múltiplas linhas principais em uma.

Priorizar a organização de um KR com a seguinte estrutura:

【Aspecto-chave】Através de [caminho necessário], até [prazo] atingir [resultado observável/valor-alvo], sob responsabilidade de [responsável principal], com a colaboração de @ [colaborador].

Se o caminho for muito longo, pode ser encurtado; resultado, prazo e critério de aceitação devem ser preservados.

5. Executar Verificação de Qualidade

Verificar cada O e KR individualmente e classificar os problemas em "bloqueia publicação" e "recomendação de melhoria". Regras detalhadas em references/okr-writing-principles.md.

Verificar principalmente:

  • Se o O é de alta prioridade, claro, moderadamente desafiador e corresponde ao ciclo atual;
  • Se o KR suporta diretamente o O, descreve um resultado, é mensurável, alcançável e tem limite de tempo;
  • Se os KRs são redundantes, se falta uma dimensão crucial de suporte ou se entram em conflito;
  • Se o valor-alvo, linha de base, data e responsável têm fonte;
  • Se há desdobramento vertical, colaboração horizontal, responsabilidade principal clara e objeto de alinhamento real;
  • Se já foram verificados o grau de conclusão do ciclo anterior, menções recebidas no ciclo atual, menções feitas no ciclo anterior e OKRs do superior direto;
  • Se a ordem dos objetivos, nomes próprios e informações privadas/sensíveis estão consistentes;
  • Se pontuação, progresso, peso e valor-alvo não são confundidos entre si.

6. Produzir o Rascunho

Entregar na seguinte ordem:

  1. Ciclo e Contexto: quais ciclos, O de superior, documentos e entrada do usuário foram usados; explicar os limites de leitura.
  2. Rascunho do OKR: para cada O, listar KRs, critérios de resultado, prazos, responsável principal, partes colaboradoras e fonte da evidência.
  3. Continuidade Histórica: quais fatos históricos se tornaram linha de base, quais itens continuam, quais resultados foram elevados para replicação ou escalabilidade.
  4. Lista de Relacionamentos e Desdobramento: grau de conclusão do ciclo anterior, menções recebidas no ciclo atual, menções feitas no ciclo anterior, desdobramento do superior direto, objetos sugeridos para menção, conflitos e itens a comunicar.
  5. Diagnóstico de Qualidade: itens que bloqueiam, recomendações de melhoria, hipóteses ainda não verificadas.
  6. A Confirmar: listar apenas itens que mudariam o significado do objetivo, o padrão de resultado ou a gravação no sistema.

É proibido usar um conjunto de números aparentemente completo para mascarar incertezas. O julgamento de qualidade deve explicar "por que este KR prova que o O foi alcançado".

7. Gravar no Feishu

Só executar operações de gravação quando o usuário solicitar explicitamente a gravação ou salvamento. Antes de gravar:

  1. Confirmar novamente o usuário atual, locatário, ciclo, propriedade do objetivo e rascunho completo;
  2. Estabelecer uma "lista de gravação e menções": para cada O/KR, listar colaborador, motivo da menção, limite de responsabilidade principal, fonte e estado de verificação;
  3. Resolver cada nome ou e-mail para open_id usando lark-cli contact +search-user. Quando houver múltiplos candidatos, locatários diferentes ou informações de identidade insuficientes, pausar a menção correspondente e solicitar confirmação; não adivinhar;
  4. Primeiro usar --dry-run para verificar a solicitação;
  5. Para texto simples e menções, priorizar o estilo simple; quando for necessário controle preciso da posição da menção, usar o elemento mention do richtext;
  6. Ao criar múltiplos O/KRs novos, priorizar okr +batch-create; para um único O ou KR, usar okr +create; colocar o mention no O/KR correspondente, evitando mencionar todos em um único objetivo;
  7. Não definir automaticamente pontuação com base em "rascunho"; pontuação só deve ser tratada quando o usuário solicitar explicitamente uma avaliação;
  8. Após a gravação, reler os detalhes do ciclo e verificar quantidade de O/KRs, texto, ordem, pesos, prazos, menções e estado de salvamento/publicação;
  9. Quando a leitura de volta estiver incompleta, as menções não tiverem sido aplicadas ou a semântica do sistema puder publicar diretamente, parar e explicar ao usuário; não continuar.

Determinação de Gravação e Menção

  • Quando o usuário disser apenas "rascunhar", "gerar", "otimizar", produzir apenas um rascunho local e uma lista de sugestões de menção.
  • Quando o usuário disser explicitamente "gravar", "salvar no Feishu", "preencher para mim", pode-se criar o rascunho; quando o usuário também disser explicitamente "mencionar fulano" ou o registro de relacionamento já tiver um colaborador verificado, só então gravar a menção.
  • mention é um ID de usuário real, não uma string @nome no texto. No caminho da interface, colocar mention: ["ou_xxx"] no O/KR correspondente; no caminho da página, usar o seletor de usuário e reler a tag de usuário real na página.
  • Explicar separadamente o motivo da menção ao responsável principal, colaborador e superior direto; relações candidatas formadas apenas por "relevante" ou "foi mencionado" devem primeiro entrar na lista de itens a confirmar.
  • Reportar separadamente os resultados da gravação: criado/salvo, mencionado, não mencionado + motivo, não publicado. Para qualquer item que não tenha evidência de leitura de volta, manter como não verificado.

Quando a interface não puder gravar, pode-se usar a opção "Colar OKR em lote" ou o controle de edição da página na página de OKR do Feishu já logada para salvar o rascunho. O caminho da página deve seguir a seguinte ordem:

  1. Primeiro confirmar o usuário atual, ciclo e título da página;
  2. Após colar O/KRs, verificar a pré-visualização da análise, confirmar quantidade e hierarquia dos O/KRs; quando a colagem em lote não puder gerar menções reais, usar o controle de edição da página para selecionar colaboradores um a um;
  3. Para cada O/KR que precise de menção, usar o seletor de usuário da página, verificar o nome exibido e o departamento, evitando apenas digitar o texto normal @nome;
  4. Executar apenas a confirmação de salvamento, não clicar em publicar;
  5. Voltar à página final para confirmar "salvo", o texto dos O/KRs e as tags de usuário real, e confirmar que cada objetivo ainda tem o botão "Publicar";
  6. Quando janelas pop-up da página forem fechadas, o indicador de salvamento estiver ausente, a tag de menção não aparecer ou o número de campos estiver anormal, reler a página e não declarar salvamento bem-sucedido.

Relacionamentos de alinhamento só atuam em Objetivos. Antes de criar um alinhamento, confirmar que os dois objetivos pertencem a objetivos diferentes, que os ciclos têm sobreposição temporal e que existe uma relação de desdobramento ou colaboração; não escrever "relevante" diretamente como "alinhado". O fluxo completo está em references/okr-alignment-review.md.

Roteamento de Referências

Habilidades Relacionadas