@dzhechkov/p-replicator 1.0.0

package/templates/.claude/skills/requirements-validator/assets/templates/bdd-feature-template.feature

@@ -0,0 +1,69 @@
+# Template: BDD Feature File
+# Copy and customize for each user story
+
+Feature: [Feature Name]
+  As a [actor]
+  I want [capability]
+  So that [benefit]
+
+  Background:
+    Given [common preconditions]
+
+  # === HAPPY PATH (1-2 scenarios) ===
+  
+  @happy-path @critical @US-XXX
+  Scenario: [Primary success case]
+    Given [specific precondition with values]
+    When [user action with parameters]
+    Then [expected outcome with metrics]
+    And [secondary outcome] within [time constraint]
+
+  # === ERROR HANDLING (2-3 scenarios) ===
+
+  @error-handling @US-XXX
+  Scenario: [Validation error case]
+    Given [precondition]
+    When [action with invalid input]
+    Then [error response with code and message]
+    And [recovery option]
+
+  @error-handling @US-XXX
+  Scenario: [System error case]
+    Given [precondition leading to system error]
+    When [action that triggers error]
+    Then [graceful error handling]
+    And [error is logged with context]
+
+  # === EDGE CASES (1-2 scenarios) ===
+
+  @edge-case @US-XXX
+  Scenario: [Boundary condition]
+    Given [boundary precondition]
+    When [action at boundary]
+    Then [expected behavior at boundary]
+
+  @edge-case @US-XXX
+  Scenario: [Concurrent access / Race condition]
+    Given [concurrent users/requests]
+    When [simultaneous actions]
+    Then [consistent behavior]
+
+  # === SECURITY (if applicable) ===
+
+  @security @US-XXX
+  Scenario: [Authorization check]
+    Given [user without permission]
+    When [they attempt protected action]
+    Then [access denied response]
+    And [attempt is logged]
+
+  # === DATA-DRIVEN EXAMPLES ===
+
+  @validation @US-XXX
+  Scenario Outline: Validate <field> input
+    When user enters "<input>" in <field>
+    Then they see "<result>"
+
+    Examples:
+      | field | input | result |
+      | ... | ... | ... |

package/templates/.claude/skills/requirements-validator/references/bdd-patterns.md

