testeiya 0.3.1-5.3 → 0.3.1-5.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "testeiya",
-  "version": "0.3.1-5.3",
+  "version": "0.3.1-5.4",
   "description": "AI testing agent — QA-focused coding agent for manual and automated tests",
   "type": "module",
   "license": "MIT",

package/skills/skills.lock.json

@@ -3,7 +3,7 @@
     {
       "source": "testomatio/skills",
       "ref": null,
-      "sha": "e7cee9e276d96d22f2e3f185b4279a3092f8b428",
+      "sha": "07a67b75bb49fb7f9e8061ab69a6cbfa45f9b99f",
       "folder": "testomatio",
       "skills": [
         "automate-manual-test-cases",
@@ -71,7 +71,7 @@
     {
       "source": "microsoft/playwright-cli/tree/main/skills/playwright-cli",
       "ref": null,
-      "sha": "60cb176373cf4400405122703e6de26cd58c7a1c",
+      "sha": "cbc09311c468e10fba47964e9b3830fe625c9b01",
       "folder": "playwright",
       "skills": [
         "playwright-cli"

package/skills/testomatio/qa-process/qa-review-pr/SKILL.md

@@ -20,22 +20,20 @@ Gather intent with the `qa-pr-requirements-analyzer` skill first.
 
 ## Output
 
-Your output should be readable by person who doesn't understand or doesn't look into code.
-Use QA language, avoid coding jargon
-Avoid mentioning internal variable names, syntax, queries, not relevant for QAs.
-Use high-level business domain specific terms and not low level coding details
-If needed mention class names, file names, but never get into deeper internal details
-Explain risks and ambiguities from terms of persona using the software
-Try to resolve ambiguities based on your code and requirements understanding
-
-Only requested section named exactly the way we provide
-Information in section written as numbered lists
-
-Requested sections:
-
-- Section `👷‍♀️ Is it done`: does the code meet the original request (pr title, issue description, etc). Include brief (1 line) original issue summary in it. Avoid details, your goal is to detect unmatched or wrongly understood issues.
-- Section `🦕 Backwards Compatibility`: how this change is aligned with our existsing features, is there a significant behavior changes we need to be aware of
-- Section `🌋 Potential Risks`: what are potential problems can be introduced by merging this PR
-- Section `🔬 What must be verified`: up to 5 most risk scenarios, no more. Start in form: "What if"
-
-Prefer simple wording and short sentences.
+- Your output should be readable by person who doesn't understand or doesn't look into code.
+- Use QA language, avoid coding jargon
+- Avoid mentioning internal variable names, syntax, queries, not relevant for QAs.
+- Use high-level business domain specific terms and not low level coding details
+- If needed mention class names, file names, but never get into deeper internal details
+- Explain risks and ambiguities from terms of persona using the software. Do not put coding terms in it.
+- Try to resolve ambiguities based on your code and requirements understanding
+- You can use bold and italics to emphasize points important for reviewer to take decision
+- Reply with **Only requested section named exactly they are provided provided**. No prephrase, no conclusions, only session.
+- Prefer simple wording and short sentences.
+
+## Requested sections
+
+- Section `👷‍♀️ Is it done`: does the code meet the original request (pr title, issue description, etc). Include brief (1 line) original issue summary in it. Avoid details, your goal is to detect unmatched or wrongly understood issues. 1-3 sentances max.
+- Section `🦕 Backwards Compatibility`: how this change is aligned with our existsing features, is there a significant behavior changes we need to be aware of (if no compatibility issues present, just say so).
+- Section `🌋 Merge Risks`: what are potential problems can be introduced by merging this PR. Up to 5 items, if found, format as numbered list.
+- Section `🔬 What must be verified`: up to 5 most risk usage scenarios for end-users. Start in form: "What if {persona} {verb}". Write as numbered list. Avoid scenarios that are technical and can be unit tested.