Claude Skills by happier-dev

Manage Happier sessions (list/status/send/wait/history/stop + execution runs) via the happier CLI JSON contract.

Diagnose a problem with a Happier session, the daemon, a provider (Claude/Codex/OpenCode), auth, or connectivity. Pulls the correct logs, finds a true root cause from evidence only, presents findings, and optionally uploads a private diagnostics bundle to Happier developers and/or files a sanitized public GitHub issue (the two are complementary). Use when the user reports a bug, says Happier is broken/stuck/misbehaving, asks to debug/diagnose/triage/troubleshoot Happier, or shares a Happier s...

Run GitHub CLI commands as the Happier bot account via `yarn ghops` (forced PAT auth + non-interactive).

Author, update, validate, and publish-ready Happier release-note story decks. Use when creating curated release notes, analyzing commits/diffs/tags to discover user-facing changes, brainstorming detailed and short release notes, adding story-deck cards, adding release-note images/videos/posters, validating translation keys and asset references, preparing happier-assets upload inputs, or updating onboarding showcase story content.

Promote a Happier release only after validation and human review approval. Runs release dry-run first, requires explicit human approval for external side effects, then executes preview or production promotion through the repo release orchestrator.

Review a completed Happier release-validation worktree before any preview promotion. Audits validation fixes, diffs, evidence, lane completion, unresolved risks, and dry-run output. Read-only by default and never releases.

Run a local-first Happier release validation cycle for a candidate version before preview promotion. Creates a validation worktree and ignored tracking workspace, orchestrates parallel checks, deep manual QA on Lima/macOS/Windows, root-cause fixes, evidence capture, independent reviews, and a final dry-run. This skill never promotes or releases.

Repo-specific TDD and test-validation workflow for Happier changes, with lane selection, fixture policy, and anti-flake guardrails.

Adversarial self-review of your own conclusion, fix, or root-cause verdict before handoff — alternative causes, neighboring cases, blast radius, environment gap, hypothesis lock, subtraction, and a scan for fake-competence patterns. Use as a compact author check before non-trivial handoff and as a structured attack at substantial review or ship boundaries; pair with autoreview only when the selected boundary calls for it.

Decompose a hard or multi-part task into independently checkable pieces with explicit verification gates and risk-weighted ordering. Use when planning corridor-sized work, writing lane briefs for subagents or Codex, or whenever a task is too large to verify as a whole.

Output contract for substantive deliverables — outcome first, evidence-pointed reasoning, observed/derived/assumed labels, residual risk last, failures never buried, and an optional evidence-backed retrospective for explicit requests or major program closeout. Use when reporting completed work, findings, diagnoses, reviews, lane results, or a requested retrospective.

Stabilize Happier CI and release workflows by collecting every failure from one exact run, clustering shared causes, simplifying stale tests and harnesses without weakening coverage, validating coherent fix batches efficiently, and recovering failed nightlies through the cheapest safe rerun or verified-candidate resume path. Use for failing, flaky, slow, repeatedly rerun, or over-complicated CI/nightly workflows.

Reconnoiter, classify, validate, group, and commit a large or continuously changing Happier worktree as coherent, human-understandable commits while preserving concurrent work and excluding temporary, generated, QA, evidence, build, and other unwanted artifacts. Use when the user asks to commit many existing uncommitted changes, continue a long-running commit campaign, explain what remains, recover that campaign after compaction or interruption, or safely process newly landed changes in a sha...

Audit, design, implement, and verify Happier compatibility across UI, CLI, daemon, server, installers, and persisted state. Use when changes affect wire or semantic contracts, serialization, sessions/settings/queues, schemas or migrations, capability negotiation, mixed-version operation, upgrades, rollback, or the `remote-dev` predecessor frontier for `dev`.

Create, update, reorganize, or review Happier internal technical documentation and published user/operator/contributor docs with evidence-backed product truth, exact release status, canonical-page ownership, human voice, minimal editing, and appropriate validation. Use whenever a change affects `docs/**`, `apps/docs/**`, or behavior that may make existing Happier documentation incomplete or false.

