Why this category matters Link to heading

Feature planning quality depends on two things:

  • Evaluating implementation options with explicit tradeoffs.
  • Converting feedback into clear specifications.

The Analyze functionality category covers both.

Use cases Link to heading

  • Product and engineering teams shaping feature direction
  • Developers turning issues and feedback into build-ready specs
  • Developers who need a repeatable, structured planning workflow

The 2 examples in this category Link to heading

  1. Exploring potential feature implementations
  2. Analyzing and incorporating user feedback

Diagram: Feedback-to-spec pipeline Link to heading

U P - - - E - - D - - - s r x r e i r s i p o t r a p s r r o e e m l p r e f r o i r a n p o t a c t o l s f i c t a r i d o b u k e t t i c e o e m f l t s e i i m t n o m e e i d z o e i f e a m t b e n n m A f n t n e a s t p / s d u s c b l B a r t k y e / t e s m C i / a s e o s d n i n n p o d g t e c n a c s i a t i s l i f s o i u n c e a s p t a i t o h n s

1) Exploring potential implementations Link to heading

Cookbook scenario:

  • A dashboard needs a Recent Items section with requirements for sorting, performance, and near real-time updates.

Prompt pattern:

Given the criteria in Issue #753, list options for implementation
and tradeoffs for each option.

Typical response structure in cookbook:

  • Option list (client-side, server-side, caching, hybrid, event-driven).
  • Pros and cons for each.
  • Suggested recommendation.

How to use this safely:

  • Ask follow-up prompts for operational constraints (cost, infra complexity, failure modes).
  • Request comparison table with measurable criteria.
  • Validate recommendation against acceptance criteria.

2) Analyzing and incorporating feedback Link to heading

Cookbook includes two workflows.

Workflow A: triage feedback by reactions and sentiment.

Prompt pattern:

Find the issues with the feedback label that have the most reactions,
and categorize them based on sentiment.

What a useful triage output looks like:

Top feedback issues by reaction count:

1. "Dashboard loads too slowly on large datasets" — 42 👍 — Sentiment: Negative (performance frustration)
   Themes: latency, pagination, data volume

2. "Export to CSV is missing column headers" — 31 👍 — Sentiment: Negative (data correctness)
   Themes: export quality, usability

3. "Dark mode support requested" — 28 👍 — Sentiment: Positive request (feature desire)
   Themes: accessibility, UI preference

This triage output lets you answer: what is the most impactful issue to build next? Validate the sentiment categories against the actual issue thread before acting on them.

Workflow B: generate feature spec for selected issue.

Prompt pattern:

Write a feature specification for Issue #426.

Typical feature spec sections from the example:

  • Description
  • Problem
  • Solution
  • Feature details
  • Backward compatibility
  • Documentation updates
  • Testing scope
  • Benefits and risks

Strong follow-up prompts for this category Link to heading

  • Convert options into a decision matrix with scoring.
  • List assumptions and unknowns that require validation spikes.
  • Produce rollout and rollback plans.
  • Generate acceptance tests directly from the spec.

Worked example Link to heading

Scenario Link to heading

Feature request: add “Recent items” to dashboard with near real-time updates.

Prompt 1 (options) Link to heading 

Given these constraints:
- p95 page load under 2s
- no new paid infrastructure this quarter
- data freshness under 30 seconds

List 3 implementation options with tradeoffs and an explicit recommendation.

Prompt 2 (decision matrix) Link to heading 

Convert those options into a decision matrix with criteria:
performance, complexity, operational risk, and implementation effort.
Score each criterion from 1-5 and justify each score.

Prompt 3 (spec) Link to heading 

Write a feature specification for the recommended option.
Include:
- problem statement
- user stories
- API or data model changes
- rollout plan
- rollback plan
- acceptance tests

Validation checklist Link to heading

  • Assumptions and unknowns are explicit.
  • Recommendation aligns with constraints.
  • Spec is testable and implementation-ready.

Key takeaways Link to heading

  • This category is a bridge between discovery and implementation.
  • Tradeoff-aware prompts produce better architectural choices.
  • Feedback triage should feed directly into structured feature specs.
  • Follow-up prompts should force assumptions, risks, and testability into the plan.

References Link to heading