ganbatte-os 0.2.1

package/playbooks/ssh-multi-account-setup.md

@@ -0,0 +1,185 @@
+# SSH Multi-Account Setup Playbook
+
+**Proposito:** Configurar acesso SSH para multiplas contas GitHub na mesma maquina, com alias dedicados e identidade por repositorio.
+
+**Sucesso quando:**
+- Chaves Ed25519 geradas para cada conta
+- `~/.ssh/config` com alias por conta (IdentitiesOnly=yes)
+- `ssh -T` valida todas as conexoes
+- Cada workspace tem `ssh-identity.json` configurado via skill `git-ssh-setup`
+- Nenhum alias real exposto em documentacao ou output de agentes
+
+---
+
+## Pre-requisitos
+
+- [ ] Acesso SSH habilitado nas contas GitHub
+- [ ] OpenSSH instalado (`ssh -V` retorna versao)
+- [ ] Permissoes de escrita em `~/.ssh/`
+
+---
+
+## Phase 1: Key Generation
+
+Gerar uma chave Ed25519 por conta. Usar nome descritivo no arquivo.
+
+```bash
+ssh-keygen -t ed25519 -C "<email-da-conta>" -f ~/.ssh/id_ed25519_<account-name>
+```
+
+Repetir para cada conta. Convencao de nomes:
+- `id_ed25519_<account-name>` — nome curto, sem espacos, lowercase
+
+Verificar que os arquivos foram criados:
+```bash
+ls -la ~/.ssh/id_ed25519_<account-name>*
+# Deve mostrar: id_ed25519_<account-name> (privada) e id_ed25519_<account-name>.pub (publica)
+```
+
+**Regra de seguranca:** NUNCA compartilhar ou versionar a chave privada.
+
+---
+
+## Phase 2: SSH Config File
+
+Editar `~/.ssh/config` (criar se nao existir). Adicionar uma entrada por conta:
+
+```
+Host github-<account-name>
+  HostName github.com
+  User git
+  IdentityFile ~/.ssh/id_ed25519_<account-name>
+  IdentitiesOnly yes
+```
+
+Repetir o bloco para cada conta, trocando `<account-name>` e o path da chave.
+
+**Convencao de alias:** `github-<nome-curto>`. Exemplos: `github-personal`, `github-work`, `github-client`.
+
+Permissoes corretas:
+```bash
+chmod 600 ~/.ssh/config
+chmod 600 ~/.ssh/id_ed25519_*
+```
+
+---
+
+## Phase 3: GitHub Key Registration
+
+Para cada conta, copiar a chave publica e registrar no GitHub:
+
+```bash
+cat ~/.ssh/id_ed25519_<account-name>.pub
+```
+
+1. Acessar GitHub → Settings → SSH and GPG keys → New SSH key
+2. Titulo: nome da maquina + proposito (ex: "Workstation - Personal")
+3. Colar o conteudo da `.pub`
+4. Salvar
+
+---
+
+## Phase 4: URL Rewrite Rules (Opcional)
+
+Para que `git clone github.com/org/repo` use automaticamente o alias correto:
+
+```bash
+git config --global url."git@github-<account-name>:<github-username>/".insteadOf "https://github.com/<github-username>/"
+```
+
+Isso converte URLs HTTPS para SSH automaticamente durante clone/fetch/push.
+
+**Nota:** So usar se uma unica conta domina os repos de um org/username. Para repos mistos, configurar remote manualmente.
+
+---
+
+## Phase 5: Connection Validation
+
+Testar cada alias:
+
+```bash
+ssh -T git@github-<account-name>
+```
+
+Resposta esperada:
+```
+Hi <github-username>! You've successfully authenticated, but GitHub does not provide shell access.
+```
+
+Se falhar, diagnosticar:
+```bash
+# Verbose — mostra qual chave esta sendo usada
+ssh -vT git@github-<account-name>
+
+# Verificar chaves carregadas no agent
+ssh-add -l
+
+# Carregar chave no agent se necessario
+ssh-add ~/.ssh/id_ed25519_<account-name>
+```
+
+---
+
+## Phase 6: Workspace Configuration
+
+Para cada repositorio, configurar a identidade SSH usando a skill `git-ssh-setup`:
+
+```
+/git-ssh-setup
+```
+
+Ou manualmente:
+
+1. Verificar/ajustar remote URL:
+```bash
+git remote get-url origin
+# Se HTTPS, converter:
+git remote set-url origin git@github-<account-name>:<org>/<repo>.git
+```
+
+2. Configurar git identity local:
+```bash
+git config user.name "<nome>"
+git config user.email "<email>@users.noreply.github.com"
+```
+
+3. Se usar framework .a8z-OS ou G-OS: o arquivo `ssh-identity.json` sera gravado automaticamente pela skill.
+
+---
+
+## Checklist Final
+
+- [ ] Todas as chaves geradas e com permissoes 600
+- [ ] `~/.ssh/config` com entradas para todas as contas
+- [ ] `ssh -T` passa para todos os aliases
+- [ ] Chaves publicas registradas no GitHub
+- [ ] Cada workspace com remote URL usando alias correto
+- [ ] Git user.name e user.email configurados localmente por repo
+- [ ] Nenhuma chave privada versionada ou exposta
+
+---
+
+## Troubleshooting
+
+### "Permission denied (publickey)"
+1. Verificar se a chave esta carregada: `ssh-add -l`
+2. Carregar: `ssh-add ~/.ssh/id_ed25519_<account-name>`
+3. Se ssh-agent nao esta rodando: `eval $(ssh-agent -s)`
+
+### "Could not resolve hostname github-xxx"
+1. Verificar `~/.ssh/config` — o alias deve existir com `HostName github.com`
+2. Verificar indentacao do config (espacos, nao tabs)
+
+### "Repository not found" ao clonar
+1. Verificar que esta usando o alias correto para a conta que tem acesso
+2. Formato: `git clone git@github-<account-name>:<org>/<repo>.git`
+
+### Commits com usuario errado
+1. Verificar: `git config user.name` e `git config user.email`
+2. Se retorna global ao inves de local: `git config user.name "<nome>"`
+3. Usar flag `--local` para garantir: `git config --local user.email "<email>"`
+
+---
+
+**Versao:** 1.0
+**Referencia:** Skill `git-ssh-setup` para configuracao automatizada por workspace.