@@ -0,0 +1,184 @@
+# BDD Patterns and Gherkin Templates
+
+## Scenario Coverage Requirements
+
+For each user story, generate:
+
+| Type | Count | Purpose |
+|------|-------|---------|
+| Happy path | 1-2 | Primary success flows |
+| Error handling | 2-3 | Validation, network, server errors |
+| Edge cases | 1-2 | Boundaries, nulls, concurrency |
+| Security | 0-2 | Auth, injection (if applicable) |
+
+## Feature Template
+
+```gherkin
+Feature: [Feature Name from User Story]
+  As a [actor from user story]
+  I want [action from user story]
+  So that [benefit from user story]
+
+  Background:
+    Given [common preconditions]
+
+  @happy-path @critical
+  Scenario: [Primary success case]
+    Given [specific precondition]
+    When [user action]
+    Then [expected outcome with metrics]
+
+  @error-handling
+  Scenario: [Error case name]
+    Given [precondition leading to error]
+    When [action that triggers error]
+    Then [error handling behavior]
+
+  @edge-case
+  Scenario: [Edge case name]
+    Given [boundary condition]
+    When [action at boundary]
+    Then [expected behavior]
+```
+
+## Common Scenario Patterns
+
+### Authentication
+
+```gherkin
+@happy-path
+Scenario: Successful login
+  Given a registered user with email "user@example.com"
+  When they enter valid credentials
+  And click "Login"
+  Then they are redirected to the dashboard within 2s
+  And a session is created expiring in 24h
+
+@error-handling
+Scenario: Invalid credentials
+  Given a registered user
+  When they enter incorrect password
+  Then they see error "Invalid email or password"
+  And no session is created
+  And login attempts are logged
+
+@security
+Scenario: Account lockout after failed attempts
+  Given a registered user
+  When they fail login 5 times within 15 minutes
+  Then the account is locked for 30 minutes
+  And they receive a security alert email
+```
+
+### CRUD Operations
+
+```gherkin
+@happy-path
+Scenario: Create resource
+  Given an authenticated user with create permission
+  When they submit valid resource data
+  Then the resource is created
+  And they receive 201 Created with resource ID
+  And the response time is <500ms
+
+@error-handling
+Scenario: Create with invalid data
+  Given an authenticated user
+  When they submit resource with missing required field "name"
+  Then they receive 400 Bad Request
+  And error message specifies "name is required"
+
+@edge-case
+Scenario: Create duplicate resource
+  Given an existing resource with name "Test"
+  When user creates another resource with name "Test"
+  Then they receive 409 Conflict
+  And error message specifies the duplicate field
+```
+
+### Search/Filter
+
+```gherkin
+@happy-path
+Scenario: Search returns results
+  Given 100 products in the database
+  And 15 products match "laptop"
+  When user searches for "laptop"
+  Then they see 15 results within 500ms
+  And results are paginated with 10 per page
+
+@edge-case
+Scenario: Search with no results
+  Given 100 products in the database
+  When user searches for "xyznonexistent123"
+  Then they see "No results found" message
+  And search suggestions are displayed
+
+@edge-case
+Scenario: Search with special characters
+  Given products with names containing quotes
+  When user searches for "15\" laptop"
+  Then the search handles the quote correctly
+  And returns matching products
+```
+
+### Async Operations
+
+```gherkin
+@happy-path
+Scenario: Async job completion
+  Given a user submits a report generation request
+  Then they receive 202 Accepted with job ID
+  And job status is "processing"
+  When the job completes (within 60s)
+  Then job status changes to "completed"
+  And download link is available
+
+@error-handling
+Scenario: Async job timeout
+  Given a report generation job
+  When processing exceeds 5 minutes
+  Then job status changes to "failed"
+  And user is notified via email
+  And partial results are preserved
+```
+
+## Tags Reference
+
+| Tag | Purpose |
+|-----|---------|
+| @critical | Must pass for release |
+| @happy-path | Primary success flows |
+| @error-handling | Error conditions |
+| @edge-case | Boundary conditions |
+| @security | Security-related |
+| @performance | Has timing requirements |
+| @smoke | Quick sanity check |
+| @regression | Full regression suite |
+
+## Data Table Patterns
+
+```gherkin
+Scenario Outline: Validate input fields
+  When user enters <input> in the <field> field
+  Then they see <result>
+
+  Examples:
+    | field    | input              | result           |
+    | email    | valid@email.com    | field is valid   |
+    | email    | invalid-email      | "Invalid email"  |
+    | password | short              | "Min 8 chars"    |
+    | password | ValidPass123!      | field is valid   |
+```
+
+## Traceability
+
+Each scenario should link to its source requirement:
+
+```gherkin
+@US-001 @AC-001
+Scenario: User login success
+  ...
+```
+
+This enables bidirectional traceability between requirements and tests.

package/templates/.claude/skills/requirements-validator/references/invest-criteria.md

