Ferramentas do Ecossistema OKF

Curadoria honesta das ferramentas que existem hoje (set/2026) ao redor do Open Knowledge Format. Para cada item: o que faz, como usar, onde encontrar, e minha opinião sobre maturidade.

Migração de Repositório: OKF agora tem repositório próprio. O endereço canônico é GoogleCloudPlatform/open-knowledge-format. O caminho antigo (knowledge-catalog/okf/) é um snapshot congelado — não use para trabalhos novos.

1. Enrichment Agent (OKF — BigQuery → Bundles)

O que é: Um agente de referência que ingere metadata de uma fonte plugável (hoje BigQuery) e emite um bundle OKF completo — diretório de markdowns com YAML frontmatter prontos para humanos, LLMs e ferramentas de catálogo.

Como funciona:

• BQ pass: Gera um doc OKF por conceito usando apenas metadados do BigQuery (schemas, descrições, tabelas).

• Web pass: Aqui o bicho fica interessante. O LLM (Gemini via ADK) vira o próprio crawler. Recebe uma lista de seed URLs (via --web-seed ou --web-seed-file), busca via tool fetch_url, e decide sozinho quais links outbound vale a pena seguir — basicamente: “isso parece documentação autoritativa pro conceito X?” Se sim, segue. Pra cada página buscada, ele toma uma de três decisões:

  • (a) Enrich — adiciona citações, schemas ou join paths a docs existentes
  • (b) Mint — cria um doc standalone em references/<slug> pra aquela página
  • (c) Skip — não vale o token

  Pra não virar um webcrawl descontrolado: --web-max-pages define um cap hard e --web-allowed-host restringe por same-domain. Use --no-web pra pular o web pass inteiro.

Stack: Python 3.13, Google Agent Development Kit (ADK), Gemini como backend de modelo.

Como rodar:

# Instalar
python3.13 -m venv .venv
.venv/bin/pip install -e .[dev]

# Credenciais
gcloud auth application-default login
export GEMINI_API_KEY=<sua-key>  # ou Vertex AI

# Rodar (mínimo)
.venv/bin/python -m enrichment_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file seeds.txt \
    --out ./bundles/<nome>

# Só BigQuery (sem web crawl)
.venv/bin/python -m enrichment_agent enrich \
    --source bq \
    --dataset bigquery-public-data.ga4_obfuscated_sample_ecommerce \
    --no-web \
    --out ./bundles/ga4

Bundles de exemplo incluídos:

• bundles/ga4/ — GA4 e-commerce
• bundles/stackoverflow/ — Stack Overflow public dataset
• bundles/crypto_bitcoin/ — Bitcoin blocks/transactions

Link: github.com/GoogleCloudPlatform/open-knowledge-format

Limitações:

• Só BigQuery como source (interface Source existe mas nenhuma outra implementação)
• Exige Gemini API key ou Vertex AI configurado
• O web pass pode consumir bastante token se os seeds forem muitos
• Não suporta incremental updates — roda do zero cada vez

🟡 Maturidade: Proof of concept funcional. Os bundles gerados são legítimos e úteis, mas o agente em si é uma demo do que é possível, não um produto pronto. Funciona de verdade para datasets públicos do BigQuery. Para uso em produção, você vai querer customizar o prompt e os seeds.

2. Static HTML Visualizer (viz.html)

O que é: Um subcomando visualize que pega qualquer bundle OKF e gera um arquivo HTML self-contained — grafo interativo de conceitos, painel de detalhes, busca, filtros por tipo, backlinks. Zero backend, zero instalação no lado do viewer.

O que mostra:

• Grafo force-directed (Cytoscape.js) com nós coloridos por tipo
• Painel lateral com frontmatter + body renderizado em markdown
• Links internos navegáveis dentro do viewer
• Seção “Cited by” (backlinks computados)
• Busca por título, ID, tags
• Layouts alternativos (cose, concentric, breadthfirst, circle, grid)

Como gerar:

.venv/bin/python -m reference_agent visualize --bundle ./bundles/ga4
# Gera bundles/ga4/viz.html

# Customizar
.venv/bin/python -m reference_agent visualize \
    --bundle ./bundles/crypto_bitcoin \
    --out /tmp/btc.html \
    --name "Bitcoin OKF"

Como consumir: Abra o viz.html em qualquer browser moderno. Pode hospedar em file server estático, compartilhar por email, commitar no repo.

Link: Mesmo repo — open-knowledge-format/README.md#visualize

Limitações:

• Bundles muito grandes podem gerar HTMLs pesados (tudo é inline no JSON)
• O viewer é um SPA minimal — não tem paginação, não tem lazy loading
• Depende de CDN para Cytoscape.js e marked.js (não é 100% offline sem ajuste)

🟢 Maturidade: Funciona de verdade. É simples, faz o que promete, e os viz.html commitados no repo são ótimos para demo. Para bundles de 10-50 conceitos, perfeito. Para 500+, provavelmente precisa de otimização.

3. Metadata as Code (kcmd) — Sync com Knowledge Catalog

O que é: Ferramenta de sync bidirecional entre metadata local (YAML/markdown no filesystem) e o Google Cloud Knowledge Catalog (antigo Dataplex). Pense em “git para metadados” — você edita localmente e faz push/pull para o catálogo cloud.

Formato: YAML para entries, sidecar .md para conteúdos ricos (overviews, descriptions). Organização hierárquica espelhando a estrutura de recursos.

Distribuição: TypeScript library (npm install kcmd), CLI standalone (kcmd), e MCP server.

Como usar (CLI):

# Inicializar snapshot de um dataset BigQuery
kcmd init --bigquery-dataset <projectId>.<datasetId>

# Puxar metadata do catálogo
kcmd pull

# Ver mudanças locais
kcmd status

# Enviar mudanças para o catálogo (com dry-run)
kcmd push --dry-run
kcmd push

Como usar (MCP Server):

{
  "mcpServers": {
    "kc-mac": {
      "command": "kcmd",
      "args": ["mcp", "--path", "/path/to/root"]
    }
  }
}

Tools MCP disponíveis: pull, push, list-entries, lookup-entry, modify-entry.

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode

Limitações:

• Exige projeto GCP com Knowledge Catalog habilitado
• Autenticação via gcloud (não suporta service accounts direto)
• O formato YAML/sidecar é diferente do OKF puro (mais voltado para o catálogo Dataplex)
• Documentação ainda esparsa — o docs/concept.md referenciado existe mas é conceitual

🟡 Maturidade: Early product, mas bem estruturado. A CLI funciona, o MCP server é real, e o workflow push/pull faz sentido. O fato de ter library + CLI + MCP mostra intenção de ser usado em ambientes variados. Ainda não tem releases versionadas no npm.

