Vibeguard

VibeGuard

Lightweight VibeGuard for everyday use inside Spellbook.

This skill helps with three moments where AI-assisted work usually drifts:

• before implementation starts
• while review findings are being prioritized
• after regressions or avoidable mistakes happen

What This Skill Includes

• A task contract checklist for scoping work before coding
• A scoring matrix for prioritizing findings with evidence
• A weekly review template for regression and guardrail retrospectives

Hard Boundaries

This skill is intentionally lightweight.

It does:

• guide task kickoff
• structure review output
• make risk tradeoffs explicit

It does not:

• install hooks
• run guard scripts automatically
• patch global Claude or Codex configuration
• claim that full VibeGuard enforcement is active

If the user asks for automated interception, repo-level rules, or environment setup, escalate to the full VibeGuard repository and tooling.

When To Use It

Trigger this skill when the user asks for:

• anti-hallucination guardrails
• task startup checks
• review scoring or triage
• regression prevention
• retrospective templates
• "vibeguard" by name

Workflow

1. Start With The Task Contract

Open `references/task-contract.yaml` and confirm:

• goal
• source of truth
• acceptance criteria
• scope

Do not move into implementation until these are concrete.

2. Score Findings Before Acting

Open `references/scoring-matrix.md` and score each finding on:

• impact
• effort
• risk
• confidence

Use the score to separate urgent fixes from weak guesses.

3. Pick The Right Delivery Mode

• 1-2 files: implement directly once the contract is clear
• 3-5 files: write a short spec or step plan first
• 6+ files: produce a full design/spec and staged execution plan

4. Review The Failure, Not Just The Symptom

If something regressed, identify which defense failed:

• scope control
• source-of-truth validation
• verification depth
• review prioritization
• missing guardrail

Then capture the follow-up in `references/review-template.md`.

Expected Outputs

Depending on the request, produce one of these:

• a filled task contract
• a scored findings table with priorities
• a short regression review or weekly retrospective

Reference Files

• `references/task-contract.yaml` - kickoff checklist
• `references/scoring-matrix.md` - prioritization model
• `references/review-template.md` - retrospective template

Hallucination Risk Review

Use this template for a weekly review or after an avoidable regression.

Incident Summary

Which Defense Failed?

Evidence

Prevention Actions

• [ ] Add or strengthen a guardrail
• [ ] Add a missing verification step
• [ ] Tighten scope language for similar tasks
• [ ] Update a reusable skill, checklist, or template

Metrics

Next Week Focus

• [ ]
• [ ]
• [ ]

Risk Scoring Matrix

Use this matrix to prioritize findings before implementation.

Dimensions

Score each finding from 1 to 5.

Impact

• 1: cosmetic or low-value cleanup
• 2: readability or minor developer-experience improvement
• 3: meaningful maintainability or correctness improvement
• 4: affects core behavior, data quality, or reliability
• 5: severe defect, major regression risk, or architecture-level issue

Effort

• 1: tiny localized edit
• 2: small change across a few files
• 3: medium cross-module change
• 4: large refactor or migration
• 5: broad, high-cost system change

Risk

• 1: very unlikely to regress
• 2: limited blast radius
• 3: requires targeted verification
• 4: touches critical paths or contracts
• 5: highly sensitive, compatibility-heavy, or hard to roll back

Confidence

• 1: weak intuition only
• 2: indirect evidence
• 3: partial path or symptom evidence
• 4: strong code, test, or log evidence
• 5: fully traced and reproducible

Formula

priority_score = (impact * confidence) - (effort + risk)

Higher scores should be handled earlier.

Priority Bands

Gating Rules

1. High-risk findings do not become P0 without strong evidence. 2. Low-confidence findings stay out of execution plans. 3. Re-score the backlog after major architectural changes. 4. If a fix is risky, add verification before widening scope.

Template

| id | finding | impact | effort | risk | confidence | score | priority |
|----|---------|--------|--------|------|------------|-------|----------|
| F1 | ...     | 5      | 2      | 2    | 5          | 21    | P0       |
| F2 | ...     | 3      | 3      | 3    | 4          | 6     | P1       |