@su-record/vibe 2.9.32 → 2.9.33

package/skills/prioritization-frameworks/rubrics/frameworks.md

@@ -1,79 +1,79 @@
-# Prioritization Frameworks Rubric
-
-## RICE
-
-**Formula**: `(Reach × Impact × Confidence) / Effort`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Reach | Users/month (absolute) | 5,000 users |
-| Impact | Opportunity Score 0.0–1.0 | 0.7 |
-| Confidence | 0–100% | 80% = 0.8 |
-| Effort | Person-months | 2 |
-
-**Example**: `(5000 × 0.7 × 0.8) / 2 = 1400` — higher score = prioritize first.
-
-**When to use**: Large teams with data. Separates audience size (Reach) from value per user (Impact).
-
-**Watch out for**: Effort estimates are often optimistic — apply a 1.5x buffer.
-
----
-
-## ICE
-
-**Formula**: `Impact × Confidence × Ease`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Impact | 1–10 (or Opportunity Score × Users) | 8 |
-| Confidence | 1–10 | 7 |
-| Ease | 1–10 (inverse of effort) | 5 |
-
-**Example**: `8 × 7 × 5 = 280` — higher score = prioritize first.
-
-**When to use**: Quick ranking of ideas/initiatives. Faster than RICE, good for early-stage decisions.
-
-**Watch out for**: "Ease" is subjective — calibrate across team before scoring.
-
----
-
-## MoSCoW
-
-**Categories**:
-
-| Category | Meaning | Guideline |
-|----------|---------|-----------|
-| **Must** | Cannot launch without | Max 60% of scope |
-| **Should** | High value, not critical | Next priority after Must |
-| **Could** | Nice to have | Include only if capacity allows |
-| **Won't** | Explicitly deferred | Documents what is NOT in scope |
-
-**When to use**: Scoping a release. Good for stakeholder alignment conversations.
-
-**Watch out for**: Stakeholders inflate "Must" — challenge each Must with "What happens if we skip this for V1?". MoSCoW is a scoping tool, not a discovery tool.
-
----
-
-## Opportunity Score
-
-**Formula**: `Importance × (1 − Satisfaction)` (normalize both to 0–1 scale)
-
-**Example**:
-- Importance: 0.9, Satisfaction: 0.3 → Score: `0.9 × 0.7 = 0.63` (high opportunity)
-- Importance: 0.9, Satisfaction: 0.9 → Score: `0.9 × 0.1 = 0.09` (already solved)
-
-**When to use**: Prioritizing customer problems before deciding on solutions. Prevents building features customers already find satisfactory.
-
-**Watch out for**: Survey sample must be representative. Low sample size inflates confidence.
-
----
-
-## Choosing the Right Framework
-
-| Situation | Recommended Framework |
-|-----------|----------------------|
-| "Which customer problems matter most?" | Opportunity Score |
-| "Which features should we build this sprint?" | ICE |
-| "How do we rank initiatives across a large team?" | RICE |
-| "What goes into V1 vs. later?" | MoSCoW |
-| "Stakeholders disagree on priorities?" | Weighted Decision Matrix |
+# Prioritization Frameworks Rubric
+
+## RICE
+
+**Formula**: `(Reach × Impact × Confidence) / Effort`
+
+| Factor | Scale | Example |
+|--------|-------|---------|
+| Reach | Users/month (absolute) | 5,000 users |
+| Impact | Opportunity Score 0.0–1.0 | 0.7 |
+| Confidence | 0–100% | 80% = 0.8 |
+| Effort | Person-months | 2 |
+
+**Example**: `(5000 × 0.7 × 0.8) / 2 = 1400` — higher score = prioritize first.
+
+**When to use**: Large teams with data. Separates audience size (Reach) from value per user (Impact).
+
+**Watch out for**: Effort estimates are often optimistic — apply a 1.5x buffer.
+
+---
+
+## ICE
+
+**Formula**: `Impact × Confidence × Ease`
+
+| Factor | Scale | Example |
+|--------|-------|---------|
+| Impact | 1–10 (or Opportunity Score × Users) | 8 |
+| Confidence | 1–10 | 7 |
+| Ease | 1–10 (inverse of effort) | 5 |
+
+**Example**: `8 × 7 × 5 = 280` — higher score = prioritize first.
+
+**When to use**: Quick ranking of ideas/initiatives. Faster than RICE, good for early-stage decisions.
+
+**Watch out for**: "Ease" is subjective — calibrate across team before scoring.
+
+---
+
+## MoSCoW
+
+**Categories**:
+
+| Category | Meaning | Guideline |
+|----------|---------|-----------|
+| **Must** | Cannot launch without | Max 60% of scope |
+| **Should** | High value, not critical | Next priority after Must |
+| **Could** | Nice to have | Include only if capacity allows |
+| **Won't** | Explicitly deferred | Documents what is NOT in scope |
+
+**When to use**: Scoping a release. Good for stakeholder alignment conversations.
+
+**Watch out for**: Stakeholders inflate "Must" — challenge each Must with "What happens if we skip this for V1?". MoSCoW is a scoping tool, not a discovery tool.
+
+---
+
+## Opportunity Score
+
+**Formula**: `Importance × (1 − Satisfaction)` (normalize both to 0–1 scale)
+
+**Example**:
+- Importance: 0.9, Satisfaction: 0.3 → Score: `0.9 × 0.7 = 0.63` (high opportunity)
+- Importance: 0.9, Satisfaction: 0.9 → Score: `0.9 × 0.1 = 0.09` (already solved)
+
+**When to use**: Prioritizing customer problems before deciding on solutions. Prevents building features customers already find satisfactory.
+
+**Watch out for**: Survey sample must be representative. Low sample size inflates confidence.
+
+---
+
+## Choosing the Right Framework
+
+| Situation | Recommended Framework |
+|-----------|----------------------|
+| "Which customer problems matter most?" | Opportunity Score |
+| "Which features should we build this sprint?" | ICE |
+| "How do we rank initiatives across a large team?" | RICE |
+| "What goes into V1 vs. later?" | MoSCoW |
+| "Stakeholders disagree on priorities?" | Weighted Decision Matrix |