package/prompts/01-search.md

@@ -0,0 +1,18 @@
+# gos.search
+
+Use este prompt quando a tarefa for descobrir contexto antes de construir.
+
+## Objetivo
+
+- entender o projeto, o design ou o output gerado por IA
+- identificar stack, fluxo, componentes, restricoes e dependencias
+- decidir qual skill ou squad do `G-OS` deve assumir a proxima etapa
+
+## Rotas mais comuns
+
+- Figma com frame URL: `figma-implement-design`
+- Screenshot ou referencia visual: `design-to-code`
+- Figma Make bruto: `figma-make-analyzer`
+- Codigo do Stitch ou outro gerador: `make-code-triage`
+- Planejamento de entrega: `sprint-planner`
+- Sincronizacao operacional: `clickup`

package/prompts/02-spec.md

@@ -0,0 +1,19 @@
+# gos.spec
+
+Converta a descoberta em especificacao curta e executavel.
+
+## Deve incluir
+
+- escopo claro
+- entradas e saidas
+- decisoes de arquitetura relevantes
+- fluxos de UI e regras de negocio
+- arquivos provaveis a criar ou alterar
+- risco principal e forma de validar
+
+## Foco do G-OS
+
+- design-to-code
+- React/Next.js
+- handoff de Figma/Figma Make/Stitch
+- backlog pronto para sprint

package/prompts/03-tasks.md

@@ -0,0 +1,15 @@
+# gos.tasks
+
+Quebre a especificacao em tarefas pequenas e ordenadas.
+
+## Regras
+
+- cada task deve caber em menos de um dia
+- separar FE, UX, QA, DevOps e operacao ClickUp quando fizer sentido
+- incluir criterios de aceite objetivos
+- explicitar dependencias
+
+## Saida esperada
+
+- backlog pronto para `sprint-planner`
+- ou JSON/markdown que possa virar importacao no ClickUp

