GITHUB PORTFOLIO
MASTERCLASS
Guia Completo: Do Zero ao Portfólio de Nível Sênior
Git, GitHub, Documentação & Projetos Reais
Autor Claude AI × Henrique (Tech Lead)
Objetivo Construir GitHub que abre portas Big Tech
Nível Junior Git → Senior Portfolio
Projetos 20+ projetos reais mapeados
Meta Nubank / iFood / Mercado Livre
ATENÇÃO
Este documento é seu mapa de execução. Não leia passivamente — execute cada seção em sequência. Cada
conceito é explicado com o PORQUÊ estratégico e o COMO prático.
ÍNDICE
01 <b>DIAGNÓSTICO: Por que GitHub importa</b><br/><font size=8 color='#6E7681'>O sistema de incentivos por
02 <b>FUNDAMENTOS GIT: O modelo mental correto</b><br/><font size=8 color='#6E7681'>Commits, branches,
03 <b>GITHUB ANATOMY: Estrutura de um repo profissional</b><br/><font size=8 color='#6E7681'>README, Lic
04 <b>PERFIL GITHUB: Sua vitrine para recrutadores</b><br/><font size=8 color='#6E7681'>Profile README, pinn
05 <b>PADRÃO DE DOCUMENTAÇÃO: O que separa junior de senior</b><br/><font size=8 color='#6E7681'>REA
06 <b>WORKFLOW PROFISSIONAL: Como times sérios usam Git</b><br/><font size=8 color='#6E7681'>Branchin
07 <b>SEUS PROJETOS: Plano repo-a-repo</b><br/><font size=8 color='#6E7681'>20+ projetos com contexto, sta
08 <b>CHECKLIST FINAL: Auditoria de portfólio</b><br/><font size=8 color='#6E7681'>Validação ponto a ponto an
DIAGNÓSTICO
01
Por que GitHub é sua arma mais subestimada
O ERRO DE PREMISSA
Você pensa em GitHub como 'lugar de guardar código'. Recrutadores de Big Tech pensam em GitHub como
sua prova de competência técnica. Quando um recrutador da Nubank busca 'data engineer databricks' e
encontra seu perfil com repos bem documentados, você pula a fila de 500 currículos.
A LÓGICA OCULTA
O sistema de contratação em Big Tech funciona assim: (1) Recrutador filtra por keywords no LinkedIn/GitHub,
(2) Hiring Manager abre seu GitHub e avalia em 30 segundos se vale entrevistar, (3) Entrevistador técnico
verifica se você realmente entende o que documentou. Seu GitHub é o funil — sem ele, você nem entra no
processo.
ERRO COMUM
Hiring Managers gastam em média 30 segundos no seu GitHub. Se o README do repo principal não tiver: problema
resolvido + stack + arquitetura + resultados mensuráveis — NEXT.
O QUE RECRUTADORES AVALIAM NO GITHUB
CRITÉRIO JUNIOR SENIOR PESO
Contribution Graph Vazio ou irregular Consistente, diário ●●■
README Quality Título + 'como rodar' Problema → Solução → Métricas → Arquitetura
●●●
Commit Messages 'fix bug', 'update' Conventional Commits (feat:, fix:, docs:) ●●■
Repo Structure Tudo na raiz Pastas organizadas, .gitignore, CI/CD ●●●
Docs & ADRs Inexistente ADRs, CHANGELOG, CONTRIBUTING ●●●
Code Quality Scripts soltos Testes, linting, type hints ●●■
CONTEXTO NA SUA CARREIRA
Você tem 20+ projetos reais na Delp (Data Lake, KaizekaGPT, Portal de Notas, BIs, automações). Isso é ouro
para portfólio. O problema: hoje esses projetos existem só dentro da empresa. Nenhum recrutador sabe que
você existe. GitHub é o mecanismo que transforma trabalho interno em visibilidade externa.
DICA PRO
Você NÃO precisa publicar código proprietário da Delp. Publique: arquiteturas (diagramas), scripts genéricos
(templates de pipeline), documentação técnica (ADRs anonimizados), e projetos-exemplo que demonstrem o mesmo
skill sem expor dados da empresa.
FUNDAMENTOS GIT
02
O modelo mental que faz tudo fazer sentido
O QUE É GIT (DE VERDADE)
Git é um sistema de controle de versão distribuído. Tradução prática: é um sistema que fotografa o estado
do seu código a cada momento que você decide salvar (commit). Você pode voltar a qualquer foto anterior,
trabalhar em versões paralelas (branches), e combinar trabalho de várias pessoas sem que um sobrescreva o
outro.
Analogia industrial: Pense em Git como o sistema de revisões de projeto de engenharia da Delp. Cada
revisão é registrada, assinada, e você pode voltar a qualquer versão. Se o Rev.C introduziu um erro, volta pro
Rev.B. Branch é como ter duas equipes trabalhando em variações diferentes do mesmo projeto
simultaneamente.
OS 4 ESTADOS DO GIT
Todo arquivo no Git está em um destes estados. Entender isso elimina 90% da confusão:
ESTADO O QUE SIGNIFICA ANALOGIA DELP
Untracked Git não sabe que esse arquivo existe Documento novo no seu PC, fora do SGQ
Modified Arquivo mudou desde a última foto (commit) Desenho com alteração pendente de revisão
Staged Marcado para entrar na próxima foto Documento na fila de aprovação do coordenador
Committed Salvo permanentemente no histórico Revisão aprovada e registrada no SGQ
COMANDOS ESSENCIAIS — O FLUXO DIÁRIO
Estes são os únicos comandos que você precisa dominar para operar no dia-a-dia. Todo o resto é situacional.
# 1. Clonar repo (baixar projeto do GitHub para sua máquina)
git clone [Link]
# 2. Ver status (quais arquivos mudaram?)
git status
# 3. Adicionar arquivos para staging (preparar para commit)
git add [Link] # arquivo específico
git add . # TODOS os arquivos modificados
# 4. Fazer commit (salvar snapshot com mensagem descritiva)
git commit -m "feat: adiciona pipeline de ingestão Bronze"
# 5. Enviar para GitHub (sincronizar local → remoto)
git push origin main
# 6. Atualizar local (baixar mudanças do GitHub)
git pull origin main
BRANCHES: TRABALHO PARALELO SEM DESTRUIÇÃO
Branch = linha paralela de desenvolvimento. Você cria uma branch para trabalhar em algo novo sem afetar o
código principal (main). Quando termina e testa, faz merge (combina) de volta na main.
# Criar branch nova e entrar nela
git checkout -b feature/pipeline-bronze
# Trabalhar... fazer commits...
git commit -m "feat: implementa extração SQL Server"
# Voltar para main
git checkout main
# Combinar branch na main (merge)
git merge feature/pipeline-bronze
# Deletar branch (já foi mergeada, não precisa mais)
git branch -d feature/pipeline-bronze
DICA PRO
REGRA SÊNIOR: nunca commite direto na main. Sempre crie branch, trabalhe, abra Pull Request, e faça merge via
GitHub. Isso cria histórico de code review — exatamente o que Big Tech espera ver.
CONVENTIONAL COMMITS: MENSAGENS QUE IMPRESSIONAM
Mensagens de commit ruins (fix, update, test) mostram amadorismo. Conventional Commits é o padrão
profissional que Big Techs usam:
PREFIXO QUANDO USAR EXEMPLO
feat: Nova funcionalidade feat: adiciona endpoint de consulta NF por CNPJ
fix: Correção de bug fix: corrige timeout na conexão SQL Server
docs: Documentação docs: adiciona diagrama de arquitetura ao README
refactor: Refatoração (sem mudar comportamento)
refactor: extrai lógica de parsing para módulo
test: Adição/correção de testes test: adiciona testes unitários para validador
ci: Mudança em CI/CD ci: configura GitHub Actions para deploy staging
chore: Manutenção geral chore: atualiza dependências do [Link]
ANATOMIA DE UM REPO
03
A estrutura que grita 'esse cara é sênior'
Um repositório profissional tem uma estrutura previsível. Recrutadores reconhecem em 5 segundos se é
trabalho sênior ou projeto de tutorial. Aqui está a estrutura-alvo:
projeto-nome/
■■■ .github/
■ ■■■ workflows/ # CI/CD (GitHub Actions)
■ ■ ■■■ [Link]
■ ■■■ ISSUE_TEMPLATE/ # Templates para bugs/features
■ ■■■ PULL_REQUEST_TEMPLATE.md
■■■ docs/
■ ■■■ [Link] # Diagramas de arquitetura
■ ■■■ adr/ # Architecture Decision Records
■ ■ ■■■ [Link]
■ ■■■ [Link] # Guia de instalação detalhado
■■■ src/ # Código-fonte
■ ■■■ __init__.py
■ ■■■ pipeline/
■ ■■■ utils/
■■■ tests/ # Testes automatizados
■ ■■■ test_pipeline.py
■■■ .gitignore # Arquivos que Git ignora
■■■ .[Link] # Template de variáveis (sem secrets!)
■■■ [Link] # Porta de entrada — O MAIS IMPORTANTE
■■■ [Link] # Histórico de mudanças
■■■ [Link] # Como contribuir
■■■ LICENSE # Licença open-source
■■■ Makefile # Atalhos de comandos
■■■ [Link] # Dependências Python
EXPLICAÇÃO DE CADA ARQUIVO
.gitignore
Lista de arquivos/pastas que o Git deve IGNORAR. Nunca commite: senhas (.env), dependências
(node_modules), arquivos temporários (__pycache__), dados sensíveis. Use [Link] para gerar
automaticamente.
ERRO COMUM
Commitar .env com senhas no Git = senha exposta PARA SEMPRE. Git guarda histórico. Mesmo se deletar depois,
qualquer um pode ver no histórico. Use .[Link] com valores fake.
[Link]
A PÁGINA DE VENDA do seu projeto. É a primeira coisa que qualquer pessoa vê ao abrir o repo. Precisa
responder em 10 segundos: O que é? Que problema resolve? Qual a stack? Qual o resultado?
DICA PRO
80% da impressão que um recrutador tem do repo vem do README. Invista 30% do tempo do projeto nele.
LICENSE
Define como outros podem usar seu código. MIT = qualquer um pode usar/copiar (mais aberta). Apache 2.0 =
similar a MIT mas com proteção de patente. Sem license = ninguém pode usar legalmente.
INFO
Para portfólio, use MIT. É a mais comum e mostra que você entende open-source.
[Link]
Histórico de todas as mudanças significativas do projeto, organizado por versão. Segue formato Keep a
Changelog. Mostra maturidade profissional e disciplina de versionamento.
DICA PRO
Sêniors mantêm CHANGELOG atualizado a cada release. Juniors não sabem o que é.
docs/adr/
Architecture Decision Records: documentos curtos que explicam POR QUE uma decisão técnica foi tomada.
Ex: 'Por que escolhemos Delta Lake ao invés de Parquet puro?' Registra contexto, alternativas, e trade-offs.
DICA PRO
ADRs são o diferencial #1 que separa portfólio sênior de junior. É RARO ver isso em repos brasileiros.
PERFIL GITHUB
04
Sua vitrine para o mercado — cada pixel conta
PASSO 1: CRIAR CONTA PROFISSIONAL
Se ainda não tem conta GitHub, crie em [Link]. Username deve ser profissional — nada de apelidos.
Ideal: seu nome ou variação (ex: henrique-delp, hsilva-data).
PASSO 2: PROFILE README (A ARMA SECRETA)
GitHub permite criar um README especial que aparece na página do seu perfil. Para ativar: crie um repositório
com o MESMO NOME do seu username. O [Link] desse repo vira a 'capa' do seu perfil.
1 Crie repositório com seu username (ex: henrique-delp/henrique-delp)
2 Adicione [Link] com seu profile
3 Customize com badges, stats e links
TEMPLATE DE PROFILE README
# Henrique Silva ■
**Tech Lead | Data Engineering | AI/ML | Digital Transformation**
■ Leading digital transformation at industrial company (40+ years)
■ Building data platforms from scratch (Azure, Databricks, dbt)
■ Implementing AI solutions (RAG, LLMs, Predictive ML)
■■ Azure ecosystem (Data Factory, ADLS Gen2, Databricks)
## ■ Featured Projects
| Project | Description | Stack |
|---------|-------------|-------|
| [data-lakehouse-eto](link) | Enterprise Data Platform | Azure, Delta Lake, dbt |
| [kaizeka-rag-agent](link) | AI Agent with RAG | LangChain, OpenAI, Azure |
| [invoice-portal](link) | Invoice Management SaaS | [Link], SQL Server, React |
## ■ Stats
- RAG-based AI agent for industrial documentation
- BI dashboards for quality management (Power BI + Delta Lake)
## ■ Connect
[](seu-linkedin) []([Link]
PASSO 3: PINNED REPOSITORIES (OS 6 ESCOLHIDOS)
GitHub permite fixar até 6 repositórios no seu perfil. Esses são os primeiros que recrutadores veem. Escolha
estrategicamente — cada um deve demonstrar uma competência diferente:
SLOT PROJETO SUGERIDO COMPETÊNCIA DEMONSTRADA
1 data-lakehouse-eto Arquitetura de dados, Azure, Delta Lake, dbt
2 kaizeka-rag-agent IA aplicada, LLMs, RAG, LangChain
3 invoice-portal-api Backend, APIs REST, [Link], SQL Server
4 bi-dashboards-powerbi BI, modelagem dimensional, Power BI
5 azure-infra-templates DevOps, IaC, Terraform, CI/CD
6 python-data-pipelines Python, PySpark, automação de dados
PASSO 4: CONTRIBUTION GRAPH (O QUADRO VERDE)
O gráfico de contribuições mostra sua atividade diária. Um gráfico vazio = perfil morto. Não precisa commitar
código complexo todo dia — documentação, issues, e reviews contam. Meta mínima: 3-5 contribuições por
semana.
DICA PRO
Hack legítimo: ao criar documentação, escreva em Markdown no próprio repo e commite. Cada commit = 1 quadrado
verde. Ao invés de escrever docs no Word, escreva no GitHub.
DOCUMENTAÇÃO SÊNIOR
05
O diferencial que 95% dos devs brasileiros ignoram
README TEMPLATE COMPLETO (COPIE ISSO)
Este é o template que você deve usar em TODOS os seus repos. Adapte o conteúdo, mantenha a estrutura:
# ■ Nome do Projeto
> Uma linha que resume o projeto e o impacto.
  
## ■ Problem Statement
Descreva o problema de negócio que motivou o projeto.
Inclua métricas do 'antes' (ex: 'Relatórios levavam 4h').
## ■ Solution
Descreva sua solução em 2-3 parágrafos.
Inclua diagrama de arquitetura (imagem Mermaid ou [Link]).
## ■■ Architecture
```mermaid
graph LR
A[SQL Server] -->|ADF| B[Bronze/ADLS]
B -->|dbt| C[Silver]
C -->|dbt| D[Gold]
D -->|DirectQuery| E[Power BI]
```
## ■ Results
- Redução de X% no tempo de geração de relatórios
- R$ Y economizados em horas-pessoa/mês
- Z áreas consumindo dados self-service
## ■■ Tech Stack
| Layer | Technology |
|-------|-----------|
| Storage | Azure Data Lake Storage Gen2 |
| Processing | Databricks (PySpark) |
| Transformation | dbt Core |
| Orchestration | Azure Data Factory |
| Consumption | Power BI |
## ■ Quick Start
```bash
git clone [Link]
cd project
pip install -r [Link]
cp .[Link] .env # configure suas credenciais
python [Link]
```
## ■ Project Structure (tree do repo)
## ■ Testing
## ■ ADRs (Architecture Decision Records)
## ■ Contributing
## ■ License
ARCHITECTURE DECISION RECORDS (ADRs)
ADRs são documentos curtos (1 página) que registram decisões técnicas importantes. Formato padrão:
Contexto → Decisão → Consequências. Recrutadores técnicos AMAM ADRs porque demonstram pensamento
crítico, não apenas execução.
# ADR-001: Escolha de Delta Lake como formato de armazenamento
## Status: Aceito
## Data: 2025-03-15
## Contexto
Precisamos de formato de armazenamento para Data Lake que suporte:
- ACID transactions (pipeline pode falhar no meio)
- Schema evolution (novas colunas sem quebrar)
- Time travel (auditar dados históricos)
## Alternativas Consideradas
1. Parquet puro - Simples, mas sem ACID
2. Delta Lake - ACID + time travel + schema evolution
3. Apache Iceberg - Similar ao Delta, menor ecossistema Azure
## Decisão
Delta Lake, por integração nativa com Databricks (já contratado)
e suporte completo no Azure.
## Consequências
- (+) ACID garantido em todas as camadas
- (+) Time travel para auditoria
- (-) Vendor lock-in parcial com Databricks
- (-) Precisa de OPTIMIZE periódico (manutenção)
WORKFLOW PROFISSIONAL
06
Como times sérios usam Git no dia-a-dia
BRANCHING STRATEGY: TRUNK-BASED (RECOMENDADO)
Para time pequeno como o da Delp, trunk-based development é o ideal: uma branch main, feature branches
curtas (máximo 2-3 dias), merge via Pull Request. Nada de branches de 3 semanas — isso é onde bugs se
escondem.
# Fluxo completo trunk-based:
# 1. Atualizar main
git checkout main
git pull origin main
# 2. Criar feature branch
git checkout -b feature/pipeline-silver-transform
# 3. Trabalhar (commits pequenos e frequentes!)
git add .
git commit -m "feat: adiciona transformação de limpeza Silver"
git commit -m "test: adiciona testes para validação de schema"
# 4. Push para GitHub
git push origin feature/pipeline-silver-transform
# 5. Abrir Pull Request no GitHub (via browser)
# - Título descritivo
# - Descrição do que mudou e porquê
# - Solicitar review de colega
# 6. Após aprovação → Merge no GitHub (botão verde)
# 7. Deletar branch (GitHub oferece automaticamente)
PULL REQUESTS: O RITUAL DE CODE REVIEW
Pull Request (PR) é um pedido formal para mergear sua branch na main. Na Big Tech, NENHUM código entra
na main sem PR aprovado. Mesmo que você trabalhe sozinho, faça PRs — cria histórico de decisões técnicas
documentadas.
Template de PR profissional:
## O que muda
Adiciona pipeline de transformação da camada Silver para dados de produção.
## Por que
Dados brutos na Bronze têm nulos e duplicatas que causam erros nos dashboards.
## Como testar
1. Rodar `python -m pytest tests/test_silver.py`
2. Verificar output na tabela `[Link]`
## Checklist
- [x] Testes passando
- [x] Documentação atualizada
- [x] Sem secrets no código
- [ ] Review de pares solicitado
CI/CD COM GITHUB ACTIONS
GitHub Actions executa automações a cada push/PR. Crie arquivo .github/workflows/[Link] para: rodar testes
automaticamente, checar linting, e fazer deploy. Isso mostra maturidade DevOps.
# .github/workflows/[Link]
name: CI Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- run: pip install -r [Link]
- run: python -m pytest tests/ -v
- run: python -m flake8 src/
DICA PRO
Ter CI/CD no repo, mesmo que simples, é um dos sinais mais fortes de maturidade técnica. Se o badge de 'CI
Passing' aparece no README, recrutador sabe que você leva qualidade a sério.
SEUS PROJETOS
07
Plano detalhado repo-a-repo para seu portfólio
Aqui está o mapeamento de TODOS os projetos que já desenvolvemos/discutimos, organizados por prioridade
estratégica para portfólio Big Tech. Cada projeto tem: contexto público (sem expor dados Delp), stack
demonstrada, e sugestão de documentação.
ATENÇÃO
REGRA DE OURO: Você NÃO publica código proprietário. Publica versões genéricas que demonstram a mesma
competência. Ex: ao invés de 'Pipeline ETL da Delp', publique 'Pipeline ETL para indústria ETO' com dados fictícios
e a mesma arquitetura.
■ PRIORIDADE 1: data-lakehouse-platform
Campo Detalhe
Projeto Real DATA LAKE DELP — Implantação de Data Lake completo
Repo Público data-lakehouse-platform
Descrição End-to-end data lakehouse architecture for manufacturing industry. Bronze → Silver → Gold with Delta Lake, dbt, and Databrick
Stack Azure ADLS Gen2, Databricks, PySpark, dbt Core, Azure Data Factory, Delta Lake, Power BI
Competências Data Engineering, Cloud Architecture, ELT, Data Modeling (Kimball), DevOps
Impacto p/ CV ★★★★★ — É o projeto #1 que Big Techs querem ver
Estrutura sugerida do repo:
data-lakehouse-platform/
■■■ docs/adr/ # ADRs: Delta Lake, Kimball, ADF vs Airflow
■■■ pipelines/
■ ■■■ bronze/ # Scripts de ingestão (ADF configs)
■ ■■■ silver/ # Transformações dbt (limpeza, tipagem)
■ ■■■ gold/ # Modelos dimensionais dbt (star schema)
■■■ notebooks/ # Notebooks exploratórios Databricks
■■■ tests/ # Data quality tests (Great Expectations)
■■■ infra/ # Terraform/Bicep para provisioning Azure
■■■ [Link] # Com diagrama de arquitetura completo
■■■ Makefile # make test, make deploy, make docs
README deve conter: Diagrama Bronze→Silver→Gold, métricas de impacto (tempo de relatório
antes/depois), ADR sobre escolha do Delta Lake, e link para artigo no LinkedIn.
■ PRIORIDADE 2: kaizeka-rag-agent
Campo Detalhe
Projeto Real KaizekaGPT — Agente IA com RAG para documentação interna
Repo Público kaizeka-rag-agent
Descrição RAG-based AI agent for industrial documentation retrieval. Combines LLM capabilities with company-specific knowledge base.
Stack Python, LangChain, OpenAI API, Azure Cognitive Search, FastAPI, ChromaDB/FAISS
Competências LLM/RAG, NLP, API Design, Vector Databases, Prompt Engineering
Impacto p/ CV ★★★★★ — IA aplicada é o hype #1 de contratação
kaizeka-rag-agent/
■■■ docs/adr/ # ADRs: LangChain vs LlamaIndex, embedding model
■■■ src/
■ ■■■ ingestion/ # Document loading + chunking
■ ■■■ retrieval/ # Vector search + reranking
■ ■■■ generation/ # LLM prompts + chain logic
■ ■■■ api/ # FastAPI endpoints
■■■ tests/ # Eval metrics (relevance, faithfulness)
■■■ configs/ # Prompt templates, model configs
■■■ [Link] # Com diagrama RAG pipeline
■■■ [Link] # Setup local completo
■ PRIORIDADE 3: invoice-portal-api
Campo Detalhe
Projeto Real Portal de Notas — Sistema SaaS de gestão de notas fiscais
Repo Público invoice-portal-api
Descrição RESTful API for invoice management system with multi-tenant architecture. Built for industrial suppliers.
Stack [Link], Express, SQL Server, React (frontend), Azure VMs, Nginx, PM2
Competências Backend Development, REST APIs, Database Design, DevOps, Full-Stack
Impacto p/ CV ★★★★■ — Mostra que você entrega software end-to-end
■ PRIORIDADE 4: bi-quality-dashboards
Campo Detalhe
Projeto Real BI SGQ + BI Qualidade + People Analytics + Controle de Projetos
Repo Público bi-quality-dashboards
Descrição Collection of business intelligence solutions for manufacturing quality management. Star schema modeling, DAX optimization, a
Stack Power BI, DAX, SQL Server, Python (automação), Kimball methodology
Competências BI Architecture, Dimensional Modeling, DAX, Data Visualization
Impacto p/ CV ★★★★■ — BI ainda é skill demandado, especialmente com modelagem correta
Inclui projetos: BI People Analytics RH, BI SGQ, BI Controle de Qualidade, BSC Integrado Fase 3, BI Controle
de Projetos Pasta 36, Gestão de Custos Usinagem, Reformulação HH/TON. Todos consolidados em 1 repo
demonstrando capacidade de BI em escala.
■ PRIORIDADE 5: industrial-automation-suite
Campo Detalhe
Projeto Real Ciro Automático + CDS Automático + DataBook Digital + Delp Ideia + RPA Databooks
Repo Público industrial-automation-suite
Descrição Suite of automation tools for industrial engineering workflows. Includes document generation, process automation, and RPA sol
Stack Python, Power Automate, OCR, Flask/FastAPI, SQL Server
Competências Process Automation, RPA, Python scripting, System Integration
Impacto p/ CV ★★★■■ — Suporte, demonstra pragmatismo e impacto operacional
■ PRIORIDADE 6: orcabot-quotation-agent
Campo Detalhe
Projeto Real OrçaBot — Agente IA de cotações automáticas
Repo Público orcabot-quotation-agent
Descrição AI-powered quotation agent that automates supplier price comparison and generates recommendations for industrial procureme
Stack Python, LangChain, OpenAI, Web Scraping, FastAPI, PostgreSQL
Competências AI Agents, NLP, Automation, API Integration
Impacto p/ CV ★★★★■ — AI Agent é o hype mais quente de 2025-2026
PROJETOS SECUNDÁRIOS (Repos de Suporte)
Estes projetos podem virar repos menores ou serem referenciados dentro dos repos principais:
PROJETO REAL REPO SUGERIDO CATEGORIA
Percepto (Monitoramento) percepto-process-monitoring IoT / Monitoring
SOC (Controle Projetos) Integrar no bi-quality-dashboards BI
Planejamento Digital SKA Integrar no industrial-automation-suite Automação
Plataforma Gestão Mudança change-management-platform Web App
Stratws One / BSC Integrar no bi-quality-dashboards BI
Carregamento Fabril Integrar no data-lakehouse-platform Data
Controle Contratos Integrar no industrial-automation-suite Automação
Reserva Material Integrar no invoice-portal-api Backend
CHECKLIST FINAL
08
Auditoria completa antes de mostrar ao mercado
CHECKLIST DE PERFIL
■ Username profissional (sem números aleatórios ou apelidos)
■ Profile README criado e completo (repo com seu username)
■ Foto profissional no perfil
■ Bio com: cargo + stack principal + link LinkedIn
■ 6 repos pinados cobrindo: Data, IA, Backend, BI, DevOps, Automação
■ Contribution graph com atividade nos últimos 30 dias
■ Pelo menos 1 repo com stars de outras pessoas (peça para colegas)
CHECKLIST POR REPO (Aplicar em cada um dos 6 pinados)
■ [Link] completo com: Problem → Solution → Architecture → Results → Stack → Quick Start
■ Diagrama de arquitetura (Mermaid, [Link] ou imagem)
■ Pelo menos 1 ADR em docs/adr/
■ .gitignore adequado (nenhum arquivo sensível no repo)
■ .[Link] (nunca .env real!)
■ LICENSE (MIT para portfólio)
■ [Link] com pelo menos 3 versões
■ CI/CD configurado (.github/workflows/[Link])
■ Badge de CI no README (verde = passing)
■ Commits seguindo Conventional Commits (feat:, fix:, docs:)
■ Mínimo 20 commits com mensagens descritivas
■ Pelo menos 3 Pull Requests mergeados (mesmo que auto-review)
■ Testes presentes (mesmo que básicos)
■ Código organizado em pastas (src/, tests/, docs/)
■ Métricas de impacto mencionadas no README (números reais ou realistas)
CRONOGRAMA DE EXECUÇÃO SUGERIDO
SEMANA AÇÃO ENTREGÁVEL
Sem 1 Setup: conta GitHub, .gitconfig, SSH keys, profile README Perfil ativo com Profile README
Sem 2 Repo #1: data-lakehouse-platform (estrutura + README + ADR)
Repo publicado e pinado
Sem 3 Repo #2: kaizeka-rag-agent (estrutura + README + código Repo
base) publicado e pinado
Sem 4 Repo #3: invoice-portal-api (estrutura + README + CI/CD) Repo publicado e pinado
Sem 5 Repo #4: bi-quality-dashboards (README + modelos + métricas)
Repo publicado e pinado
Sem 6 Repo #5 e #6: automation + orcabot (estrutura + README) 6 repos pinados completos
Sem 7 Polish: badges, contribution graph, cross-links entre repos Portfólio pronto para review
Sem 8 Validação: pedir feedback de 2 devs seniores + postar no LinkedIn
Portfólio publicado
ERRO COMUM
AÇÃO IMEDIATA: Abra [Link] agora, crie a conta (ou limpe a existente), e execute a Semana 1. Não espere ler
tudo para começar. Cada semana é independente. A pior coisa que pode acontecer é você ler este documento
inteiro e não fazer nada.
Confiança desta entrega: 0.93
Alta: baseado em análise completa de 20+ projetos mapeados, histórico de conversas, e padrões reais de contratação Big Tech BR.
Limitação: adaptações serão necessárias conforme você publicar código real vs. templates genéricos.