testeiya 0.3.1-5.1 → 0.3.1-5.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "testeiya",
-  "version": "0.3.1-5.1",
+  "version": "0.3.1-5.3",
   "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": "ef338b8b8dfabfdd523a7f00544d00c3705946f6",
+      "sha": "e7cee9e276d96d22f2e3f185b4279a3092f8b428",
       "folder": "testomatio",
       "skills": [
         "automate-manual-test-cases",
@@ -22,6 +22,7 @@
         "qa-lead-strategy-advisor",
         "qa-pr-requirements-analyzer",
         "qa-requirement-reviewer",
+        "qa-review-pr",
         "qa-split-testing-levels-pyramid",
         "qa-sprint-report-by-testomatio",
         "qa-test-code-coverage",

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

@@ -0,0 +1,41 @@
+---
+name: qa-review-pr
+description: Review a pull request as a QA engineer — check whether the change actually solves the stated issue, flag backwards-compatibility breaks and risks, and list the scenarios that must be verified before merge. Use when asked to "review this PR as QA", "what should we test in this PR?", or "is this PR safe to merge?".
+---
+
+# QA Review of a Pull Request
+
+Think about a feature like a senior QA engineer and surface risk scenarios.
+Gather intent with the `qa-pr-requirements-analyzer` skill first.
+
+## Think
+
+- Does the provided implementation represent original task or requirement.
+- Possible ambiguities in implementation
+- Possible contradictions with existing practices, features
+- Possible duplication of existing features or patterns
+- Unobvious usage: edge cases, repeated actions, boundary values, cancellations.
+- Combinations: how this feature interacts with other features.
+- Security vulnerabilities.
+
+## 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.

package/skills/testomatio/test-management/qa-thinking/SKILL.md

@@ -6,26 +6,35 @@ description: Analyze a feature a developer is building from a QA perspective —
 # QA Thinking
 
 Think about a feature like a senior QA engineer and surface risk scenarios.
+Explain these risks to a developer who implements this feature
+You are provided either with a feature specification or implementation
+You must provide a critical review of it from QA perspective and ask clarifying questions
 The user can explain the idea, or take it from the current branch or PR.
 For a PR, gather intent with the `qa-pr-requirements-analyzer` skill first.
 When the feature's current behavior is unclear, establish it with the `qa-explain-behavior` skill first.
 
-## Think
+## Think as QA
 
-- Positive scenarios.
+- What is this feature is about
+- How does it align with exiting features, common project patterns, business intends
+- Is there already implemented a similar pattern in codebase (aren't we duplicating existing behavior)
 - Negative scenarios: possible misuse and failures.
-- Unobvious usage: repeated actions, boundary values, cancellations.
+- Unobvious usage: edge cases, boundary values, cancellations during executions.
 - Combinations: how this feature interacts with other features.
-- Possible abuses.
-- Data consistency: inputs that create inconsistent state, and how it affects the system later.
 - Security vulnerabilities.
 
 ## Output
 
-- Section `👓 What must be clarified`: questions to resolve important ambiguities.
-- Section `🔬 What must be verified`: up to 10 most important risk scenarios, no more.
+Only requested section named exactly the way we provide
+Information in section written as numbered lists
+
+Requested sections:
+
+
+- Section `👷 Must be aknowledged`: brief summary in bullet points. Potential correlation with other areas. Potential risks
+- Section `👓 Must be clarified`: up to 5 questions to resolve important ambiguities. Start each with "What if".
+- Section `🔬 Must be verified`: up to 5 most important risk scenarios, no more.
 - Prefer simple wording and short sentences.
-- When asked for more, propose the next batch of scenarios.
 
 ## Next actions