4. Enrichment Agent (Toolbox — kcenrich)

O que é: Uma versão mais “production-oriented” do enrichment, integrada ao workflow do kcmd. Diferente do agente OKF (que gera bundles standalone), este enriquece metadata que já está no formato do catálogo.

Diferença do agente OKF:

• O OKF agent gera bundles markdown autônomos
• O kcenrich enriquece snapshots do Knowledge Catalog (formato kcmd)
• Usa MCP servers como sources (ex: md-fileset para crawlear docs locais)
• Customizável via prompt.md + diretório de tools/skills/

Como usar:

# Pré-requisito: ter um snapshot kcmd já inicializado
kcmd init --bigquery-dataset <project>.<dataset>
kcmd pull

# Rodar enrichment com tools customizados
kcagent enrich --catalog-path . --tools-path tools --prompt-path prompt.md

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/enrichment

Limitações:

• Depende do kcmd (Metadata as Code) configurado
• O demo funciona mas requer setup BigQuery real
• Ainda não tem release binário standalone

🟠 Maturidade: Mais proof of concept que produto. O demo é didático e funciona, mas é claramente um showcase de como combinar MCP + skills + catálogo. Não é “instala e sai usando” — precisa montar a infra de tools ao redor.

5. Google Cloud Knowledge Catalog (Ingestão Nativa)

O que é: O produto GCP (antigo Dataplex) que serve como catálogo de metadados AI-powered. É o “backend oficial” que o ecossistema de ferramentas acima sincroniza.

Features relevantes para OKF:

• 🆕 Ingestão nativa de OKF — Sim, o Knowledge Catalog agora engole bundles OKF direto e serve pros agentes. Sem conversão, sem middleware. Veja o demo e código.
• 🆕 Distribuição enterprise de OKF (agosto 2026) — escala bundles OKF pela organização:
  • Push de bundles via kcmd push com AspectType okf (sinaliza campos de trust v0.2: sources, generated, verified, status, stale_after)
  • Entries governadas por IAM: agentes veem só o que têm autorização
  • Caminho de retrieve do agente: searchEntries → LookupContext → entries.get(view=ALL)
  • Leia mais: Escalando OKF com Knowledge Catalog (26 ago 2026)
• Harvesting automático de BigQuery, AlloyDB, Spanner, Cloud SQL, Firestore, Looker
• Integrações 3P: Ab Initio, Anomalo, Atlan, Collibra, Datahub
• Enrichment nativo com Gemini — gera descrições, glossários, mapeia entidades
• Semantic search sub-segundo para agentes
• Context APIs + MCP tools para que agentes descubram assets
• Data products — empacotamento de assets com SLAs e governança

Pricing (resumo):

• Free tier: 100 DCU-hour/mês + 1 MiB storage + 1M API calls/mês
• Standard: $0.06/DCU-hour
• Premium (lineage, quality, profiling): $0.089/DCU-hour
• Storage: $2/GiB/mês (acima de 1 MiB)

Link: cloud.google.com/products/knowledge-catalog

Limitações:

• Vendor lock-in GCP (o kcmd é a ponte para portabilidade)
• Pricing pode escalar rápido com muitos DCU-hours
• O “formato nativo” NÃO é OKF — OKF é a camada portável que interopera

🟢 Maturidade: Produto GA do Google Cloud. É real, funciona em produção, tem SLA, tem suporte enterprise. O Knowledge Catalog em si está maduro — o que é novo são as ferramentas open-source ao redor.

6. Possíveis Integrações

6.1 Obsidian

Status: Não existe plugin oficial, mas o OKF foi deliberadamente desenhado para funcionar com Obsidian out-of-the-box.

Por que funciona:

• Bundles OKF são diretórios de .md com YAML frontmatter — exatamente o que o Obsidian espera
• Links internos funcionam como wikilinks (paths relativos)
• Tags no frontmatter aparecem nativamente no Obsidian
• O index.md funciona como nota índice

Como usar hoje:

1. Gere um bundle OKF com o enrichment agent
2. Abra o diretório do bundle como vault no Obsidian
3. Navegue, edite, use o graph view nativo

O que faltaria para um plugin real:

• Validação inline (lint de conformidade OKF)
• Template para criação de novos conceitos
• Sync com Knowledge Catalog via kcmd

🟢 Compatibilidade natural. Não precisa de plugin — funciona por design. Um plugin seria nice-to-have para validação, mas não é blocker.

6.2 GitHub Actions

Status: Nenhum Action oficial publicado, mas os comandos são todos scriptáveis.

Workflows possíveis:

# .github/workflows/okf-validate.yml
name: Validate OKF Bundle
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.13'
      - run: pip install okf-validator  # quando existir
      - run: okf validate ./bundles/

# .github/workflows/okf-enrich.yml (mais avançado)
name: Enrich on Schedule
on:
  schedule:
    - cron: '0 6 * * 1'  # Toda segunda
jobs:
  enrich:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -e ./okf[dev]
      - run: |
          python -m enrichment_agent enrich \
            --source bq --dataset ${{ secrets.BQ_DATASET }} \
            --no-web --out ./bundles/weekly
      - uses: peter-evans/create-pull-request@v6
        with:
          title: "chore: weekly OKF enrichment"

🟡 Potencial alto, implementação zero oficial. O workflow de “enrich → commit → PR” é natural para OKF. Nosso projeto (okf.md) poderia publicar um Action reutilizável como diferencial.

6.3 MCP Servers

Status: O kcmd mcp é real e documentado. É o ponto de integração mais maduro.

O que o MCP server do kcmd oferece:

Onde usar:

• Gemini CLI / Google AI Studio
• Claude Desktop (via MCP config)
• Cursor / VS Code (qualquer editor com suporte MCP)
• Agentes customizados (LangChain, ADK, etc.)

Também existe: O md-fileset MCP server (usado pelo toolbox/enrichment) para navegar diretórios de markdown como knowledge base.

🟢 Maturidade do kcmd MCP: Funcional. Está documentado com exemplo de config JSON, tools claras. O md-fileset é mais básico mas serve como padrão.

6.4 Coding Agents (Claude, Codex, Cursor, Gemini)

Status: Nenhuma skill oficial publicada (essa é justamente a oportunidade do nosso projeto).

O que existe hoje:

• O README do OKF funciona como documentação para um agente entender o formato
• O SPEC.md é legível o suficiente para um LLM gerar bundles conformantes
• O toolbox/enrichment usa tools/skills/ como diretório de skills do agente

O que falta (e onde entramos):

• Uma skill .md standalone que ensine qualquer agente a produzir OKF
• Validação em tempo de geração (o agente checa conformidade antes de salvar)
• Templates reutilizáveis para cenários comuns (SaaS metrics, analytics, APIs)

