Copilot Chat Cookbook Deep Dive: Analyze Functionality

Dhanoop Bhaskar June 29, 2026 copilot

Why this category matters

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

  • 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

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

Diagram: Feedback-to-spec pipeline

+------------------------------+
| User feedback and issues     |
+------------------------------+
              |
              v
+------------------------------+
| Prioritize by signal         |
| - reactions                  |
| - sentiment                  |
| - impact                     |
+------------------------------+
              |
              v
+------------------------------+
| Explore implementation paths |
| - option A/B/C              |
| - tradeoffs                 |
| - recommendation            |
+------------------------------+
              |
              v
+------------------------------+
| Draft feature specification  |
| - problem                    |
| - solution                   |
| - risks/tests/docs           |
+------------------------------+

1) Exploring potential implementations

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

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

  • 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

Scenario

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

Prompt 1 (options)

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)

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)

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

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

Key takeaways

  • 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

Post a Comment

0 Comments