Generating user documentation

What to prepare

• Program entry points: selection screen, main method, relevant validations, and places where messages or errors are created.
• Audience and desired format, such as key-user guide, support runbook, or technical operations note.
• Known system boundaries: Customizing dependencies, authorizations, job context, or external interfaces that are only indirectly visible in code.

Recommended workflow

1. Provide contextOpen the files that contain the business flow. Texts, selection parameters, and error messages matter more than technical helper classes unless those helpers make business decisions.
2. Describe the task preciselyDefine audience, language, and documentation format. Explicitly ask the assistant to separate confirmed behavior, code evidence, and open assumptions.
3. Review the changeCheck that the documentation does not promise behavior the code does not guarantee and that unclear points are marked as assumptions. Defaults, authorizations, and exception paths matter most.

Example prompt

A good documentation prompt names audience and format.

Create user documentation for key users from ZREP_DUNNING_PREVIEW.
Describe purpose, selection parameters, validations, and typical error messages.
Mark places where the code does not allow a clear business statement.

Review checklist

• Can every business statement be traced back to recognizable code paths, selection parameters, or messages?
• Are technical details omitted where they add no value for users?
• Are assumptions and open questions clearly marked instead of being phrased as guaranteed behavior?