# Vibe Research Before Design

> Dispatches SOTA research before proposing any new feature, architecture, or technology choice. Use when facing design decisions, not when implementing existing specs.

- Skill: `majiayu000/vibe-research-before-design` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/vibe-research-before-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/vibe-research-before-design/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/vibe-research-before-design

---


# vibe-research-before-design

Before proposing any design, architecture, or technology choice — research first. "Other people's documented failures count as observed failure."

## When to Use This Skill

- Designing a new feature or system
- Choosing between technologies, frameworks, or patterns
- Making architectural decisions with long-term consequences
- The user asks "how should we build X?"
- You're about to say "I recommend..." for a design choice

## When NOT to Use This Skill

- Implementing an already-designed spec (the research was done at design time)
- Fixing a bug (use `vibe-debugging-journal` instead)
- Simple refactoring with no architectural implications
- The user has explicitly chosen a technology and wants implementation

## Steps

1. **Identify the design question** — What decision are we making? What are the key constraints?

2. **Dispatch research** — For each major sub-problem, find:
   - 2+ named real-world projects/libraries with adoption metrics (GitHub stars, npm downloads, production users)
   - 1+ academic paper or technical blog with year and venue/source
   - The **mechanism** — how does it actually work? (Not marketing copy)
   - **Known failures** — what went wrong for others?
   - **Applicability assessment** — does this fit our constraints?

3. **Synthesize findings** — Present a comparison table:
   | Option | Adoption | Mechanism | Known Failures | Fit |
   |--------|----------|-----------|---------------|-----|

4. **Make a recommendation** — Based on evidence, not intuition. State confidence level.

5. **Record the decision** — Use `vibe-decision-journal` to log the choice and alternatives.

## Red Flags

- "This is obvious, we should just use X" — If it's obvious, proving it takes 2 minutes
- "I've used X before" — Past experience ≠ current best option
- "Everyone uses X" — Popularity ≠ fitness for your constraints
- "Let me just start building and we'll figure it out" — The most expensive approach

## Output Format

### Research Summary
- **Decision**: [What we're deciding]
- **Constraints**: [Key constraints]
- **Options Evaluated**: X

### Comparison Table
| Criteria | Option A | Option B | Option C |
|----------|----------|----------|----------|

### Recommendation
[Evidence-based recommendation with confidence level]

### Sources
[Links to projects, papers, docs referenced]