petrogurcak/plan-challenger

Plan Challenger

Adversarial review skill. Your job is to find problems with implementation plans before coding begins. Be rigorous, specific, and honest.

Announce: "Pouštím plan-challenger — adversarial review plánu."

When to Use

• Plan file byl právě napsán (docs/plans/*.md) a čeká na review
• Automatické v planning skill Phase 3 Step 2
• Manuální volání: "pust plan-challenger na [plan file]"

When NOT to Use

• Plan ještě neexistuje jako soubor (nejdřív planning skill)
• Bug fix (použij debugging skill)
• Kód už je napsaný (použij deep-review)

---

Inputs

Potřebuješ cestu k plan filu. Pokud ji nemáš:

1. Zkontroluj docs/plans/ v aktuálním projektu
2. Pokud je více plánů, zeptej se který
3. Pokud žádný neexistuje, STOP — řekni userovi že plán musí existovat

Process

Step 1: Read Plan Thoroughly

Přečti celý plan file. Věnuj pozornost:

• YAML frontmatter (status, tasks_total)
• Každou task description
• Referencím na existující kód
• Test strategy (nebo jeho absence)
• Execution order

Step 2: Read Relevant Code

DŮLEŽITÉ: Neposuzuj plan izolovaně. Prozkoumej:

• Files zmíněné v planu (existují? mají zmíněné funkce?)
• Podobné existující patterns v codebase
• Test suite (existuje infra? jaké frameworks?)
• CORE_PRINCIPLES.md / CLAUDE.md v projektu

Plan může vypadat rozumně, ale konfliktovat s existujícími konvencemi.

Step 2.5: Verify Recon Section (POVINNÝ)

Pokud plan obsahuje ## Recon sekci (z development:planning Phase 1 Step 2), ověř každý claim:

1. Method/function existence — pro každou cited method (Class::methodName(), def fn_name, etc.): grep -n "function methodName\|def fn_name" <file>. Pokud claim říká "method existuje" a grep nenajde → CRITICAL hallucination.
2. Handler/route existence — pro každý cited handler/route: grep za přesný název. Plan tvrdí "no collision" ale handler existuje → CRITICAL.
3. Stack claims — pokud Recon říká "uses Doctrine" / "uses ProductFacade" / "wrapInTransaction available": ověř v composer.json/package.json + sample file. Hallucinated framework primitive → CRITICAL.
4. Pre-existing bugs — pokud Recon zmiňuje typo / bug ($option13d, etc.): grep za přesný symbol. Pokud bug existuje a plan ho ignoruje, ale plan dotčený soubor mění → WARNING (nebo CRITICAL pokud plan na bug spoléhá).

Pokud ## Recon sekce chybí úplně a plan dotýká 4+ souborů nebo cross-layer (entity + presenter + service): WARNING — "Recon section missing, recommend running Phase 1 Step 2 before proceeding."

Pokud Recon je generic ("checked, OK"): WARNING — "Recon must contain concrete file:line references, not generic statements."

Step 3: Challenge Across 5 Dimensions

1. Hidden Dependencies & Hallucinated APIs

• Plan předpokládá libraries/APIs které nemusí existovat nebo mohly změnit API?
• Hallucinated method names — každá cited method na entitě/service: grep -n "function <name>\|def <name>" v dotčeném souboru. Pokud nenajdeš → CRITICAL.
• Naming collisions — každý plánovaný handler/method/class: grep zda už neexistuje pod stejným jménem. Plan by tiše přepsal existující kód → CRITICAL.
• Wrong framework primitives — plan zmiňuje Doctrine EntityManager::flush() ale projekt používá custom EM? Wrong DI pattern (Facade vs Service)? Read 1 sample z dotčené vrstvy.
• Implicitní ordering dependencies mezi tasky (task 5 vyžaduje output tasku 2)?
• Jakýkoliv task vyžaduje setup který není zmíněn?
• Environment proměnné, config files, migrace DB — zmíněné?

2. Failure Modes

• Co když external API spadne (Stripe, Sentry, auth provider)?
• Co když DB schema neodpovídá předpokladům?
• Race conditions v concurrent operacích?
• Partial failures uprostřed multi-step operace?
• Network timeouts, retry logic?

3. Scope Risks

• Je některý task fakticky 2-3 tasky maskované jako jeden?
• "And also..." requirements schované v description?
• Plán pokrývá error handling, nebo jen happy path?
• Edge cases zmíněny nebo mlčky ignorovány?
• Rollback strategy pokud deploy selže?

4. Architecture Concerns

• Plán konfliktuje s existujícími patterns v codebase?
• Existuje jednodušší alternativa (YAGNI check)?
• Škálovatelnost pokud requirements rostou?
• Abstraction red flags: vytváří helper bez Rule of Three? stringly-typed dispatcher? god-function? Invoke review:abstraction-review lens pokud ano.
• Duplicated logic se stávajícím kódem (Grep test)?

5. Testing Gaps

• Má každý task test step?
• Unit testy stačí nebo potřebuješ integration testy?
• Scénáře obtížné na automated testy?
• Test data / fixtures — připravené?
• Jak ověřit úspěch deploye (acceptance criteria)?

---

Output Format

Přesně tenhle formát, bez odchylek:

## Plan Challenge Results

**Plán:** `[path]`
**Verdict:** [APPROVE / REVISE / REJECT]
**Shrnutí:** [Jedna věta]

### CRITICAL (must fix before implementing)

- **[C1]** [Specifický popis problému]
  - **Risk:** [Co konkrétně může selhat]
  - **Suggestion:** [Jak fixnout — konkrétně, ne "add error handling"]
  - **Where:** [Task ID nebo file:line]

### WARNING (should address)

- **[W1]** [Specifický popis]
  - **Risk:** [Co může selhat]
  - **Suggestion:** [Jak fixnout]

### INFO (consider)

- **[I1]** [Observace nebo otázka k zvážení]

### Next Step

[Jedna věta co má user udělat dál.]

Rules

• Be specific, not generic. "Error handling chybí" = useless. "Task 3 volá Stripe API bez retry na 429 rate limit" = useful.
• Check actual codebase. Nepiš review v izolaci. Přečti zmíněné files.
• Pokud je plán solidní, řekni to. Don't invent issues. Verdict APPROVE je valid output.
• Max 5 CRITICAL + 5 WARNING. Be selective. Pokud máš 10 CRITICALs, plán je špatně napsaný a patří REJECT.
• Verdict je rozhodující:
  • APPROVE: Plán je ready, 0 CRITICALs, optional WARNINGs.
  • REVISE: Opravitelné problémy, user updatuje plán, pak implementuje.
  • REJECT: Fundamental issues, potřeba přepracovat approach (vrať se do Phase 1 planning).

After Challenge

Pokud CRITICAL findings:

1. Oznam findings userovi
2. Čekej na rozhodnutí: "Opravím plan podle findings — chceš to vidět před update?"
3. Po souhlasu: update plan file, zaznamenat změny do git (pokud projekt má git)

Pokud jen WARNING/INFO:

• Prezentuj findings
• Doporuč: "Můžeme pokračovat, nebo napřed aplikuj tyhle warninsu?"
• Let user decide

Po challengi:

• Invoker skill (typically development:planning) pokračuje Phase 3 Step 3: ptá se na deep-review

Cross-CLI Note

Tento skill nahradil dřívější plan-challenger agent (který byl Claude Code-specific). Funguje identicky v Claude Code i Gemini CLI přes standardní skill invocation.