Research Md Maker

Step 2: Cast a Wide Net

Before writing, brainstorm the broadest possible landscape of segments. The goal is diversity and coverage — not depth yet.

Segmentation strategies to consider (use whichever fit the topic):

• By category or type
• By geography or market
• By size or scale (enterprise vs SMB vs individual)
• By approach or methodology
• By stage or maturity (emerging vs established vs declining)
• By stakeholder or user type
• By price tier or business model
• By technology or platform
• By use case or application
• By risk profile or trade-off

Present the proposed segments to the user for confirmation before writing. Aim for 6-12 clean, non-overlapping segments that collectively cover the full landscape.

Step 3: Survey Criteria

After segments are confirmed, identify 6–10 (or more) criteria that matter for evaluating and comparing these segments. These criteria will be used by the analyzer skill to score and rank segments.

Criteria should be:

• Relevant to the decision or question at hand
• Differentiating — criteria where segments actually vary
• Measurable — can be assessed with evidence, not gut feeling

Present the proposed criteria to the user for confirmation. Include them in the research file under a dedicated section so the analyzer has them ready.

Step 4: Write the Research File

Structure:

# [Topic] Research

**Author:** [Name]
**Date:** [YYYY-MM-DD]

## Overview

[2-3 sentences framing the topic and why it matters. State the research question.]

## Landscape

[One paragraph summarizing the full range of what exists. Set up the segments.]

## [Segment 1 Name]

**What it is:** [1-2 sentences]
**Key players/examples:** [Names, links if available]
**Strengths:** [Bullets]
**Weaknesses:** [Bullets]
**Relevance to Pocket Space:** [1 sentence — how this connects]

## [Segment 2 Name]
[Same structure]

...

## Proposed Evaluation Criteria

[6-10 criteria for comparing these segments. Each with a one-line rationale.]

| # | Criterion | Why It Matters |
|---|---|---|
| 1 | [Name] | [One-line rationale] |
| 2 | [Name] | [One-line rationale] |
| ... | ... | ... |

## Key Takeaways

- [3-5 bullets distilling the most important findings]

## Open Questions

- [What this research didn't answer]
- [What needs deeper investigation]

## Sources

- [List of sources used]

Step 5: File Placement

• If a topic folder with a Research/ subfolder already exists for this topic, place the .md file inside Research/ (or a nested subfolder within it)
• If this is the start of a new research effort that will eventually produce a .docx deliverable, create the topic folder structure:

  [Department_Folder]/
  └── [Topic_of_Research]/
      └── Research/
          ├── README.md
          └── [Topic]_Research.md   ← This file goes here
  

  The .docx will be added later by the research-synthesizer skill at the top level of the topic folder.
• If this is standalone research with no planned .docx, place it directly in the appropriate department research folder
• Name: [Topic]_Research.md using underscore convention
• Follow naming conventions from contribution guidelines

Sources & Citations (Vancouver Style)

All research files use Vancouver citation style — numbered references in order of first appearance.

Inline: Use superscript or bracketed numbers in the text where a claim is made.

• Example: Bonding curves were first proposed in 2017 [1] and later adopted in DeFi protocols [2].

Reference list: A numbered ## References section at the end of the document.

• Format: [Number] Author(s). Title. Source/Publication. Year. URL (if applicable).
• Example:

  ## References
  [1] de la Rouviere S. Tokens 2.0: Curved token bonding. Medium. 2017. https://example.com
  [2] Zargham M. An introduction to bonding curves. BlockScience. 2019. https://example.com
  

Rules:

• Every factual claim, statistic, or finding must have a numbered citation
• Numbers are assigned in order of first appearance in the text
• If a finding cannot be sourced, explicitly mark it as [Author's analysis]
• Prefer primary sources over secondhand summaries

Segment Quality Checklist

Before finalizing segments, verify:

• Segments are mutually exclusive — no overlap
• Segments are collectively exhaustive — no major gap in coverage
• At least one segment is unconventional — something the user might not have considered
• Each segment can stand alone as a meaningful category
• Segments are at roughly the same level of abstraction