prompts.chatprompts.chat
Login
All classifiers
ChoiceFeedback & research

Feature request specificity

Tell whether a feature request explains the user's problem, only proposes a solution, or is a vague wish.

F@f

Problem

Product teams get requests like "add a button for X" with no context. Building exactly what's asked often misses the real need.

Goal

Keep requests with a concrete use case for planning, and ask the others what they are trying to achieve.

Input / state

The request text.

request
The feature request as written.

Decision question

ChoiceQuestion key specificity

How much does this request explain the problem the user is trying to solve?

Options

  • concrete_use_caseDescribes a situation, a goal and why the current product falls short.
  • solution_onlyAsks for a specific feature or change without saying what it's for.
  • vague_wishA general wish without a specific problem or solution.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

  • Add to research backlogChoice is concrete_use_case and confidence meets your threshold.
  • Ask for the use caseChoice is solution_only and confidence meets your threshold.
  • Count toward themeChoice is vague_wish and confidence meets your threshold.
  • Researcher reads itConfidence is below your threshold: probability is spread across options.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "request": "We show clients a timeline every Monday; today we export to a spreadsheet and draw bars by hand. A Gantt view would remove that step."
}

Outcome

Illustrative
Add to research backlog

Choice is concrete_use_case and confidence meets your threshold.

Why

Situation, goal and current gap.

Using it well

  • Use one open question to ask for the use case: "What were you trying to do when you needed this?"

Request definition

POST https://api.typesafe.ai/v1/systemone
{
  "model": "jev-latest",
  "state": {
    "request": "<request>"
  },
  "questions": {
    "specificity": {
      "type": "choice",
      "instructions": "How much does this request explain the problem the user is trying to solve?",
      "criteria": {
        "concrete_use_case": "Describes a situation, a goal and why the current product falls short.",
        "solution_only": "Asks for a specific feature or change without saying what it's for.",
        "vague_wish": "A general wish without a specific problem or solution."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.

Version History

v1Current Versionabout 8 hours ago@f

Initial version

Comments (0)