Claude Code Tahák

Projdi celý projekt a vytvoř CLAUDE.md.

Zahrň:
- Jak spustit dev server a build
- Strukturu projektu (hlavní složky a co v nich je)
- Konvence (pojmenování, styling, testy)
- Důležité příkazy (test, lint, deploy)
- Gotchas — věci co nováčka překvapí

Podívej se na existující konfiguraci (package.json, tsconfig, .eslintrc) a dokumentaci.
Buď stručný — CLAUDE.md čte AI agent, ne člověk.

Vytvoř nový REST endpoint [GET/POST/PUT/DELETE] /api/v1/[resource].

Dodržuj konvence z CLAUDE.md. Podívej se na existující endpoint v [soubor] jako vzor.

Kontext:
- Autentizace: [Bearer token / API key / žádná]
- Databáze: [existující tabulka / vytvoř migraci]

Požadavky:
- Validace inputu s konkrétními chybovými zprávami
- Error handling (422, 404, 500)
- Vrací JSON response ve stejném formátu jako [konkrétní soubor]
- [test framework] test (happy path + error cases)

Akceptační kritéria:
- [ ] Endpoint odpovídá na správnou URL
- [ ] Úspěšný request vrací správný status (200/201/204)
- [ ] Validace funguje (test s neplatnými daty → 422)
- [ ] Testy procházejí

Refaktoruj třídu v [soubor].

Problémy:
- [konkrétní problém 1]
- [konkrétní problém 2]

Pravidla:
- Zachovej veřejné API (žádné breaking changes)
- [coding standard]
- Existující testy musí stále procházet
- Přidej testy pro nově extrahované metody

Spusť testy po každé změně: [test příkaz] --filter [Třída]

Napiš [test framework] testy pro [soubor/třída].

Podívej se na existující testy v [test_dir] pro styl a konvence.

Pokryj:
- Happy path pro každou veřejnou metodu
- Edge cases (prázdný input, null, boundary values) — použij [parametrized test pattern]
- Error cases (nevalidní data, neexistující záznamy)
- Mockuj externí závislosti (DB, API) přes [mock metoda]

Každý test musí fungovat nezávisle. Ověř: [test příkaz] --coverage-text
Cíl: >80% code coverage pro tuto třídu.

Vytvoř [framework] komponentu [NázevKomponenty]

Podívej se na [existující_komponenta] jako vzor pro náš styl.

Požadavky:
- [component pattern]
- Props s typy a default hodnotami
- Emits správně typované
- Responzivní (mobile-first)
- SSR-safe: [SSR-safe pattern]
- Přístupnost: sémantické HTML, ARIA atributy
- Dodržuj náš design system z [soubor]

Přidej [test runner] test ([test utilities] pro mount) — renderování, props, emitované eventy.

Vytvoř hook/composable use[Název].

Vzor: podívej se na [existující_composable].

Požadavky:
- Plně TypeScript typy (žádné any), typovaný return objekt
- SSR-safe: [state management] pro sdílený stav
- Reaktivní stav přes [state management]
- Cleanup v onUnmounted
- Error handling
- JSDoc dokumentace

Napiš unit test (reaktivita, error handling, cleanup).

Oprav layout problém v [komponenta]:

Aktuální chování: [co se děje]
Očekávané chování: [co se má dít]
Kde se to projevuje: [breakpoint/prohlížeč/stránka]

Pravidla:
- Použij existující utility třídy kde je to možné
- Nerozbij ostatní stránky
- Nesmí vzniknout hydration mismatch (SSR)
- Otestuj na mobile (375px), tablet (768px) i desktop (1440px)
- Spusť build a ověř že prochází bez chyb

/ralph-loop:ralph-loop "Implementuj feature podle PRD.md.

