| 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
- The user's explicit instructions win over any skill.
- Happy skills override default behavior where they conflict.
- When several skills fit: memory-keeper (capture context) → process skill (loop / route) → implementation.
