The copy-paste prompt for producing a partner Tesztelési jegyzőkönyv (TjK) in a fresh session — a one-line form when the /fk-tjk command is available, and a longer standalone Hungarian prompt for when it is not (another agent, another tool, or a session where the command is not loaded). Paste into a fresh session in /Users/levander/coding/facekom and replace <partner>.

For Agents

  • This note is the single source for the primer prompt — it used to live at docs/tjk-primer-prompt.md in the facekom working directory, which is being retired. Knowledge lives in the vault; only executable config stays on disk.
  • Executable config that stays in facekom (do not copy into the vault, reference by real path): /Users/levander/coding/facekom/.claude/commands/fk-tjk.md (the authoritative procedure) and /Users/levander/coding/facekom/.claude/scripts/tjk/*.py + partners.json.
  • The Hungarian prompt below is verbatim and meant to be pasted — do not paraphrase, reflow, or “improve” it. If the process changes, change .claude/commands/fk-tjk.md first, then re-sync this text.
  • Process narrative: tesztjegyzokonyv-generation-flow. Document shape: tesztjegyzokonyv-partner-release-document-structure.

Short form (command available)

/fk-tjk <partner>

That’s it. The command is zero-context by design: it dispatches the historian, resolves the partner’s own release train, takes the base document from ~/Downloads, regenerates evidence, and writes both the .docx and the tester’s runbook. Everything in the standalone prompt below is what it already knows.

Standalone form (no skill loaded, or another agent / another tool)

Készíts Tesztelési jegyzőkönyv (TjK) draftot a <partner> partnernek a soron következő release-hez.

Kövesd a /Users/levander/coding/facekom/.claude/commands/fk-tjk.md folyamatot — az a hiteles forrás,
olvasd el először. A lényeg:

1. NULLA KONTEXTUS. Ne vegyél át release-számot, ticketet vagy partnert semmilyen korábbi
   beszélgetésből. A release-vonalak PARTNERENKÉNT külön futnak (a Raiffeisen 1.9.11.100-on volt,
   miközben a NÚSZ 1.9.11.48-on). A verziót a partner SAJÁT release ticketjéből vedd
   (`project: <YTPROJECT> Assistance Type: Release`, a legfrissebb nyitott).

2. Először a `historian` subagentet indítsd el (model: opus, háttérben): mi van a releaseben, mit
   implementáltunk ticketenként (repo/branch/PR/merge state), milyen teszt-evidencia van már a
   lemezen, mi maradt nyitva. Élő ellenőrzés (YouTrack + gh + git ls-remote) — a vault gyorsan avul.

3. Az alapdokumentum a ~/Downloads-ban lévő LEGFRISSEBB TjK. Minden partner a `release-doc`
   formátumot kapja (Bevezetés + ticketenként egy Heading2 szakasz). NÉV szerint keress
   (`Tesztelési jegyzőkönyv` / `Tesztjegyzokonyv`), soha ne méret vagy sorrend alapján — a
   Downloads-ban van hasonló méretű, nem ide tartozó dokumentum is. Ha az alap más partneré, az
   rendben van, a newdoc lépés átírja.

4. Az evidenciát ÚJRA ELŐ KELL ÁLLÍTANI, nem régi riportból idézni: futtasd le az érintett
   teszt-suite-okat és a ticket worktree-jében lévő `.dev-e2e/` harness-t. Ami emberi tesztet
   igényel (mobil SDK, valódi kliens, PROD adat), az ÜRES evidencia-slot marad + runbook lépés.
   SOHA ne találj ki evidenciát.

5. Renderelés két lépésben, kézzel írt python NÉLKÜL:
   .claude/scripts/tjk/append_release_sections.py newdoc  → átírja partnerre + release-re
   .claude/scripts/tjk/append_release_sections.py         → hozzáfűzi a szakaszokat JSON-ből

6. Írj tesztelői runbookot is: out/<partner>-<release>-teszt-runbook.md — tesztesetenként
   előfeltételek / számozott lépések / elvárt eredmény + hibajelenség / bizonyíték (mit kell
   rögzíteni ÉS melyik TjK slotba kerül) / mikor NEM reprodukálható.

Kemény szabályok:
- A szakaszcímekben PARTNER-oldali ticket ID szerepel (ASS…/SLA…/CR…). FKITDEV-<n> SOHA nem
  kerülhet ügyfélnek szóló dokumentumba — a tool ezt ellenőrzi.
- A tartalomjegyzék statikus mező: a rebase kiüríti a gyorsítótárát, PDF export előtt frissíteni kell.
- Ha egy javítás a bejelentett hibának csak egy részét oldja meg, azt írd le a szakaszban, ne hagyd,
  hogy a ticket címe többet sugalljon.

A végén sorold fel: mi maradt kézi lépés, mi nem tesztelhető házon belül és miért, és ha a partner
`priorShape`-je nem `release-doc` volt, jelezd, hogy MÁS FORMÁTUMOT kap, mint legutóbb.

What you get back

  • out/<fileStem>.docx — the draft, evidence pasted in where it could be generated
  • out/<partner>-sections.json — the input, so a re-run is one edit away
  • out/<partner>-<release>-teszt-runbook.md — what the tester executes
  • a hand-off list: manual steps, untestable cases, and anything blocking the release itself

What stays manual

Bevezetés fields the rebase can’t know (tester/reviewer names, dates, device+browser bullets), screenshots, underlining Sikeres / sikertelen and igen / nem, refreshing the TOC, PDF export, and attaching to the partner release ticket.