From up
Use before any creative work — features, components, behavior changes. Turns an idea into a validated spec with explicit tradeoffs and unknowns, and splits scope into multiple tasks if it's too large. Output is the `## Design` section of the task file.
How this skill is triggered — by the user, by Claude, or both
Slash command
/up:udesignThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Turn an idea into a validated spec through collaborative dialogue. Output lives in `docs/tasks/<slug>.md` — `## Design`, `### Invariants`, `### Principles` — with a TDD decision recorded. Nothing is planned or written until the user approves.
Turn an idea into a validated spec through collaborative dialogue. Output lives in docs/tasks/<slug>.md — ## Design, ### Invariants, ### Principles — with a TDD decision recorded. Nothing is planned or written until the user approves.
Before any creative work: new features, component builds, behavior changes, architectural moves. Even "simple" tasks — five minutes of design prevents hours of rework. Skip only when the task is trivial (typo, one-line fix) and the user has confirmed the skip.
up:test-driven-development's applicability rule.## Design, ### Invariants, ### Principles.up:uplan.
If the ask spans multiple independent subsystems, stop and propose a split. Each piece gets its own task file. We work on one in this dialogue; the rest wait.
User: "Add auth, billing, and admin dashboard."Agent: "That's three independent tasks. I'd split into:
docs/tasks/add-auth.mddocs/tasks/add-billing.mddocs/tasks/add-admin-dashboard.mdEach is a separate task file, designed and built in its own session. Which one should we start with?"
Agent designs all three at once in a single task file. Later agents can't resume a coherent piece of work; plans become gigantic and unreviewable.A good test: can a plan for this piece produce working, testable software on its own? If no, it's too big.
For every option, state:
End with a recommendation and why. Don't hedge on the recommendation — if the tradeoffs don't settle it cleanly, say that explicitly and ask the user to weigh in.
"Option A: Redis-backed rate limiter. - Tradeoff: fast, durable across restarts. Adds Redis as a required dep in prod. - Unknown: our existing Redis cluster's latency from the edge nodes — need to measure before committing.Option B: In-memory token bucket per pod.
Option C: Postgres-backed counter with short TTL.
Recommendation: B for now, revisit when we outgrow it. The redis latency unknown (A) and write-load unknown (C) both need measurement work before committing, and B is cheap to replace."
If the task is greenfield (no existing consumers), say so in one line and move on. Don't invent risks.
Not principles: "prefer composition" (too vague without "over inheritance"). "Be consistent." "Write clean code."
Invoke the applicability rule from up:test-driven-development. Record in Design:
TDD: yes
or
TDD: no (reason: one-off migration script; no reusable logic)
## Design
<purpose, scope, chosen approach, key decisions, tradeoffs that settled it, unknowns that remain>
<TDD: yes|no (reason)>
### Invariants
- <specific thing that must hold>
- <...>
### Principles
- <softer guidance — concrete enough to check>
- <...>
See up:handsoff for the full contract. Stage-specific delta: Design is still the one interactive stage — run the full process. The only relaxation is "one question per message" → "ask only when genuinely blocking; prefer a conservative default". Log each defaulted answer as - udesign: <what> — <rationale> in ### Hands-off decisions; log no-default gaps under ### Deferred (needs user input).
User has approved the Design section (interactive) or the Design has been written and self-reviewed (hands-off) → invoke up:uplan. Do not write code. Do not invoke any other skill.
npx claudepluginhub btseytlin/ultrapack --plugin upGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.