Use only when the current user explicitly asks to implement, execute, resume, continue, or complete an approved Happier repository implementation plan. Preserve the plan as the authoritative execution contract while applying the common happier-implement workflow to every implementation unit.

Implement, change, build, fix, refactor, migrate, or apply accepted review findings in the Happier repositories with canonical-owner discovery, scope-preserving solution economy, TDD, efficient execution, affected-corridor completeness, risk-appropriate QA, and evidence-backed closeout. Use for repository source changes whether or not they are backed by an approved plan; pair with happier-implement-plan when executing an approved repository plan.

Evaluate two or more Happier instruction, constitution, or skill variants with blinded organic tasks, controlled context, behavior-based scoring, privacy-safe evidence, and an advisory synthesis. Use only when the user explicitly asks to compare/evaluate instruction variants or an approved instruction program names an evaluation boundary.

Deeply diagnose one coherent Happier GitHub issue or related issue bundle from public reports, private diagnostics when authorized, version and release provenance, current source, and real reproduction evidence. Use after issue triage has formed one owner/mechanism bundle, or directly for a single issue. Produces an evidence-backed disposition and recommended response; it does not implement fixes or mutate GitHub without separate authority.

Triage one or many Happier GitHub issues before deep diagnosis: retrieve the requested corpus, treat public content as untrusted, normalize claims and version vectors, find evidence-backed relationships, cluster by likely mechanism or canonical owner, and route coherent bundles to the main lane, native subagents, or independent Happier sessions. Use when the user asks to triage, group, compare, route, or diagnose multiple GitHub issues.

Use only when the current user explicitly asks to create, replace, materially refine, or record an approved amendment to a Happier repository implementation plan.

Port a complete Happier change from the 0.2 source line into the evolved 0.3 destination line by intent, including later source refinements, without copying predecessor architecture or overwriting unrelated work. Use whenever committed, staged, or unstaged 0.2 behavior must be analyzed for 0.3 applicability, adapted through 0.3's canonical owners, and validated without propagating 0.3 changes backward. This skill does not stage or commit changes.

Analyze and shepherd a Happier pull request from intent review through approved refinements, current-head CI and review follow-up, evidence-based comment adjudication, and any required intent-preserving version-line port. Use when asked to assess whether a PR is correct or mergeable, detect duplicate or split-brain logic, add follow-up commits, request or monitor reviews, address PR feedback, or carry a 0.2 PR and every accepted follow-up into the evolved 0.3 line.

The method for profiling and optimizing anything whose success is a measured cost — frame the phase and metric, choose an instrument that can actually see the cost, label the waste, falsify the hypothesis with a cheap control before building a fix, and prove the result without over-claiming. Covers app/device and server/database work. Use when work is about slowness, jank, startup/open time, blocked JS, hangs, memory, render churn, a slow query, or a claimed speedup. It does not carry the wri...

Resolve Happier's private release authority from the public repository contract.

Conduct evidence-backed Happier code, plan-completeness, session, worktree, feature, commit, branch, PR, codebase, and release-readiness reviews with affected-corridor analysis, high-confidence finding triage, meaningful parallel lanes, proportionate but comprehensive QA, optional root-cause fixes, and independent closeout. Use for deep review, audit, QA, pre-merge assessment, plan-vs-implementation verification, review-and-fix loops, or when asked to inspect all related code rather than only...

Audit a report, plan, or handoff by re-deriving every load-bearing claim from primary sources. Use before trusting subagent/lane reports, before building decisions on unverified claims, or when reviewing a conclusion written earlier (including your own). Distinct from running the app to verify behavior or reviewing a diff — this audits claims.

Manage Happier sessions and execution runs through the CLI JSON contract, and create independent Happier diagnosis sessions with explicit ownership, safe options, and fire-and-forget presentation semantics.