---
name: adding-to-github
description: Use when user wants to add, update, commit, or push anything to the Oswald GitHub repository - guides through branch selection, file staging, committing, and PR creation step by step
---

# Přidávání do GitHubu (NetWalking Pro projekt)

## Přehled

Průvodce pro bezpečné přidávání obsahu do Oswald knowledge base na GitHubu.

**Základní pravidlo:** Vždy větev → soubory → commit → push → PR. Nikdy přímo do main.

**Při zahájení řekni uživateli:**
> "Spouštím průvodce přidáváním do GitHubu. Projdeme to krok po kroku – u každého kroku ti vysvětlím co děláme a proč."

---

## 📖 Odkaz na manuál

Před zahájením práce upozorni uživatele:
> "Máme Notion manuál 'Github for Dummies' který vysvětluje vše od základů. Pokud ti něco není jasné, najdeš tam podrobnější vysvětlení: https://www.notion.so/319977b58b5381379e85c1dc047ec71c"

---

## 🧭 Jak Git funguje – základní model

Než začneme, připomeň uživateli mentální model z manuálu (stejná přirovnání):

- **Tvůj počítač** = pracovní plocha. Soubory jsou jen u tebe.
- **Větev (branch)** = osobní kopie rukopisu. Jako kdybys psal kapitoly knihy – každý autor má svoji kopii, sloučení do finální verze přijde až po schválení.
- **Commit** = uložení hry. Vytváříš bod, ke kterému se lze kdykoli vrátit. Zatím jen na tvém počítači.
- **Staging** = balení kufru. Máš na posteli více věcí (změněných souborů), ale do kufru (commitu) dáš jen to co patří dohromady.
- **Push** = nahrát na sdílený disk. Teprve teď to vidí ostatní.
- **Pull Request (PR)** = odevzdat dokument ke kontrole nadřízenému. On/ona schválí a pak se stane součástí "oficiální verze".
- **Main** = oficiální verze projektu. Nikdy přímo sem.

---

## Krok 1: Co přidáváš?

**Zeptej se uživatele:**
- Je to nový dokument, nebo upravuješ existující?
- Čeho se týká? (prodej, strategie, firma, procesy, šablony…)

**Vysvětli uživateli:**
> "Potřebuji vědět kam soubor patří – v tomto projektu má každý typ dokumentu své místo. Máme na to routovací tabulku v CLAUDE.md."

Podle odpovědi najdi správné umístění v CLAUDE.md → Knowledge Routing Table a navrhni ho uživateli:
> "Tento soubor patří do `processes/sales/` – tam jsou všechny sales procesy."

---

## Krok 2: Zkontroluj větev

```bash
git branch --show-current
```

**Vysvětli uživateli:**
> "Představ si, že píšete kolektivní knihu. Každý autor dostane svoji vlastní kopii rukopisu a pracuje na svých kapitolách – teprve až je hotov, navrhne začlenění svého textu do hlavní verze. Větev je právě ta osobní kopie. Ty nikdy nepracuješ přímo na `main` (finální verzi knihy)."

**Pravidla pojmenování:**
- Člověk: `feature/{scope}-{popis}` → např. `feature/sales-cenova-politika`
- AI agent: `agent/{scope}-{popis}` → např. `agent/sales-chytry-kolega`

**Scope = název složky dokumentu:** `sales`, `strategy`, `context`, `processes`, `agents`, `blueprints`, `templates`, `reference`, `docs`

Pokud je uživatel na `main`, vytvoř novou větev:
```bash
git checkout -b feature/{scope}-{kratky-popis}
```

Navrhni název větve a zeptej se uživatele jestli souhlasí. Pak větev vytvoř.

---

## Krok 3: Zkontroluj co je na počítači

```bash
git status
```

**Vysvětli uživateli výstup:**
> "Git mi říká co se na tvém počítači změnilo oproti poslednímu commitu. Pojďme si to přečíst."

Ke každému souboru vysvětli co znamená jeho stav:
- `M` (modified) = soubor existoval a byl upraven
- `??` (untracked) = nový soubor, Git ho zatím nesleduje
- `D` (deleted) = soubor byl smazán
- `A` (added/staged) = soubor je připravený k commitu

Zeptej se: "Jsou toto všechny soubory, které chceš přidat? Nebo je tu něco co přidávat nechceš?"

---

## Krok 4: Staging – výběr souborů pro commit

```bash
git add {konkretni-soubor}
```

**Vysvětli uživateli:**
> "Staging je jako balení kufru. Máš na posteli různé věci (změněné soubory), ale do kufru (commitu) dáš jen to, co patří dohromady. Díky tomu můžeš mít na počítači rozeditovaných 5 souborů, ale do jednoho commitu dáš jen ty, které spolu logicky souvisí."

**NIKDY nepoužívej `git add -A` ani `git add .`**
> "Tyto příkazy přidají VŠE – včetně dočasných souborů v tmp/, nebo osobních nastavení. Vždy přidávej konkrétní soubory."

Po přidání ukaž co je ve stage:
```bash
git diff --staged --name-only
```

> "Toto jsou soubory, které půjdou do commitu. Vypadá to správně?"

Počkej na potvrzení od uživatele.

---

## Krok 5: Commit – uložení snímku

