delight-habits git:20260911.ae14461A

Immutable. This exact content never changes and is served at /api/v1/blob/aecfd9c55b741b58.

---
name: delight-habits
description: Design or review streak, reward, and recovery rules. Use when qualification, cadence, incentives, or progress accounting need decisions; cosmetic streak feedback belongs to delight.
---

# Delight habits

Make progress mechanics support the activity users came to do.

## Name the useful behaviour

Identify the user's outcome, the qualifying action, and its natural cadence. Daily use is a product decision, not a default. If the task only asks to animate an existing streak, preserve its rules; the visual request does not authorise redesigning the habit system.

For a new mechanic, compare its incentive with the real goal. A practice count can reward repetition without measuring learning. Keep that distinction visible in the product and in any success claim. If there is no plausible benefit beyond increasing visits, propose a progress signal tied to useful work.

## Define the rules users will live with

Read [mechanics.md](references/mechanics.md) for the relevant mechanic. Specify eligibility, cadence, miss/recovery rules, pause or exit, and how progress is explained. For counters, settle duplicate events, offline work, and time boundaries when those affect correctness. Reuse existing event and time semantics where possible.

Design recovery alongside accumulation. A missed day should have a clear consequence and a reasonable way back. Avoid guilt copy, shaming characters, obstructed exit, or pressure whose paid remedy is the feature's main purpose. Let users control optional reminders and competitive layers. Check the likely impact on children or vulnerable audiences when relevant to the product.

Keep points, ranks, and scarce lives distinct from sensory celebration. Adding a counter does not justify adding confetti. Confirm useful milestones with an intensity that suits their frequency and preserve a clear result under reduced motion or mute.

## Assess outcomes

Pair participation measures with a measure of the real goal, such as retained learning, completed work, or chosen practice. Track pressure signals only when appropriate measurement exists; do not add analytics infrastructure without scope. Published experiments from another product are hypotheses for this one, not forecasts.

When implementing, verify qualification, duplicates, boundary times, missed periods, recovery, and opt-out as applicable. When reviewing, identify concrete rules or screens that cause the problem; distinguish unknown behaviour from an observed failure.

Deliver the rule set or scoped implementation, the recovery path, and the behaviour checks. Keep commercial choices explicit when they are not established by the brief.