package/prompts/04-code.md

@@ -0,0 +1,10 @@
+# gos.code
+
+Implemente a entrega usando os artefatos do `G-OS`.
+
+## Prioridades
+
+- seguir `react-architecture`
+- usar `frontend-dev`, `design-to-code` e `figma-implement-design` quando aplicavel
+- tratar output de Figma Make/Stitch como material de triagem antes de integrar
+- validar com `react-doctor` e `react-best-practices`

package/prompts/05-reviews.md

@@ -0,0 +1,11 @@
+# gos.review
+
+Revise a entrega com foco em regressao, fidelidade ao design e prontidao para sprint.
+
+## Checagens minimas
+
+- arquitetura e separacao por camada
+- aderencia ao design/tokens
+- acessibilidade
+- riscos de dados mockados ou codigo Make misturado com UI final
+- importacao/sincronizacao correta para ClickUp quando fizer parte do fluxo

package/rules/plan-mode.md

@@ -0,0 +1,60 @@
+---
+paths: "**"
+---
+
+# Plan Mode — Planejamento Obrigatório Antes de Agir
+
+## Quando Ativar
+
+Ativar **PLAN MODE** automaticamente sempre que o input do usuário envolver **qualquer** dos triggers abaixo:
+
+### Triggers de Conteúdo
+- Verbos de intenção: `analisar`, `planejar`, `criar tasks`, `arquitetar`, `refatorar`, `redesign`, `implementar`, `criar`, `construir`, `organizar`, `estruturar`, `migrar`, `integrar`
+- Escopo: tarefa com **>3 passos** em múltiplos domínios
+- Criação: novo feature, nova skill, novo agente, novo componente, novo módulo
+- Sprint: histórias, backlog, roadmap, planning
+- Arquitetura: revisão cross-cutting, redesign de sistema, decisão técnica
+- Análise de código/codebase com intenção de mudança
+
+### Exceções — NÃO ativar plan mode
+- Git operations: `commit`, `push`, `pull`, `branch`, `merge`, `status`, `log`
+- Leitura e explicação: "o que é", "como funciona", "onde está", "mostre", "explique"
+- Edições simples: 1 arquivo, 1 mudança isolada (ex: corrigir typo, ajustar 1 linha)
+- Quando o usuário inclui: `"só faça"`, `"execute direto"`, `"sem plano"`, `"direto ao ponto"`
+- Quando plan mode já foi ativado ou aprovado na sessão atual
+
+---
+
+## Protocolo de 4 Fases
+
+### Fase 1 — RESEARCH
+- Investigar o problema sem alterar nenhum arquivo
+- Ler arquivos relevantes, entender arquitetura, identificar dependências
+
+### Fase 2 — PLAN
+- Criar o artefato `implementation_plan.md` com:
+  - Objetivo e contexto
+  - Mudanças propostas agrupadas por componente
+  - Arquivos a criar `[NEW]`, modificar `[MODIFY]`, deletar `[DELETE]`
+  - Plano de verificação
+- **Apresentar o plano ao usuário e PARAR**
+
+### Fase 3 — AWAIT APPROVAL
+- Aguardar aprovação explícita do usuário (`"ok"`, `"aprovado"`, `"go"`, etc.)
+
+### Fase 4 — EXECUTE + TRACK
+- Criar `task.md` com checklist de tarefas
+- Executar as tarefas marcando progresso
+- Criar `walkthrough.md` ao finalizar
+
+---
+
+## Artefatos
+
+| Fase | Artefato | Propósito |
+|------|----------|-----------|
+| PLAN | `implementation_plan.md` | Plano técnico para revisão do usuário |
+| EXECUTE | `task.md` | Checklist de progresso |
+| DONE | `walkthrough.md` | Resumo do que foi implementado |
+
+Referência central: `rules/plan-mode.md` (G-OS context)