V každé iteraci:
1. Přečti PRD.md a progress.md (pokud progress.md neexistuje, vytvoř ho ze seznamu itemů v PRD.md)
2. Najdi další nehotový item
3. Implementuj ho
4. Spusť lint a testy
5. Pokud testy procházejí, commitni a aktualizuj progress.md
6. Pokud všechny items hotové, vypiš <promise>===COMPLETE===</promise>

Pokud po 2 neúspěšných pokusech o stejný item testy stále neprocházejí, zapiš problém do BLOCKED.md a pokračuj dalším itemem." --max-iterations 25 --completion-promise "===COMPLETE==="

/ralph-loop:ralph-loop "Refaktoruj všechny soubory v [dir] aby používaly [nový pattern].

Vzor: [soubor] je už hotový, použij ho jako referenci.

V každé iteraci:
1. Vypiš seznam zbývajících souborů k refaktorování
2. Zpracuj 1-2 soubory
3. Po každém souboru spusť testy
4. Pokud testy prošly, commitni
5. Pokud testy selhaly 3x na stejném souboru, přeskoč ho a zapiš do BLOCKED.md

Když jsou všechny soubory hotové (nebo přeskočené), vypiš <promise>===COMPLETE===</promise>" --max-iterations 40 --completion-promise "===COMPLETE==="

/ralph-loop:ralph-loop "Projdi [dir] a napiš chybějící testy.

V každé iteraci:
1. Spusť testy s coverage ([test příkaz] --coverage) a najdi soubor s nejnižší coverage
2. Napiš testy (happy path + edge cases)
3. Spusť testy, oprav pokud padají
4. Commitni s message 'test: add tests for [soubor]'

Pokud se zasekneš (stejný soubor selhává 3x za sebou), zapiš do BLOCKED.md a přeskoč na další.

Cíl: každý soubor v [dir] má >80% coverage. Když je cíl splněn nebo nezbývají řešitelné soubory, vypiš <promise>===COMPLETE===</promise>" --max-iterations 30 --completion-promise "===COMPLETE==="

/loop 3m Zkontroluj stav deploye příkazem 'gh run list --limit 3'.
Pokud některý run selhal, podívej se na logy přes 'gh run view <id> --log-failed' a napiš mi shrnutí co selhalo a proč.
Pokud vše prošlo, jen napiš "✓ Deploy OK".

/loop 5m Podívej se na git log --oneline -5 a git diff --stat.
Shrň co se změnilo od poslední kontroly.
Pokud vidíš nový commit, spusť 'npm run build' a ověř, že build prochází.
Pokud build selže, zapiš problém do REVIEW-NOTES.md.

/loop 2m Zkontroluj posledních 50 řádků logu: 'docker logs --tail 50 muj-kontejner 2>&1'.
Hledej errory, warningy nebo neobvyklé patterny.
Pokud najdeš nový error, analyzuj root cause a navrhni fix.
Pokud se opakuje stejný error, sleduj frekvenci.

/loop 5m Zkontroluj adresář ./inbox/ jestli jsou nové soubory.
Pro každý nový soubor:
1. Přečti obsah
2. Zpracuj ho podle pravidel v PROCESSING-RULES.md
3. Výstup ulož do ./processed/
4. Původní soubor přesuň do ./archive/
Pokud je inbox prázdný, jen napiš "Žádné nové soubory."

Jsi autonomní improvement agent pro [můj projekt/web].

V každé iteraci:
1. Projdi [web/aplikaci] a najdi 3 nejdůležitější věci ke zlepšení
   (design, UX, performance, přístupnost, SEO, obsah)
2. Zapiš nálezy do improvements.md s konkrétním popisem
   (ne "zlepši spacing" ale "zvětši padding na Hero z py-12 na py-20 na mobilu")
3. Implementuj nejjednodušší fix
4. Ověř: [build příkaz] prochází bez chyb
5. Commitni změnu
6. Pokračuj dalším nálezem

