How do I install the Vibe Research Before Design skill?

Run npx skillmds@latest add majiayu000/vibe-research-before-design in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Vibe Research Before Design safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Vibe Research Before Design?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Vibe Research Before Design free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Vibe Research Before Design?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Vibe Research Before Design by majiayu000

Name: Vibe Research Before Design
Rating: 4.666666666666667 (3 reviews)
Author: majiayu000

File contents

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

Identify the design question — What decision are we making? What are the key constraints?
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?
Synthesize findings — Present a comparison table:

Option Adoption Mechanism Known Failures Fit
Make a recommendation — Based on evidence, not intuition. State confidence level.
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]

---name: vibe-research-before-designdescription: Dispatches SOTA research before proposing any new feature, architecture, or technology choice. Use when facing design decisions, not when implementing existing specs.--- # 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]

Frequently asked questions

Vibe Research Before Design