Clod Lens Ethics

---
name: "Lens: Ethics"
description: "Passive ethical review: manipulation, accessibility, privacy, sustainability in user-facing features."
when_to_use: "When designing or reviewing a user-facing feature: dark patterns, accessibility gaps, privacy overreach or sustainability trade-offs worth surfacing before it ships."
user-invocable: false
metadata:
  family: clod-lens
allowed-tools:
  - Read
---

# Ethics Reviewer

Passive ethical review skill. Activates when user-facing features touch the four ethical concerns: manipulation, accessibility, privacy, and sustainability. Checks designs and implementations against principled constraints without requiring explicit invocation.

---

## When This Skill Applies

Use this skill when:
- Building forms that collect personal data
- Implementing notifications, emails, or alerts
- Designing pricing pages, upgrade flows, or paywalls
- Adding analytics, tracking, or telemetry
- Creating urgency mechanisms (countdowns, scarcity indicators)
- Implementing accessibility-sensitive UI (navigation, forms, modals)
- Making performance decisions that affect device/network inclusivity
- The conversation involves user-facing features of any kind

**This skill is ambient**; it should fire as a background check when relevant keywords or patterns appear, not only when explicitly requested.

---

## The Four Ethical Constraints

### 1. No Manipulation

Software should amplify the user, not exploit them.

**Red flags**:
- Confirmshaming ("No thanks, I don't want to save money")
- Hidden opt-outs (pre-checked boxes, buried unsubscribe)
- Artificial urgency ("Only 2 left!" when stock is unlimited)
- Dark patterns in cancellation flows (extra steps, guilt language)
- Misdirection (visual emphasis on the option that benefits the business)
- Forced continuity (hard to cancel subscriptions)
- Roach motels (easy to get into, hard to get out of)

**Principle**: The user's best interest and the business's best interest should align. If they diverge, side with the user.

**Check**:
- Would the user feel tricked if they understood the full mechanism?
- Is the easiest path also the one that serves the user?
- Can the user reverse this action as easily as they took it?

### 2. Accessibility as Default

If someone can't use it, it doesn't work.

**Requirements** (not aspirations):
- Semantic HTML (headings, landmarks, labels, roles)
- Keyboard navigable (all interactive elements reachable via Tab/Enter/Escape)
- Screen reader compatible (meaningful alt text, aria-labels where semantic HTML isn't enough)
- Colour contrast ratios meet WCAG 2.1 AA minimum (4.5:1 for normal text, 3:1 for large text); project themes ship a `contrast` table that `validate.ts` checks, so pairs taken from the theme are verified rather than assumed
- Focus indicators visible
- Error messages associated with inputs (aria-describedby or aria-errormessage)
- No information conveyed by colour alone
- Reduced motion support (`prefers-reduced-motion`)

**Check**:
- Can a keyboard-only user complete this flow?
- Does every image/icon have appropriate alt text or aria-label?
- Does the colour scheme pass contrast checks?
- Are form errors announced to screen readers?

### 3. Privacy by Default

Collect the minimum. Store it carefully. Be transparent about it.

**Principles**:
- **Data minimisation**: Only collect what's needed for the feature to work
- **Purpose limitation**: Don't repurpose data without consent
- **Transparent collection**: Tell users what's collected and why
- **Secure storage**: Encrypt sensitive data, use environment variables for secrets
- **Right to delete**: Users can remove their data
- **No silent tracking**: Analytics require disclosure; no hidden telemetry

**Red flags**:
- Collecting email "for later" without a clear purpose
- Tracking user behaviour without disclosure
- Storing data you don't actively need
- Third-party scripts that phone home with user data
- Cookies set before consent given

**Check**:
- What data does this feature collect?
- Is all of it necessary for the feature to work?
- Is the user informed about the collection?
- Can the user opt out without losing core functionality?
- Is sensitive data encrypted at rest and in transit?

### 4. Sustainability

Software that wastes resources wastes everyone's time and energy.

**Principles**:
- **Performance budgets**: Set limits on page weight, load time, bundle size
- **Device inclusivity**: Don't require flagship hardware; test on constrained devices
- **Network inclusivity**: Work on slow connections; progressive enhancement
- **Efficient queries**: Avoid N+1, over-fetching, unnecessary computation
- **Lazy loading**: Don't load what's not visible
- **Caching strategy**: Don't re-fetch what hasn't changed

**Check**:
- Does this feature degrade gracefully on slow connections?
- Is the bundle size impact proportional to the feature's value?
- Are images/assets appropriately sized and lazy-loaded?
- Are database queries efficient? (No N+1, appropriate indexes)

---

## How to Apply

This skill doesn't produce a standalone output. It **annotates** other work:

### During Design
When discussing a feature, flag ethical concerns inline:
```
⚠️ Ethics: This notification flow sends emails on a schedule the user didn't choose.
Consider: opt-in frequency selection, easy one-click unsubscribe.
```

### During Implementation
When reviewing or writing code, flag issues:
```
⚠️ Ethics (accessibility): This modal traps focus but doesn't return focus
to the trigger element on close.
```

### During Review
When assessing completed work:
```
⚠️ Ethics (privacy): This analytics call sends the user's full name to a
third-party service. Consider sending an anonymised ID instead.
```

---

## Severity Levels

Not all ethical concerns are equal. Use these to calibrate:

**Must fix** (blocks shipping):
- Keyboard traps (user literally cannot proceed)
- Data collection without disclosure
- Dark patterns that exploit vulnerable users
- Missing alt text on functional images
- WCAG AA contrast failures on primary UI

**Should fix** (fix before v1):
- Missing reduced-motion support
- Overly broad data collection (works but collects more than needed)
- Cancellation flows with unnecessary friction
- Images without descriptive alt text (decorative is fine)
- Large bundle sizes on critical paths

**Consider** (improve over time):
- Enhanced screen reader experience beyond minimum
- Performance optimisation for constrained devices
- Additional privacy controls beyond legal requirements
- WCAG AAA contrast compliance

---

## Integration Points

### With domain-modeller
When the domain model includes personal data entities (User, Profile, Preferences), ethics-reviewer flags data minimisation and privacy concerns.

### With frontend-styler
Accessibility checks integrate directly into styling work: contrast, focus indicators, semantic structure.

### With api-designer
Privacy-by-default patterns in API design: no excessive data in responses, secure defaults, proper auth scoping.

### With testing-obsessive
Accessibility testing is part of the testing strategy: automated a11y checks, keyboard navigation tests, screen reader verification.

---

## Quick Reference Checklist

Before shipping any user-facing feature:

- [ ] **Manipulation**: Would the user feel tricked? Is the easiest path the honest one?
- [ ] **Accessibility**: Can a keyboard/screen-reader user complete this flow?
- [ ] **Privacy**: Is data collection minimal, disclosed, and deletable?
- [ ] **Sustainability**: Does this work on slow connections and modest hardware?

---

## Success Criteria

Ethics review is effective when:
- Concerns are caught during design, not after launch
- The team treats accessibility as a requirement, not a nice-to-have
- Users can understand, control, and delete their data
- No dark patterns exist in the product
- The software works for people with different abilities, devices, and connections