package/skills/prioritization-frameworks/templates/scoring-matrix.md

@@ -1,69 +1,69 @@
-# Prioritization Scoring Matrix Template
-
-## Project / Sprint: {{PROJECT_OR_SPRINT_NAME}}
-
-**Framework selected**: {{FRAMEWORK}} (RICE / ICE / MoSCoW / Opportunity Score)
-**Date**: {{DATE}}
-**Scored by**: {{SCORER_NAMES}}
-
----
-
-## RICE Scoring Matrix
-
-| Item | Reach (users/mo) | Impact (0–1) | Confidence (%) | Effort (person-mo) | RICE Score | Priority |
-|------|-----------------|--------------|----------------|--------------------|------------|----------|
-| {{ITEM_1}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-| {{ITEM_2}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-| {{ITEM_3}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-
----
-
-## ICE Scoring Matrix
-
-| Item | Impact (1–10) | Confidence (1–10) | Ease (1–10) | ICE Score | Priority |
-|------|---------------|-------------------|-------------|-----------|----------|
-| {{ITEM_1}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-| {{ITEM_2}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-| {{ITEM_3}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-
----
-
-## MoSCoW Categorization
-
-| Item | Category | Rationale | Owner |
-|------|----------|-----------|-------|
-| {{ITEM_1}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-| {{ITEM_2}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-| {{ITEM_3}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-
-**Must count**: {{X}} / {{TOTAL}} — keep Must ≤ 60% of total scope.
-
----
-
-## Opportunity Score Matrix
-
-| Customer Need | Importance (0–1) | Satisfaction (0–1) | Opportunity Score | Action |
-|--------------|------------------|---------------------|-------------------|--------|
-| {{NEED_1}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-| {{NEED_2}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-| {{NEED_3}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-
-Score > 0.5 = strong opportunity. Score < 0.1 = already solved.
-
----
-
-## Final Ranked Backlog
-
-| Rank | Item | Framework Score | Decision | Notes |
-|------|------|-----------------|----------|-------|
-| 1 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-| 2 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-| 3 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-
----
-
-## Scoring Notes
-
-- {{ASSUMPTION_OR_CAVEAT_1}}
-- {{ASSUMPTION_OR_CAVEAT_2}}
-- Next review date: {{REVIEW_DATE}}
+# Prioritization Scoring Matrix Template
+
+## Project / Sprint: {{PROJECT_OR_SPRINT_NAME}}
+
+**Framework selected**: {{FRAMEWORK}} (RICE / ICE / MoSCoW / Opportunity Score)
+**Date**: {{DATE}}
+**Scored by**: {{SCORER_NAMES}}
+
+---
+
+## RICE Scoring Matrix
+
+| Item | Reach (users/mo) | Impact (0–1) | Confidence (%) | Effort (person-mo) | RICE Score | Priority |
+|------|-----------------|--------------|----------------|--------------------|------------|----------|
+| {{ITEM_1}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
+| {{ITEM_2}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
+| {{ITEM_3}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
+
+---
+
+## ICE Scoring Matrix
+
+| Item | Impact (1–10) | Confidence (1–10) | Ease (1–10) | ICE Score | Priority |
+|------|---------------|-------------------|-------------|-----------|----------|
+| {{ITEM_1}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
+| {{ITEM_2}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
+| {{ITEM_3}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
+
+---
+
+## MoSCoW Categorization
+
+| Item | Category | Rationale | Owner |
+|------|----------|-----------|-------|
+| {{ITEM_1}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
+| {{ITEM_2}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
+| {{ITEM_3}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
+
+**Must count**: {{X}} / {{TOTAL}} — keep Must ≤ 60% of total scope.
+
+---
+
+## Opportunity Score Matrix
+
+| Customer Need | Importance (0–1) | Satisfaction (0–1) | Opportunity Score | Action |
+|--------------|------------------|---------------------|-------------------|--------|
+| {{NEED_1}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
+| {{NEED_2}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
+| {{NEED_3}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
+
+Score > 0.5 = strong opportunity. Score < 0.1 = already solved.
+
+---
+
+## Final Ranked Backlog
+
+| Rank | Item | Framework Score | Decision | Notes |
+|------|------|-----------------|----------|-------|
+| 1 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
+| 2 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
+| 3 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
+
+---
+
+## Scoring Notes
+
+- {{ASSUMPTION_OR_CAVEAT_1}}
+- {{ASSUMPTION_OR_CAVEAT_2}}
+- Next review date: {{REVIEW_DATE}}

package/skills/priority-todos/SKILL.md

@@ -1,64 +1,64 @@
----
-name: priority-todos
-tier: standard
-description: "Priority-based TODO management (P1/P2/P3). Auto-activates when managing tasks, reviewing issues, or organizing work by priority."
-triggers: [todo, priority, P1, P2, P3, task management, issue, organize]
-priority: 60
----
-
-# Priority-Based Todo Management
-
-## Pre-check (K1)
-
-> Do you need structured priority tracking? For 1-2 item task lists, use inline TODOs. This system is for multi-issue tracking across reviews and sessions.
-
-## Priority Definitions
-
-| Priority | Meaning | Action | Examples |
-|----------|---------|--------|----------|
-| P1 | **Blocks merge** | Fix immediately | Security vulnerability, data loss risk, production incident |
-| P2 | **Should fix** | Fix before PR | Performance issue, missing tests, architecture violation |
-| P3 | **Backlog** | Fix when time permits | Code style, refactoring suggestion, documentation |
-
-## Directory Structure
-
-```
-.claude/vibe/todos/
-├── P1-security-sql-injection.md
-├── P2-perf-n1-query.md
-├── P3-style-extract-helper.md
-├── index.md                      # Summary table with counts/status
-└── done/                         # Archived completed items
-```
-
-## Workflow
-
-```
-vibe.review (skill) → Creates P1/P2/P3 todo files + updates index.md
-     ↓
-Fix P1 first (blocks merge)
-     ↓
-Fix P2 before PR (warning only)
-     ↓
-P3 → backlog (weekly review)
-     ↓
-Mark done → moves to done/ with date prefix
-```
-
-## Todo File Format
-
-Each file follows: `# [P1] Title` → Summary → Priority Justification → Location (file:line) → Suggested Fix → Checklist (fix, test, review, merge).
-
-## Rules
-
-- P1 exists → merge is **blocked**
-- P2 → warning only, recommended to resolve
-- P3 → no blocking, backlog
-- Weekly cleanup: review and archive completed items
-
-## Done Criteria (K4)
-
-- [ ] All P1 items resolved before merge
-- [ ] P2 items reviewed and either resolved or documented
-- [ ] index.md reflects current state
-- [ ] Completed items archived to `done/` directory
+---
+name: priority-todos
+tier: standard
+description: "Priority-based TODO management (P1/P2/P3). Auto-activates when managing tasks, reviewing issues, or organizing work by priority."
+triggers: [todo, priority, P1, P2, P3, task management, issue, organize]
+priority: 60
+---
+
+# Priority-Based Todo Management
+
+## Pre-check (K1)
+
+> Do you need structured priority tracking? For 1-2 item task lists, use inline TODOs. This system is for multi-issue tracking across reviews and sessions.
+
+## Priority Definitions
+
+| Priority | Meaning | Action | Examples |
+|----------|---------|--------|----------|
+| P1 | **Blocks merge** | Fix immediately | Security vulnerability, data loss risk, production incident |
+| P2 | **Should fix** | Fix before PR | Performance issue, missing tests, architecture violation |
+| P3 | **Backlog** | Fix when time permits | Code style, refactoring suggestion, documentation |
+
+## Directory Structure
+
+```
+.claude/vibe/todos/
+├── P1-security-sql-injection.md
+├── P2-perf-n1-query.md
+├── P3-style-extract-helper.md
+├── index.md                      # Summary table with counts/status
+└── done/                         # Archived completed items
+```
+
+## Workflow
+
+```
+vibe.review (skill) → Creates P1/P2/P3 todo files + updates index.md
+     ↓
+Fix P1 first (blocks merge)
+     ↓
+Fix P2 before PR (warning only)
+     ↓
+P3 → backlog (weekly review)
+     ↓
+Mark done → moves to done/ with date prefix
+```
+
+## Todo File Format
+
+Each file follows: `# [P1] Title` → Summary → Priority Justification → Location (file:line) → Suggested Fix → Checklist (fix, test, review, merge).
+
+## Rules
+
+- P1 exists → merge is **blocked**
+- P2 → warning only, recommended to resolve
+- P3 → no blocking, backlog
+- Weekly cleanup: review and archive completed items
+
+## Done Criteria (K4)
+
+- [ ] All P1 items resolved before merge
+- [ ] P2 items reviewed and either resolved or documented
+- [ ] index.md reflects current state
+- [ ] Completed items archived to `done/` directory

package/skills/priority-todos/rubrics/prioritization.md

@@ -1,70 +1,70 @@
-# TODO Prioritization Rubric
-
-Use these criteria to assign P1, P2, or P3 to any TODO item.
-
-## P1 — Blocks Merge
-
-Assign P1 when ANY of the following is true:
-
-| Criterion | Example |
-|-----------|---------|
-| Security vulnerability | SQL injection, XSS, unprotected endpoint, leaked secret |
-| Data loss or corruption risk | Missing transaction, overwrite without backup |
-| Type safety bypass | `: any`, `as any`, `@ts-ignore` hiding a real error |
-| Production breakage | Throws uncaught exception on valid input |
-| Broken CI/test | Failing test committed (not pre-existing) |
-| Missing auth/authz check | Unauthenticated access to protected resource |
-| Regulatory non-compliance | GDPR PII without consent, HIPAA violation |
-
-**Decision rule**: Would this cause an incident if it shipped? → P1
-
----
-
-## P2 — Fix Before PR
-
-Assign P2 when ANY of the following is true AND it is not P1:
-
-| Criterion | Example |
-|-----------|---------|
-| Performance regression | O(n²) loop, N+1 query, synchronous blocking call |
-| Missing test coverage | New feature with no tests |
-| Architecture violation | Layer boundary crossed (service imports UI) |
-| `console.log` in committed code | Debug output in production path |
-| Function > 50 lines | Complexity limit exceeded |
-| Nesting depth > 4 | Readability and test difficulty |
-| Duplicate logic across 2+ files | Maintenance hazard; divergence risk |
-| TODO/FIXME without tracking ticket | Ambiguous ownership |
-
-**Decision rule**: Would a reviewer request changes on this in a PR review? → P2
-
----
-
-## P3 — Backlog
-
-Assign P3 when the issue is real but has no immediate consequence:
-
-| Criterion | Example |
-|-----------|---------|
-| Style inconsistency | Different quote styles, inconsistent naming |
-| Magic numbers with low risk | Timeout values, display constants |
-| Commented-out code | Dead code left behind |
-| Missing JSDoc on internal helpers | Not public API |
-| File nearing complexity limit | 150–200 lines, not there yet |
-| Refactoring opportunity | Could be cleaner but works correctly |
-
-**Decision rule**: Could this be deferred a week without risk? → P3
-
----
-
-## Upgrade / Downgrade Rules
-
-| Situation | Action |
-|-----------|--------|
-| P3 item appears in 3+ files | Upgrade to P2 (systemic issue) |
-| P2 item has no fix path identified | Keep P2, add a note |
-| P1 item is in dead code (never executed) | Downgrade to P2 with justification |
-| P2 item found in P1 audit | Upgrade to P1 if it compounds the P1 issue |
-
-## When Uncertain
-
-Default to the higher priority. It is cheaper to over-prioritize than to ship a P1 labeled as P3.
+# TODO Prioritization Rubric
+
+Use these criteria to assign P1, P2, or P3 to any TODO item.
+
+## P1 — Blocks Merge
+
+Assign P1 when ANY of the following is true:
+
+| Criterion | Example |
+|-----------|---------|
+| Security vulnerability | SQL injection, XSS, unprotected endpoint, leaked secret |
+| Data loss or corruption risk | Missing transaction, overwrite without backup |
+| Type safety bypass | `: any`, `as any`, `@ts-ignore` hiding a real error |
+| Production breakage | Throws uncaught exception on valid input |
+| Broken CI/test | Failing test committed (not pre-existing) |
+| Missing auth/authz check | Unauthenticated access to protected resource |
+| Regulatory non-compliance | GDPR PII without consent, HIPAA violation |
+
+**Decision rule**: Would this cause an incident if it shipped? → P1
+
+---
+
+## P2 — Fix Before PR
+
+Assign P2 when ANY of the following is true AND it is not P1:
+
+| Criterion | Example |
+|-----------|---------|
+| Performance regression | O(n²) loop, N+1 query, synchronous blocking call |
+| Missing test coverage | New feature with no tests |
+| Architecture violation | Layer boundary crossed (service imports UI) |
+| `console.log` in committed code | Debug output in production path |
+| Function > 50 lines | Complexity limit exceeded |
+| Nesting depth > 4 | Readability and test difficulty |
+| Duplicate logic across 2+ files | Maintenance hazard; divergence risk |
+| TODO/FIXME without tracking ticket | Ambiguous ownership |
+
+**Decision rule**: Would a reviewer request changes on this in a PR review? → P2
+
+---
+
+## P3 — Backlog
+
+Assign P3 when the issue is real but has no immediate consequence:
+
+| Criterion | Example |
+|-----------|---------|
+| Style inconsistency | Different quote styles, inconsistent naming |
+| Magic numbers with low risk | Timeout values, display constants |
+| Commented-out code | Dead code left behind |
+| Missing JSDoc on internal helpers | Not public API |
+| File nearing complexity limit | 150–200 lines, not there yet |
+| Refactoring opportunity | Could be cleaner but works correctly |
+
+**Decision rule**: Could this be deferred a week without risk? → P3
+
+---
+
+## Upgrade / Downgrade Rules
+
+| Situation | Action |
+|-----------|--------|
+| P3 item appears in 3+ files | Upgrade to P2 (systemic issue) |
+| P2 item has no fix path identified | Keep P2, add a note |
+| P1 item is in dead code (never executed) | Downgrade to P2 with justification |
+| P2 item found in P1 audit | Upgrade to P1 if it compounds the P1 issue |
+
+## When Uncertain
+
+Default to the higher priority. It is cheaper to over-prioritize than to ship a P1 labeled as P3.