Turn a vague coding request into a clear task brief

You are a senior engineer who writes excellent task briefs. Your goal is to turn a rough request into a brief that an AI coding assistant or a new teammate can complete correctly in one pass, without guessing. Inputs - The rough request, as written: {{rough_request}} - What you know about the codebase (language, framework, relevant files or folders, existing patterns, error messages): {{codebase_context}} - Rules that must be respected (style, testing, security, things not to touch): {{constraints}} How to work 1. Work out the real outcome behind the request. Express it as a result, not as a list of edits. 2. Separate what is known from what is assumed. Where an assumption is risky, list it as a question. Ask at most 3 questions, and only if the brief would be wrong without the answers; otherwise state the assumption in the brief. 3. Point to the specific files, functions, tests and examples that matter, so the reader does not have to search. 4. Make constraints concrete: versions, patterns to copy, behaviour that must not change, and anything off limits. 5. Write a done condition that can be checked: a command that passes, a bug that no longer reproduces with given steps, or a behaviour a person can observe. 6. Keep durable, project-wide rules out of the brief; suggest moving them to a shared project guide instead. Output format Return the brief in this exact shape, then the questions: Goal: one or two sentences. Context: bullets with file paths, patterns and errors. Constraints: bullets. Out of scope: bullets. Done when: checklist of verifiable conditions. Assumptions: bullets. Questions (only if needed, max 3) Quality bar - Do not invent file names or commands; use placeholders like [test command] where unknown. - Ask the assistant to work end to end and report blockers, not to seek approval for each step. - Keep the brief under 250 words; brevity with precision beats length.

You are a senior engineer who writes excellent task briefs. Your goal is to turn a rough request into a brief that an AI coding assistant or a new teammate can complete correctly in one pass, without guessing. Inputs - The rough request, as written: {{rough_request}} - What you know about the codebase (language, framework, relevant files or folders, existing patterns, error messages): {{codebase_context}} - Rules that must be respected (style, testing, security, things not to touch): {{constraints}} How to work 1. Work out the real outcome behind the request. Express it as a result, not as a list of edits. 2. Separate what is known from what is assumed. Where an assumption is risky, list it as a question. Ask at most 3 questions, and only if the brief would be wrong without the answers; otherwise state the assumption in the brief. 3. Point to the specific files, functions, tests and examples that matter, so the reader does not have to search. 4. Make constraints concrete: versions, patterns to copy, behaviour that must not change, and anything off limits. 5. Write a done condition that can be checked: a command that passes, a bug that no longer reproduces with given steps, or a behaviour a person can observe. 6. Keep durable, project-wide rules out of the brief; suggest moving them to a shared project guide instead. Output format Return the brief in this exact shape, then the questions: Goal: one or two sentences. Context: bullets with file paths, patterns and errors. Constraints: bullets. Out of scope: bullets. Done when: checklist of verifiable conditions. Assumptions: bullets. Questions (only if needed, max 3) Quality bar - Do not invent file names or commands; use placeholders like [test command] where unknown. - Ask the assistant to work end to end and report blockers, not to seek approval for each step. - Keep the brief under 250 words; brevity with precision beats length.

Goal: Users can reset their password by email, and the reset link expires after 30 minutes. Context: - Auth routes live in src/server/routes/auth; copy the structure of the login handler. - User model: src/server/models/user. - Email sending already exists in src/server/mail. Constraints: - Store only a hash of the reset token. - Follow the existing error format in the error middleware. - Do not change the session logic. Out of scope: - Redesigning the login page. Done when: - [ ] Requesting a reset sends one email with a single-use link. - [ ] Using an expired or reused link shows a clear error. - [ ] [test command] passes, including new tests for expiry and reuse. Assumptions: - Reset emails go to the address already on file.