Happier is an open-source, end-to-end encrypted client that lets people run AI coding-agent sessions on a computer and continue controlling them from a phone, browser, or desktop app. It is for developers who use agents such as Claude Code, Codex, Gemini, or OpenCode across multiple devices, with self-hosting available. The catalogue entries are add-ons for configuring or extending this client and its supported coding-agent workflows.
Borrowing it
Nothing to install: this file belongs to happier-dev/happier. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/happier-dev/happier/dev/.agents/skills/happier-testing/SKILL.mdgit clone --depth 1 https://github.com/happier-dev/happierWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/happier-dev/happier/happier-testing)<a href="https://agentmods.dev/skills/happier-dev/happier/happier-testing"><img src="https://agentmods.dev/badge/skills/happier-dev/happier/happier-testing.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00032 | $0.02199 |
| Opus 5 | $0.00016 | $0.01099 |
| Sonnet 5 | $0.00006 | $0.00440 |
| Haiku 4.5 | $0.00003 | $0.00220 |
Grade A, and why
happier-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Happier Testing And TDD
Use this skill for behavior-changing work in this repository, especially when changes touch shared runtime contracts, CLI/server/UI flows, or any lane that historically accumulates stale fixtures.
Goal
Apply strict RED-GREEN-REFACTOR while following Happier-specific lane, fixture, and rerun rules so changes do not silently drift until a late pipeline sweep.
Workflow
- Inventory first
- Search for existing tests by symbol, route, command, feature id, config key, component name, or error code.
- Map the affected lane(s) and any shared/package-local harnesses the change can invalidate before editing code.
- Name the observable contract or material risk the test must distinguish before writing it.
- For user-visible or environment-dependent work, define the composed live recipe before implementation: exact entry point, provider/account/state, actions, expected outcome, recovery path, and build/bundle/runtime identity that will prove the result.
- Update the most relevant existing test first when possible.
- Consolidate overlapping tests instead of stacking new ones on top.
- Classify failures correctly
production bug: runtime behavior is wrongtest drift: assertions/fixtures assume an obsolete contractharness drift: helpers/mocks/testkit no longer match real runtime wiringinfra/resource issue: disk, Docker, stale child processes, or similar environment failures
- RED
- Write or update the smallest relevant test first.
- Run only the smallest relevant slice and confirm it fails because the intended behavior is missing or wrong, not because of setup, fixtures, mocks, wording, syntax, or an unrelated error.
- GREEN
- Implement the smallest fix that satisfies the failing behavior.
- Keep internal behavior real; mock only system boundaries.
- REFACTOR
- Extract shared helpers only when there is repeated real duplication or repeated stale drift.
- Keep file responsibilities focused.
- Broaden validation
- After a targeted green run in a shared area, rerun one broader related lane.
- Before handoff, rerun the touched package typecheck/build-enforcing lane and the relevant repo lanes.
- Validate the current moving source and the existing development stack. Feature validation must not create, freeze, pack, install, identify, or certify a separate release representation; archive production and publication verification belong only to release automation during an explicitly dispatched release.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday Changed 95a3c24e87f0
- 3d ago First seen · 137 lines · 32 tokens per session scan A 90a848f1b743
happier-testing is a skill published in the GitHub repository happier-dev/happier (1,624 stars, last pushed yesterday), licensed MIT. It adds 32 tokens to every session and 2,199 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
cmux-testing
A regression test for a bug fix ships as two commits so CI proves the test catches the bug.
testing-expert
Expert-level software testing with unit tests, integration tests, E2E tests, TDD/BDD, and testing best practices. Use when the user mentions TDD, BDD, unit tests, integration tests, or end-to-end tests, or when the task involves Testing Fundamentals, Unit Testing, Integration Testing, or End-to-End Testing.
absolute-work
End-to-end, phase-gated SDLC for AI coding agents: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge. Handles features, bugs, refactors, greenfield projects, planning breakdowns, and migrations. Triggers on "absolute work", "build this…
TDD 开发纪律助手
引导开发过程遵循测试先行、红绿重构和回归验证纪律。.
Pair Programming
AI-assisted pair programming with multiple modes (driver/navigator/switch), real-time verification, quality monitoring, and comprehensive testing. Supports TDD, debugging, refactoring, and learning sessions. Features automatic role switching, continuous code review, security scanning, and performance optimization with…
tdd
Test-driven development workflow for implementing features or fixing bugs through red-green-refactor. Use when the user asks to build, change, or fix behavior and the codebase has a practical automated test surface.