Pdd Research.prompt

---
agent: agent
description: "Research a problem space, evaluate approaches, and decide what to build"
---

# Research Before Building

This is the Copilot adapter for the shared `Research` workflow in `core/workflows/research.md`. Keep shared workflow behavior aligned there; this file exists to preserve Copilot-specific frontmatter, `#file:` references, and `/pdd-*` command wording.

## Purpose

Explore the problem space before implementation so the team can adopt, extend, compose, or build with intention.

Research exists to prevent waste. Do not jump straight from "I want feature X" to implementation prompts when the real question is still "what problem are we solving, and what already exists?"

## Use When

- The user is unsure which approach to take.
- Existing tools or libraries may already solve the problem.
- The feature is expensive or risky enough to justify pre-work.
- The team needs a build-vs-adopt decision with explicit tradeoffs.

## Inputs

- Problem statement
- constraints
- success criteria
- any candidate tools or approaches already under consideration

## Step 1: Clarify The Problem

Ask conversationally:

- What problem are you trying to solve?
- Who encounters this problem and when?
- What happens today without this?
- What does success look like?

If the user already has a clear, narrow need, skip most of the discovery and move directly to scanning for solutions.

## Step 2: Surface Constraints

Capture the constraints that shape the decision:

- performance or scale requirements
- security, privacy, or compliance requirements
- integration points with the existing codebase
- timeline or effort budget
- things that are explicitly out of scope

These notes should be reusable later in `/pdd-plan`, `/pdd-prompts`, and `/pdd-review`.

## Step 3: Scan For Existing Solutions

Check these sources in order:

1. Existing codebase
2. Prompt history and templates
3. Package or tool ecosystem
4. MCP servers or external capabilities
5. Framework built-ins

Look for solutions that are current, maintained, and compatible with the project constraints.

## Step 4: Evaluate The Approaches

Use these four buckets:

| Approach | When to use | Example |
|---|---|---|
| **Adopt** | An existing tool already fits | Use zod for validation |
| **Extend** | Something close exists but needs small customization | Fork a template, add constraints |
| **Compose** | Several existing pieces fit together well | Wrap two tools behind one local interface |
| **Build** | Nothing fits, or constraints rule out the existing options | Implement a custom solution |

Present findings in a durable format: