Use when starting any creative work - building features, adding components, modifying behavior, or before implementation of new functionality. Required before writing code for unclear requirements or when user provides high-level idea without detailed specifications.
Turns vague ideas into concrete designs through collaborative research and iterative validation. Triggers when you start any creative work without clear specifications or when requirements are ambiguous.
/plugin marketplace add astrosteveo/harness-mp/plugin install harness@harness-mpThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This is the failure mode: User says "like EVE Online" → you describe EVE's mining system in detail → user has to correct you → time wasted.
The fix: User says "like EVE Online" → you ask "Describe the specific interaction you want. What does the player do, what happens, what feedback do they see?" </THE-RULE>
Help turn ideas into fully formed designs through collaborative dialogue.
The process: Understand context → Ask questions one at a time → Research → Verify understanding → Present design in sections → Document.
Understanding the idea:
Marking recommendations:
When asking questions with options, ALWAYS indicate your recommendation:
Should we use client-side or server-side rendering?
A) Client-side - faster initial dev, simpler setup
B) Server-side - better SEO, faster first paint **(Recommended)**
I'd lean toward server-side because SEO matters for this use case.
How should the camera follow the ship?
A) Locked behind - always directly behind ship
B) Orbit camera - user can rotate around ship **(Recommended)**
C) Free camera - fully detached from ship
Orbit gives the best balance of control and spatial awareness.
Why this matters:
Research before designing:
Once you understand WHAT to build, research HOW before proposing designs:
| Research Type | When | How |
|---|---|---|
| UX/Game references | User mentions "like X" or "similar to Y" | WebSearch for current behavior, ask user to verify |
| Library/Framework | Building with specific tech | Context7 (if available) for latest docs, or WebSearch |
| Best practices | Architecture decisions | WebSearch for current patterns (include year in query) |
| Integration | Connecting to APIs/services | Check official docs for current API shape |
How to research:
Use subagents and save findings to .artifacts/<feature-name>/research.md
This keeps research out of main session context AND creates a reference for later.
Create feature directory:
mkdir -p .artifacts/<feature-name>
Ensure git repo exists:
# If no .git directory, initialize
git init
git add .
git commit -m "Initial commit"
Ensure CLAUDE.md exists: If no CLAUDE.md in project root, copy the template:
harness/templates/CLAUDE.mddocs: add CLAUDE.md project guideA strong CLAUDE.md is foundational - take time to fill it out properly.
Launch both subagents in parallel at the start of brainstorming. They run in background while you ask the user clarifying questions.
Task tool (Explore) - run_in_background: true
prompt: "Explore the codebase for [feature context]. Find:
- Relevant existing files and patterns
- How similar features are implemented
- Key dependencies and conventions
Write findings to .artifacts/<feature-name>/YYYY-MM-DD-research.md
under a '## Codebase Analysis' section."
Task tool (general-purpose) - run_in_background: true
prompt: "Research [topic]. Find: [specific questions].
Include the current year in searches.
Use Context7 for library docs if available.
Use WebSearch for UX patterns, best practices.
Write findings to .artifacts/<feature-name>/YYYY-MM-DD-research.md
under a '## External Research' section."
While research runs: Continue with clarifying questions. By the time questions are done, research is ready.
Once questions answered and subagents complete:
useQuery with object syntax. Should I use that pattern?"Why this approach:
Why research matters:
Skip research only if:
Exploring approaches:
Before presenting design - checkpoint questions:
After understanding and research, ask these lightweight questions before writing the design:
Scope check (if complexity emerged): "This is getting substantial. Want to scope down to just [core piece] for v1?"
Success criteria: "How will we know this is done? What's the acceptance test?"
Edge cases: "Any edge cases or error scenarios you're particularly worried about?"
MVP gate: "What's the minimum version that would be useful?"
Mental model: "Walk me through how you'd actually use this"
Don't ask all five every time - pick 2-3 that are most relevant. These surface gaps before you write a design that misses the point.
Pre-design summary:
Before writing, confirm understanding:
"Before I write the design, here's what we agreed:
Sound right?"
Wait for confirmation. Then proceed to design.
Presenting the design:
Deferred items:
managing-backlog skill to add to BACKLOG.mdEpic-sized initiatives:
managing-roadmap skill to add as epic to ROADMAP.mdDocumentation:
Determine feature name:
oauth-service).artifacts/ directories.artifacts/<derived-name>/. Okay?"Save design:
.artifacts/<feature-name>/ directory if needed.artifacts/<feature-name>/YYYY-MM-DD-design.mdEnsure git repo exists:
.git directory exists in project rootgit init and create initial commit with existing filesCommit:
docs: add <feature-name> designImplementation (if continuing):
/using-git-worktrees to create isolated workspaceQuestion flow:
You: [Question with options, one marked **(Recommended)**]
User: [Answers]
You: "[Brief confirmation of what you understood]
Does this sound correct to you?"
User: [Confirms or corrects]
You: [Next question]
Always confirm understanding before moving on. This catches misunderstandings early.
Never assume. Always ask.
| Situation | Wrong | Right |
|---|---|---|
| Unclear requirement | Assume most likely meaning | "Did you mean X or Y?" |
| Multiple valid approaches | Pick one silently | "Option A or B? Here's the tradeoff..." |
| Missing detail | Fill in the gap yourself | "What should happen when...?" |
| Ambiguous scope | Include everything possible | "Should this include X, or is that separate?" |
| Technical choice | Use your favorite | "Should we use X or Y for this?" |
| Reference to game/app/UX | Assume you know how it works | "I'm not 100% sure how X works - can you describe the specific behavior?" |
Critical for game/UX references:
When user says "like EVE Online" or "similar to Notion" or "Figma-style":
Building the wrong interaction model wastes massive time. Ask upfront.
Red flags you're assuming:
The cost of asking: 30 seconds The cost of wrong assumption: Hours of rework
Ask.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.