/service-check

name: service-check
description: "Use to evaluate a service or feature against Downe's 15 principles of good services."
metadata:
  instruction_budget: "52"
  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."

Service Check Skill

Evaluate against Lou Downe's 15 principles.

Checklist

For each principle, assess: Pass / Partial / Fail / N/A

1. **Easy to find**: Can users find this service without knowing its name?

• [ ] Discoverable through natural search terms
• [ ] Linked from logical starting points

2. **Clearly explains its purpose**: Is it immediately clear what this does?

• [ ] Purpose statement visible without scrolling
• [ ] Target audience identifiable

3. **Sets expectations**: Do users know what will happen?

• [ ] Timeline/process visible upfront
• [ ] Requirements stated before starting

4. **Enables completion**: Can users finish what they came to do?

• [ ] End-to-end journey works
• [ ] No organizational barriers blocking completion

5. **Familiar**: Does it work the way users expect?

• [ ] Uses conventions users know
• [ ] No surprising behavior

6. **No prior knowledge needed**: Can a new user succeed?

• [ ] No jargon or acronyms without explanation
• [ ] No assumed context

7. **Agnostic of org structures**: Are internal boundaries invisible?

• [ ] Users don't need to know which department handles what
• [ ] No internal handoffs visible to users

8. **Minimum steps**: Is every step necessary?

• [ ] No redundant data entry
• [ ] No unnecessary confirmation steps

9. **Consistent**: Is language/design uniform throughout?

• [ ] Same terms used for same concepts
• [ ] Visual patterns consistent

10. **No dead ends**: Is there always a next step?

• [ ] Error states have recovery paths
• [ ] Edge cases have guidance

11. **Usable by everyone**: Is it accessible and inclusive?

• [ ] WCAG 2.1 AA compliant
• [ ] Works across devices and assistive technologies

12. **Encourages right behaviors**: Does design nudge good outcomes?

• [ ] No dark patterns (confirmshaming, hidden costs, forced continuity, misdirection, roach motel, trick questions, bait-and-switch)
• [ ] Default options are the safe/good ones
• [ ] Behavioral science used to HELP users, not exploit them (Shotton: ethical application)
• [ ] If dark patterns detected: flag "Dark Pattern Marketing" anti-pattern (see ${CLAUDE_PLUGIN_ROOT}/harness/anti-patterns.md)

13. **Responds to change**: Can it adapt?

• [ ] Handles edge cases gracefully
• [ ] Can be updated without full rebuild

14. **Explains decisions**: Are automated decisions transparent?

• [ ] Rejection reasons are clear
• [ ] Algorithm outputs are explainable

15. **Easy to get human help**: Can users reach a person?

• [ ] Help/support clearly accessible
• [ ] Escalation path exists

When to Run

• **An L3, before `commit_to_build`** (solution design): Run a lightweight check focusing on principles 1-4, 8, 10, 11. These inform the Four Risks viability dimension — a solution that violates core service principles has viability risk. Feed results into `/mycelium:ice-score`.
• **An L3's `release`** (its learning delivery to a named audience, v0.331.0): Run the full 15-principle check, because the Service Quality gate reads all 15 for any release. A principle the test's audience never meets is judged `n/a` with a line saying why, which keeps a small pilot's check small.
• **An L4's `release`**: Run the full 15-principle check. Required REVIEW gate (G-V2).
• **An L4's `close`**: Final validation. Required REVIEW gate.

Running at L3 catches service design issues BEFORE delivery, not after. A solution that can't meet "enable completion" (P4) or "no dead ends" (P10) has a design problem, not just a quality problem.

Output

## Service Check: [Service Name]
| # | Principle | Status | Notes |
|---|-----------|--------|-------|
| 1 | Easy to find | Pass/Partial/Fail | ... |
...
| 15 | Human help | Pass/Partial/Fail | ... |

Score: [X/15 Pass, Y/15 Partial, Z/15 Fail]
Priority fixes: [top 3 items to address]

Canvas (MANDATORY — the source of truth, do this FIRST)

`.claude/canvas/services.yml` is the canonical record. The decision log is provenance; the canvas is what the framework READS. Write the canvas before the decision log — if only one of the two lands, it must be this one.

**WHY THIS SECTION EXISTS (v0.170.0).** It did not, and the cost was measured. A full 15-principle assessment ran on the dogfood project on 2026-05-23 (7 Pass / 8 Partial / 0 Fail), landed in the decision log, and `services.yml` held every principle at `assessment: not-assessed` with `overall_score: null` for **103 days**. The scores existed the whole time and no reader of the canvas could see them. The `Service Quality` theory gate reads this file, so a Required gate at L4 had no data to read while the data sat in a log nothing gates on.

**Since v0.331.0 the gate checks this itself.** A Service Quality pass counts only when all 15 principles in `principles[]` are judged with `evidence`, at every scale the gate applies to (`engine/theory-gates.md`, gate 9: "Service evaluated against all 15 Downe principles"); the scale-lock gate and the release gate both name the principles that are not. A principle that does not apply is judged `n/a` with a line of `evidence` saying why, and counts. The lighter L3 check under "When to Run" feeds the Four Risks before the L3 builds; it is not this gate's bar. A gate marked `n/a` (a product with no service to judge) needs no record. Until 0.331.0 the gate passed on the status word.

**UPDATE, per principle, in `principles[]`:**

  - id: <1-15>
    assessment: pa