add new skill: write user story; add "requirements" plugin

.claude-plugin/marketplace.json

@@ -1,12 +1,17 @@
 {
   "name": "testomatio-plugins",
   "metadata": {
-    "description": "Testomatio.io plugins and skills for managing tests, test cases, test automation, results, coverage etc"
+    "description": "Testomatio.io plugins and skills for requirements, tests, test cases, test automation, results, coverage etc"
   },
   "owner": {
     "name": "Testomatio.io"
   },
   "plugins": [
+    {
+      "name": "requirements",
+      "source": "./plugins/requirements",
+      "description": "Write, review, and analyze product requirements and features — user stories, acceptance criteria, gaps, risks, and PR intent"
+    },
     {
       "name": "test-management",
       "source": "./plugins/test-management",

README.md

@@ -26,13 +26,22 @@ For other ways of installation (Claude Code plugin, Codex, Cursor etc.) see [ins
 
 ## Available Skills
 
-### Test Management
+### Requirements
 
 | Skill                  | Description                                                                                          |
 | ---------------------- | ---------------------------------------------------------------------------------------------------- |
+| `write-user-story` | Write user stories and acceptance criteria (the requirements) from a feature idea, ticket, or notes |
+| `qa-requirement-reviewer` | Review requirements for ambiguity, gaps, contradictions, and testability before development |
 | `qa-explain-behavior`  | Answer QA questions about product behavior — features, flows, rules, edge cases, and what is not implemented |
-| `qa-write-test-cases`       | Generate test cases and checklists from requirements, tickets, or feature descriptions               |
 | `qa-thinking`          | Analyze a feature from a QA perspective — edge cases, negative flows, abuses, unobvious scenarios |
+| `qa-pr-requirements-analyzer` | Extract original intent and acceptance criteria from a PR's title, description, comments, and linked tickets |
+| `pull-request-diff-analyzer` | Analyze a PR/branch diff to detect features/fixes and extract acceptance criteria from the code |
+
+### Test Management
+
+| Skill                  | Description                                                                                          |
+| ---------------------- | ---------------------------------------------------------------------------------------------------- |
+| `qa-write-test-cases`       | Generate test cases and checklists from requirements, tickets, or feature descriptions               |
 | `qa-split-testing-levels-pyramid` | Apply the test pyramid to a feature — assign scenarios to testing levels, coverage split per level |
 | `improve-test-cases`   | Analyze and improve existing markdown test cases for clarity                                         |
 | `detect-duplicate-test-cases` | Find duplicate, near-duplicate, and overlapping test cases                                           |
@@ -90,6 +99,9 @@ testomatio/skills
 │   ├── sync-test-cases-with-tms/
 │   └── ...
 └── plugins/                   # Claude Code plugin wrappers
+    ├── requirements/
+    │   └── skills/
+    │       └── [symlinks to ../../skills/*]
     ├── test-management/
     │   └── skills/
     │       └── [symlinks to ../../skills/*]
@@ -111,6 +123,7 @@ Skills are also bundled as [Claude Code plugins](https://docs.testomat.io) via t
 
 | Plugin            | Bundled skills                                                       | Use it to                                                                       |
 | ----------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
+| `requirements`    | `write-user-story`, `qa-requirement-reviewer`, `qa-thinking`, `qa-explain-behavior`, `qa-pr-requirements-analyzer`, `pull-request-diff-analyzer` | Write, review, and analyze requirements and features before and during development |
 | `qa-process`      | `qa-lead-strategy-advisor`, `qa-explain-behavior`, `qa-thinking`, `testing-workflow` | Assess QA maturity, prioritize a quality roadmap, explain product behavior, and orchestrate the test lifecycle |
 | `test-management` | `qa-write-test-cases`, `improve-test-cases`, `sync-test-cases-with-tms`, coverage & more | Manage the test case lifecycle: generate, improve, sync to Testomat.io          |
 | `test-automation` | `automate-manual-test-cases`, `debug-fix-failed-flaky-autotests`, `qa-data-seeder` | Create automated tests, heal failing/flaky autotests, and seed test data        |

plugins/requirements/.claude-plugin/plugin.json

@@ -0,0 +1,14 @@
+{
+  "name": "requirements",
+  "version": "1.0.0",
+  "description": "Write, review, and analyze product requirements and features — user stories, acceptance criteria, gaps, risks, PR intent, and existing behavior",
+  "author": {
+    "name": "Testomat.io",
+    "url": "https://testomat.io"
+  },
+  "homepage": "https://docs.testomat.io",
+  "repository": "https://github.com/testomatio/skills",
+  "license": "MIT",
+  "keywords": ["qa", "requirements", "features", "user-stories", "acceptance-criteria", "testomat"],
+  "skills": "./skills/"
+}

plugins/requirements/skills/pull-request-diff-analyzer

@@ -0,0 +1 @@
+../../../skills/pull-request-diff-analyzer

plugins/requirements/skills/qa-explain-behavior

@@ -0,0 +1 @@
+../../../skills/qa-explain-behavior

plugins/requirements/skills/qa-pr-requirements-analyzer

@@ -0,0 +1 @@
+../../../skills/qa-pr-requirements-analyzer

plugins/requirements/skills/qa-requirement-reviewer

@@ -0,0 +1 @@
+../../../skills/qa-requirement-reviewer

plugins/requirements/skills/qa-thinking

@@ -0,0 +1 @@
+../../../skills/qa-thinking

plugins/requirements/skills/write-user-story

@@ -0,0 +1 @@
+../../../skills/write-user-story

plugins/test-management/skills/write-user-story

@@ -0,0 +1 @@
+../../../skills/write-user-story

skills/qa-thinking/SKILL.md

@@ -31,6 +31,7 @@ When the feature's current behavior is unclear, establish it with the `qa-explai
 
 Offer after the analysis:
 
+- Draft missing or unclear user stories → `write-user-story` skill.
 - Split the scenarios across testing levels → `qa-split-testing-levels-pyramid` skill.
 - Turn scenarios into test cases or a checklist → `qa-write-test-cases` skill.
 - Ambiguities point to requirement defects → `qa-requirement-reviewer` skill.

skills/testing-workflow/SKILL.md

@@ -16,6 +16,8 @@ Orchestrates the test case lifecycle by routing requests to specialized skills a
 | `qa-explain-behavior`                | Explain what the product does — features, flows, permissions, edge cases, gaps    |
 | `qa-thinking`                        | Analyze a feature as QA — edge cases, negative flows, abuses, risk scenarios      |
 | `qa-split-testing-levels-pyramid`    | Apply the test pyramid — assign scenarios to testing levels, coverage split       |
+| `write-user-story`                    | Write user stories and acceptance criteria (the requirements)                     |
+| `qa-requirement-reviewer`            | Review requirements for ambiguity, gaps, and testability                          |
 | `qa-write-test-cases`                | Generate new test cases and checklists from requirements                          |
 | `improve-test-cases`                 | Improve existing test cases quality                                               |
 | `detect-duplicate-test-cases`        | Find duplicate, near-duplicate, and overlapping test cases                        |
@@ -34,6 +36,7 @@ Orchestrates the test case lifecycle by routing requests to specialized skills a
 - Match the request to a flow below. Delegate to that flow's skill, then suggest its next actions.
 - Flows are examples, not exhaustive. Combine or extend them when a request spans several tasks.
 - When suggesting next steps, take into account the flows, context, user request, and results of previous steps.
+- **Write / draft user stories** (requirements, spec, acceptance criteria) → route to the `write-user-story` skill. Review of existing requirements → `qa-requirement-reviewer`.
 - **Behavior questions** ("what happens when…", "can a user…", "is X supported") ask what the product does rather than for an artifact → route to the `qa-explain-behavior` skill first, then continue with the flow the answer points to.
 - **Strategic intent** ("where do I start", "improve our QA process", "QA maturity review") → route to the `qa-lead-strategy-advisor` skill instead. It owns the high-level roadmap and delegates execution back here.
 

skills/write-user-story/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: write-user-story
+description: Write user stories, and acceptance criteria (which represent requirements) from a feature idea, ticket, notes, or existing behavior. Use when the user asks to write, draft, or rewrite requirements, a spec, BRD, user stories, use cases, or acceptance criteria.
+metadata:
+  author: Testomat.io
+  version: 1.0.0
+---
+
+# Write User Story
+
+Turn source material into user stories. Acceptance criteria on each story are the requirements — testable, atomic rules the story must satisfy.
+
+If the source of data is a PR, use `qa-pr-requirements-analyzer` skill.
+If the source is a ticket in issue tracking system, ask for MCP connection.
+
+## Rules
+
+Every user story must be (at least, but not limited to):
+
+- **Atomic** — one actor, one capability.
+- **Clear** — no vague words (`fast`, `relevant`, `user-friendly`, `should work`, `as needed`).
+- **Complete** — actor, trigger, outcome, business rules; empty, error, and permission paths covered in AC.
+- **Consistent** — same terms throughout; no contradictions.
+- **Testable** — every story has acceptance criteria with a measurable pass/fail.
+
+Follow other best practices for writing user stories.
+
+Also:
+
+- Describe **what**, not how. No UI widgets, API implementation details or frameworks unless the user asked for that.
+- Flag assumptions and open questions. Never silently invent missing rules. Do NOT: guess, imagine, assume. Always ask the user for clarification if something is unclear.
+
+## Output
+
+Default: user stories + acceptance criteria. Match the user's format if they specify one (BRD, use cases, Gherkin, ticket AC) — still express each unit as a user story with AC.
+
+- Each user story gets a short unique identifier (e.g. `US-1`). Use local IDs only. Never invent TMS IDs.
+- Each story has at least one AC. Mark AC with a short unique id (e.g. `AC-1`).
+  (Better to set ids at the end of the line to make it more readable.)
+
+## Next actions
+
+- Review for gaps and testability → `qa-requirement-reviewer`
+- Risk scenarios → `qa-thinking`
+- Test cases from these user stories → `qa-write-test-cases`