Prompt file imported from PauloHYBEX/Nexus-TCMS (.windsurf/workflows/templates/research-project/SUMMARY.md). Copyright stays with the author.

Summary Research Template

Name: SUMMARY
Author: PauloHYBEX

Template for .planning/research/SUMMARY.md — synthesis of all research findings into actionable guidance.

# Research Summary

**Domain:** [domain type]
**Researched:** [date]
**Confidence:** [HIGH/MEDIUM/LOW]

## Recommended Stack

### Primary Technologies

| Technology | Version | Role |
|------------|---------|------|
| [name] | [version] | [primary purpose in this project] |
| [name] | [version] | [primary purpose in this project] |
| [name] | [version] | [primary purpose in this project] |

### Key Stack Decisions

- **[Decision 1]:** [rationale — why this over alternatives]
- **[Decision 2]:** [rationale]
- **[Decision 3]:** [rationale]

## Table Stakes Features

Features that must be in v1 — users expect these by default:

- [ ] [Feature] — [one-line description]
- [ ] [Feature] — [one-line description]
- [ ] [Feature] — [one-line description]
- [ ] [Feature] — [one-line description]

## Key Architecture Decisions

### System Shape

[1-2 sentences describing the overall architecture pattern — e.g., "Monolithic Next.js app with server components, Postgres via Prisma ORM, and Stripe for payments."]

### Critical Boundaries

| Boundary | What It Separates | Why It Matters |
|----------|-------------------|----------------|
| [boundary] | [side A] / [side B] | [architectural significance] |
| [boundary] | [side A] / [side B] | [architectural significance] |

### Recommended Build Order

