design
From the author
Plan implementation before coding: investigate the repo, write spec and plan, and validate with a peer. Use for "plan", "design approach", "scope", or any coding task needing a plan. Not system-design thinking (/ship:arch-design) or full /ship:auto.
Install
npx skills add heliohq/ship --skill design -a claude-code
Installs to .claude/skills/design/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 78
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- planowainlewis/youtube-tutorialsWrite a short implementation plan or a longer execution plan before coding. Use when starting new work, when a ticket needs clearer boundaries, when a change spans multiple files or interfaces, or when a multi-hour task needs a living plan.Planning★ 409
- devheliohq/shipImplement from a spec or plan: extract stories, build in safe waves, test, commit, and get peer review per story. Use for "implement", "build/code this plan", or targeted fix findings. If no plan exists, use /ship:design first.Testing★ 93
- writing-plansjnMetaCode/superpowers-zh当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前Writing★ 8.4K
- implementation-planningcbrock84/headcountTurns a spec or requirement into a written plan a separate session or agent can execute, then drives that plan through review checkpoints. Use this before touching code on any multi-step task, when work needs handing to someone else, when a task keeps sprawling mid-implementation, or when a plan exists and needs executing in order with verification between steps.Planning★ 2.1K
- solution-designthiientv/godmodeExplores ambiguous product or engineering intent before implementation, clarifies users, constraints, alternatives, risks, and acceptance criteria, and turns the result into an approved design direction. Use for a new feature, subsystem, creative UI, architecture change, or unclear request. Not for an already-scoped bug fix, an existing implementation plan, or a narrow code review.Design★ 99
- arch-designheliohq/shipSystem-design thinking before any doc or code: goals/non-goals, back-of-envelope numbers, components and contracts, failure modes, operability, security, trade-offs. Use for "design this system", "architecture for X", "trade-offs for X", "how should we architect", "API design", "data model for", "service boundaries", or before an ADR. Hands off to /ship:write-docs to record the decision. Not implementation planning (/ship:design — that turns a decided design into stories).Design★ 93
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in