using-happy

name	using-happy
description	Use when starting any conversation in a repo with the happy plugin — establishes how to find happy skills, when to route model/effort, when to loop, and how to keep and reply from memory.

Using Happy

You have the happy plugin: a small set of skills plus a persistent memory store.

The rule

Before answering, check whether a happy skill applies. If there's even a small chance one fits, load it and follow it. Loading a skill costs little; skipping the right one costs a redo.

Core skills

Skill	Load it when…
memory-keeper	You learn a decision, fact, preference, or todo worth remembering — or the user asks "what were we doing / what did we decide / continue".
code-reducer	Code is verbose, duplicated, or over-engineered and the user wants it simpler/shorter (low effort, behavior-preserving).
model-router	A task has clearly separable phases (plan / execute / review) and you're dispatching subagents, so each phase gets the right model + effort.
agentic-loop	A task needs repeated make-a-change → verify → fix cycles until a check passes (tests green, lint clean, build ok).

Delivery pipeline skills

For shipping a change end to end. Order: plan-feature → track-work → implement → review-changes → open-pr, with ship as the umbrella. Ticket + step state lives in the happy pipeline store and mirrors into memory.

Skill	Load it when…
plan-feature	The user describes new work or asks to design/spec something. Produces scope, approach, file map, and a test plan.
track-work	A feature is bigger than one change, or the user wants a task breakdown or a status view.
implement	A ticket has a plan and is ready to build (test-first, on a branch, verify loop).
review-changes	A ticket branch is built and needs a fresh, independent review before a PR.
open-pr	A ticket passed review and is ready to push + open a PR (never merges).
ship	The user wants one command to take a request through the whole pipeline, or to resume a ticket.

Load a skill with your platform's skill tool — do not read SKILL.md files by hand.

Memory comes first

This project has a memory store. At session start its contents are injected into your context under "Project memory".

• Reply from memory before asking. If the user asks what you were doing, what was decided, or to continue — answer from the injected memory. Don't make them repeat themselves.
• Keep memory as you go. When a durable decision, fact, preference, or open todo appears, follow memory-keeper to store it. Future sessions load it automatically.
• Memory is per-project and lives on this machine. It is never shared unless you export it.

Model, effort, and loops in one line

• Model / effort — heavier reasoning (planning, review) → a strong model at high effort; mechanical work → a cheaper model at low/medium effort. See model-router.
• Loops — never hand-loop by eyeballing. Use agentic-loop: a bounded change→verify→fix cycle with a hard iteration cap.

Shipping work

When the user wants a change built and shipped, use the pipeline instead of freelancing straight to git. ship is the one-command path (plan → implement → review → PR); the individual skills exist for finer control. The pipeline is state-driven — pipeline.mjs next <ticket> decides the next step, not your recollection — and review-gated: no PR opens until review-changes passes. It always stops before merge; a human lands the PR.

Priority

1. The user's explicit instructions win over any skill.
2. Happy skills override default behavior where they conflict.
3. When several skills fit: memory-keeper (capture context) → process skill (loop / route) → implementation.