@tinkcarlos/skillora 0.2.0

package/.claude/skills/product-requirements/references/acceptance-criteria.md

@@ -0,0 +1,335 @@
+# Acceptance Criteria Guide
+
+Writing effective, testable acceptance criteria that leave no ambiguity.
+
+---
+
+## What are Acceptance Criteria?
+
+Acceptance Criteria (AC) are the conditions that must be met for a user story to be considered complete. They serve as:
+
+1. **Definition of Done** - Clear completion checklist
+2. **Test Cases** - Basis for QA testing
+3. **Contract** - Agreement between dev and product
+4. **Documentation** - Record of intended behavior
+
+---
+
+## Formats
+
+### 1. Checklist Format (Simple)
+
+Best for straightforward requirements:
+
+```markdown
+Acceptance Criteria:
+- [ ] User can enter email in the input field
+- [ ] Email validation shows error for invalid format
+- [ ] Submit button disabled until email is valid
+- [ ] Success message shown after submission
+- [ ] Email sent to user's inbox within 1 minute
+```
+
+### 2. Gherkin Format (BDD)
+
+Best for complex scenarios and automated testing:
+
+```gherkin
+Feature: User Login
+
+  Background:
+    Given the login page is displayed
+
+  @happy-path
+  Scenario: Successful login with valid credentials
+    When I enter "user@example.com" in the email field
+    And I enter "ValidP@ss123" in the password field
+    And I click the "Login" button
+    Then I should be redirected to the dashboard
+    And I should see "Welcome back, User" in the header
+
+  @validation
+  Scenario: Login fails with invalid email format
+    When I enter "invalid-email" in the email field
+    And I click outside the field
+    Then I should see "Please enter a valid email" error message
+    And the email field should have a red border
+
+  @security
+  Scenario: Account locked after 5 failed attempts
+    Given I have failed login 4 times
+    When I enter incorrect password again
+    Then I should see "Account locked. Try again in 15 minutes."
+    And the login form should be disabled
+```
+
+### 3. Rule Format (Specification)
+
+Best for business rules and constraints:
+
+```markdown
+## Rules
+
+**R1: Password Requirements**
+- Minimum 8 characters
+- At least 1 uppercase letter
+- At least 1 lowercase letter
+- At least 1 number
+- At least 1 special character (!@#$%^&*)
+- Cannot contain spaces
+- Cannot be same as last 5 passwords
+
+**R2: Session Management**
+- Session expires after 30 minutes of inactivity
+- "Remember me" extends session to 30 days
+- Concurrent sessions allowed: 3 max
+- New session invalidates oldest if limit exceeded
+```
+
+---
+
+## Writing Effective AC
+
+### The SMART Criteria
+
+| Criteria | Meaning | Example |
+|----------|---------|---------|
+| **S**pecific | Clear and unambiguous | "Show error message" → "Show 'Email is required' below the field" |
+| **M**easurable | Quantifiable where possible | "Fast loading" → "Page loads in <2 seconds" |
+| **A**chievable | Technically feasible | Confirm with dev team |
+| **R**elevant | Relates to user story value | Tied to user's goal |
+| **T**estable | Can be verified true/false | Can write test for it |
+
+### Templates for Common Scenarios
+
+#### Input Validation
+```markdown
+- [ ] [Field] is required / optional
+- [ ] [Field] accepts [type/format] (e.g., email, phone, URL)
+- [ ] [Field] has min length of [X] / max length of [Y]
+- [ ] [Field] shows "[error message]" when validation fails
+- [ ] [Field] validates on blur / on submit / in real-time
+- [ ] Invalid [field] has visual indicator (red border, error icon)
+```
+
+#### Button Actions
+```markdown
+- [ ] Button is visible and labeled "[Label]"
+- [ ] Button is enabled when [condition]
+- [ ] Button is disabled when [condition]
+- [ ] Clicking button triggers [action]
+- [ ] Button shows loading state during [action]
+- [ ] After success: [what happens]
+- [ ] After failure: [what happens]
+```
+
+#### Data Display
+```markdown
+- [ ] [Data] is displayed in [location]
+- [ ] [Data] updates when [trigger]
+- [ ] [Data] is formatted as [format] (date, currency, etc.)
+- [ ] Empty state shows "[message]" when no data
+- [ ] Loading state shows [skeleton/spinner] during fetch
+- [ ] Error state shows "[message]" with retry option
+```
+
+#### Navigation
+```markdown
+- [ ] [Link/Button] navigates to [destination]
+- [ ] Back button returns to [previous page]
+- [ ] Browser back button works correctly
+- [ ] URL reflects current state (bookmarkable)
+- [ ] Navigation shows loading indicator
+```
+
+#### Permission/Access
+```markdown
+- [ ] Feature is visible to [user role(s)]
+- [ ] Feature is hidden from [user role(s)]
+- [ ] Unauthorized access shows [error message]
+- [ ] Unauthenticated users redirected to login
+```
+
+---
+
+## Coverage Checklist
+
+Ensure AC covers all aspects:
+
+### Functional
+- [ ] Happy path (everything works)
+- [ ] Validation errors (user mistakes)
+- [ ] System errors (server failures)
+- [ ] Edge cases (empty, max, boundary)
+- [ ] Concurrent actions (if applicable)
+
+### UI/UX
+- [ ] All states (default, hover, focus, active, disabled, loading, error, success)
+- [ ] Responsive behavior (mobile, tablet, desktop)
+- [ ] Loading indicators
+- [ ] Success feedback
+- [ ] Error messages
+
+### Performance
+- [ ] Load time expectations
+- [ ] Data limits (pagination, max items)
+- [ ] Timeout handling
+
+### Security
+- [ ] Authentication requirements
+- [ ] Authorization checks
+- [ ] Input sanitization
+- [ ] Sensitive data handling
+
+### Accessibility
+- [ ] Keyboard navigation
+- [ ] Screen reader compatibility
+- [ ] Focus management
+
+---
+
+## Examples by Feature Type
+
+### Form Submission
+
+```gherkin
+Feature: Contact Form
+
+  Scenario: Successful form submission
+    Given I am on the contact page
+    When I fill in "Name" with "John Doe"
+    And I fill in "Email" with "john@example.com"
+    And I fill in "Message" with "Hello, I have a question."
+    And I click "Send Message"
+    Then I should see "Message sent successfully"
+    And the form should be cleared
+    And I should receive a confirmation email
+
+  Scenario: Form validation errors
+    Given I am on the contact page
+    When I click "Send Message" without filling the form
+    Then I should see "Name is required"
+    And I should see "Email is required"
+    And I should see "Message is required"
+    And the form should not be submitted
+
+  Scenario: Server error handling
+    Given I am on the contact page
+    And the server will return an error
+    When I submit a valid form
+    Then I should see "Something went wrong. Please try again."
+    And my input should be preserved
+    And I should see a "Retry" button
+```
+
+### Search Feature
+
+```gherkin
+Feature: Product Search
+
+  Scenario: Search returns results
+    Given I am on the products page
+    When I type "laptop" in the search box
+    And I press Enter
+    Then I should see products matching "laptop"
+    And results should show product image, name, and price
+    And I should see "[X] results found"
+
+  Scenario: Search with no results
+    Given I am on the products page
+    When I search for "xyznonexistent123"
+    Then I should see "No products found for 'xyznonexistent123'"
+    And I should see search suggestions
+    And I should see a "Clear search" button
+
+  Scenario: Search with filters
+    Given I have searched for "laptop"
+    When I filter by "Price: Low to High"
+    Then results should be sorted by price ascending
+    And the URL should update with filter params
+    And the filter should be visually selected
+
+  Scenario: Search performance
+    Given there are 10,000 products in the database
+    When I search for "laptop"
+    Then results should appear within 1 second
+    And results should be paginated (20 per page)
+```
+
+### Modal/Dialog
+
+```gherkin
+Feature: Delete Confirmation Modal
+
+  Scenario: Modal opens on delete click
+    Given I am viewing an item
+    When I click "Delete"
+    Then a confirmation modal should appear
+    And the modal should have "Delete Item" as the title
+    And the modal should ask "Are you sure you want to delete this item?"
+    And the modal should have "Cancel" and "Delete" buttons
+    And focus should be on the "Cancel" button
+
+  Scenario: Confirm delete
+    Given the delete confirmation modal is open
+    When I click "Delete"
+    Then the item should be deleted
+    And the modal should close
+    And I should see "Item deleted" toast
+    And the item should no longer appear in the list
+
+  Scenario: Cancel delete
+    Given the delete confirmation modal is open
+    When I click "Cancel"
+    Then the modal should close
+    And the item should not be deleted
+
+  Scenario: Close modal with Escape
+    Given the delete confirmation modal is open
+    When I press the Escape key
+    Then the modal should close
+    And the item should not be deleted
+
+  Scenario: Close modal by clicking outside
+    Given the delete confirmation modal is open
+    When I click outside the modal
+    Then the modal should close
+    And the item should not be deleted
+```
+
+---
+
+## Common Mistakes
+
+### Too Vague
+```
+❌ The form should work properly.
+❌ Error messages should be user-friendly.
+❌ The page should load fast.
+
+✅ The form should submit successfully with valid data.
+✅ Email validation error shows "Please enter a valid email address."
+✅ The page should be interactive within 2 seconds.
+```
+
+### Missing Negative Cases
+```
+❌ User can log in with email and password.
+
+✅ User can log in with valid email and password.
+✅ User sees error for invalid email format.
+✅ User sees error for incorrect password.
+✅ User is locked out after 5 failed attempts.
+```
+
+### Implementation Details
+```
+❌ Use React useState for form fields.
+❌ Store data in PostgreSQL.
+❌ Call POST /api/users endpoint.
+
+✅ User data is saved and persists across sessions.
+✅ User receives confirmation email within 1 minute.
+✅ Form data is validated before submission.
+```
+

