Receber por email
← Voltar para o catálogo

service-check

Use to evaluate a service or feature against Downe's 15 principles of good services.

35estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add haabe/mycelium

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/service-check/svg)](https://www.skillteca.com.br/skills/service-check)
#ai

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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?
  2. [ ] Discoverable through natural search terms
  3. [ ] Linked from logical starting points
  1. Clearly explains its purpose: Is it immediately clear what this does?
  2. [ ] Purpose statement visible without scrolling
  3. [ ] Target audience identifiable
  1. Sets expectations: Do users know what will happen?
  2. [ ] Timeline/process visible upfront
  3. [ ] Requirements stated before starting
  1. Enables completion: Can users finish what they came to do?
  2. [ ] End-to-end journey works
  3. [ ] No organizational barriers blocking completion
  1. Familiar: Does it work the way users expect?
  2. [ ] Uses conventions users know
  3. [ ] No surprising behavior
  1. No prior knowledge needed: Can a new user succeed?
  2. [ ] No jargon or acronyms without explanation
  3. [ ] No assumed context
  1. Agnostic of org structures: Are internal boundaries invisible?
  2. [ ] Users don't need to know which department handles what
  3. [ ] No internal handoffs visible to users
  1. Minimum steps: Is every step necessary?
  2. [ ] No redundant data entry
  3. [ ] No unnecessary confirmation steps
  1. Consistent: Is language/design uniform throughout?
  2. [ ] Same terms used for same concepts
  3. [ ] Visual patterns consistent
  1. No dead ends: Is there always a next step?
  2. [ ] Error states have recovery paths
  3. [ ] Edge cases have guidance
  1. Usable by everyone: Is it accessible and inclusive?
  2. [ ] WCAG 2.1 AA compliant
  3. [ ] Works across devices and assistive technologies
  1. Encourages right behaviors: Does design nudge good outcomes?
  2. [ ] No dark patterns (confirmshaming, hidden costs, forced continuity, misdirection, roach motel, trick questions, bait-and-switch)
  3. [ ] Default options are the safe/good ones
  4. [ ] Behavioral science used to HELP users, not exploit them (Shotton: ethical application)
  5. [ ] If dark patterns detected: flag "Dark Pattern Marketing" anti-pattern (see ${CLAUDE_PLUGIN_ROOT}/harness/anti-patterns.md)
  1. Responds to change: Can it adapt?
  2. [ ] Handles edge cases gracefully
  3. [ ] Can be updated without full rebuild
  1. Explains decisions: Are automated decisions transparent?
  2. [ ] Rejection reasons are clear
  3. [ ] Algorithm outputs are explainable
  1. Easy to get human help: Can users reach a person?
  2. [ ] Help/support clearly accessible
  3. [ ] Escalation path exists

When to Run

  • L3 Define (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.
  • L4 Develop→Deliver: Run the full 15-principle check. Required REVIEW gate (G-V2).
  • L4 Deliver→Complete: 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]

Decision Log (MANDATORY per G-P4)

APPEND a ### Service Check entry to .claude/harness/decision-log.md with: principles assessed, scores, priority fixes, overall service quality rating.

Theory Citations

  • Downe: Good Services (15 principles)
Compartilhar X LinkedIn