@su-record/vibe 2.8.24 → 2.8.26

package/skills/parallel-research/experts/framework-docs.md

@@ -0,0 +1,65 @@
+# Expert Persona: Framework Documentation Specialist
+
+## Identity
+
+You are a **technical documentation expert** who has read the official docs and changelog for most major frameworks and libraries. You know how to find the canonical answer — not blog posts that may be outdated.
+
+## Objective
+
+Extract precise, version-specific information from official documentation. Provide the exact API, configuration options, and constraints the framework imposes.
+
+## Research Approach
+
+1. **Go to the official source first** — docs.framework.dev, GitHub README, or changelog
+2. **Check the current version** — note the version and whether it differs from LTS
+3. **Find the specific API** — not conceptual overviews; find the actual function signatures
+4. **Read the migration guides** — breaking changes between versions are often the root cause of bugs
+5. **Check "Gotchas" / "Pitfalls" sections** — framework authors document known sharp edges
+
+## Output Format
+
+```markdown
+## Framework Docs: {{FRAMEWORK}} — {{TOPIC}}
+
+### Current Version: {{VERSION}} (LTS: {{LTS_VERSION}})
+
+### Relevant API
+
+\`\`\`typescript
+// Exact signature from docs
+{{API_SIGNATURE}}
+\`\`\`
+
+### Configuration Options
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| {{OPTION}} | {{TYPE}} | {{DEFAULT}} | {{DESC}} |
+
+### Official Recommendation
+> [direct quote or close paraphrase from docs]
+
+### Known Limitations
+- [Limitation 1]
+- [Limitation 2]
+
+### Version Differences
+- v{{OLD}}: [old behavior]
+- v{{NEW}}: [new behavior / breaking change]
+
+### Source
+[URL to official docs page]
+```
+
+## Scope Boundaries
+
+- Do NOT summarize — extract exact API details
+- Flag when the question is about an undocumented internal API
+- Flag when docs conflict with observed community behavior
+- Note if the feature is experimental or unstable
+
+## Quality Signal
+
+A good framework docs finding:
+- Links directly to the official source
+- Specifies the exact version the information applies to
+- Includes the actual type signatures, not paraphrases

package/skills/parallel-research/experts/security-advisory.md

@@ -0,0 +1,69 @@
+# Expert Persona: Security Advisory Analyst
+
+## Identity
+
+You are a **security-focused engineer** who reviews features for vulnerabilities, data exposure risks, and compliance implications. You think like an attacker and a regulator simultaneously.
+
+## Objective
+
+Identify security risks, known CVEs, and compliance concerns related to the given feature or technology choice. Surface what must be handled, not just what could go wrong theoretically.
+
+## Research Approach
+
+1. **Search for known CVEs** — search `site:nvd.nist.gov` or `site:cve.mitre.org` for the library/pattern
+2. **Check OWASP Top 10 relevance** — which OWASP categories apply to this feature?
+3. **Look for supply chain risks** — check npm audit history, GitHub security advisories
+4. **Review authentication/authorization implications** — who can access what?
+5. **Check data handling** — PII exposure, logging of sensitive data, encryption at rest/transit
+
+## Output Format
+
+```markdown
+## Security Advisory: {{TOPIC}}
+
+### Risk Level: {{CRITICAL | HIGH | MEDIUM | LOW}}
+
+### Applicable OWASP Categories
+- [A01:2021 Broken Access Control] — [relevance]
+- [A03:2021 Injection] — [relevance]
+
+### Known CVEs / Advisories
+| CVE | Severity | Affected Versions | Description |
+|-----|----------|-------------------|-------------|
+| {{CVE_ID}} | {{SEVERITY}} | {{VERSIONS}} | {{DESCRIPTION}} |
+
+### Required Mitigations (must implement)
+1. [Mitigation 1] — prevents [attack vector]
+2. [Mitigation 2] — prevents [attack vector]
+
+### Recommended Mitigations (should implement)
+1. [Mitigation 1]
+
+### Data Handling Concerns
+- PII involved: {{YES/NO}} — [fields]
+- Encrypted at rest: {{REQUIRED/OPTIONAL}}
+- Logged (must NOT log): {{SENSITIVE_FIELDS}}
+
+### Compliance Implications
+- GDPR: [relevant article, if any]
+- HIPAA: [relevant rule, if any]
+- SOC 2: [relevant control, if any]
+
+### Sources
+- [Source 1]
+- [Source 2]
+```
+
+## Scope Boundaries
+
+- Flag issues that MUST be addressed before shipping (required mitigations)
+- Do not block on theoretical risks with no practical exploit path
+- Always distinguish between "must fix" and "should fix"
+- If no significant security concerns found, state this explicitly (do not invent risks)
+
+## Quality Signal
+
+A good security finding:
+- Links to the specific CVE or advisory (not generic warnings)
+- Specifies which exact version of the library is affected
+- Provides a concrete mitigation, not just "be careful with this"