Padrão de skill que o toolbox já usa:

---
name: fileset-source
description: >
  Use the fileset source to find relevant markdown documents...
---

[instruções de uso das tools]

🟡 Oportunidade clara. O formato OKF foi feito para ser agent-friendly, mas ninguém empacotou isso como skill distribuível ainda. Nosso okf-skill será o primeiro.

Mapa de Maturidade

Pra uma visão visual de onde cada ferramenta se encontra (maturidade × barreira de entrada), veja o Mapa do Ecossistema dedicado.

Conclusão

O ecossistema OKF tem duas camadas claras:

1. Camada portável (OKF puro): Format spec + enrichment agent + visualizer. Funciona standalone, sem GCP. É onde vivem as oportunidades para comunidade.

2. Camada enterprise (Knowledge Catalog): kcmd + kcenrich + catálogo GCP. Funciona em produção mas exige infra Google Cloud.

Nosso projeto (okf.md / okf.ia.br) se posiciona na camada 1 — tornando OKF acessível, validável e produzível por qualquer agente, sem dependência de cloud provider.

7. Ferramentas da Comunidade

A spec OKF saiu em 12 Jun 2026. Em semanas, implementações independentes apareceram em todas as categorias.

Geradores & Produtores

Ferramentas que criam bundles OKF a partir de conteúdo existente.

AgentFitech

Startup que construiu suporte OKF (producer + consumer) no dia seguinte ao lançamento. Documentaram no Medium: “Google just standardized ‘How AI Agents read the web’. Here’s how we shipped it in a day.”

Takeaway: O formato é simples o suficiente pra um time pequeno ir de zero a conformante em um sprint.

Link: medium.com/@AgentFitech

KL4A — Knowledge Layer For Agents

O KL4A transforma SOPs, políticas e documentos regulatórios em claims pequenas e ligadas à fonte. Seu diferencial é um gate de revisão humana: uma claim minerada continua como proposta até alguém aprovar, rejeitar, adiar ou editar, com revisor identificado, justificativa e valores antes/depois gravados no histórico de review em arquivos simples.

Aceita fontes Markdown, texto, PDF e DOCX; inventaria e calcula checksum, normaliza em seções, minera claims em forma de obrigação e exporta um bundle em formato OKF, além de JSON de grafo e RDF. Cada claim aponta para evidência com offsets no texto-fonte preservado. O app desktop, a CLI em Rust e o servidor MCP somente-leitura por padrão usam o mesmo bundle.

O exemplo de GLP-1 deixa a proposta concreta: ele rejeita uma extração que transforma uma exigência de documentação condicionada ao pagador em obrigação incondicional, preservando o span da fonte e a justificativa do revisor.

Stack: Rust (10 crates), app desktop em Tauri, CLI, servidor MCP e servidor HTTP. Apache-2.0. Versão atual: 0.0.1-alpha.

Link: github.com/CogniSwitch/KL4A

Limitações:

• Software pre-alpha; os builds desktop não têm assinatura de código.
• A exportação atual usa generated.actor/generated.date e verified.actor/verified.date, em vez de by/at do OKF v0.2; exemplos aprovados hoje escrevem data de verificação nula. Trate os metadados de trust como profile em rascunho até essa correção.
• O minerador offline perde sentenças quebradas entre linhas, o que deixa a extração de PDFs rala sem usar o minerador com LLM.
• Os offsets de evidência cobrem apenas texto, não regiões de imagem ou timestamps de vídeo.

🔴 Maturidade: Pre-alpha, mas cobre uma lacuna real. O pipeline e o bundle de exemplo demonstram evidência por claim e revisão humana persistida, mas o projeto é novo e a exportação dos campos de trust ainda não é interoperável com a convenção do OKF v0.2. Vale avaliar em fluxos de compliance ou políticas nos quais um revisor precisa validar a extração antes que um agente a use.

Padrões & Profiles

Extensões formais e profiles construídos em cima do OKF.

W3C Holon CG (DataBook)

O W3C Holon Community Group (30+ participantes na reunião inaugural, 19 Jun 2026) está propondo DataBook como um profile formal do OKF para semantic web.

O que DataBook adiciona sobre OKF:

• Identidade baseada em IRI (URIs dereferenciáveis como IDs de conceito)
• Blocos tipados com RDF (Turtle, JSON-LD), SPARQL, SHACL
• Push para triplestore SPARQL via Graph Store Protocol
• Versionamento e proveniência de autor

Implicação: A comunidade Semantic Web vê OKF como base layer válida para estender — não como competidor. Valida a decisão de design extensível do OKF.

Link: The Ontologist — “The Format Convergence”

🟡 Maturidade: Proposta. Se aterrizar, OKF ganha tipagem ontológica formal de graça via profiles.

AIX — AI eXchange Format

Um superset estrito do OKF v0.2 que adiciona as capacidades que o OKF deliberadamente não inclui: identidade estável, relacionamentos tipados, identidade de mídia e federação. Todo bundle AIX também é um bundle OKF válido — publica uma vez, consumido por ambos.

O que AIX adiciona sobre OKF v0.2:

• Identidade estável (campo id) — a identidade do conceito sobrevive a renomeações e movimentações de arquivo; chega de referências quebradas quando você reorganiza seu vault
• Relacionamentos tipados (array links) — depends-on, supersedes, contradicts, describes, e mais, com inversas definidas; consumidores podem inferir backlinks automaticamente
• Identidade de mídia (array media) — identidade por hash de conteúdo para assets binários (diagramas, gravações, screenshots) mais ponteiros de embedding para retrieval multimodal
• Federação — namespaces de bundle, referências qualificadas cross-bundle (namespace/id), declarações de vocabulário compartilhado; bundles de múltiplos times interoperam sem precisar fazer merge de repos

Contrato de compatibilidade: AIX adota os campos de trust do OKF v0.2 (sources, generated, verified, status, stale_after) sem alteração. Dados específicos do AIX ficam em chaves de frontmatter que consumidores OKF preservam ou ignoram. Cada edge tipado em links também é espelhado por um link markdown plain no body, então leitores OKF-only ainda veem o grafo (sem tipo).

Escada de conformidade:

Validar qualquer bundle:

python3 tools/aix-validate.py path/to/bundle --level 2
python3 tools/aix-validate.py path/to/bundle --json

Stack: Spec (markdown), validador de referência (Python single-file, PyYAML opcional), bundle de exemplo funcional. Licença MIT.

Link: github.com/DavidROliverBA/aix-format (spec, validador, exemplos; v0.2 lançada em 2026-08-20)

Limitações:

