← Oktatási rendszerek · projekttervezési csomag adatlapja

Skill · 1.0.0 verzió

Átadás lezárásának ellenőrzése

Megállapítja, teljesült-e az elfogadott cél, és elválasztja a valódi lezárási akadályt az opcionális későbbi csiszolástól.

delivery-closure-review

Ezt a skillt használó ügynökök

Nézd meg, miben segít

Mikor hasznos?

Akkor használd feladatzárás előtt, ha a megvalósítás, bizonyíték és maradék ötletek egyértelmű értékelést igényelnek.

Miben segít neked?

  • Összeveti az elfogadási feltételeket a megvalósítással és lefutott ellenőrzésekkel.
  • Feltárja a félkész folyamatot, hiányzó elkülönítést és kéretlen fenntartási terhet.
  • Elkülöníti a blokkoló hibát az opcionális további ötlettől.

Például ezt kérheted

Ellenőrizd, hogy lezárható-e az új meghívási folyamat fejlesztése. Vesd össze a követelményekkel az elfogadott, lejárt és már felhasznált meghívókat. Jelezd a lefutott ellenőrzéseket és a lezárást akadályozó nyitott hibákat.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

Delivery Closure Review

Use this skill when reviewing a completed implementation or preparing a task for closure to confirm that the accepted goal is fully achieved, core quality invariants hold, and the work item closes cleanly without endless polishing loops.

Closure Principle

A task is done when its explicit acceptance criteria, end-to-end user workflow, and core correctness baselines (security, authorization, data integrity, error handling, and verification tests) are satisfied — not when every conceivable future enhancement or stylistic preference has been exhausted.

Workflow

  1. Verify outcome completeness against the brief:
    • Check each acceptance criterion against the actual implementation and test results:
      • Does the primary user or API flow work end-to-end without manual intervention?
      • Are authorization, tenant boundaries, data integrity, and failure states handled properly?
      • Were any required steps silently stubbed out or left half-finished?
  2. Check for unapproved scope drift or gold-plating:
    • Inspect the diff for unrequested features, speculative config layers, unused abstractions, or unrelated file churn that crept in during implementation.
    • If an unrequested addition introduces new maintenance burden, security surface, or untested paths, recommend removing or simplifying it before merge.
    • If an addition is benign and already tested, do not create busywork by demanding its removal solely on formality.
  3. Separate blocking defects from optional future ideas:
    • Blocking (Must fix before closure): Broken acceptance criteria, regressions, missing permission/tenant checks, data loss/corruption risks, or failing tests.
    • Non-blocking (Defer or drop): Cosmetic nitpicks, alternative naming preferences, or future feature extensions. Record genuine future extensions briefly with their revisit trigger and approve closure.
  4. Fast-pass when proportional and complete:
    • Never become a bureaucratic bottleneck. When the implementation meets the goal cleanly with proportional complexity, issue a concise approval immediately so the team can ship and move on.

Concise Closure Summary Format

When findings exist, report them in four lines:

Goal: [The accepted objective and acceptance criteria] Observation: [Any missing core requirement or disproportionate extra complexity in the diff] Proposal: [The minimal change needed to close cleanly] Trade-off: [Deferred follow-ups and the condition under which to revisit them]

Csomagban lévő fájlok 1

  • SKILL.md