package/skills/parallel-research/orchestrator.md

@@ -0,0 +1,65 @@
+---
+name: parallel-research-orchestrator
+type: orchestrator
+agents: [best-practices, framework-docs, codebase-patterns, security-advisory, synthesizer]
+---
+
+# Parallel Research Orchestrator
+
+## Workflow
+
+### Phase 1: Launch Research Agents
+- **Agent**: best-practices, framework-docs, codebase-patterns, security-advisory
+- **Input**: Research topic + technology context (stack, framework versions)
+- **Output**: Per-agent findings `{source, findings[], confidence}`
+- **Parallel**: yes — all 4 agents run simultaneously
+- **Timeout**: 60s per agent (agents that exceed timeout are marked `timed-out`)
+
+### Phase 2: Wait and Collect
+- **Agent**: orchestrator (self)
+- **Input**: Streams from all 4 agents
+- **Output**: Collected results map `{agentName: result | "timed-out"}`
+- **Parallel**: no — barrier synchronization point
+
+### Phase 3: Synthesize
+- **Agent**: synthesizer
+- **Input**: All collected results from Phase 2
+- **Output**: Merged, deduplicated findings with source attribution and conflict flags
+- **Parallel**: no — sequential merge and deduplication
+
+### Phase 4: Rank and Output
+- **Agent**: orchestrator (self)
+- **Input**: Synthesized findings from Phase 3
+- **Output**: Ranked recommendations ordered by confidence and relevance
+- **Parallel**: no
+
+## DAG (Dependency Graph)
+
+```mermaid
+graph TD
+    A[Phase 1a: best-practices] --> C[Phase 2: Collect]
+    B[Phase 1b: framework-docs] --> C
+    D[Phase 1c: codebase-patterns] --> C
+    E[Phase 1d: security-advisory] --> C
+    C --> F[Phase 3: Synthesizer]
+    F --> G[Phase 4: Ranked Output]
+```
+
+## Error Handling
+
+| Phase | Failure Mode | Strategy |
+|-------|-------------|----------|
+| Phase 1 | Agent times out (>60s) | Mark as `timed-out`, continue with remaining results |
+| Phase 1 | Agent returns empty results | Mark as `no-findings`, note in output |
+| Phase 1 | All 4 agents fail | Escalate — prompt user to retry or narrow topic |
+| Phase 2 | <2 agents return results | Warn user, proceed with partial synthesis |
+| Phase 3 | Conflicting recommendations | Flag conflict explicitly, present both sides |
+| Phase 4 | 0 actionable recommendations | Fallback — return raw findings without ranking |
+
+## Scalability Modes
+
+| Mode | When | Agents Used |
+|------|------|-------------|
+| Full | Normal operation | All 4 research agents + synthesizer |
+| Reduced | Time pressure | best-practices + codebase-patterns only |
+| Single | Quick lookup | codebase-patterns only — check existing patterns first |

package/skills/parallel-research/templates/synthesis.md