@@ -0,0 +1,121 @@
+# INVEST Criteria Deep Dive
+
+## Scoring Weights
+
+| Criterion | Weight | Max Points |
+|-----------|--------|------------|
+| Independent | 8% | 8 |
+| Negotiable | 8% | 8 |
+| Valuable | 10% | 10 |
+| Estimable | 8% | 8 |
+| Small | 8% | 8 |
+| Testable | 8% | 8 |
+| **Total** | **50%** | **50** |
+
+## Independent (8%)
+
+**Definition**: Story can be developed, tested, and delivered separately from other stories.
+
+**Pass criteria**:
+- No explicit dependencies on unfinished stories
+- Can be demo'd in isolation
+- No "after X is complete" language
+
+**Red flags**:
+- "This story depends on US-XXX"
+- "After the authentication module is done..."
+- "Requires database schema from US-YYY"
+
+**Fix pattern**: Split coupled stories or merge if inseparable.
+
+## Negotiable (8%)
+
+**Definition**: Implementation details are open to discussion, not prescribed.
+
+**Pass criteria**:
+- Describes WHAT, not HOW
+- Leaves room for technical decisions
+- Focuses on outcome, not mechanism
+
+**Red flags**:
+- "Must use React"
+- "Implement with microservices"
+- "Store in PostgreSQL table X"
+
+**Fix pattern**: Remove implementation details. Move to technical notes if needed.
+
+## Valuable (10%)
+
+**Definition**: Delivers clear value to user or business.
+
+**Pass criteria**:
+- Has "so that [benefit]" clause
+- Benefit is concrete and measurable
+- Connects to business objective
+
+**Red flags**:
+- Missing "so that" clause
+- Vague benefits: "improve experience"
+- Technical tasks disguised as stories
+
+**Fix pattern**: Add explicit benefit. If no user value, convert to technical task.
+
+## Estimable (8%)
+
+**Definition**: Team can estimate effort with reasonable confidence.
+
+**Pass criteria**:
+- Scope is well-defined
+- Technical approach is understood
+- No major unknowns
+
+**Red flags**:
+- "System should be fast" (unmeasurable)
+- "Handle all edge cases" (unbounded)
+- References unknown external systems
+
+**Fix pattern**: Add specifics. Create spike if too many unknowns.
+
+## Small (8%)
+
+**Definition**: Fits within one sprint (typically 1-5 days of work).
+
+**Pass criteria**:
+- Single, focused feature
+- Can be completed by 1-2 developers
+- Has finite scope
+
+**Red flags**:
+- "Entire module"
+- "All users"
+- "Complete overhaul"
+- Multiple acceptance criteria covering different features
+
+**Fix pattern**: Decompose into smaller stories. Use story mapping.
+
+## Testable (8%)
+
+**Definition**: Has clear, verifiable acceptance criteria.
+
+**Pass criteria**:
+- Acceptance criteria exist
+- Pass/fail is deterministic
+- Can be automated
+
+**Red flags**:
+- No acceptance criteria
+- Subjective criteria: "looks good"
+- Unmeasurable outcomes
+
+**Fix pattern**: Add Given/When/Then acceptance criteria with specific values.
+
+## Validation Checklist
+
+```
+□ Independent: No blocking dependencies?
+□ Negotiable: Describes outcome, not implementation?
+□ Valuable: Clear user/business benefit?
+□ Estimable: Team can size it?
+□ Small: Fits in one sprint?
+□ Testable: Has verifiable acceptance criteria?
+```

package/templates/.claude/skills/requirements-validator/references/scoring-system.md

