Feature Request to Technical Acceptance Checklist

The Prompt

You are an engineering planning assistant. Turn the feature request into a technical acceptance checklist that a developer can actually build against.

FEATURE REQUEST:
{{feature_request}}

PRODUCT CONTEXT:
{{product_context}}

USER OR BUSINESS GOAL:
{{user_or_business_goal}}

CONSTRAINTS:
{{constraints}}

WORKFLOW SURFACE:
{{workflow_surface}}

Return exactly:
1) Interpreted feature goal
2) What is still unclear or risky
3) Technical acceptance checklist
   - grouped into user-visible behavior
   - failure or empty states
   - permission, rollout, or data conditions if relevant
4) Edge cases and non-goals
5) Dependencies or approvals needed
6) Best next prompt or handoff for the named workflow surface

Rules:
- Do not convert vague intent into fake certainty.
- Write acceptance items so they can be checked as pass/fail statements.
- Separate user-visible behavior from implementation assumptions.
- If the request bundles multiple features, split them before writing the checklist.

When to Use

Use this when a feature idea exists, but the technical team still needs a clearer definition of done. It is especially useful when someone has a ticket, note, or chat message and needs to turn it into something a developer or coding agent can actually verify.

Good scenarios:

• a product note is short but implementation work is non-trivial
• a feature sounds simple until you start listing edge cases
• a coding assistant needs better acceptance criteria before it starts editing files
• the team wants to expose hidden assumptions before sizing or implementation begins

Variables

Variable	Description	Good input examples
feature_request	The raw feature ask as written	roadmap note, ticket, Slack message, PRD excerpt
product_context	The current system or page this affects	billing settings page, API endpoint, onboarding flow
user_or_business_goal	The outcome the feature should create	reduce setup friction, improve admin control, cut support tickets
constraints	Limits that shape implementation	no schema changes, mobile-first UI, must preserve current API contract
workflow_surface	Where the output will be used next	CLI agent, IDE assistant, planning/review app, human handoff

Tips & Variations

• Include known non-goals early. They often save more time than adding extra detail later.
• Ask for “group acceptance items by user journey” when the feature spans several screens or states.
• If approvals matter, specify who must sign off on behavior, copy, or rollout.
• After the checklist is approved, follow with a planning prompt that turns it into a file-level implementation brief.
• If the request bundles several ideas, ask the model to split them into “this release” and “later” before writing the checklist.

Example Output

Interpreted feature goal: let admins pause new user invites without breaking existing user access or audit visibility.

Technical acceptance checklist: admins can toggle invite state, paused state is visible in settings, invite attempts fail with the approved message, and audit logs record who changed the state.

Dependencies: final copy approval and confirmation that no API schema changes are allowed in this release.

Related site references

• Prompt: Coding Agent Task Brief
• AI Use Case: AI-Assisted Product Spec to Engineering Execution