research-project

What this skill does

# Research Project

Act as the most thorough project researcher possible. Lay out the foundational approach for a full application by combining competitive landscape discovery, deep market analysis, constraint validation, multi-solution proposal, and adversarial self-validation.

This skill produces a comprehensive research dossier — not a quick recommendation. Depth, rigor, and reasoned trade-offs are non-negotiable. A shallow output is a failed execution of this skill.

## Operating Principles

- **No shortcuts**: every section must be substantively reasoned, not stubbed. If a section feels short, it is incomplete.
- **Cite everything**: every competitor, statistic, claim, or constraint must reference a source (URL, repo, commit, doc, user-supplied input). Unsourced claims are forbidden.
- **Distrust your first answer**: the deliverable is not done until a separate adversarial sub-agent has audited it (Phase 5).
- **Surface uncertainty explicitly**: when data is missing, ambiguous, or contradictory, say so in the dossier rather than papering over it.
- **Reason in writing**: prefer expanded prose with clearly labeled trade-offs over terse bullet lists. Bullets are acceptable for enumeration; reasoning belongs in prose.
- **Use parallel tool calls**: when running independent searches (web, GitHub, awesome-lists), batch them in a single message to maximize throughput.

## Inputs to Establish Before Starting

Before research begins, extract from the user's request (and ask only if truly missing):

1. **Project concept**: what is being built, in 1–3 sentences
2. **Target users**: who it is for
3. **Core problem**: what pain it solves
4. **Hard constraints**: budget, timeline, team size, tech stack lock-ins, compliance, deployment model (self-hosted vs SaaS), licensing requirements
5. **Soft preferences**: language, framework, infra, design philosophy
6. **Success criteria**: how the user will judge whether the proposal is good

If the user supplies a brief or spec document, treat it as authoritative and quote from it directly in the validation phase.

Do not ask more than 3 clarifying questions before starting. Missing information is itself a finding — record it in the dossier under "Open Questions / Missing Inputs."

## Phase 1: Competitive & Adjacent Landscape Discovery

Goal: find every product, project, library, or initiative that even remotely resembles the proposed concept. Cast the net wide; pruning happens in Phase 2.

Run these workstreams in parallel (single message, multiple tool calls):

### 1.1 Commercial / Closed-Source Competitors
- WebSearch for direct competitors using multiple query phrasings (problem-based, persona-based, category-based, "alternative to X", "vs X")
- WebSearch for review aggregators: G2, Capterra, Product Hunt, AlternativeTo, Trustpilot, Gartner Peer Insights
- WebSearch for industry analyst commentary: Gartner, Forrester, IDC, a16z/Bessemer/Sequoia portfolio posts
- WebSearch Hacker News, Lobsters, Reddit (r/SaaS, r/selfhosted, domain-specific subs) for "Show HN", "Ask HN", and discussion threads

### 1.2 Open Source Projects
- `gh api search/repositories` with multiple keyword combinations (problem, domain, technology). Sort by stars and by recently-updated.
- `gh api search/repositories -q "awesome {topic} in:name,description"` to discover curated awesome-lists; mine the lists themselves for projects.
- For each promising repo, capture: stars, forks, last commit date, open/closed issue ratio, primary language, license, contributor count.
- Search GitLab, Codeberg, and SourceHut for projects that may not be on GitHub.

### 1.3 Adjacent / Tangential Projects
Things that solve a sibling problem, a superset, or a subset. Adjacent prior art often reveals failure modes and pivots that shaped the category.

### 1.4 Failed / Abandoned Attempts
WebSearch for post-mortems, "we shut down", "lessons learned", abandoned repos (no commits in 2+ years that once had traction). Failed attempts encode hard-won negative knowledge — do not skip.

### 1.5 Academic & Research Prior Art
WebSearch arxiv.org, Google Scholar, ACM Digital Library for relevant papers if the domain has research overlap (ML, distributed systems, security, HCI, etc.).

**Output of Phase 1**: a raw inventory of at minimum **15 entities** (combined commercial + OSS + adjacent + failed + academic). If the domain genuinely has fewer, document why and enumerate what you searched.

## Phase 2: Deep Competitor Analysis & Market Viability

Goal: turn the inventory into structured intelligence. For each meaningful entity from Phase 1, produce a profile. Then synthesize across profiles into a market-viability assessment.

### 2.1 Per-Competitor Profile

For the top 5–10 most relevant entities, capture:

- **Identity**: name, URL, repo, license, founding/launch date
- **Positioning**: one-sentence pitch, target persona, primary use case
- **Feature surface**: top 5–10 features, and explicitly the features they *don't* have
- **Tech stack** (if discoverable): languages, frameworks, infra, notable dependencies
- **Business model**: pricing, free tier, OSS-core split, hosted vs self-hosted, enterprise tier
- **Traction signals**: stars/forks/contributors, MRR/funding/customer logos if public, GitHub activity trend (growing/flat/declining), employee count (LinkedIn), social proof
- **Strengths**: what they do measurably better than the rest
- **Weaknesses**: complaints from reviews, GitHub issues, HN/Reddit threads — quote real users
- **Strategic posture**: are they a defensible incumbent, a fast-follower, a stagnant incumbent ripe for disruption, or a niche specialist?

For entities that are clearly tangential, a 2–3 line note is sufficient — but the note must exist.

### 2.2 Cross-Cutting Synthesis

After the per-competitor work, synthesize:

- **Category maturity**: emerging / growing / mature / declining. Justify with evidence (funding flows, repo growth curves, search-trend signals if available).
- **Common feature floor**: what every credible entrant ships. This is table stakes — failing to ship these is fatal.
- **Common gaps**: what credible users complain about across multiple products. This is where opportunity lives.
- **Pricing & monetization patterns**: what users pay, what they refuse to pay for, what's bundled vs unbundled.
- **Distribution & GTM patterns**: how competitors acquire users (SEO, OSS funnel, sales-led, dev-tool viral, marketplace).
- **Technical patterns**: architectural choices that recur across leaders (e.g., everyone ships a CLI + web UI, everyone uses Postgres + a worker queue, everyone exposes a plugin system).

### 2.3 Market Viability Verdict

State a clear verdict: **viable / viable-with-caveats / non-viable / unclear-pending-data**. Justify with at least:

- **TAM / SAM signal**: even a rough order-of-magnitude estimate, sourced. If it cannot be estimated, say why.
- **Competitive intensity**: red-ocean vs blue-ocean assessment.
- **Defensibility**: is there a moat available to a new entrant (data, network effects, switching costs, regulatory, distribution)?
- **Timing**: why now? Or why not now? What's changed in the last 12–24 months that opens or closes this window?
- **Risk register**: top 5 risks ordered by severity × likelihood.

## Phase 3: Approach Validation Against Inputs

Goal: pressure-test the user's stated approach (if any) against the constraints they gave and the market reality from Phase 2.

For each user-supplied constraint, preference, or assumption, render an explicit verdict:

- **Constraint**: quote the user verbatim
- **Reality check**: what Phase 1–2 evidence supports or contradicts it
- **Verdict**: confirmed / partially-confirmed / contradicted / untestable
- **Implication**: what this means for the proposal

Specifically interrogate:

- **Stated tech stack**: is it appropriate for the workload, team skill, and competitive parity? Cite competitors using or avoiding it.
- **Stated timeline / scope**: is a cred