/bvssh-check

name: bvssh-check
description: "Use to evaluate whether current work aligns with Better Value Sooner Safer Happier. Run at diamond completion and periodically."
metadata:
  instruction_budget: "50"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

BVSSH Check Skill

Evaluate alignment with Better Value Sooner Safer Happier.

Workflow

For each dimension, assess current state:

Better

• [ ] Quality improving or stable (not degrading)?
• [ ] Technical debt under control (not growing unchecked)?
• [ ] User satisfaction metrics stable or improving?
• [ ] Defect rate stable or declining?
• Evidence: [cite specific metrics or observations]

Value

• [ ] Delivering measurable user or business outcomes?
• [ ] Outcome metrics moving (not just output metrics)?
• [ ] Work aligned with strategic priorities?
• [ ] Not shipping features nobody uses?
• Evidence: [cite specific metrics or observations]

Sooner

• [ ] Lead time stable or decreasing?
• [ ] Batch sizes small?
• [ ] WIP limits respected?
• [ ] Handoffs minimized?
• [ ] No unnecessary waiting or queuing?
• Evidence: [cite specific metrics or observations]

Safer

• [ ] Security posture maintained or improved?
• [ ] Compliance requirements met?
• [ ] Risk being actively managed (not ignored)?
• [ ] Rollback capability tested?
• [ ] No new single points of failure?
• [ ] Error budget healthy? (SRE -- check dora-metrics.yml sre section)
• Evidence: [cite specific metrics or observations]

Happier

Smart's Happier covers four stakeholders: **customers, colleagues, citizens, and climate**. "Not 'more for less' at any human or climatic cost."

**Colleagues:**

• [ ] Team working at sustainable pace? No chronic overtime? (XP -- Beck)
• [ ] AI tools helping or adding cognitive load? (APEX DevX)
• [ ] No signs of burnout?
• [ ] Team has autonomy and purpose?
• [ ] Learning happening continuously?

**Customers:**

• [ ] Users expressing satisfaction?
• [ ] Customer advocacy high? (Not just retained — actively recommending?)

**Citizens:**

• [ ] Positive societal impact? (Open knowledge sharing, accessibility, inclusivity)
• [ ] No harm to communities or vulnerable groups?

**Climate:**

• [ ] Compute/token usage proportionate to value delivered? (Not brute-forcing with retries)
• [ ] Waste prevented? (Projects killed before unnecessary code, discovery before delivery)
• [ ] Sustainable resource usage patterns?

• Evidence: [cite specific metrics or observations]

CALMS Culture Assessment (Willis & Humble)

*CALMS originated as CAMS (Culture, Automation, Measurement, Sharing) coined by Damon Edwards and John Willis at DevOpsDays Mountainview 2010. Jez Humble added the L (Lean) to create CALMS.*

Assess the five cultural dimensions that explain WHY DORA outcomes are what they are:

• [ ] **Culture**: Is there a learning culture? Blameless post-mortems? Psychological safety? Or blame-and-fear?
• [ ] **Automation**: Are repetitive tasks automated (testing, deployment, provisioning)? Or manual and error-prone?
• [ ] **Lean**: Are batch sizes small? WIP limited? Waste actively identified and removed? Or big-batch waterfall?
• [ ] **Measurement**: Are you measuring outcomes (DORA, BVSSH) or outputs (velocity, story points)? Watch for MORF anti-pattern.
• [ ] **Sharing**: Is knowledge shared across teams? Cross-functional collaboration? Or siloed expertise?
• Evidence: [cite specific observations or team feedback]

**Automation — cite a measurement, not an impression.** The four fitness functions emit machine-readable counts, so the Automation rating can rest on evidence rather than narrative:

python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_wiring.py" --root .
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_wiring_contract.py" --root .
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_negative_control.py" --root .
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check_test_authenticity.py" --root .

Record under `calms_assessment.automation`:

wiring_integrity:
  unwired_mechanisms: 0       # check_wiring / check_wiring_contract
  guards_that_cannot_fail: 0  # check_negative_control
  inauthentic_tests: 0        # check_test_authenticity
  ungoverned_files: 12        # files matching NO contract rule
  measured_at: "YYYY-MM-DD"

`ungoverned_files` is the load-bearing field and the one most likely to be dropped: it counts what **no rule covers**. A `0/0/0` beside 400 ungoverned files reports the health of a subset while implying the whole — which is the same false green the other three exist to catch, one level up.

**Why this belongs in BVSSH at all.** Smart's framework separates **output** from **outcome**, and built-but-not-wired is the purest case of output *without* outcome: a mechanism that ships, passes review, raises coverage, appears in the changelog, and does nothing. It bears hardest on three dimensions — **Value** (if delivered-and-inert cannot be distinguished from delivered-and-connected, value claims are not merely hard to measure but *unfalsifiable*), **Safer** (an unwired safety mechanism gives *negative* safety: false assurance displaces the attention that absence would attract), and **Better** (a defect no quality gate catches). It does **not** obviously help **Sooner** — these checks add first-pass friction, and the counter-argument is about avoided rework, not speed. Say that plainly rather than claiming all five.

**Interpreting CALMS with DORA**: DORA tells you WHAT your delivery performance is. CALMS explains WHY. If DORA metrics are poor, CALMS identifies the cultural root cause. If DORA is good but CALMS is weak, the performance is fragile.

Output

**Lead with the verdict; make Red pop** (Von Restorff, per `harness/design-principles.md` — a