• Um produtor até agora — é uma hipótese publicada, não um padrão estabelecido
• O design de federação não foi testado até que um segundo time tenha seu próprio bundle
• O espelhamento de edges tipados custa alguma redundância por arquivo

🟡 Maturidade: Early. Spec + validador + bundle de exemplo são reais e versionados; ecossistema não. O racional de design foi publicado em dois ensaios: “I Was Going to Adopt Google’s Knowledge Format. I Wrote the Superset Instead.” e “OKF v0.2 Quietly Admits the Folder Has a Ceiling”. Vale acompanhar se você já bateu nas limitações de identidade ou relacionamentos do OKF.

Publicação & Visualização

Ferramentas que transformam bundles em sites ou grafos visuais.

Suganthan Web Converter

Cola uma URL ou sitemap, ele crawlea até 100 páginas, arranca o HTML decorativo, converte cada uma em conceito OKF com cross-links, e te entrega o bundle num zip. O grafo visual — pontos pras páginas, linhas pros links — já vale a pena rodar sozinho. Você enxerga páginas órfãs em segundos.

Link: suganthan.com/free-seo-tools/okf-generator/

🟡 Maturidade: Funcional. Opera no nível de página (um arquivo por página). Extração real de conceitos — puxar ideias distintas de dentro da prosa — é o próximo passo que ninguém resolveu ainda.

Suganthan WordPress Plugin

Provavelmente o caminho mais rápido pra ter um bundle OKF ao vivo se seu site roda WordPress. Instala o plugin, ativa, e o conteúdo já tá servindo em /okf/. Sem etapa de export, sem cron, sem manter arquivos markdown na mão.

O plugin escuta eventos de publicação e edição. Toda vez que você clica “Atualizar” num post, o bundle reconstrói. No painel, aparece um grafo dos links internos — mesmo motor da ferramenta web acima, só que plugado direto no WordPress.

Na prática:

• Posts e páginas viram arquivos de conceito OKF (frontmatter + body em markdown limpo)
• Serve em seusite.com/okf/ com pretty permalinks, ou seusite.com/?okf=index.md sem
• Página de settings pra incluir/excluir por tipo de post
• GPL, gratuito, open source — só leitura (nunca mexe no seu conteúdo, remover não deixa rastro)

Precisa de: WordPress 6.0+, PHP 7.4+, pretty permalinks ligados (Configurações → Links Permanentes — qualquer opção exceto “Simples”).

Instalar:

1. Pega o zip: uploads.suganthan.com
2. Plugins → Adicionar Novo → Upload de Plugin → seleciona o zip → Instalar → Ativar
3. Pronto. Confere o menu OKF pro grafo. Já tá ao vivo em /okf/.

Também submetido ao Diretório de Plugins do WordPress — aguardando revisão.

Link: suganthan.com/blog/open-knowledge-format/

🟢 Maturidade: Pronto. WordPress roda uns 40% da web. Pra essa fatia, é instalar e esquecer — o bundle fica atualizado sem você pensar nisso.

superops-team/okf CLI

CLI em Go que escaneia um repositório Git e gera um bundle OKF a partir do código-fonte — roda okf init e pronto, aparece um diretório .okf/knowledge/ com um conceito por arquivo relevante. Vem com updates incrementais via git hooks, linter embutido (13 regras), e engine de busca por tipo, tags ou texto livre.

O que chama atenção:

• okf init → escaneia o repo, gera o bundle
• okf hook -type post-commit → instala git hook que mantém o bundle atualizado a cada commit
• okf lint → valida contra a spec OKF (erros pra type/title ausentes, warnings pra estilo)
• okf search -q "database" → filtra por tipo, tags ou texto
• Updates incrementais — só regenera conceitos dos arquivos que mudaram desde o último commit

Instalar: one-liner (curl | bash), go install, ou binários pré-compilados (Linux, macOS, Windows — amd64/arm64).

# One-liner
curl -fsSL https://raw.githubusercontent.com/superops-team/okf/main/scripts/install.sh | bash

# Ou via Go
go install github.com/superops-team/okf/cmd/okf@latest

Stack: Go, licença Apache 2.0. v0.4.0 lançada em 30 Ago 2026.

Link: github.com/superops-team/okf

🟢 Maturidade: Funcional, com release. Arquitetura limpa (pacotes separados pra parsing, linting, querying, git). A abordagem de git hook preenche um gap real — a maioria das outras ferramentas são geradores one-shot, essa mantém o bundle em sync conforme o código evolui. Comunidade pequena (10 stars), mas entregou com stress tests e binários cross-platform.

Validadores & Linters

Ferramentas que checam conformidade OKF.

okflint (Linter)

Lembra daquele gap na página que dizia “um plugin de validação seria legal, mas não trava nada”? O okflint é exatamente isso — só que como CLI, não plugin. Um linter determinístico (zero LLM) que valida bundles OKF contra a spec e contra as regras que você declarou no seu próprio manifesto.

A analogia mais honesta: é o Ruff da documentação. Roda, aponta, sai com exit code. Pronto.

Dois comandos, filosofias distintas:

• okflint audit — radiografia da base. Links quebrados, candidatos a split, estatísticas. Sempre exit 0 — é observação, não gate.
• okflint validate — portão de CI. Passou? exit 0. Não passou? exit 1. Ponto. Feito pra pre-commit hook e pipeline.

O pulo do gato é o sistema de três etapas:

A sacada é a camada do meio. OKF é deliberadamente mínimo (só exige type no frontmatter, basicamente). Mas na prática todo time quer mais: “todo ADR precisa ter campo created”, “status só pode ser draft/prod/obsoleto”. O okflint te deixa declarar isso num YAML (okf-base.yaml) e depois cobra. Nenhum vocabulário vem hardcoded — a engine é genérica.

Outro detalhe que importa pra quem usa Obsidian: ele resolve [[wikilinks]] contra a vault inteira, não só contra o bundle. Ou seja, um link pra uma nota fora do bundle não dispara falso positivo.

Instalar:

# Via uv (recomendado)
uv tool install okflint

# Ou pip, se preferir
pip install okflint

# Validar um bundle
okflint validate --manifest okf-base.yaml ./meu-bundle/

Na CI fica assim:

- name: Validate OKF conformance
  run: |
    pip install okflint
    okflint validate --manifest docs/okf-base.yaml docs/

18 regras documentadas (com exemplo de erro e correção pra cada uma), saída JSON pra quem quer parsear no pipeline.

Stack: Python 3.12+, MIT. v0.4.0 saiu em 29 Ago 2026.

Links: github.com/mattdav/okflint · PyPI · API docs

Autor: mattdav

