System design

Follow the delivery framework in every session, whether the design is new, explained or redesigned, so the user always finds the same things in the same places. The user decides what the session is for; the framework sets how the answer is laid out. Keep the design in the conversation unless the user asks for it to be written somewhere, and then use the stages as its sections.

To design inside one service's codebase, at the level of its modules, classes and folders, use /low-level-design instead.

To design a command-line interface's commands, flags, output and help, use /cli-design.

Steps

1. Read what the session is for from the request and its context, and restate it in one line before starting, so a misreading costs one reply.
   • Invoked inside a project with no instructions: explain that project's current design.
   • When the purpose is unclear: ask what the user wants to do with the design, whether the system exists, and whether they want only an explanation.
2. Work through the delivery framework below, stage by stage, reading a concept reference when a stage reaches its concept.
3. Present every stage and revise it with the user until they are satisfied.

The purpose decides how the stages are walked. The cases below are common, not a complete list; a session can mix them or move from one to another.