```bash
git commit -m "type(scope): krátký popis v angličtině"
```

**Vysvětli uživateli:**
> "Commit je jako uložení hry. Kdykoli uložíš, vytvoříš bod v historii, ke kterému se lze vrátit. Commitovat pravidelně = chránit svou práci. Git si zapamatuje přesný stav souborů a ty mu říkáš co se změnilo a proč – za rok se podíváš do historie a budeš vědět proč byl soubor takhle napsán."

**Formát commit message – conventinal commits:**
| Typ | Kdy použít | Příklad |
|-----|-----------|---------|
| `feat` | Nový dokument nebo funkce | `feat(sales): add phase 3 AI analysis` |
| `docs` | Aktualizace existujícího | `docs(strategy): update Q1 OKRs` |
| `fix` | Oprava odkazu, překlep | `fix(processes): fix broken link` |
| `chore` | Metadata, verze, frontmatter | `chore: bump document versions` |
| `refactor` | Přeorganizování bez změny obsahu | `refactor(agents): reorganize personas` |

Navrhni commit message uživateli:
> "Navrhuji: `feat(sales): add cenová politika pro Chytrý Kolega`. Souhlasíš?"

Pak teprve commitni.

---

## Krok 6: Push – nahrání na GitHub

```bash
git push -u origin {nazev-vetve}
```

**Vysvětli uživateli:**
> "Push je jako nahrát dokument na sdílený disk. Teprve teď to vidí ostatní. Ale pozor – nahráváš jen svoji větev, `main` se vůbec nemění. Ostatní vidí tvůj koncept, ale do finální verze projektu se nedostal."

Příznak `-u origin` nastaví propojení větve s GitHubem – příště stačí jen `git push`.

Potvrď uživateli:
> "Hotovo. Tvoje větev `feature/...` je teď na GitHubu. Main se nezměnil."

---

## Krok 7: Pull Request – žádost o schválení

**Vysvětli uživateli:**
> "Pull Request je jako odevzdání dokumentu ke kontrole nadřízenému. On/ona si ho přečte, dá zpětnou vazbu nebo ho rovnou schválí – a teprve pak se stane součástí 'oficiální verze'. Toto je ochrana kvality. Mantainer (správce) provede review, případně přidá komentáře, a pak schválí nebo požádá o úpravy."

```bash
gh pr create --title "type(scope): popis" --body "$(cat <<'EOF'
## Co se změnilo
- [co a proč – pro kolegy kteří neznají kontext]

## Dotčené soubory
- `path/to/file.md` (new / updated / removed)

## Status přechod
- např. `draft` → `review`

🤖 Vytvořeno s Claude Code
EOF
)"
```

Pomoz uživateli napsat PR popis – přelož technické změny do lidské řeči:
> "Popis PR je pro kolegy. Napišme ho tak, aby pochopili co jsi udělal, i kdyby neznali detaily."

---

## Krok 8: Čekání na review

**ZASTAV SE ZDE.**

**Vysvětli uživateli:**
> "PR nesmíš mergovat sám – to je pravidlo tohoto projektu. Slouží to jako čtyřoký princip: někdo jiný vždy zkontroluje práci. Teď pošli kolegovi číslo PR a řekni mu ať se na to podívá."

Řekni uživateli:
- Číslo PR (např. `#16`)
- Co se po schválení stane: kolega klikne Merge a tvoje změny se dostanou do `main`
- Jak zjistit jestli byl PR schválen: GitHub pošle email, nebo zkontroluj `gh pr status`

---

## Rychlý checklist

- [ ] Na větvi (ne main)?
- [ ] Soubor ve správné složce dle routing table?
- [ ] Soubor má YAML frontmatter?
- [ ] Staged jen správné soubory (ne tmp/, settings)?
- [ ] Commit message: `type(scope): popis`?
- [ ] Push na origin proběhl?
- [ ] PR vytvořen s lidsky čitelným popisem?
- [ ] Kolega informován?

---

## Časté chyby a co se stane

| Chyba | Co se stane | Jak to poznat | Řešení |
|-------|------------|---------------|---------|
| Práce na `main` | Push se zablokuje | `git branch` ukáže `main` | `git checkout -b feature/...` |
| `git add -A` | Přidají se tmp/ nebo secrets | `git diff --staged` ukáže nechtěné soubory | `git reset HEAD {soubor}` pro odebrání ze stage |
| Chybí YAML frontmatter | CI validace selže, PR se nezlije | Červený křížek v PR na GitHubu | Přidej frontmatter dle `docs/conventions.md` |
| Prázdný PR popis | Kolegové nemohou zrevidovat | PR vypadá prázdně | Doplň co a proč |
| Self-merge | Porušení governance | – | Vždy požádej kolegu |

---

## Kde najít správné umístění souborů

Otevři `CLAUDE.md` → sekce **Knowledge Routing Table**.

Nejčastější destinace:
| Typ dokumentu | Kam patří |
|--------------|-----------|
| Sales procesy | `processes/sales/` |
| Strategie, OKRs | `strategy/` |
| Info o firmě, týmu | `context/company/` |
| Produkty, ceník | `context/products/` |
| Šablony dokumentů | `templates/` |
| AI agent konfigurace | `agents/` |
| Technická rozhodnutí | `strategy/decisions/` |