/plan-maker

← Vissza az áttekintéshez

Összefoglaló

Részletes, végrehajtható implementációs terveket készít és frissít: a lehető legkisebb feladatokra bontva, teljes teszt-specifikációval és világos függőségi láncokkal.

Mikor használd

Akkor használd a /plan-maker-t, amikor a munkát strukturált, megvalósítható feladatokra kell bontanod. Mielőtt bármit is leírnál, lefuttat egy architekturális kihívás-kört, így a döntések explicit módon születnek meg, és a határesetek még az implementáció előtt felszínre kerülnek.

Trigger kifejezések (a SKILL.md-ből):

Bármilyen kérésre is triggerelődik, amely egy feature, javítás, refaktor vagy kezdeményezés végrehajtható lépésekre bontását kéri — még rövid vagy lazán megfogalmazott tervezési kérésekre is.

Munkafolyamatbeli kontextus: a /plan-maker a 9 lépéses ügynöki munkafolyamat-pipeline egyik kulcsfontosságú belépési pontja. Lásd agentic-workflow-hu.html, amely bemutatja, hogyan illeszkedik a /feature-refinement és /implement mellé.

Meghívás

Slash parancsként hívd meg, opcionálisan egy rövid leírással arról, hogy mit kell megtervezni:

/plan-maker [feature description or goal]

A skill interaktívan összegyűjti a kontextust, lefuttatja az architekturális kihívás-köröket (az aggályokat opciókként veti fel, előnyökkel/hátrányokkal és egy ajánlással), majd kiírja a tervet a projekt tervkönyvtárába.

Paraméterek: egy sem kötelező. Ha megadsz egy leírást, az a kontextusgyűjtés kiindulópontja lesz; ha nem, akkor a skill rákérdez.

Meglévő terv frissítése: mondd azt, hogy "update the plan for X" — a skill megkeresi a meglévő fájlt, és új feladatokat fűz hozzá ahelyett, hogy duplikátumot hozna létre.

1. példa — Új feature terv

Bemenet:

/plan-maker Add OAuth2 login to the API so users can sign in with Google or GitHub

Kimenet / eredmény:

# FEAT-012 — OAuth2 Login
**Purpose**: Allow users to authenticate via Google or GitHub instead of email/password
**Audience**: API consumers and end users
**Status**: To Do

## Background
The current auth system requires email/password accounts. Adding OAuth2 removes signup
friction and delegates credential management to trusted providers.

## Goal
Users can initiate OAuth2 login, exchange the callback code for a session token, and
access protected endpoints — with no change to the existing password-login path.

## Scope
### In Scope
- Google and GitHub OAuth2 providers
- Token exchange endpoint, session creation, user upsert

### Out of Scope
- OAuth2 for admin accounts (separate system)
- Mobile deep-link callbacks (deferred)

## Task breakdown

### Phase 1 — OAuth2 core
#### Task 1.1 — OAuth2 provider config loader
- [ ] **File**: `src/auth/oauth_config.py`
...
#### Task 1.2 — Callback endpoint
...
#### Task 1.N — Final verification & documentation update
...

2. példa — Meglévő terv frissítése

Bemenet:

update the plan for FEAT-012 — we also need to support Apple Sign In

Kimenet / eredmény:

Found existing plan: plans/FEAT-012-oauth2-login.md

Architectural concern raised:
  Apple Sign In uses a different token format (JWT, not opaque) and requires
  client-secret rotation every 6 months.
  - Option A: reuse the existing provider abstraction — Pro: minimal change;
    Con: abstraction leaks Apple-specific JWT handling
  - Option B: add an AppleProvider subclass with dedicated JWT validation —
    Pro: clean separation; Con: slightly more code
  - Recommendation: Option B — cleaner long-term

New tasks appended to Phase 1:
  Task 1.5 — AppleProvider JWT validator
  Task 1.6 — Apple client-secret rotation script
  Task N.N — Final verification updated with Apple AC

Plan saved: plans/FEAT-012-oauth2-login.md (6 tasks, 2 new)

Kapcsolódó eszközök