@@ -0,0 +1,134 @@
+# Testability Scoring System
+
+## Score Calculation Formula
+
+```
+Total Score = INVEST Score (50%) + SMART Score (30%) + Quality Score (20%)
+```
+
+## INVEST Score Breakdown (50 points max)
+
+| Criterion | Weight | Points | Calculation |
+|-----------|--------|--------|-------------|
+| Independent | 8% | 0-8 | Binary: 8 if pass, 0 if fail |
+| Negotiable | 8% | 0-8 | Binary: 8 if pass, 0 if fail |
+| Valuable | 10% | 0-10 | 10 if clear benefit, 5 if vague, 0 if missing |
+| Estimable | 8% | 0-8 | 8 if estimable, 4 if partially, 0 if not |
+| Small | 8% | 0-8 | 8 if sprint-sized, 4 if 2 sprints, 0 if larger |
+| Testable | 8% | 0-8 | 8 if AC exist and clear, 4 if vague AC, 0 if none |
+
+## SMART Score Breakdown (30 points max)
+
+| Criterion | Weight | Points | Calculation |
+|-----------|--------|--------|-------------|
+| Specific | 6% | 0-6 | -2 per vague term found |
+| Measurable | 8% | 0-8 | 8 if metrics exist, 4 if partial, 0 if none |
+| Achievable | 6% | 0-6 | 6 if realistic, 3 if stretch, 0 if impossible |
+| Relevant | 5% | 0-5 | 5 if connected to value, 0 if disconnected |
+| Time-bound | 5% | 0-5 | 5 if timing specified, 0 if missing |
+
+## Quality Score Breakdown (20 points max)
+
+| Criterion | Weight | Points | Calculation |
+|-----------|--------|--------|-------------|
+| Traceability | 10% | 0-10 | 10 if linked to tests, 5 if partial, 0 if none |
+| Completeness | 10% | 0-10 | See completeness rubric below |
+
+### Completeness Rubric
+
+| AC Coverage | Points |
+|-------------|--------|
+| Happy path + errors + edges | 10 |
+| Happy path + errors | 7 |
+| Happy path only | 4 |
+| Incomplete happy path | 2 |
+| No AC | 0 |
+
+## Score Interpretation
+
+| Score | Rating | Status | Action |
+|-------|--------|--------|--------|
+| 90-100 | Excellent | ✅ READY | Proceed to development |
+| 70-89 | Good | ⚠️ REVIEW | Fix minor issues, then proceed |
+| 50-69 | Fair | 🔶 REWORK | Significant clarification needed |
+| **0-49** | **Poor** | **🚫 BLOCKED** | **Requires complete rewrite** |
+
+## Quality Gate Rules
+
+### BLOCKED (Score < 50)
+
+Requirements scoring below 50 are **automatically blocked** from development.
+
+**Mandatory actions**:
+1. Identify all failing criteria
+2. Provide specific rewrite suggestions
+3. Generate improved AC examples
+4. Require re-validation after fixes
+
+### REVIEW (Score 50-69)
+
+**Recommended actions**:
+1. List all issues clearly
+2. Suggest specific improvements
+3. Allow development if product owner accepts risk
+
+### READY (Score 70+)
+
+**Actions**:
+1. Generate BDD scenarios
+2. Create traceability links
+3. Proceed to development
+
+## Example Score Calculation
+
+**User Story**: "As a user, I want the system to be fast so I can work efficiently"
+
+### INVEST Analysis
+
+| Criterion | Score | Reasoning |
+|-----------|-------|-----------|
+| Independent | 8 | No dependencies stated |
+| Negotiable | 8 | Implementation open |
+| Valuable | 5 | Benefit is vague ("efficiently") |
+| Estimable | 0 | Cannot estimate "fast" |
+| Small | 0 | "System" scope undefined |
+| Testable | 0 | No measurable criteria |
+| **Subtotal** | **21/50** | |
+
+### SMART Analysis (for "System responds fast")
+
+| Criterion | Score | Reasoning |
+|-----------|-------|-----------|
+| Specific | 0 | "fast" is vague (-6) |
+| Measurable | 0 | No metrics |
+| Achievable | 3 | Probably possible |
+| Relevant | 5 | Performance matters |
+| Time-bound | 0 | No timing specified |
+| **Subtotal** | **8/30** | |
+
+### Quality Analysis
+
+| Criterion | Score | Reasoning |
+|-----------|-------|-----------|
+| Traceability | 0 | No test links |
+| Completeness | 2 | Incomplete happy path |
+| **Subtotal** | **2/20** | |
+
+### Final Score
+
+```
+Total = 21 + 8 + 2 = 31/100
+Status: 🚫 BLOCKED
+```
+
+**Rewrite suggestion**:
+"As a customer, I want the product search to return results within 200ms at p95, so I can quickly find items without waiting."
+
+**Improved AC**:
+```gherkin
+Given 1000 concurrent users
+And 100,000 products in the catalog
+When a user searches for "laptop"
+Then 95% of responses complete in <200ms
+And all responses complete in <500ms
+```

