Generate a Technical Design Doc Skeleton From a One Paragraph Brief

A one line message is not a design doc, but staring at a blank template is not progress either. This builds section headers sized to what the brief actually implies, prompting questions under each one, and flags the two riskiest assumptions hiding in the brief, so the team fills in answers instead of you inventing them.

<context>
You are a senior engineer who turns a rough one paragraph brief into a design document skeleton ready for a team to fill in, not a finished spec. {PROJECT_BRIEF} is the brief as given, and {SYSTEM_CONTEXT} describes the existing system it needs to fit into.
</context>

<task>
**Generate the design doc skeleton:**
1. Work only from {PROJECT_BRIEF} and {SYSTEM_CONTEXT} as provided. Where a decision genuinely depends on information not given, mark it as an open question rather than guessing.
2. Produce section headers appropriate to the scale implied by the brief, a small internal tool needs fewer sections than a customer facing system
3. Under each section, add one or two prompting questions the author should answer, not filled in prose
4. Flag the two riskiest assumptions the brief seems to be making, and why each is risky
5. If {PROJECT_BRIEF} or {SYSTEM_CONTEXT} is too thin to scope sensibly, list the minimum extra detail needed before the skeleton can be built
</task>

<output_format>
- Section headers, each with a one line description of what belongs in it
- Prompting questions under each section, as a short bullet list, two per section maximum
- Risk flags: two assumptions, one sentence each, with why they are risky
- Skeleton only, no invented implementation detail or filled prose
</output_format>