Como se encaixa com o superops-team/okf: são complementares, não concorrentes. O CLI Go gera bundles a partir de código-fonte e mantém em sync via git hook. O okflint não gera nada — só valida. Um produz, outro gateia. Faz sentido usar os dois juntos.

🟢 Maturidade: Com release. Escopo afiado — faz uma coisa e faz bem. O diferencial real é o sistema de profiles: você declara suas regras, ele cobra. Sem mágica, sem IA, sem opinião embutida.

okf-guard (Content Safety)

Uma camada de segurança de conteúdo que roda antes do seu gerador OKF. Enquanto o okflint valida estrutura de bundles, o okf-guard escaneia os arquivos fonte (PDF, DOCX, PPTX, XLSX, HTML) procurando texto oculto e padrões de prompt injection antes de virarem conhecimento confiável.

O problema que ele resolve: atacantes podem contrabandear instruções maliciosas em documentos usando texto branco-sobre-branco, caracteres zero-width, linhas ocultas em planilhas, ou shapes fora do canvas. Um humano revisando o documento não vê nada; um parser de LLM extrai tudo. O okf-guard pega isso antes do conteúdo entrar na sua base de conhecimento.

Três ações:

• pass — conteúdo limpo, sem problemas
• quarantine — sinais suspeitos, precisa revisão humana
• block — ataque detectado com alta confiança

Filosofia: Escanear antes de gravar. Conteúdo oculto + pattern matching (não só regex). Defaults conservadores — v0.1.0 é determinístico sem camada de julgamento LLM, então prefere falsos positivos a falsos negativos.

Quick start (CLI):

# Instala via pipx (recomendado para uso CLI)
pipx install "okf-guard[all]"

# Escaneia um arquivo
okfguard scan documento.docx

# Escaneia diretório recursivamente, output JSON para CI
okfguard scan -r /docs/uploads --json > scan_log.json

Quick start (API Python):

from okfguard import sanitize

result = sanitize("documento_suspeito.pdf")
print(f"Ação: {result.action}")        # "pass", "quarantine", ou "block"
print(f"Risk Score: {result.risk_score}")
print(f"Texto Limpo: {result.clean_text}")

# Campos de provenance OKF v0.2 prontos pro seu bundle
print(result.provenance_fields)

Exit codes: 0 pass, 1 quarantine, 2 block, 3 erro — pronto pra gates de CI.

Stack: Python · Apache-2.0 · v0.1.0 (Ago 2026)

Link: github.com/darshanNhb/okf-guard

Limitações:

• Sem OCR ou análise de imagens (esteganografia, texto em imagens)
• Sem análise de macros/VBA — só conteúdo
• Detecção de render mode 3 em PDF é parcial (libs subjacentes não expõem de forma confiável)
• Não move/deleta arquivos — retorna decisão, sua pipeline que aplica

Como se encaixa com o okflint: Sequencial, não concorrente. okf-guard escaneia documentos fonte antes da conversão; okflint valida bundles OKF depois da geração. Pipeline: fontes → okf-guard → gerador → okflint → deploy.

🟡 Maturidade: Early. v0.1.0, um único mantenedor, poucas stars. Mas a implementação é sólida: estrutura de pacote apropriada, testes, CI, documentação honesta das limitações. Preenche uma lacuna real — ninguém mais está fazendo segurança de conteúdo pré-geração para pipelines OKF.

OKF-Schema (Validação com JSON Schema)

Traz validação JSON Schema para bundles OKF. Em vez de só checar “esse arquivo tem um campo type?”, o okf-schema valida a estrutura do seu frontmatter contra schemas que você define por tipo. Pense nisso como type-checking para sua base de conhecimento.

A ideia central: Para cada type no seu bundle, existe um arquivo de schema correspondente em _schema/. Os schemas podem ser escritos em YAML, JSON ou JSON5 (JSON com comentários e vírgulas finais). O schema define campos obrigatórios, valores permitidos e documentação para cada propriedade. Quando você roda okf-schema validate, ele verifica cada arquivo de conceito contra o schema do seu tipo e dá feedback acionável.

O que o projeto oferece:

O pulo do gato: Os schemas são commitados dentro do bundle (pasta _schema/), então viajam junto com seu conhecimento. Sem registry externo, sem mismatch de versão. Clona o bundle, roda o validador, pronto.

Quick start:

# Instalar a CLI em um ambiente isolado (recomendado)
uv tool install okf-schema

# Validar um bundle
okf-schema validate --path ./meu-bundle/

# Ou usar o workflow okfkb
okfkb init ./nova-kb
okfkb validate ./nova-kb

Exemplo de schema (em _schema/concept.schema.json):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["type", "title", "status"],
  "properties": {
    "type": { "const": "concept" },
    "title": { "type": "string", "minLength": 1 },
    "status": { "enum": ["draft", "review", "accepted"] },
    "sources": {
      "type": "array",
      "items": { "type": "string", "format": "uri" }
    }
  }
}

Stack: Python · MIT · v0.11.1 · PyPI

Links: github.com/gsemet/okf-schema · Documentação · Exemplos

Comparação com okflint: Filosofias diferentes. okflint valida contra um conjunto fixo de regras (spec OKF + seu profile YAML). okf-schema valida contra JSON Schemas que você define por tipo — mais configurável, mais explícito e intencionalmente mais estrito. Um bundle OKF válido pode falhar se não corresponder aos schemas commitados junto dele. okflint é “isso segue as convenções OKF?”; okf-schema é “isso bate exatamente com o shape que eu declarei?”. Ambos podem rodar na CI.

Limitações:

• Não há inferência de schema embutida. Na prática, um LLM pode derivar um schema inicial a partir de alguns conceitos representativos
• Os workflows okfkb e okfreq são opinados — úteis se batem com seu caso de uso, overhead se não

🟡 Maturidade: Funcional. Publicado no PyPI, documentado no ReadTheDocs, exemplos reais no repo. A biblioteca é estável o suficiente para validação em produção. As camadas okfkb/okfreq são mais experimentais — demonstrações interessantes do que OKF pode suportar, mas não obrigatórias para usar a validação core.

Autor: gsemet

Kiso (Publishing)

Kiso é um engine de publicação que pega seu bundle OKF e cospe um site estático pronto — com llms.txt e sitemap.xml gerados automaticamente. Ou seja: um comando e você tem um site legível por humanos e por agentes de IA ao mesmo tempo.

O que chama atenção: a CLI é enxuta de verdade — só dois comandos. check valida a estrutura do seu markdown antes de qualquer coisa, build gera o site. Tem GitHub Action pronta, suporte a temas DaisyUI, e um sistema de publishing profiles (.kiso/<perfil>/configuration.yaml) que deixa você manter configs diferentes pro mesmo bundle.

Quick start:

