Követelmények nyomon követése
Összekapcsolja az elfogadott játékszabályokat a megvalósító kóddal és ellenőrzésekkel. Láthatóvá teszi a lefedett, még igazolatlan és indokolatlanul hozzáadott viselkedéseket.
requirement-to-code-traceability
Ezt a skillt használó ügynökök
Mikor hasznos?
Akkor használd, ha a szállítást a briefhez méred vagy minden ígéret mögött működő kódot és érdemi tesztet keresel.
Miben segít neked?
- Minden elfogadott feltételt megvalósító kódhoz és teszthez rendel.
- Indokolt követelményig követi vissza a módosított kódot.
- Új terjedelem kitalálása nélkül vizsgálja a sikert, hibát és határesetet.
Például ezt kérheted
Kövesd végig azt a követelményt, hogy az ellenőrzőpont visszatölti az életerőt, de nem teremti újra a felvett küldetéstárgyakat. Kösd a részeit az újraéledési kódhoz, mentett adatokhoz és tesztekhez. Vizsgáld a gyűjtés közbeni halált és régi mentést is, új visszaállítási szabály kitalálása nélkül.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Requirement-to-Code Traceability
Use this skill to verify that the implemented code actually fulfills the accepted specification — neither dropping required business rules nor introducing unrequested behavior changes.
The Three-Way Traceability Matrix
For every work item, map each requirement across three columns: $$\text{Requirement / Acceptance Criterion} \longrightarrow \text{Implementing Code Path(s)} \longrightarrow \text{Verifying Test(s)}$$
Workflow
- Map every acceptance criterion to its exact implementation:
- Walk through the brief and specification item by item:
- Fully implemented: Identify the exact functions, handlers, UI states, and database queries enforcing the rule.
- Partially implemented: E.g., enforced in the UI button state, but missing from the backend API endpoint or background worker.
- Missing / Stubbed: Left unimplemented, hardcoded, or behind an unreachable branch.
- Walk through the brief and specification item by item:
- Trace reverse from the diff back to requirements:
- For every non-trivial behavioral change in the diff, ask: "Which accepted requirement or bugfix requires this change?"
- Flag unrequested behavioral changes (silent changes to existing defaults, altered API response shapes, modified sorting/filtering semantics, or weakened validation) that were not authorized by the specification.
- Verify happy, error, and boundary paths in code:
- Confirm the code handles not only the nominal path, but also the specified rejection paths, permission denials, empty states, and boundary values.
- Link each requirement to its verification evidence:
- Check whether each acceptance criterion has a corresponding test assertion that exercises the real code path and would fail if that requirement were broken.
- Explicitly list any acceptance criterion that is implemented in code but currently lacks automated test coverage.
Csomagban lévő fájlok 1
SKILL.md
