azcodr 1.5.2 → 2.0.0

package/.agents/skills/product-analyst/SKILL.md

@@ -1,154 +1,154 @@
----
-name: product-analyst
-description: Use when analyzing product requirements, aligning features with OKRs and Product Goals, prioritizing backlogs with Kano/MoSCoW/RICE, decomposing epics into INVEST user stories and SMART tasks, authoring Gherkin Given-When-Then acceptance criteria, or mapping domain models and failure edge cases. Do not use for writing application code, debugging implementation bugs, or running tests.
----
-
-# Product Analyst & Requirements Architect Skill
-
-> **Core Purpose:** Bridge strategic business intent and engineering execution by grounding feature requirements in OKRs, maximizing product value via empirical backlog ordering (Kano, MoSCoW, RICE), and decomposing scope into vertically sliced INVEST user stories with Gherkin acceptance criteria and SMART developer tasks.
-
----
-
-## 1. When to Use This Skill
-- Decomposing a broad business request, feature idea, or PRD into actionable vertical slices.
-- Evaluating alignment with strategic **Objectives & Key Results (OKRs)** and the overarching **Product Goal**.
-- Ordering and prioritizing Product Backlog items using **Kano**, **MoSCoW**, **RICE**, or **Buy a Feature**.
-- Distinguishing user-facing stories from non-story requirements (system invariants, NFRs, architectural spikes).
-- Formulating Gherkin acceptance tests before kicking off Outside-In TDD.
-- Decomposing INVEST stories into actionable, time-boxed **SMART developer tasks**.
-- Establishing Ubiquitous Language definitions for new domain models.
-
----
-
-## 2. Step-by-Step Analysis Workflow
-
-```
-1. OKR & Goal Alignment ──► 2. Backlog Triage & Ordering ──► 3. Story vs. NFR Classification ──► 4. INVEST Stories & Gherkin ──► 5. SMART Tasks & Edge Cases
-```
-
-### Step 1: Align with OKRs & the Product Goal
-- **Product Goal Validation:** Verify how this feature advances the long-term Product Goal.
-- **OKR Mapping:** Map the feature to a specific **Objective** (qualitative "what") and its associated **Key Results** (quantitative "how").
-- **Satisfaction Gap Check:** Identify which customer pain point or satisfaction gap is addressed:
-  $$\text{Satisfaction Gap} = \text{Desired Customer Experience} - \text{Current Customer Experience}$$
-- **Deciding What NOT to Do:** Explicitly identify and eliminate speculative, low-impact sub-features.
-
-### Step 2: Prioritize via Backlog Ordering Models
-Consult [`references/backlog_ordering_techniques.md`](./references/backlog_ordering_techniques.md) to apply the optimal prioritization model:
-- **Kano Model:** Classify as *Must-be* (table stakes), *Performance* (linear satisfaction), or *Attractive* (delighter). Reject *Indifferent* or *Reverse* items.
-- **MoSCoW:** Categorize into *Must*, *Should*, *Could*, or *Won't have this time*.
-- **RICE Scoring:** Compute $(Reach \times Impact \times Confidence) / Effort$ to break ranking ties objectively.
-
-### Step 3: Classify User Stories vs. Non-Story Requirements
-Recognize that **user stories are not requirements**, but a technique to express them:
-- **User Story (3 C's: Card, Conversation, Confirmation):** Fits user-facing features where customer/business perspective is translated into software behavior via a "pidgin language".
-- **Non-Story Requirements:** If the requirement represents a system invariant, data integrity rule, security policy (OWASP), latency SLA, or an architectural spike, model it directly as a technical specification, architectural fitness test, or spike task rather than forcing an artificial `"As a user..."` persona.
-
-### Step 4: Author User Stories (INVEST Framework & Vertical Cake Slicing)
-Ensure every user story conforms to Bill Wake's **INVEST** criteria:
-- **Independent:** Sliced vertically through all layers (UI ➔ API ➔ Domain ➔ DB) without circular dependencies.
-- **Negotiable:** Captures essence and value, leaving implementation details open for pairing co-creation.
-- **Valuable:** Delivers observable benefit to the customer or business stakeholder.
-- **Estimable:** Right-sized and bounded. Spikes used for major unknowns.
-- **Small:** Sized to be completable in 1–2 development days.
-- **Testable:** Accompanied by executable, unambiguous Gherkin acceptance criteria.
-
-**The Multi-Layer Cake Rule & UI Integration:**
-- **Never slice horizontally** (e.g. *"Create database schema only"* or *"Create backend API only"*). Always slice vertically through the full stack so that every story delivers working software.
-- **Mandatory UI/UX Triage Gate for User-Facing Applications:** If the project has a frontend or user interface (Fullstack Web SaaS, Extension, Desktop), execute the **7-Pillar Design Architecture Triage Gate** ([`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md)) before finalizing stories:
-  1. *Role & Identity:* Define who the user is and their operational boundary.
-  2. *Information Architecture:* Define how the view fits into the Persistent App Shell vs Dynamic Canvas.
-  3. *Experience Duality:* Clarify whether the screen belongs to an Enterprise Operator Workspace or Consumer Portal.
-  4. *Navigation & Wayfinding:* Specify sidebar route, active tab, breadcrumbs, and command palette entries.
-  5. *State & URL Synchronization:* Specify query params (`?tab=`, `?q=`, `?page=`, `?modal=`).
-  6. *Access Control:* Specify route guards and permission checks.
-  7. *Accessibility & Feedback:* Specify accessible notifications, focus trapping, and zero native alerts.
-- **Every user-facing story MUST specify:** (1) The UI view/component & user interaction, (2) The API Command/Query DTO, (3) The core domain invariant, and (4) The persistence change.
-
-### Step 5: Decompose Stories into SMART Developer Tasks
-For engineering execution, translate INVEST user stories into Bill Wake's **SMART** developer tasks:
-- **S - Specific:** Unambiguous scope without conceptual overlap.
-- **M - Measurable:** Clear pass/fail criteria (tests pass, clean code, DoD met).
-- **A - Achievable:** Realistically executable; triggers early help request if blocked.
-- **R - Relevant:** Justified by direct contribution to parent story.
-- **T - Time-boxed:** Limited to 2–4 hours (never exceeding 1 day).
-
-### Step 6: Construct the Edge Case & Failure Matrix
-Map all failure paths to HTTP status codes (`400`, `401`, `403`, `404`, `409`, `422`, `429`, `500`) and RFC 7807 problem details.
-
----
-
-## 3. Gotchas & What NOT to Do
-
-- **DO NOT** confuse output (features shipped, story points burned) with outcome (value delivered, satisfaction gap closed).
-- **DO NOT** write horizontal, technical user stories (e.g., *"As a developer, I want a database table"* or *"As an API, I want a REST endpoint"*).
-- **DO NOT** author backend-only user stories or ignore the UI when analyzing a user-facing system. If the system has a web frontend or client interface, slicing must start with user interactions and views.
-- **DO NOT** force technical constraints, security policies, or infrastructure upgrades into user story syntax. Treat them as non-story requirements or architectural spikes.
-- **DO NOT** omit the Out-of-Scope ("Won't Have this time") section. Lack of negative boundaries causes runaway scope bloat.
-- **DO NOT** allow developer tasks to be open-ended without a measurable time-box. If a task exceeds 4 hours, it must be split or paired.
-- **DO NOT** skip failure paths in Gherkin scenarios. Happy-path-only requirements lead to production defects.
-
----
-
-## 4. Structured Output Template
-
-```markdown
-# Product Specification: [Feature Name]
-
-## 1. Strategic Alignment & Product Goal
-- **Product Goal:** [Target milestone / commitment]
-- **Target OKR:**
-  - **Objective:** [Qualitative, inspiring What]
-  - **Key Result(s):** [Quantitative, measurable outcome How]
-- **Target Satisfaction Gap:** [Customer pain point addressed]
-- **Prioritization Category:** [Kano: Must-be / Performance / Attractive | MoSCoW: Must / Should | RICE Score: X]
-
-## 2. In-Scope vs. Out-of-Scope (Non-Goals)
-- **In-Scope (Must/Should):** ...
-- **Out-of-Scope (Won't Have This Time):** ...
-
-## 3. Ubiquitous Language & Entity Relationships
-- **[Term 1]**: [Definition grounded in domain invariants]
-- **[Term 2]**: [Definition grounded in domain invariants]
-
-## 4. User Stories & Gherkin Acceptance Scenarios
-
-### US-01: [User Story Title]
-**As a** [role]  
-**I want to** [action]  
-**So that** [value]
-
-```gherkin
-Scenario: [Happy path]
-  Given ...
-  When ...
-  Then ...
-
-Scenario: [Edge case / Failure path]
-  Given ...
-  When ...
-  Then ...
-```
-
-## 5. SMART Developer Tasks (Inner-Loop Breakdown)
-- [ ] **Task 1 [Specific & Time-boxed: 2h]:** [Technical description, e.g. Domain entity and value object invariants with unit test RED-GREEN]
-- [ ] **Task 2 [Specific & Time-boxed: 3h]:** [Use case & secondary repository implementation with integration tests]
-- [ ] **Task 3 [Specific & Time-boxed: 2h]:** [HTTP controller endpoint & RFC 7807 error handling]
-- [ ] **Task 4 [Specific & Time-boxed: 3h]:** [UI view integration, TanStack query hooks, accessible Radix primitives]
-
-## 6. Edge Case & Error Response Matrix
-| Condition | HTTP Status | Error Code | Expected Behavior |
-|---|---|---|---|
-| Invalid payload | 400 | `VALIDATION_ERROR` | Return field errors |
-| Cross-tenant attempt | 403 / 404 | `FORBIDDEN` | Mask existence or block |
-| Duplicate invariant | 409 | `CONFLICT` | Prevent double-submission |
-```
-
----
-
-## 5. Subdirectories & Progressive Resources
-- [references/invest_checklist.md](./references/invest_checklist.md): Checklist for evaluating user stories against Bill Wake's INVEST criteria and cake-slicing rules.
-- [references/smart_tasks.md](./references/smart_tasks.md): Guide and patterns for breaking stories into SMART developer tasks.
-- [references/backlog_ordering_techniques.md](./references/backlog_ordering_techniques.md): Matrix and decision trees for Kano, MoSCoW, RICE, and Buy a Feature.
-- [references/okr_alignment_guide.md](./references/okr_alignment_guide.md): Framework for authoring Objectives, Key Results, and connecting them to Product Goals.
-- [references/gherkin_patterns.md](./references/gherkin_patterns.md): Reusable Gherkin scenario patterns for REST APIs and UI interactions.
+---
+name: product-analyst
+description: Use when analyzing product requirements, aligning features with OKRs and Product Goals, prioritizing backlogs with Kano/MoSCoW/RICE, decomposing epics into INVEST user stories and SMART tasks, authoring Gherkin Given-When-Then acceptance criteria, or mapping domain models and failure edge cases. Do not use for writing application code, debugging implementation bugs, or running tests.
+---
+
+# Product Analyst & Requirements Architect Skill
+
+> **Core Purpose:** Bridge strategic business intent and engineering execution by grounding feature requirements in OKRs, maximizing product value via empirical backlog ordering (Kano, MoSCoW, RICE), and decomposing scope into vertically sliced INVEST user stories with Gherkin acceptance criteria and SMART developer tasks.
+
+---
+
+## 1. When to Use This Skill
+- Decomposing a broad business request, feature idea, or PRD into actionable vertical slices.
+- Evaluating alignment with strategic **Objectives & Key Results (OKRs)** and the overarching **Product Goal**.
+- Ordering and prioritizing Product Backlog items using **Kano**, **MoSCoW**, **RICE**, or **Buy a Feature**.
+- Distinguishing user-facing stories from non-story requirements (system invariants, NFRs, architectural spikes).
+- Formulating Gherkin acceptance tests before kicking off Outside-In TDD.
+- Decomposing INVEST stories into actionable, time-boxed **SMART developer tasks**.
+- Establishing Ubiquitous Language definitions for new domain models.
+
+---
+
+## 2. Step-by-Step Analysis Workflow
+
+```
+1. OKR & Goal Alignment ──► 2. Backlog Triage & Ordering ──► 3. Story vs. NFR Classification ──► 4. INVEST Stories & Gherkin ──► 5. SMART Tasks & Edge Cases
+```
+
+### Step 1: Align with OKRs & the Product Goal
+- **Product Goal Validation:** Verify how this feature advances the long-term Product Goal.
+- **OKR Mapping:** Map the feature to a specific **Objective** (qualitative "what") and its associated **Key Results** (quantitative "how").
+- **Satisfaction Gap Check:** Identify which customer pain point or satisfaction gap is addressed:
+  $$\text{Satisfaction Gap} = \text{Desired Customer Experience} - \text{Current Customer Experience}$$
+- **Deciding What NOT to Do:** Explicitly identify and eliminate speculative, low-impact sub-features.
+
+### Step 2: Prioritize via Backlog Ordering Models
+Consult [`references/backlog_ordering_techniques.md`](./references/backlog_ordering_techniques.md) to apply the optimal prioritization model:
+- **Kano Model:** Classify as *Must-be* (table stakes), *Performance* (linear satisfaction), or *Attractive* (delighter). Reject *Indifferent* or *Reverse* items.
+- **MoSCoW:** Categorize into *Must*, *Should*, *Could*, or *Won't have this time*.
+- **RICE Scoring:** Compute $(Reach \times Impact \times Confidence) / Effort$ to break ranking ties objectively.
+
+### Step 3: Classify User Stories vs. Non-Story Requirements
+Recognize that **user stories are not requirements**, but a technique to express them:
+- **User Story (3 C's: Card, Conversation, Confirmation):** Fits user-facing features where customer/business perspective is translated into software behavior via a "pidgin language".
+- **Non-Story Requirements:** If the requirement represents a system invariant, data integrity rule, security policy (OWASP), latency SLA, or an architectural spike, model it directly as a technical specification, architectural fitness test, or spike task rather than forcing an artificial `"As a user..."` persona.
+
+### Step 4: Author User Stories (INVEST Framework & Vertical Cake Slicing)
+Ensure every user story conforms to Bill Wake's **INVEST** criteria:
+- **Independent:** Sliced vertically through all layers (UI ➔ API ➔ Domain ➔ DB) without circular dependencies.
+- **Negotiable:** Captures essence and value, leaving implementation details open for pairing co-creation.
+- **Valuable:** Delivers observable benefit to the customer or business stakeholder.
+- **Estimable:** Right-sized and bounded. Spikes used for major unknowns.
+- **Small:** Sized to be completable in 1–2 development days.
+- **Testable:** Accompanied by executable, unambiguous Gherkin acceptance criteria.
+
+**The Multi-Layer Cake Rule & UI Integration:**
+- **Never slice horizontally** (e.g. *"Create database schema only"* or *"Create backend API only"*). Always slice vertically through the full stack so that every story delivers working software.
+- **Mandatory UI/UX Triage Gate for User-Facing Applications:** If the project has a frontend or user interface (Fullstack Web SaaS, Extension, Desktop), execute the **7-Pillar Design Architecture Triage Gate** ([`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md)) before finalizing stories:
+  1. *Role & Identity:* Define who the user is and their operational boundary.
+  2. *Information Architecture:* Define how the view fits into the Persistent App Shell vs Dynamic Canvas.
+  3. *Experience Duality:* Clarify whether the screen belongs to an Enterprise Operator Workspace or Consumer Portal.
+  4. *Navigation & Wayfinding:* Specify sidebar route, active tab, breadcrumbs, and command palette entries.
+  5. *State & URL Synchronization:* Specify query params (`?tab=`, `?q=`, `?page=`, `?modal=`).
+  6. *Access Control:* Specify route guards and permission checks.
+  7. *Accessibility & Feedback:* Specify accessible notifications, focus trapping, and zero native alerts.
+- **Every user-facing story MUST specify:** (1) The UI view/component & user interaction, (2) The API Command/Query DTO, (3) The core domain invariant, and (4) The persistence change.
+
+### Step 5: Decompose Stories into SMART Developer Tasks
+For engineering execution, translate INVEST user stories into Bill Wake's **SMART** developer tasks:
+- **S - Specific:** Unambiguous scope without conceptual overlap.
+- **M - Measurable:** Clear pass/fail criteria (tests pass, clean code, DoD met).
+- **A - Achievable:** Realistically executable; triggers early help request if blocked.
+- **R - Relevant:** Justified by direct contribution to parent story.
+- **T - Time-boxed:** Limited to 2–4 hours (never exceeding 1 day).
+
+### Step 6: Construct the Edge Case & Failure Matrix
+Map all failure paths to HTTP status codes (`400`, `401`, `403`, `404`, `409`, `422`, `429`, `500`) and RFC 9457 problem details.
+
+---
+
+## 3. Gotchas & What NOT to Do
+
+- **DO NOT** confuse output (features shipped, story points burned) with outcome (value delivered, satisfaction gap closed).
+- **DO NOT** write horizontal, technical user stories (e.g., *"As a developer, I want a database table"* or *"As an API, I want a REST endpoint"*).
+- **DO NOT** author backend-only user stories or ignore the UI when analyzing a user-facing system. If the system has a web frontend or client interface, slicing must start with user interactions and views.
+- **DO NOT** force technical constraints, security policies, or infrastructure upgrades into user story syntax. Treat them as non-story requirements or architectural spikes.
+- **DO NOT** omit the Out-of-Scope ("Won't Have this time") section. Lack of negative boundaries causes runaway scope bloat.
+- **DO NOT** allow developer tasks to be open-ended without a measurable time-box. If a task exceeds 4 hours, it must be split or paired.
+- **DO NOT** skip failure paths in Gherkin scenarios. Happy-path-only requirements lead to production defects.
+
+---
+
+## 4. Structured Output Template
+
+```markdown
+# Product Specification: [Feature Name]
+
+## 1. Strategic Alignment & Product Goal
+- **Product Goal:** [Target milestone / commitment]
+- **Target OKR:**
+  - **Objective:** [Qualitative, inspiring What]
+  - **Key Result(s):** [Quantitative, measurable outcome How]
+- **Target Satisfaction Gap:** [Customer pain point addressed]
+- **Prioritization Category:** [Kano: Must-be / Performance / Attractive | MoSCoW: Must / Should | RICE Score: X]
+
+## 2. In-Scope vs. Out-of-Scope (Non-Goals)
+- **In-Scope (Must/Should):** ...
+- **Out-of-Scope (Won't Have This Time):** ...
+
+## 3. Ubiquitous Language & Entity Relationships
+- **[Term 1]**: [Definition grounded in domain invariants]
+- **[Term 2]**: [Definition grounded in domain invariants]
+
+## 4. User Stories & Gherkin Acceptance Scenarios
+
+### US-01: [User Story Title]
+**As a** [role]  
+**I want to** [action]  
+**So that** [value]
+
+```gherkin
+Scenario: [Happy path]
+  Given ...
+  When ...
+  Then ...
+
+Scenario: [Edge case / Failure path]
+  Given ...
+  When ...
+  Then ...
+```
+
+## 5. SMART Developer Tasks (Inner-Loop Breakdown)
+- [ ] **Task 1 [Specific & Time-boxed: 2h]:** [Technical description, e.g. Domain entity and value object invariants with unit test RED-GREEN]
+- [ ] **Task 2 [Specific & Time-boxed: 3h]:** [Use case & secondary repository implementation with integration tests]
+- [ ] **Task 3 [Specific & Time-boxed: 2h]:** [HTTP controller endpoint & RFC 9457 error handling]
+- [ ] **Task 4 [Specific & Time-boxed: 3h]:** [UI view integration, TanStack query hooks, accessible Radix primitives]
+
+## 6. Edge Case & Error Response Matrix
+| Condition | HTTP Status | Error Code | Expected Behavior |
+|---|---|---|---|
+| Invalid payload | 400 | `VALIDATION_ERROR` | Return field errors |
+| Cross-tenant attempt | 403 / 404 | `FORBIDDEN` | Mask existence or block |
+| Duplicate invariant | 409 | `CONFLICT` | Prevent double-submission |
+```
+
+---
+
+## 5. Subdirectories & Progressive Resources
+- [references/invest_checklist.md](./references/invest_checklist.md): Checklist for evaluating user stories against Bill Wake's INVEST criteria and cake-slicing rules.
+- [references/smart_tasks.md](./references/smart_tasks.md): Guide and patterns for breaking stories into SMART developer tasks.
+- [references/backlog_ordering_techniques.md](./references/backlog_ordering_techniques.md): Matrix and decision trees for Kano, MoSCoW, RICE, and Buy a Feature.
+- [references/okr_alignment_guide.md](./references/okr_alignment_guide.md): Framework for authoring Objectives, Key Results, and connecting them to Product Goals.
+- [references/gherkin_patterns.md](./references/gherkin_patterns.md): Reusable Gherkin scenario patterns for REST APIs and UI interactions.

package/.agents/skills/product-analyst/references/backlog_ordering_techniques.md

@@ -1,107 +1,107 @@
-# Product Backlog Ordering & Prioritization Techniques
-
-> **Core Concept:** Prioritizing product backlog items (PBIs) requires disciplined, objective frameworks rather than arbitrary stakeholder pressure. Use this guide to select and apply the right prioritization technique for the product stage.
-
----
-
-## 1. Prioritization Framework Comparison Matrix
-
-| Framework | Primary Focus | Best Used When... | Key Metric / Input |
-|---|---|---|---|
-| **The Kano Model** | Customer emotional satisfaction vs. investment level | Discovering baseline expectations vs. competitive differentiators | Functional vs. Dysfunctional customer responses |
-| **MoSCoW** | Release scope packaging & non-negotiable boundaries | Planning fixed-date releases or MVP feature gating | Critical path vs. optional enhancements |
-| **RICE Scoring** | Objective algorithmic ranking based on measurable impact | Resolving prioritization disputes across diverse feature requests | $(Reach \times Impact \times Confidence) / Effort$ |
-| **Buy a Feature** | Stakeholder consensus under budget constraints | Engaging cross-functional stakeholders or customer advisory boards | Constrained allocation of currency |
-
----
-
-## 2. The Kano Model
-
-Categorizes features based on how customer satisfaction correlates with implementation completeness:
-
-```
-Satisfaction (Delighted)
-          ▲
-          │          Attractive (Delighters)
-          │         /
-          │        /    Performance (Linear)
-          │       /    /
-          │      /    /
-          │     /    /
-──────────┼────/────/────────────────────────► Completeness (Invested)
-          │   /    /
-          │  /    /
-          │ /    /   Must-be (Basic Expectations)
-          │/____/
-          ▼
-Dissatisfaction (Frustrated)
-```
-
-### The 5 Kano Categories
-1. **Must-be (Basic / Threshold):** Table stakes. Taken for granted when present, but causes catastrophic dissatisfaction when absent (e.g., database ACID transactions, secure authentication, password resets). *Rule: Must be fully delivered before optimizing performance.*
-2. **Performance (One-Dimensional):** Satisfaction is linearly proportional to execution (e.g., faster page load, higher search speed, larger export limits). *Rule: Optimize strategically where competitive advantage exists.*
-3. **Attractive (Delighters / Excitement):** Unexpected innovations that trigger disproportionate joy and buzz (e.g., instant one-click self-service onboarding, predictive issue alerts). *Rule: Include at least one delighter per major release to drive adoption.*
-4. **Indifferent:** Features that customers do not care about either way. *Rule: Eliminate immediately; do not waste engineering capacity.*
-5. **Reverse:** Features that actively cause frustration if added (e.g., excessive mandatory onboarding modals, invasive popups). *Rule: Avoid or remove.*
-
----
-
-## 3. MoSCoW Prioritization
-
-Essential for packaging release increments and enforcing negative scope:
-
-- **Must Have (M):**
-  - Non-negotiable core invariants.
-  - Without this, the system cannot operate legally, securely, or fundamentally.
-  - *Example:* "Users must be able to view their pending agreement."
-- **Should Have (S):**
-  - Highly important and valuable, but not critical for launch; a temporary workaround exists.
-  - *Example:* "Automated transactional notifications upon signing" (workaround: manual status check).
-- **Could Have (C):**
-  - Desirable enhancements that provide delight, but are easily deferred if time is constrained.
-  - *Example:* "Downloadable execution certificate with custom styling."
-- **Won't Have This Time (W):**
-  - Explicitly agreed as out-of-scope for the current release. Protects the team from scope creep.
-  - *Example:* "Multi-party commercial co-signer execution flows."
-
----
-
-## 4. RICE Scoring Framework
-
-When competing stakeholder requests clash, calculate the objective RICE score:
-
-$$\text{RICE Score} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
-
-### Component Definitions & Scoring Scales
-1. **Reach (R):** Number of users or events impacted over a defined timeframe (e.g., per month).
-   - *Example:* 500 active customers signing agreements per quarter $\rightarrow Reach = 500$.
-2. **Impact (I):** Qualitative impact on individual users or conversion:
-   - $3.0$ = Massive impact
-   - $2.0$ = High impact
-   - $1.0$ = Medium impact
-   - $0.5$ = Low impact
-   - $0.25$ = Minimal impact
-3. **Confidence (C):** Percentage reflecting empirical backing vs. speculation:
-   - $100\%$ = High confidence (backed by verified user interviews and analytics)
-   - $80\%$ = Medium confidence (backed by qualitative feedback)
-   - $50\%$ = Low confidence (speculative assumption / gut feeling)
-4. **Effort (E):** Estimated development effort in person-weeks or person-sprints:
-   - *Example:* 1 person-week of engineering $\rightarrow Effort = 1$.
-
-### Example Calculation:
-- **Feature A (Digital Agreement Execution):**
-  - $R = 500$, $I = 3.0$, $C = 100\%$, $E = 1.0 \rightarrow \text{RICE} = \frac{500 \times 3.0 \times 1.0}{1.0} = 1500$
-- **Feature B (Custom Dark Mode Themes):**
-  - $R = 200$, $I = 0.5$, $C = 50\%$, $E = 2.0 \rightarrow \text{RICE} = \frac{200 \times 0.5 \times 0.5}{2.0} = 25$
-- *Conclusion: Feature A takes clear priority.*
-
----
-
-## 5. Buy a Feature
-
-A collaborative budgeting game ideal for quarterly roadmap planning:
-1. List 10–15 candidate features.
-2. Price each feature proportionally to its engineering effort (e.g., Small = \$50, Medium = \$150, Large = \$400).
-3. Allocate each participant (or group) a constrained budget of fictitious currency equal to roughly 50% of the total cost of all features.
-4. Encourage participants to negotiate and pool their funds to "buy" the features that matter most.
-5. High-priced features that get bought through shared pooling reveal true, undeniable consensus value.
+# Product Backlog Ordering & Prioritization Techniques
+
+> **Core Concept:** Prioritizing product backlog items (PBIs) requires disciplined, objective frameworks rather than arbitrary stakeholder pressure. Use this guide to select and apply the right prioritization technique for the product stage.
+
+---
+
+## 1. Prioritization Framework Comparison Matrix
+
+| Framework | Primary Focus | Best Used When... | Key Metric / Input |
+|---|---|---|---|
+| **The Kano Model** | Customer emotional satisfaction vs. investment level | Discovering baseline expectations vs. competitive differentiators | Functional vs. Dysfunctional customer responses |
+| **MoSCoW** | Release scope packaging & non-negotiable boundaries | Planning fixed-date releases or MVP feature gating | Critical path vs. optional enhancements |
+| **RICE Scoring** | Objective algorithmic ranking based on measurable impact | Resolving prioritization disputes across diverse feature requests | $(Reach \times Impact \times Confidence) / Effort$ |
+| **Buy a Feature** | Stakeholder consensus under budget constraints | Engaging cross-functional stakeholders or customer advisory boards | Constrained allocation of currency |
+
+---
+
+## 2. The Kano Model
+
+Categorizes features based on how customer satisfaction correlates with implementation completeness:
+
+```
+Satisfaction (Delighted)
+          ▲
+          │          Attractive (Delighters)
+          │         /
+          │        /    Performance (Linear)
+          │       /    /
+          │      /    /
+          │     /    /
+──────────┼────/────/────────────────────────► Completeness (Invested)
+          │   /    /
+          │  /    /
+          │ /    /   Must-be (Basic Expectations)
+          │/____/
+          ▼
+Dissatisfaction (Frustrated)
+```
+
+### The 5 Kano Categories
+1. **Must-be (Basic / Threshold):** Table stakes. Taken for granted when present, but causes catastrophic dissatisfaction when absent (e.g., database ACID transactions, secure authentication, password resets). *Rule: Must be fully delivered before optimizing performance.*
+2. **Performance (One-Dimensional):** Satisfaction is linearly proportional to execution (e.g., faster page load, higher search speed, larger export limits). *Rule: Optimize strategically where competitive advantage exists.*
+3. **Attractive (Delighters / Excitement):** Unexpected innovations that trigger disproportionate joy and buzz (e.g., instant one-click self-service onboarding, predictive issue alerts). *Rule: Include at least one delighter per major release to drive adoption.*
+4. **Indifferent:** Features that customers do not care about either way. *Rule: Eliminate immediately; do not waste engineering capacity.*
+5. **Reverse:** Features that actively cause frustration if added (e.g., excessive mandatory onboarding modals, invasive popups). *Rule: Avoid or remove.*
+
+---
+
+## 3. MoSCoW Prioritization
+
+Essential for packaging release increments and enforcing negative scope:
+
+- **Must Have (M):**
+  - Non-negotiable core invariants.
+  - Without this, the system cannot operate legally, securely, or fundamentally.
+  - *Example:* "Users must be able to view their pending agreement."
+- **Should Have (S):**
+  - Highly important and valuable, but not critical for launch; a temporary workaround exists.
+  - *Example:* "Automated transactional notifications upon signing" (workaround: manual status check).
+- **Could Have (C):**
+  - Desirable enhancements that provide delight, but are easily deferred if time is constrained.
+  - *Example:* "Downloadable execution certificate with custom styling."
+- **Won't Have This Time (W):**
+  - Explicitly agreed as out-of-scope for the current release. Protects the team from scope creep.
+  - *Example:* "Multi-party commercial co-signer execution flows."
+
+---
+
+## 4. RICE Scoring Framework
+
+When competing stakeholder requests clash, calculate the objective RICE score:
+
+$$\text{RICE Score} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
+
+### Component Definitions & Scoring Scales
+1. **Reach (R):** Number of users or events impacted over a defined timeframe (e.g., per month).
+   - *Example:* 500 active customers signing agreements per quarter $\rightarrow Reach = 500$.
+2. **Impact (I):** Qualitative impact on individual users or conversion:
+   - $3.0$ = Massive impact
+   - $2.0$ = High impact
+   - $1.0$ = Medium impact
+   - $0.5$ = Low impact
+   - $0.25$ = Minimal impact
+3. **Confidence (C):** Percentage reflecting empirical backing vs. speculation:
+   - $100\%$ = High confidence (backed by verified user interviews and analytics)
+   - $80\%$ = Medium confidence (backed by qualitative feedback)
+   - $50\%$ = Low confidence (speculative assumption / gut feeling)
+4. **Effort (E):** Estimated development effort in person-weeks or person-sprints:
+   - *Example:* 1 person-week of engineering $\rightarrow Effort = 1$.
+
+### Example Calculation:
+- **Feature A (Digital Agreement Execution):**
+  - $R = 500$, $I = 3.0$, $C = 100\%$, $E = 1.0 \rightarrow \text{RICE} = \frac{500 \times 3.0 \times 1.0}{1.0} = 1500$
+- **Feature B (Custom Dark Mode Themes):**
+  - $R = 200$, $I = 0.5$, $C = 50\%$, $E = 2.0 \rightarrow \text{RICE} = \frac{200 \times 0.5 \times 0.5}{2.0} = 25$
+- *Conclusion: Feature A takes clear priority.*
+
+---
+
+## 5. Buy a Feature
+
+A collaborative budgeting game ideal for quarterly roadmap planning:
+1. List 10–15 candidate features.
+2. Price each feature proportionally to its engineering effort (e.g., Small = \$50, Medium = \$150, Large = \$400).
+3. Allocate each participant (or group) a constrained budget of fictitious currency equal to roughly 50% of the total cost of all features.
+4. Encourage participants to negotiate and pool their funds to "buy" the features that matter most.
+5. High-priced features that get bought through shared pooling reveal true, undeniable consensus value.

package/.agents/skills/product-analyst/references/gherkin_patterns.md

@@ -1,46 +1,46 @@
-# Gherkin Scenario Patterns Reference
-
-Reusable Gherkin acceptance criteria patterns for full-stack and API features.
-
----
-
-## 1. REST API CRUD Pattern
-```gherkin
-Scenario: Successfully creating a tenant resource
-  Given an authenticated user with role "ADMIN" in tenant "tenant-123"
-  When the user sends a "POST" request to "/api/roles" with payload:
-    """
-    {
-      "name": "Editor",
-      "description": "Content editor role"
-    }
-    """
-  Then the response status should be 201
-  And the response body should contain the generated "id"
-  And the role should be persisted in tenant "tenant-123"
-```
-
----
-
-## 2. Multi-Tenant Isolation Pattern
-```gherkin
-Scenario: Tenant data isolation violation attempt
-  Given an authenticated user in tenant "tenant-A"
-  When the user sends a "GET" request to "/api/members" with header "X-Tenant-ID: tenant-B"
-  Then the response status should be 403
-  And the response code should be "FORBIDDEN_TENANT_ACCESS"
-  And a security audit event should be recorded
-```
-
----
-
-## 3. UI Interaction & Validation Pattern
-```gherkin
-Scenario: Submitting an invalid email address
-  Given the user is on the login page
-  When the user enters "invalid-email" into the email input
-  And clicks the "Sign In" button
-  Then an alert message "Invalid email address format" should appear
-  And the email input should have "aria-invalid" set to "true"
-  And no network request should be dispatched to the server
-```
+# Gherkin Scenario Patterns Reference
+
+Reusable Gherkin acceptance criteria patterns for full-stack and API features.
+
+---
+
+## 1. REST API CRUD Pattern
+```gherkin
+Scenario: Successfully creating a tenant resource
+  Given an authenticated user with role "ADMIN" in tenant "tenant-123"
+  When the user sends a "POST" request to "/api/roles" with payload:
+    """
+    {
+      "name": "Editor",
+      "description": "Content editor role"
+    }
+    """
+  Then the response status should be 201
+  And the response body should contain the generated "id"
+  And the role should be persisted in tenant "tenant-123"
+```
+
+---
+
+## 2. Multi-Tenant Isolation Pattern
+```gherkin
+Scenario: Tenant data isolation violation attempt
+  Given an authenticated user in tenant "tenant-A"
+  When the user sends a "GET" request to "/api/members" with header "X-Tenant-ID: tenant-B"
+  Then the response status should be 403
+  And the response code should be "FORBIDDEN_TENANT_ACCESS"
+  And a security audit event should be recorded
+```
+
+---
+
+## 3. UI Interaction & Validation Pattern
+```gherkin
+Scenario: Submitting an invalid email address
+  Given the user is on the login page
+  When the user enters "invalid-email" into the email input
+  And clicks the "Sign In" button
+  Then an alert message "Invalid email address format" should appear
+  And the email input should have "aria-invalid" set to "true"
+  And no network request should be dispatched to the server
+```