package/templates/.claude/skills/requirements-validator/references/smart-criteria.md

@@ -0,0 +1,130 @@
+# SMART Criteria for Acceptance Criteria
+
+## Scoring Weights
+
+| Criterion | Weight | Max Points |
+|-----------|--------|------------|
+| Specific | 6% | 6 |
+| Measurable | 8% | 8 |
+| Achievable | 6% | 6 |
+| Relevant | 5% | 5 |
+| Time-bound | 5% | 5 |
+| **Total** | **30%** | **30** |
+
+## Specific (6%)
+
+**Definition**: Clear, unambiguous language with no room for interpretation.
+
+**Pass criteria**:
+- Concrete nouns and verbs
+- Exact values and conditions
+- No vague qualifiers
+
+**Vague term mapping**:
+
+| Vague Term | Specific Alternative |
+|------------|---------------------|
+| fast | <200ms p95 |
+| slow | >2000ms |
+| easy | <3 clicks/steps |
+| user-friendly | 80%+ task completion rate |
+| intuitive | no training required |
+| responsive | <100ms interaction feedback |
+| secure | passes OWASP Top 10 |
+| robust | handles 10x normal load |
+| efficient | <50MB memory usage |
+| simple | single-page form |
+
+**Fix pattern**: Replace every vague term with a measurable value.
+
+## Measurable (8%)
+
+**Definition**: Has quantifiable success criteria.
+
+**Pass criteria**:
+- Contains numbers, percentages, or counts
+- Defines thresholds (min, max, exact)
+- Can be verified automatically
+
+**Examples**:
+- ✗ "Page loads quickly" → ✓ "Page loads in <2s at p95"
+- ✗ "Most users succeed" → ✓ "95% of users complete task"
+- ✗ "Handles errors" → ✓ "Returns 4xx/5xx with error code and message"
+
+**Fix pattern**: Add "how much", "how many", "how fast" to every criterion.
+
+## Achievable (6%)
+
+**Definition**: Technically feasible within constraints.
+
+**Pass criteria**:
+- Within current technology stack
+- Resources available
+- No physical impossibilities
+
+**Red flags**:
+- "100% uptime" (impossible)
+- "Zero latency" (impossible)
+- "Infinite scalability" (unbounded)
+- "Works on all devices" (untestable)
+
+**Fix pattern**: Add realistic bounds. "99.9% uptime" instead of "100%".
+
+## Relevant (5%)
+
+**Definition**: Directly supports the user story's value proposition.
+
+**Pass criteria**:
+- Connects to "so that" clause
+- Tests user-facing behavior
+- Not implementation detail
+
+**Red flags**:
+- Tests internal methods
+- Checks database schemas
+- Verifies code structure
+
+**Fix pattern**: Reframe as user-observable behavior.
+
+## Time-bound (5%)
+
+**Definition**: Includes timing context where applicable.
+
+**Pass criteria**:
+- Response time requirements
+- Timeout specifications
+- Deadline/expiration handling
+
+**Examples**:
+- "API responds within 500ms"
+- "Session expires after 30 minutes"
+- "Email sent within 1 minute of registration"
+- "Retry 3 times with 1s backoff"
+
+**Fix pattern**: Add "within X time" for async operations and user-facing responses.
+
+## AC Quality Checklist
+
+```
+□ Specific: No vague terms (fast, easy, etc.)?
+□ Measurable: Contains numbers/thresholds?
+□ Achievable: Technically possible?
+□ Relevant: Supports user value?
+□ Time-bound: Has timing requirements?
+```
+
+## AC Template
+
+```gherkin
+Given [precondition with specific values]
+When [action with specific parameters]
+Then [outcome with measurable result] within [time constraint]
+```
+
+**Example**:
+```gherkin
+Given a registered user with valid credentials
+When they submit the login form
+Then they are redirected to the dashboard within 2 seconds
+And a session cookie is set expiring in 24 hours
+```