Password Reset Flow Documentation Prompt

This prompt is designed for product security engineers and technical writers who need to produce a complete, unambiguous, and secure documentation artifact for a self-service password reset flow. The job-to-be-done is converting a set of architectural decisions and security parameters—such as token generation method, delivery channel, and expiration window—into a single, structured document that can be handed directly to a frontend team, a backend implementer, and a security reviewer. The ideal user already knows the flow's technical details but needs the prompt to enforce the correct structure, surface missing edge cases, and produce language that leaves no room for implementation guesswork.

Use this prompt when you have finalized the technical design of your reset flow and need to generate the official specification. The prompt requires concrete inputs: the token format (e.g., JWT, opaque), the delivery mechanism (e.g., email, SMS), the exact expiration period, the account lockout policy, and the post-reset session behavior. It is not a design tool. Do not use it to brainstorm flow options or to make security decisions. It is also unsuitable for documenting flows that include novel, non-standard cryptographic handshakes without providing those details explicitly in the [INPUT] context. The prompt's value is in its exhaustive checklist of required sections, its strict output schema, and its built-in checks for common documentation failures like missing rate-limiting descriptions or ambiguous error messages.

Before executing this prompt, ensure you have the complete [INPUT] data package ready. The prompt will fail to produce a safe document if it must hallucinate security parameters. After generation, the output must be treated as a draft that requires human review, specifically for the accuracy of the token generation mechanism and the correctness of the lockout integration logic. The next step is to run the generated document through the provided evaluation criteria to check for enumeration vulnerabilities and missing rate-limiting sections before publishing it to your developer portal.

This prompt template is designed to produce a comprehensive password reset flow document suitable for internal security review, API documentation, and integration guides. It takes structured inputs about your system's token generation, delivery mechanism, expiration policies, and account lockout behavior, then generates a complete reference with sequence descriptions, error handling, and vulnerability mitigation checks. The output is intended to be a first draft that a security engineer or technical writer can refine, not a final publishable document without human review.

textCopy
You are a technical documentation specialist with expertise in authentication security and API design. Your task is to generate a complete password reset flow documentation page from the provided specifications.

## INPUT SPECIFICATIONS
[INPUT]

## DOCUMENTATION CONTEXT
[CONTEXT]

## REQUIRED OUTPUT STRUCTURE
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## REFERENCE EXAMPLES
[EXAMPLES]

## AVAILABLE TOOLS
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Parse the [INPUT] specifications to extract all password reset flow parameters including token generation method, delivery channel, expiration window, and lockout thresholds.
2. Generate documentation following the [OUTPUT_SCHEMA] structure exactly. Do not omit any required sections.
3. For each step in the flow, describe the sequence of events, the actors involved (user, client application, auth server, email service), and the data exchanged.
4. Include explicit error handling for every failure point: invalid token, expired token, reused token, rate-limited request, account not found, and delivery failure.
5. Add a dedicated security considerations section that addresses enumeration vulnerabilities, rate limiting, token entropy, and secure delivery practices.
6. If [RISK_LEVEL] is "high" or "critical", include a human review checklist at the top of the document with specific items that must be verified before publication.
7. Use the [EXAMPLES] to match the organization's documentation style, tone, and level of technical detail.
8. Apply all [CONSTRAINTS] strictly. If a constraint conflicts with the input specifications, flag the conflict in a "Documentation Notes" section rather than silently resolving it.
9. If [TOOLS] includes a validation function, run it against the generated document and report any failures.
10. Do not invent token formats, expiration values, or lockout policies not present in [INPUT]. If a required detail is missing, mark it with "[TO BE SPECIFIED]" and add it to a "Gaps Requiring Product Input" section.

To adapt this template for your own use, replace each square-bracket placeholder with concrete values. The [INPUT] placeholder should contain your system's specific password reset parameters as structured data (JSON works well). The [OUTPUT_SCHEMA] should define the exact sections you need—at minimum, include flow overview, step-by-step sequence, error reference, security considerations, and integration requirements. The [CONSTRAINTS] field is where you enforce organizational rules such as "never document internal token structure" or "always include rate limit headers in error responses." For high-risk authentication flows, set [RISK_LEVEL] to "high" and ensure the human review checklist is populated with specific verification items like "confirm no user enumeration is possible via timing analysis" and "verify token entropy meets organizational minimum of 128 bits." After generating the document, run it through your security review process and validate all code samples against your actual API before publication.

This prompt is designed to be called programmatically as part of a documentation generation or audit pipeline, not as a one-off chat interaction. The primary integration point is a CI/CD step that triggers after an API specification change, a security review ticket, or a scheduled documentation freshness check. The harness should supply the prompt with a structured [INPUT] containing the current flow specification—endpoints, request/response schemas, token generation logic, and rate limit configurations—sourced from an OpenAPI spec, an internal feature flag manifest, or a product requirements document. Because the output is a complete documentation page, the harness must validate that every required section (token generation, email delivery, expiration windows, account lockout integration) is present before publishing.

Wire the prompt into an application using a validate-then-review pattern. First, call the model with the prompt template and capture the full markdown output. Immediately run a structural validator that checks for the presence of required H2 sections (## Token Generation, ## Email Delivery, ## Expiration Windows, ## Account Lockout Integration) and required subsections like ### Rate Limiting and ### Enumeration Prevention. If the validator fails, retry the prompt once with an explicit error message appended to the [CONSTRAINTS] field, e.g., 'The previous output was missing the Account Lockout Integration section. Regenerate the full document.' If the second attempt fails, escalate to a human reviewer queue. For model choice, use a model with strong instruction-following and long-context handling (e.g., claude-sonnet-4-20250514 or gpt-4o); avoid smaller models that may drop sections or flatten nested markdown structure. Log every generation attempt, the validator result, and the final published version to an audit table for traceability.

After structural validation passes, route the output to a security review stage. This stage should use a separate evaluation prompt (from the LLM Judge and Evaluation Rubrics pillar) to score the documentation against the specific security checks listed in the playbook: enumeration vulnerability coverage, rate limiting explicitness, and token expiration clarity. If the eval score falls below a defined threshold (e.g., 4 out of 5 on a security completeness rubric), flag the document for human security review before publication. Do not auto-publish password reset documentation without this security gate. For teams using a docs-as-code workflow, the final output should be committed as a markdown file to the documentation repository with a commit message that includes the prompt version, model used, and eval score. Avoid wiring this prompt directly to a public-facing CMS without the validation and review stages; the risk of publishing incomplete or insecure recovery documentation is too high.