/feature-refinement

Összefoglaló

Interaktív, senior termékstratéga gondolkodásmódú segéd, amely egy nyers feature-ötlettől eljuttat egy jól körülhatárolt Feature Brief dokumentumig, amelyet a projektbe ment, és készen áll a /plan-maker futtatására. Feltételezi, hogy akár product owner vagy végfelhasználó is lehetsz, aki sem a kódbázist, sem a technológiát nem ismeri — mindent közérthetően fogalmaz, és ha egy döntéshez egy technológia megértése szükséges, azt előbb egy egyszerű mondatban elmagyarázza.

Mikor használd

Akkor használd a /feature-refinement parancsot, ha van egy feature-ötleted, de még nincs tiszta scope-od, felhasználói folyamatod vagy döntési naplód. A parancs feltérképezi a kódbázist, megkérdőjelezi a feltételezéseidet, és célzott kérdéseket tesz fel addig, amíg a feature pontosan körülhatárolt nem lesz — majd egy strukturált Feature Brief fájlt állít elő.

Az agentic workflow pipeline (agentic-workflow-hu.html) is ismerteti, mint a tervezést és implementációt megelőző upstream lépést.

Tipikus helyzetek, amikor érdemes elindítani:

• Van egy nyers feature-ötleted, és scope-olnod kell, mielőtt tervet írnál.
• Szeretnél egy ördögügyvéd szerepben gondolkodó terméktervezőt, aki megkérdőjelezi a feltételezéseidet, mielőtt elköteleződsz egy irány mellett.
• Szükséged van egy Feature Brief fájlra (Documentation/Backlog/…-brief.md), amely a /plan-maker bemenete lesz.
• Szeretnéd felszínre hozni a kódbázisban rejlő ütközéseket, kockázatokat vagy korábbi döntéseket, mielőtt megoldást tervezel.
• Product owner vagy nem műszaki érintett vagy — a parancs használatához nem kell sem kódbázis-, sem technológiaismeret, közvetlenül használhatod.

Meghívás

Add át a feature-ötletedet argumentumként. A parancs először feltérképezi a kódbázist, majd iteratív tisztázási körökbe lép.

/feature-refinement [feature idea or description]

Paraméterek:

• [feature idea or description] — (kötelező) Rövid leírás a finomítani kívánt feature-ről. Lehet egy mondat, egy nyers user story vagy néhány felsorolásponti gondolat.

Kimenet: Egy Feature Brief Markdown fájl a Documentation/Backlog/[feature-name-kebab-case]-brief.md útvonalon (vagy a projekt gyökerében, ha ez a könyvtár nem létezik). A brief a következőket fedi le: Probléma, Cél, Felhasználók és kontextus, Fő folyamat, Scope-ban, Scope-on kívül, Kulcsdöntések, Határesetek és korlátok, Nyitott kérdések, Jövőbeli iterációk, valamint egy Ajánlás. A brief közérthető nyelven íródik, kivéve a Nyitott kérdések szakaszt, amely technikai marad — az a /plan-maker-nek és a fejlesztőknek szól.

Folyamat fázisai:

1. 1. fázis — Feltérképezés: Két párhuzamos Explore ágenst indít — egyet a dokumentációra (README-k, ADR-ek, spec-ek), egyet a forráskódra —, majd jelzi, ahol a dokumentáció ellentmond a kódnak. Nagy projekteknél területenként legfeljebb ~4 ágensre bontható.
2. 2. fázis — Tisztázás, kihívás és ötletelés: Iteratív körök — minden kör megkérdőjelezi a feltételezéseket, és legfeljebb 3, jól megfogalmazott kérdést tesz fel — mindegyik arról szól, hogy te mit látsz vagy mit teszel, sosem az implementációról —, amíg a scope, a folyamat és a határesetek nem tisztázódnak. A kihívások és kérdések egy közös, globális sorszámozást kapnak (#1, #2, ...), amely körök között sem kezdődik újra, így tömören válaszolhatsz ("#2: igen, #4: hagyjuk").
3. 3. fázis — Feature Brief: Elkészíti és elmenti a strukturált briefet, majd javasolja a /plan-maker [path] futtatását.

1. példa — Új értesítési feature finomítása (szemléltető példa)

/feature-refinement Add email notifications when a task is assigned to a user

Investigating the codebase before we start...

Docs agent: no ADRs on notifications; README lists email as a roadmap item.
Code agent: existing User model, Task model with assignee_id FK, no email infrastructure yet,
a TODO comment in task_service.py referencing future notifications.

**#1 (challenge) [Scope]**
- Option A: Email only — simple, ships fast. Con: will need rework when push notifications arrive.
- Option B: Generic notification system with email as first channel — more upfront work, extensible.
- Recommendation: Option A for now; design the interface to be swappable. Agree?

#2 (question): Should the assignee receive an email immediately on assignment, or in a daily digest?
  A) Immediate — users get context faster. Con: noisy for high-volume projects.
  B) Configurable per-user — best UX. Con: adds a settings screen to scope.
  C) Immediate for now, configurable later — pragmatic. Recommendation: C.

[After user responds...]

Saved: Documentation/Backlog/task-assignment-notifications-brief.md
Run `/plan-maker Documentation/Backlog/task-assignment-notifications-brief.md` to create an implementation plan.

2. példa — Keresési feature scope-olása ütköző korlátokkal (szemléltető példa)

/feature-refinement Full-text search across all project documents

Investigating the codebase before we start...

Docs agent: prior ADR-007 deferred search to "Phase 2".
Code agent: PostgreSQL 15, 3 document types (notes, tasks, files), existing ILIKE queries in search_service.py,
no full-text index, ~50k rows in production.
Contradiction flagged: ADR-007 defers search, but search_service.py already ships ILIKE queries.

**#1 (challenge) [Risk]**
- ADR-007 deferred this — do you know why? Options:
  A) Performance concern — full-text on 50k rows is fine for pg_trgm; address it.
  B) Scope concern — previous team wanted to ship faster; now it's time.
  Recommendation: Clarify before scoping to avoid repeating the same decision.

#2 (question): Which document types must be searched in v1?
  A) All three (notes, tasks, files) — complete but more complex.
  B) Notes and tasks only, files deferred — ships faster, covers 90% of use cases.
  Recommendation: B.

[After 2 rounds...]

Saved: Documentation/Backlog/full-text-search-brief.md
Run `/plan-maker Documentation/Backlog/full-text-search-brief.md` to create an implementation plan.

Kapcsolódó eszközök

• /plan-maker — A /feature-refinement által előállított Feature Briefet fázisokra bontott implementációs tervvé alakítja, feladatokkal, elfogadási kritériumokkal és TDD al-tételekkel.
• /plain-language — A közös írási konvenció, amelyet a /feature-refinement az elején betölt: először a hétköznapi következmény, a technikai részletek zárójelben.