1. [Component] — [why first]
2. [Component] — [depends on #1]
3. [Component] — [depends on #1, #2]
4. [Component] — [depends on previous]

## Top Pitfalls

The most dangerous mistakes for this domain, ranked by severity:

| # | Pitfall | Severity | Prevention |
|---|---------|----------|------------|
| 1 | [mistake] | CRITICAL | [one-line prevention strategy] |
| 2 | [mistake] | HIGH | [one-line prevention strategy] |
| 3 | [mistake] | HIGH | [one-line prevention strategy] |
| 4 | [mistake] | MEDIUM | [one-line prevention strategy] |
| 5 | [mistake] | MEDIUM | [one-line prevention strategy] |

## Primary Recommendation

[One paragraph — the single most important takeaway from this research. What should the planner prioritize above all else?]

---
*Research summary for: [domain]*
*Researched: [date]*
*Sources: STACK.md, FEATURES.md, ARCHITECTURE.md, PITFALLS.md*

Purpose:

This file synthesizes the other 4 research files into a single actionable reference
The planner reads this file first — it should contain everything needed to start planning
Keep it concise: tables and bullet points, not paragraphs

Recommended Stack:

Only include the primary technologies — no supporting libraries
Key decisions explain WHY, not just WHAT

Table Stakes Features:

Pull directly from FEATURES.md Table Stakes section
These become the v1 must_haves in requirements

Key Architecture Decisions:

System shape in 1-2 sentences — enough for the planner to understand the pattern
Build order feeds directly into roadmap phase ordering

Top Pitfalls:

Maximum 5 — the most dangerous ones only
Each must have a one-line prevention strategy
These become verification checkpoints during execution

Primary Recommendation:

One paragraph, one decision
This is what the planner optimizes for

# Summary Research Template Template for `.planning/research/SUMMARY.md` — synthesis of all research findings into actionable guidance. <template> ```markdown # Research Summary **Domain:** [domain type] **Researched:** [date] **Confidence:** [HIGH/MEDIUM/LOW] ## Recommended Stack ### Primary Technologies | Technology | Version | Role | |------------|---------|------| | [name] | [version] | [primary purpose in this project] | | [name] | [version] | [primary purpose in this project] | | [name] | [version] | [primary purpose in this project] | ### Key Stack Decisions - **[Decision 1]:** [rationale — why this over alternatives] - **[Decision 2]:** [rationale] - **[Decision 3]:** [rationale] ## Table Stakes Features Features that must be in v1 — users expect these by default: - [ ] [Feature] — [one-line description] - [ ] [Feature] — [one-line description] - [ ] [Feature] — [one-line description] - [ ] [Feature] — [one-line description] ## Key Architecture Decisions ### System Shape [1-2 sentences describing the overall architecture pattern — e.g., "Monolithic Next.js app with server components, Postgres via Prisma ORM, and Stripe for payments."] ### Critical Boundaries | Boundary | What It Separates | Why It Matters | |----------|-------------------|----------------| | [boundary] | [side A] / [side B] | [architectural significance] | | [boundary] | [side A] / [side B] | [architectural significance] | ### Recommended Build Order 1. [Component] — [why first] 2. [Component] — [depends on #1] 3. [Component] — [depends on #1, #2] 4. [Component] — [depends on previous] ## Top Pitfalls The most dangerous mistakes for this domain, ranked by severity: | # | Pitfall | Severity | Prevention | |---|---------|----------|------------| | 1 | [mistake] | CRITICAL | [one-line prevention strategy] | | 2 | [mistake] | HIGH | [one-line prevention strategy] | | 3 | [mistake] | HIGH | [one-line prevention strategy] | | 4 | [mistake] | MEDIUM | [one-line prevention strategy] | | 5 | [mistake] | MEDIUM | [one-line prevention strategy] | ## Primary Recommendation [One paragraph — the single most important takeaway from this research. What should the planner prioritize above all else?] --- *Research summary for: [domain]* *Researched: [date]* *Sources: STACK.md, FEATURES.md, ARCHITECTURE.md, PITFALLS.md* ``` </template> <guidelines> **Purpose:** - This file synthesizes the other 4 research files into a single actionable reference - The planner reads this file first — it should contain everything needed to start planning - Keep it concise: tables and bullet points, not paragraphs **Recommended Stack:** - Only include the primary technologies — no supporting libraries - Key decisions explain WHY, not just WHAT **Table Stakes Features:** - Pull directly from FEATURES.md Table Stakes section - These become the v1 must_haves in requirements **Key Architecture Decisions:** - System shape in 1-2 sentences — enough for the planner to understand the pattern - Build order feeds directly into roadmap phase ordering **Top Pitfalls:** - Maximum 5 — the most dangerous ones only - Each must have a one-line prevention strategy - These become verification checkpoints during execution **Primary Recommendation:** - One paragraph, one decision - This is what the planner optimizes for </guidelines>

{ "prompt": "# Summary Research Template\n\nTemplate for `.planning/research/SUMMARY.md` — synthesis of all research findings into actionable guidance.\n\n<template>\n\n```markdown\n# Research Summary\n\n**Domain:** [domain type]\n**Researched:** [date]\n**Confidence:** [HIGH/MEDIUM/LOW]\n\n## Recommended Stack\n\n### Primary Technologies\n\n| Technology | Version | Role |\n|------------|---------|------|\n| [name] | [version] | [primary purpose in this project] |\n| [name] | [version] | [primary purpose in this project] |\n| [name] | [version] | [primary purpose in this project] |\n\n### Key Stack Decisions\n\n- **[Decision 1]:** [rationale — why this over alternatives]\n- **[Decision 2]:** [rationale]\n- **[Decision 3]:** [rationale]\n\n## Table Stakes Features\n\nFeatures that must be in v1 — users expect these by default:\n\n- [ ] [Feature] — [one-line description]\n- [ ] [Feature] — [one-line description]\n- [ ] [Feature] — [one-line description]\n- [ ] [Feature] — [one-line description]\n\n## Key Architecture Decisions\n\n### System Shape\n\n[1-2 sentences describing the overall architecture pattern — e.g., \"Monolithic Next.js app with server components, Postgres via Prisma ORM, and Stripe for payments.\"]\n\n### Critical Boundaries\n\n| Boundary | What It Separates | Why It Matters |\n|----------|-------------------|----------------|\n| [boundary] | [side A] / [side B] | [architectural significance] |\n| [boundary] | [side A] / [side B] | [architectural significance] |\n\n### Recommended Build Order\n\n1. [Component] — [why first]\n2. [Component] — [depends on #1]\n3. [Component] — [depends on #1, #2]\n4. [Component] — [depends on previous]\n\n## Top Pitfalls\n\nThe most dangerous mistakes for this domain, ranked by severity:\n\n| # | Pitfall | Severity | Prevention |\n|---|---------|----------|------------|\n| 1 | [mistake] | CRITICAL | [one-line prevention strategy] |\n| 2 | [mistake] | HIGH | [one-line prevention strategy] |\n| 3 | [mistake] | HIGH | [one-line prevention strategy] |\n| 4 | [mistake] | MEDIUM | [one-line prevention strategy] |\n| 5 | [mistake] | MEDIUM | [one-line prevention strategy] |\n\n## Primary Recommendation\n\n[One paragraph — the single most important takeaway from this research. What should the planner prioritize above all else?]\n\n---\n*Research summary for: [domain]*\n*Researched: [date]*\n*Sources: STACK.md, FEATURES.md, ARCHITECTURE.md, PITFALLS.md*\n```\n\n</template>\n\n<guidelines>\n\n**Purpose:**\n- This file synthesizes the other 4 research files into a single actionable reference\n- The planner reads this file first — it should contain everything needed to start planning\n- Keep it concise: tables and bullet points, not paragraphs\n\n**Recommended Stack:**\n- Only include the primary technologies — no supporting libraries\n- Key decisions explain WHY, not just WHAT\n\n**Table Stakes Features:**\n- Pull directly from FEATURES.md Table Stakes section\n- These become the v1 must_haves in requirements\n\n**Key Architecture Decisions:**\n- System shape in 1-2 sentences — enough for the planner to understand the pattern\n- Build order feeds directly into roadmap phase ordering\n\n**Top Pitfalls:**\n- Maximum 5 — the most dangerous ones only\n- Each must have a one-line prevention strategy\n- These become verification checkpoints during execution\n\n**Primary Recommendation:**\n- One paragraph, one decision\n- This is what the planner optimizes for\n\n</guidelines>", "variables": [], "notes": "Template for `.planning/research/SUMMARY.md` — synthesis of all research findings into actionable guidance.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/PauloHYBEX/Nexus-TCMS", "path": ".windsurf/workflows/templates/research-project/SUMMARY.md", "ref": "af66d4e66d7443d045e74bafc302cd998ceb5b99", "url": "https://github.com/PauloHYBEX/Nexus-TCMS/blob/af66d4e66d7443d045e74bafc302cd998ceb5b99/.windsurf/workflows/templates/research-project/SUMMARY.md", "key": "PauloHYBEX/Nexus-TCMS/.windsurf/workflows/templates/research-project/SUMMARY.md" } } }

SUMMARY

About

Summary Research Template

Use it

Manifest

Reviews