Pravidla:
- Používej existující konvence z CLAUDE.md
- Neměň identitu projektu (logo, barvy, navigaci)
- Každá změna musí být viditelně hodnotná
- Po každé změně ověř build

Kontext projektu:
- Framework: [Astro/Next.js/...]
- Styling: [Tailwind/CSS modules/...]
- Dev server: [npm run dev]
- Build: [npm run build]

# Task: Refactor [Skill Name] into a Subagent Architecture

## Goal

I have an existing skill for converting [input type] into [output type]. The skill is too large (~500 lines) to run efficiently in the main conversation context. I need you to refactor it into a subagent-based architecture that keeps the main context clean while preserving all functionality.

## Target Structure

```
~/.claude/skills/[skill-name]/
  SKILL.md                        # lightweight router (max 30-40 lines)
  reference/
    component-mapping.md           # [input type] node types → [output type] mapping
    style-guide.md                 # styling rules, tokens, CSS conventions
    patterns.md                    # code patterns, composables, best practices
    validation.md                  # QA checklist, common errors, edge cases

~/.claude/agents/
  [skill-name].md                  # subagent with core workflow logic
```

## Steps

### Step 1: Analyze the current skill

Read the current skill at `~/.claude/skills/[skill-name]/SKILL.md` and identify:

- Distinct workflow phases (parsing, mapping, styling, validation, etc.)
- Reference material (component lists, mapping tables, conventions, examples)
- Rules that always apply vs. rules specific to a particular phase
- Any hardcoded paths, tool usage, or external dependencies

Summarize your findings before proceeding.

### Step 2: Create reference files

Extract reference material into separate files under `~/.claude/skills/[skill-name]/reference/`. Each file should be self-contained and focused on one concern. The subagent will load these progressively — only when needed for the current phase.

Guidelines for splitting:

- Each file should be under 150 lines
- Include a short header comment explaining when this file should be loaded
- Keep examples close to the rules they illustrate
- Remove any duplication across files

### Step 3: Create the lightweight skill (router)

Rewrite `SKILL.md` as a short routing skill that:

- Has a clear, keyword-rich `description` for auto-invocation
- Uses `context: fork` and `agent: [skill-name]` to delegate to the subagent
- Contains zero workflow logic — only routing

Template:

```yaml
---
name: [skill-name]
description: Converts [input type] exports to [output type]. Use when the user mentions [input type] export, design-to-code, [input type] JSON, or [output type] generation from design files.
context: fork
agent: [skill-name]
---

This skill delegates all work to the `[skill-name]` subagent which runs in an isolated context window.
```

### Step 4: Create the subagent

Create `~/.claude/agents/[skill-name].md` with:

**Frontmatter:**

```yaml
---
name: [skill-name]
description: Converts [input type] exports into production-ready [output type] with proper styling and structure.
tools: Read, Write, Edit, Bash, Glob, Grep
skills:
  - [skill-name]
---
```

**Body — workflow instructions:**

- Write the core workflow as a numbered step-by-step procedure
- At each phase, include an explicit instruction to load the relevant reference file (e.g., "Read `~/.claude/skills/[skill-name]/reference/component-mapping.md` before proceeding")
- Keep the subagent body concise — aim for procedural steps and decision logic only, not reference data
- Target ~100-150 lines for the subagent body itself

### Step 5: Validate

After creating all files, verify:

1. The skill SKILL.md is under 40 lines
2. The subagent body is under 150 lines
3. Each reference file is under 150 lines
4. All content from the original skill is preserved — nothing was lost
5. The subagent explicitly references each reference file at the appropriate step
6. No circular dependencies or missing file paths

Print a summary table showing: original line count → new line counts per file, and confirm nothing was dropped.

## Constraints

- Do NOT change any of the actual conversion logic, rules, or patterns — this is a structural refactor only
- Keep all file paths consistent between skill, subagent, and reference files
- If the original skill references external tools or MCP servers, preserve those in the subagent's `tools` list