@@ -0,0 +1,101 @@
+# Research Synthesis: {{RESEARCH_TOPIC}}
+
+**Date**: {{DATE}}
+**Technology**: {{TECHNOLOGY_STACK}}
+**Question**: {{RESEARCH_QUESTION}}
+
+---
+
+## Executive Summary
+
+{{ONE_PARAGRAPH_SUMMARY}}
+
+**Recommended approach**: {{RECOMMENDATION}}
+
+---
+
+## Findings by Agent
+
+### 1. Best Practices
+
+{{BEST_PRACTICES_SUMMARY}}
+
+Key insight: {{BEST_PRACTICES_KEY_INSIGHT}}
+
+### 2. Framework Documentation
+
+{{FRAMEWORK_DOCS_SUMMARY}}
+
+Key constraint: {{FRAMEWORK_CONSTRAINT}}
+Relevant API: `{{RELEVANT_API}}`
+
+### 3. Codebase Patterns
+
+{{CODEBASE_PATTERNS_SUMMARY}}
+
+Follow this existing pattern: `{{PATTERN_FILE}}:{{PATTERN_LINE}}`
+
+### 4. Security Advisory
+
+Risk level: **{{RISK_LEVEL}}**
+
+{{SECURITY_SUMMARY}}
+
+Required mitigations: {{REQUIRED_MITIGATIONS_COUNT}}
+
+---
+
+## Conflicts and Resolutions
+
+| Conflict | Agent A says | Agent B says | Resolution |
+|----------|-------------|-------------|------------|
+| {{CONFLICT_1}} | {{A_POSITION}} | {{B_POSITION}} | {{RESOLUTION}} |
+
+---
+
+## Actionable Recommendations
+
+### Must Do (before implementation)
+1. {{MUST_DO_1}}
+2. {{MUST_DO_2}}
+
+### Should Do (best practice)
+1. {{SHOULD_DO_1}}
+2. {{SHOULD_DO_2}}
+
+### Avoid
+1. {{AVOID_1}} — reason: {{AVOID_REASON_1}}
+2. {{AVOID_2}} — reason: {{AVOID_REASON_2}}
+
+---
+
+## Impact on SPEC / Implementation Plan
+
+Add to SPEC Context section:
+
+```markdown
+## Context (from parallel research)
+
+- Best practice: {{SPEC_BEST_PRACTICE_NOTE}}
+- Framework constraint: {{SPEC_CONSTRAINT_NOTE}}
+- Security requirement: {{SPEC_SECURITY_NOTE}}
+- Existing pattern to follow: {{SPEC_PATTERN_NOTE}}
+```
+
+---
+
+## Unanswered Questions
+
+- [ ] {{OPEN_QUESTION_1}} — investigate before Phase {{PHASE}}
+- [ ] {{OPEN_QUESTION_2}} — can proceed without answer
+
+---
+
+## Sources
+
+| Agent | Source | Confidence |
+|-------|--------|-----------|
+| Best Practices | {{SOURCE_1}} | {{CONFIDENCE_1}} |
+| Framework Docs | {{SOURCE_2}} | {{CONFIDENCE_2}} |
+| Codebase | `{{SOURCE_3}}` | High |
+| Security | {{SOURCE_4}} | {{CONFIDENCE_4}} |

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

@@ -0,0 +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 |

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

@@ -0,0 +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}}

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

@@ -0,0 +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.

package/skills/priority-todos/templates/todo-board.md

@@ -0,0 +1,59 @@
+# TODO Board: {{PROJECT_OR_FEATURE_NAME}}
+
+**Updated**: {{DATE}}
+**Branch**: {{GIT_BRANCH}}
+**Total open**: {{TOTAL_OPEN}} | P1: {{P1_COUNT}} | P2: {{P2_COUNT}} | P3: {{P3_COUNT}}
+
+---
+
+## P1 — Blocks Merge ({{P1_COUNT}} open)
+
+> All P1 items must be resolved before this branch can be merged.
+
+| ID | Title | File:Line | Assigned | Status |
+|----|-------|-----------|----------|--------|
+| P1-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{ASSIGNEE_1}} | {{STATUS_1}} |
+| P1-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{ASSIGNEE_2}} | {{STATUS_2}} |
+
+{{#if P1_EMPTY}}
+_No P1 items. Merge is unblocked._
+{{/if}}
+
+---
+
+## P2 — Fix Before PR ({{P2_COUNT}} open)
+
+> P2 items should be resolved before PR review. Warning only — does not block merge.
+
+| ID | Title | File:Line | Assigned | Status |
+|----|-------|-----------|----------|--------|
+| P2-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{ASSIGNEE_1}} | {{STATUS_1}} |
+| P2-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{ASSIGNEE_2}} | {{STATUS_2}} |
+
+---
+
+## P3 — Backlog ({{P3_COUNT}} open)
+
+> P3 items do not block merge. Address during scheduled cleanup sessions.
+
+| ID | Title | File:Line | Notes |
+|----|-------|-----------|-------|
+| P3-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{NOTES_1}} |
+| P3-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{NOTES_2}} |
+
+---
+
+## Completed (archived)
+
+| ID | Title | Resolved | PR/Commit |
+|----|-------|----------|-----------|
+| {{DONE_ID_1}} | {{DONE_TITLE_1}} | {{DONE_DATE_1}} | {{DONE_REF_1}} |
+
+---
+
+## Merge Checklist
+
+- [ ] P1 count = 0
+- [ ] P2 items reviewed (resolved or documented)
+- [ ] index.md reflects current state
+- [ ] Completed items archived to `done/`