package/.claude/skills/product-requirements/references/answer-first-questioning-protocol.md

@@ -0,0 +1,299 @@
+# 带答案提问协议 (Answer-First Questioning Protocol)
+
+> **核心原则**: 每个问题必须附带 AI 的推荐答案。无推荐的问题 = 无效问题。
+
+---
+
+## 🔴 为什么必须带答案提问？
+
+```
+❌ 无答案提问的问题:
+- 用户感觉 AI 不专业
+- 用户需要自己做所有决策
+- 沟通效率低下
+- 无法体现 AI 的领域知识价值
+
+✅ 带答案提问的优势:
+- 展示 AI 的专业能力
+- 用户只需确认/调整，效率高
+- 推荐有行业依据，可信度高
+- 即使用户不采纳，也提供了参考
+```
+
+---
+
+## 问题格式强制模板
+
+### 标准格式
+
+```markdown
+## 问题 [编号]: [具体问题]
+
+**AI 推荐**: [基于领域知识的推荐答案]
+
+**推荐理由**:
+- [理由1: 行业最佳实践/竞品分析/技术考量]
+- [理由2: ...]
+
+**备选方案**:
+- 方案 A: [描述] - 适用场景: [...]
+- 方案 B: [描述] - 适用场景: [...]
+
+**需要确认**: 是否采用推荐方案？如有其他考虑请说明。
+```
+
+### 示例 1: 功能范围问题
+
+```markdown
+## 问题 1: 用户认证方式选择
+
+**AI 推荐**: 采用 JWT + OAuth2.0 混合认证
+
+**推荐理由**:
+- 行业标准: 90%+ 的现代 Web 应用采用此方案
+- 安全性: JWT 无状态 + OAuth 第三方登录，兼顾安全和便利
+- 竞品分析: Notion、Figma、Linear 均采用类似方案
+
+**备选方案**:
+- 方案 A: 仅 Session 认证 - 适用场景: 简单内部系统，无第三方登录需求
+- 方案 B: 仅 OAuth - 适用场景: 完全依赖第三方身份提供商
+
+**需要确认**: 是否采用推荐的 JWT + OAuth2.0 方案？
+```
+
+### 示例 2: 技术选型问题
+
+```markdown
+## 问题 2: 前端状态管理方案
+
+**AI 推荐**: 采用 TanStack Query (React Query) + Zustand
+
+**推荐理由**:
+- 最新趋势: 2024 年 React 生态最流行的组合
+- 职责分离: TanStack Query 管理服务端状态，Zustand 管理客户端状态
+- 学习曲线: 比 Redux 更简单，团队上手快
+
+**备选方案**:
+- 方案 A: Redux Toolkit - 适用场景: 复杂状态逻辑，团队已熟悉 Redux
+- 方案 B: Jotai - 适用场景: 原子化状态管理，极简主义
+
+**需要确认**: 是否采用推荐的 TanStack Query + Zustand 方案？
+```
+
+### 示例 3: 业务规则问题
+
+```markdown
+## 问题 3: 订单取消策略
+
+**AI 推荐**: 采用分阶段取消策略
+
+**推荐理由**:
+- 行业实践: 电商平台普遍采用的策略
+- 用户体验: 给用户合理的取消窗口
+- 运营成本: 减少无效订单处理成本
+
+**推荐规则**:
+| 订单状态 | 取消策略 | 退款比例 |
+|----------|----------|----------|
+| 待支付 | 自由取消 | 100% |
+| 已支付未发货 | 自由取消 | 100% |
+| 已发货 | 需申请 | 扣除运费 |
+| 已签收 | 走售后流程 | 按售后政策 |
+
+**备选方案**:
+- 方案 A: 严格策略 - 支付后不可取消，仅走售后
+- 方案 B: 宽松策略 - 发货前均可自由取消
+
+**需要确认**: 是否采用推荐的分阶段取消策略？
+```
+
+---
+
+## 问题质量检查清单
+
+### 必须通过的检查
+
+| 检查项 | 要求 | 示例 |
+|--------|------|------|
+| 有推荐答案 | ✅ 必须 | "AI 推荐: ..." |
+| 有推荐理由 | ✅ 必须 | 至少 2 条理由 |
+| 理由有依据 | ✅ 必须 | 行业实践/竞品/技术 |
+| 有备选方案 | ✅ 必须 | 至少 1 个备选 |
+| 避免是/否问题 | ✅ 必须 | 开放式问题 |
+
+### 推荐理由来源
+
+| 来源类型 | 可信度 | 示例 |
+|----------|--------|------|
+| 行业标准 | ⭐⭐⭐⭐⭐ | "PCI DSS 要求..." |
+| 官方文档 | ⭐⭐⭐⭐⭐ | "React 官方推荐..." |
+| 竞品分析 | ⭐⭐⭐⭐ | "Notion/Figma 采用..." |
+| 行业报告 | ⭐⭐⭐⭐ | "Gartner 报告显示..." |
+| 技术考量 | ⭐⭐⭐ | "从性能角度..." |
+| AI 推断 | ⭐⭐ | 必须标注 "[AI 推断]" |
+
+---
+
+## 问题分类与模板
+
+### 1. 功能范围类
+
+```markdown
+## 问题: [功能] 是否需要包含 [子功能]？
+
+**AI 推荐**: [包含/不包含]
+
+**推荐理由**:
+- [MVP 考量/用户需求/竞品对比]
+
+**如果包含**:
+- 预计工作量: [...]
+- 依赖项: [...]
+
+**如果不包含**:
+- 可在后续版本添加
+- 替代方案: [...]
+```
+
+### 2. 技术选型类
+
+```markdown
+## 问题: [技术领域] 采用什么方案？
+
+**AI 推荐**: [具体技术/框架]
+
+**推荐理由**:
+- 技术成熟度: [...]
+- 社区支持: [...]
+- 团队熟悉度: [...]
+
+**备选方案对比**:
+| 方案 | 优点 | 缺点 | 适用场景 |
+|------|------|------|----------|
+| [方案A] | [...] | [...] | [...] |
+| [方案B] | [...] | [...] | [...] |
+```
+
+### 3. 业务规则类
+
+```markdown
+## 问题: [业务场景] 的处理规则？
+
+**AI 推荐**: [具体规则]
+
+**推荐理由**:
+- 行业惯例: [...]
+- 用户体验: [...]
+- 运营成本: [...]
+
+**规则详情**:
+| 条件 | 处理方式 |
+|------|----------|
+| [条件1] | [处理1] |
+| [条件2] | [处理2] |
+```
+
+### 4. 优先级类
+
+```markdown
+## 问题: [功能列表] 的优先级排序？
+
+**AI 推荐**: 按以下优先级排序
+
+**推荐排序** (RICE 评分):
+| 功能 | Reach | Impact | Confidence | Effort | Score | 优先级 |
+|------|-------|--------|------------|--------|-------|--------|
+| [功能1] | [...] | [...] | [...] | [...] | [...] | P0 |
+| [功能2] | [...] | [...] | [...] | [...] | [...] | P1 |
+
+**推荐理由**:
+- [功能1] 优先因为: [...]
+- [功能2] 次之因为: [...]
+```
+
+---
+
+## 问题组织策略
+
+### 问题分组
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│  问题分组策略                                                    │
+├─────────────────────────────────────────────────────────────────┤
+│                                                                  │
+│  Group 1: 核心功能确认 (必须先确认)                             │
+│  ├─ 问题 1: 核心功能范围                                        │
+│  ├─ 问题 2: 目标用户确认                                        │
+│  └─ 问题 3: 成功指标定义                                        │
+│                                                                  │
+│  Group 2: 技术方案确认 (核心功能确认后)                         │
+│  ├─ 问题 4: 技术栈选择                                          │
+│  ├─ 问题 5: 架构方案                                            │
+│  └─ 问题 6: 集成方案                                            │
+│                                                                  │
+│  Group 3: 细节确认 (技术方案确认后)                             │
+│  ├─ 问题 7: 业务规则细节                                        │
+│  ├─ 问题 8: 边界情况处理                                        │
+│  └─ 问题 9: 非功能需求                                          │
+│                                                                  │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### 问题数量控制
+
+| 需求复杂度 | 建议问题数 | 说明 |
+|------------|------------|------|
+| 简单 | 3-5 个 | 小功能/优化 |
+| 中等 | 5-10 个 | 中型功能 |
+| 复杂 | 10-15 个 | 大型功能/新产品 |
+
+**原则**: 问题越少越好，但必须覆盖关键决策点。
+
+---
+
+## 用户回复处理
+
+### 用户采纳推荐
+
+```markdown
+✅ 用户确认: 采用推荐方案
+
+**记录**:
+- 问题 X: 采用 AI 推荐的 [方案]
+- 确认时间: [时间]
+```
+
+### 用户选择备选
+
+```markdown
+✅ 用户选择: 备选方案 [X]
+
+**记录**:
+- 问题 X: 采用备选方案 [X]
+- 用户理由: [用户说明的理由]
+- 确认时间: [时间]
+```
+
+### 用户提出新方案
+
+```markdown
+✅ 用户提出: 新方案
+
+**记录**:
+- 问题 X: 采用用户提出的 [新方案]
+- 方案详情: [用户描述]
+- AI 评估: [对新方案的简要评估]
+- 确认时间: [时间]
+```
+
+---
+
+## 违规处理
+
+| 违规 | 后果 | 处理 |
+|------|------|------|
+| 问题无推荐 | 问题无效 | 必须添加推荐后再提问 |
+| 推荐无理由 | 可信度低 | 必须补充理由 |
+| 理由无依据 | 专业性不足 | 必须标注依据来源 |
+| 是/否问题 | 信息不足 | 改为开放式问题 |