# Valida a estrutura do bundle
./kiso-cli check --source=meu-bundle

# Gera o site estático
./kiso-cli build --source=meu-bundle --destination=public

GitHub Action:

- name: Build com Kiso
  uses: oak-invest/kiso/applications/kiso-cli-action@v0.1.3
  with:
    command: build
    source: meu-bundle
    destination: public

Configuração (.kiso/configuration.yaml):

site:
  baseUrl: https://knowledge.example.com/
  language: pt
  title: Minha Base de Conhecimento
  description: Documentação para humanos e agentes de IA

theme:
  name: corporate

content:
  ignorePatterns:
    - drafts/**
    - interno/**

Stack: Java · Apache-2.0 · v0.2.3 (Ago 2026)

Link: github.com/oak-invest/kiso · Site

🟢 Maturidade: Com release. Funciona, tem CI action, tem releases tagueadas — não é vaporware. Dito isso, é projeto jovem (12 stars, primeiras versões). A proposta é sólida e a execução tá limpa, mas espere mudanças de API entre minors. Bom pra quem quer publicar bundles OKF sem inventar pipeline do zero.

OpenWiki 0.2 (LangChain)

O OpenWiki lê seu repositório e gera um wiki estruturado no formato OKF — pronto pra ser consumido por coding agents como Claude Code e Cursor. A ideia é simples: seu código já tem conhecimento implícito (decisões de arquitetura, padrões, convenções), e o OpenWiki transforma isso num artefato explícito que agentes conseguem ler sem ficar adivinhando.

Harrison Chase confirmou a direção no X: “there needs to be an OPEN standard for memory. OKF is one such standard.” 113 likes. O CLI conecta o wiki gerado nos instruction files do seu agent, então o contexto flui sem fricção entre o codebase e quem opera nele.

Quick start:

pip install openwiki
openwiki init .
openwiki generate --format okf

Stack: Python · MIT · v0.5.0 (Set 2026)

Link: langchain-ai/openwiki · Blog post

🟢 Maturidade: Produção. Backed pela LangChain, mantido ativamente, documentação sólida. Já na segunda major release com suporte OKF nativo.

Bibliotecas & SDKs

Implementações nativas para embutir OKF nas suas próprias ferramentas.

W4G1/okf (Rust)

A implementação nativa mais completa do OKF fora das ferramentas de referência do Google. Um toolkit puro Rust cobrindo toda a spec OKF v0.2: parsing, validação, linting, trust tiers, e uma TUI interativa para explorar bundles.

O que você ganha:

Comandos CLI:

• okf init — scaffold de um novo bundle
• okf new — cria um novo arquivo de conceito
• okf validate — checa conformidade contra OKF v0.2
• okf lint — checagens de estilo e higiene
• okf trust — gerencia trust tiers
• okf graph — visualiza o grafo de links
• okf mv, okf rm — refatora sem quebrar links
• okf split, okf merge — operações de bundle
• okf diff, okf fmt — comparação e formatação
• okf studio — lança o explorador TUI

Instalar:

# Via cargo (do source)
cargo install --git https://github.com/W4G1/okf

# Ou clone e build
git clone https://github.com/W4G1/okf
cd okf && cargo build --release

Stack: Rust · Apache-2.0 · v0.2.6 (Ago 2026)

Link: github.com/W4G1/okf

Limitações:

• Ainda não publicado no crates.io (instale do git)
• A TUI é funcional mas minimal
• Sem MCP server (ainda)

🟢 Maturidade: Com release. 19 stars, 69 commits, desenvolvimento ativo. A única implementação Rust com cobertura total do v0.2. Se você está construindo tooling Rust que precisa ler/escrever OKF, é isso. O CLI sozinho vale experimentar — okf studio torna exploração de bundles genuinamente agradável.

Roteiro (Knowledge Graph — Producer + Consumer + Validator)

Um knowledge graph com proveniência de codebases que escreve E lê bundles OKF, com conformance checker e viewer para bundles que ele não produziu. É a implementação OKF mais completa fora das ferramentas de referência — cobrindo as três categorias: gerador, consumidor e validador.

O que faz com OKF:

• Escreve bundles a partir do grafo (roteiro render okf) — index.md por diretório, conceitos tipados, links markdown entre eles
• Lê bundles de terceiros (roteiro import --from okf) e importa como conhecimento externo, registrando o trust tier da origem sem herdá-lo
• Valida conformidade (roteiro okf validate — gate com erro) e higiene (roteiro okf lint — só reporta), além de info, trust, links, syntax, computations e diff
• Filtra conteúdo importado antes de virar conhecimento — três verdicts, com bloco reservado para diretiva de modelo que também é ocultada
• Visualiza bundles externos, resolvendo links via mapa key-to-path construído após posicionamento

Comandos principais:

# Instalar via crates.io
cargo install roteiro

# Gerar bundle OKF do codebase
roteiro index .
roteiro render okf --output ./knowledge-bundle/

# Importar bundle externo como conhecimento
roteiro import --from okf /caminho/para/bundle-externo

# Validar conformidade OKF
roteiro okf validate ./meu-bundle/   # gate — falha com erro
roteiro okf lint ./meu-bundle/       # só reporta

Stack: Rust · MIT/Apache-2.0 · v5.13.0 (Set 2026) · Biblioteca separada rto-okf-syntax para parsing de fenced code blocks

Versão OKF: v0.2, pinned no commit ad30107c — os fixtures de interoperabilidade vendem dois bundles do próprio repo da spec nesse commit exato

Dependência: Usa okf-core (W4G1/okf) como parser subjacente

Link: github.com/OffeneDatenmodellierung/Roteiro

Limitações declaradas:

• Entries de sources carregam apenas resource — não popula id, title ou author
• Não emite footnotes nem log.md
• O reader atualmente descarta title e author do peer ao importar
• Dois lints de higiene (L5 e L6) não disparam contra output próprio por causa das limitações acima

🟢 Maturidade: Ferramenta de produção. 1,527 commits, codebase maduro, publicado no crates.io. A única ferramenta que cobre producer + consumer + validator em um pacote só. Se você quer um knowledge graph que fala OKF fluentemente — lendo, escrevendo e validando — é a opção mais completa.

Confiança & Proveniência

Verificação, assinaturas e proof on-chain pra bundles.

signed-okf (Trust Layer)

O OKF resolve estrutura. Mas quem garante que aquele bundle não foi adulterado? O signed-okf adiciona proveniência criptográfica: assinatura, verificação e cadeia de custódia pro conteúdo OKF. O metadata padrão do OKF para num timestamp estático — o signed-okf preenche exatamente esse gap que o próprio Google reconheceu na spec v0.1.

A DynamicFeed integrou com o OriginTrail DKG pra quem precisa de proof on-chain. Pra maioria dos casos, a verificação local já resolve. Mas se você opera em contextos onde proveniência auditável importa (pesquisa, compliance, supply chain de dados), o layer blockchain está ali.

Quick start:

npm install signed-okf
npx signed-okf sign ./my-bundle --key ./private.pem
npx signed-okf verify ./my-bundle

Stack: TypeScript/Node.js · Apache-2.0 · v0.3 (Jun 2026)

Link: Fluxdyne/signed-okf · dynamicfeed.ai

🟡 Maturidade: Early adopter. Conceito forte, execução ainda jovem. Poucas stars, time pequeno. A integração DKG funciona mas a documentação é esparsa. Se você precisa de trust layer pro OKF hoje, é a única opção — mas vá sabendo que a API pode mudar.

Memória & Skills de Agentes

OKF como memória ou instrução runtime pra agentes IA.

hermes-okf (Memória)

Cada decisão que seu agente toma, cada observação sobre o projeto, cada pedaço de contexto — tudo vive num knowledge graph no filesystem, legível por humanos e por máquinas. O hermes-okf é o sistema de memória do Hermes Agent, mas formatado como OKF. Memória versionada, estruturada, que sobrevive entre sessões.

O diferencial: não é só um dump de contexto. Tem tool registry (o agente sabe quais ferramentas tem), plans (sequências de ação persistidas) e integração nativa com o HermesAgent. Se você já usa Hermes, plugar o OKF como backend de memória leva minutos.

Quick start:

pip install hermes-okf
hermes-okf init ./my-project

from hermes_okf import OKFMemory

memory = OKFMemory("./my-project/.hermes")
memory.observe("O usuário prefere deploys via Coolify")
memory.decide("Usar PostgreSQL ao invés de SQLite pra prod")

Stack: Python · MIT · v0.5.9 (Jun 2026)

Link: EliaszDev/hermes-okf · PyPI

🟡 Maturidade: Funcional, mas nicho. Publicado no PyPI, versionado, com releases consistentes. Comunidade pequena. Se você não usa o Hermes Agent, o valor cai bastante — a lib foi construída pra aquele ecossistema específico. Documentação ok, mas com gaps nos edge cases.

Inkeep Open Knowledge

Um editor markdown AI-native e local-first que virou plataforma completa de knowledge base na launch week de 17–21 ago 2026: apps desktop pra macOS, Windows e Linux, sync via git, busca agêntica (embeddings + RAG hierárquico) e chat nativo com 30+ coding agents via ACP. Editor rico estilo Notion que continua sendo markdown puro no disco.

Pra agentes, três superfícies importam:

• MCP server nativo (@inkeep/open-knowledge) — tools de leitura/escrita (ingest, research, consolidate) mais avisos em tempo de escrita quando o conteúdo sai da conformância
• Agent skills embutidas — incluindo a okf-knowledge-base com semântica OKF (ver plugin abaixo)
• Padrão .mcp.json commitado — bundles como o wiki Odyssey trazem config a nível de repo, então Claude Code/Codex oferecem subir o server ao abrir

Quick start:

# Baixar o app desktop (Mac/Win/Linux)
# https://openknowledge.ai/download

# Ou rodar o MCP server headless
npx -y @inkeep/open-knowledge@^0.58 mcp

Stack: TypeScript · GPL-3.0 · Desktop GA (ago 2026) · ~3.6K stars no GitHub

Links: openknowledge.ai · inkeep/open-knowledge

🟢 Maturidade: Lançado. De preview web a app desktop multiplataforma em cinco semanas. O plugin OKF abaixo é o que faz dele um editor OKF-native, não só mais um app markdown.

OKF Plugin (OpenKnowledge)

Anunciado em 21 ago 2026 como “parte linter, parte skill, parte MCP tools”. Traduz o OKF v0.2 em feedback contínuo de conformância dentro do editor, CLI e agentes do OpenKnowledge. Tudo que ele aponta é warning — nunca bloqueia escrita.

Seis rulesets de frontmatter (schemas gerados em .ok/okf/*.schema.json):

• Required — type não vazio em todo concept
• Recommended — title, description, tags (lista), resource
• Provenance/lifecycle — sources[], generated {by, at}, verified[], status, stale_after
• Computation — formato do type: Attested Computation (runtime, parameters, executor.receipt, attester)
• Index files ×2 — sem frontmatter, exceto okf_version: "0.2" na raiz

Mais regras de body/portabilidade: formato de lista do index, headings de log em ISO-8601, sem wikilinks, sem .mdx.

Três formas de rodar:

Também gera index.md automáticos por diretório (agrupados por tipo), machine-owned e à prova de merge conflict via regra no .gitattributes. Vem com a skill okf-knowledge-base pra agentes conhecerem spec e ferramenta.

Comparação com okflint: mesma filosofia — lint determinístico, warnings sem bloqueio. Entrega diferente: okflint é CLI Python standalone feito pra CI; esse vive onde os agentes escrevem. Podem rodar juntos.

Links: Anúncio · Docs

🟢 Maturidade: Lançado. Cobertura day-one do OKF v0.2, incluindo Attested Computation.

knowledge-template (Ciência)

Template vazio e conformante de bundle OKF voltado pra ciência aberta. Você clona, preenche com seu conteúdo, e sai com um bundle que atende tanto a spec OKF v0.1 quanto os requisitos do Open Science Pillars (SPECIFICATION.md §5). Inclui um exemplo anotado por tipo de conceito — definição, hipótese, método, resultado — pra você entender o que vai onde.

Não é framework, não é CLI, não tem dependência. É um template. Faz uma coisa só e faz bem.

Quick start:

gh repo create my-knowledge --template open-science-pillars/knowledge-template
cd my-knowledge
# Edite os bundles em /concepts, /methods, /results

Stack: Markdown/YAML · CC-BY-4.0 · v1.0 (Jul 3, 2026)

Link: open-science-pillars/knowledge-template

🟢 Maturidade: Completo pro que se propõe. É template — não tem bug, não tem runtime, não quebra. Conformante com OKF v0.1, exemplos claros, publicado há duas semanas. Se você trabalha com conhecimento científico e quer OKF, começa aqui.

OriginTrail DKG + OKF

Junta o Open Knowledge Format com o Decentralized Knowledge Graph da OriginTrail. Na prática: seus bundles OKF ganham um dono verificável, prova de origem e imutabilidade registrada em blockchain. Por baixo usa signed-okf pra assinar os pacotes.

O ponto forte aqui é confiança. Um agente IA consulta o DKG, encontra um bundle OKF e consegue verificar criptograficamente quem publicou, quando, e se o conteúdo foi alterado. Sem trust-me-bro. Sem depender de um servidor central dizendo “esse dado é legítimo”. O grafo descentralizado faz isso sozinho.

Quick start:

# Consulte o blog post pra setup completo — envolve node DKG + signed-okf
# Fluxo básico:
# 1. Crie seu bundle OKF
# 2. Assine com signed-okf
# 3. Publique no DKG da OriginTrail
# 4. Agentes consultam via DKG API

Stack: TypeScript/Solidity · Open Source · Integração anunciada Jul 2026

Link: Google’s OKF comes to the OriginTrail DKG

🟡 Maturidade: Conceito validado, adoção ainda inicial. A integração é recente (Jul 2026) e a documentação ainda está espalhada entre o blog post e repos separados. Promissor pra quem precisa de proveniência verificável, mas prepare-se pra montar o quebra-cabeça sozinho por enquanto.

openknowledgeformat.com

Site comunitário que resolve o problema mais básico: “meu bundle OKF tá certo?”. Cola seu YAML frontmatter, recebe validação instantânea. Sem instalar nada. Sem CLI. Sem dependência.

Além do validator, tem templates prontos pra copiar e exemplos interativos que mostram bundles reais em ação. Perfeito pra quem tá começando e quer entender a estrutura sem ler a spec inteira. Também funciona como referência rápida quando você esquece um campo obrigatório (acontece).

Quick start:

# Não precisa de terminal. Abra no browser:
# https://openknowledgeformat.com/
# Cole seu YAML → veja erros em tempo real
# Copie templates → adapte pro seu caso

Stack: Web · Gratuito · Publicado Jun 13, 2026

Link: openknowledgeformat.com

🟢 Maturidade: Pronto pra uso. Funciona, é direto, faz o que promete. Zero fricção. Limitação óbvia: só valida — não gera, não publica, não integra com pipelines. Mas pro que se propõe, resolve.

okf-skill (Agent Skill)

Um arquivo markdown. Só isso. Mas esse arquivo transforma qualquer agente com suporte a Agent Skills (Claude Code, Cursor, Hermes, etc.) num produtor e consumidor de bundles OKF. Referencia a spec completa e dá instruções claras pro agente seguir.

Preenche um gap real: coding agents sabem escrever código, mas não sabem estruturar conhecimento no formato OKF sem orientação explícita. Esse skill é essa orientação. Joga no diretório de skills do seu agente e pronto — ele passa a gerar bundles conformantes.

Quick start:

# Clone e copie pro diretório de skills do seu agente
git clone https://github.com/rakibtg/okf-skill.git

# Exemplo pra Claude Code:
cp okf-skill/SKILL.md ~/.claude/skills/okf-skill.md

# Exemplo pra Cursor:
cp okf-skill/SKILL.md .cursor/skills/okf-skill.md

Stack: Markdown · Open Source · GitHub: rakibtg/okf-skill

Link: github.com/rakibtg/okf-skill

🟡 Maturidade: Funcional, mas depende do agente host. A qualidade da saída varia conforme o modelo e o agente que consome o skill. Não tem testes automatizados — você confia que o agente vai seguir as instruções. Repo pequeno, sem muita atividade ainda, mas a ideia é sólida.

leadcraft

Analisa um repositório e gera Knowledge Bundles OKF v0.1 automaticamente. A saída é YAML frontmatter + directory tree em markdown — legível tanto por humanos quanto por agentes, e versionável com git como qualquer outro arquivo do projeto.

A proposta é simples: você aponta pro repo, o leadcraft extrai a estrutura e o conhecimento relevante, empacota no formato OKF. Útil pra documentação automatizada de codebases que outros agentes vão consumir depois.

Quick start:

# Clone o repo
git clone https://github.com/dskst/leadcraft.git
cd leadcraft

# Siga as instruções do README pra setup
# Gere bundle OKF a partir de um repo:
# leadcraft analyze <caminho-do-repo>

Stack: Open Source · OKF v0.1 · GitHub: dskst/leadcraft

Link: github.com/dskst/leadcraft

🟡 Maturidade: Early stage, documentação limitada. Repo recente com pouca documentação além do básico. Funciona pro caso de uso principal (gerar bundles de repos), mas não espere configuração avançada ou edge cases cobertos. Contribuições bem-vindas — o código tá lá, é aberto.

pi-openwiki (IBM PI)

O agente OpenWiki da LangChain reimplementado dentro do PI (Platform for AI da IBM). Gera e mantém documentação de codebase automaticamente, com o mesmo formato de saída OKF que o OpenWiki original produz.

A diferença é o runtime: ao invés de rodar standalone com LangChain, roda dentro do ecossistema PI — o que dá acesso às capacidades de orquestração, observabilidade e governança que o harness oferece. Se você já usa PI na sua org, é uma forma natural de adicionar geração de docs OKF ao pipeline.

Quick start:

# Clone o repo
git clone https://github.com/barvhaim/pi-openwiki.git
cd pi-openwiki

# Requer PI harness configurado
# Siga o README pra setup do ambiente PI
# O agente gera docs OKF automaticamente pro codebase apontado

Stack: Python · PI (IBM) · Open Source · Publicado Jul 2026

Link: github.com/barvhaim/pi-openwiki

🟡 Maturidade: Funcional, mas nicho. Publicado em Jul 2026, ainda fresco. Depende do harness PI — se você não tá nesse ecossistema, o OpenWiki original faz mais sentido. Documentação básica, poucos contributors. Mas se PI é seu mundo, essa é a porta de entrada pro OKF.

8. Padrões Emergentes (Ainda Não São Ferramentas)

OKF + llms.txt para Discovery

Vários analistas especulam que llms.txt vai apontar agentes para bundles OKF:

# llms.txt
...
## Knowledge
- /knowledge/index.md: OKF bundle — conhecimento organizacional para agentes

Status: Especulação lógica, não confirmada oficialmente.

Marketplace de Bundles OKF

Marie Haynes argumenta que bundles OKF serão produtos vendáveis — advogados, contadores, SEOs empacotando expertise como bundles compráveis.

Status: Pura especulação. Interessante mas sem infraestrutura.

OKF + Obsidian como IDE

Framing do Karpathy: “Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.” Vários times já usam Obsidian pra autorar bundles OKF enquanto agentes mantêm cross-references.

Status: Padrão funcional. Sem plugin dedicado mas zero fricção.

Timeline & Oportunidades

Movido para o Mapa do Ecossistema dedicado.

Veja também

• Spec OKF — guia anotado do formato
• FAQ OKF — o que é o formato e como agentes usam
• Skill OKF — ensine o formato ao seu agente de código
• Mapa do Ecossistema — maturidade e oportunidades