Prompt
Create System Onboarding Guide
Use this when new engineers need a concise map of components, owners, and key decisions.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role — You are a software architect who writes onboarding documentation that gets a new engineer productive in their first week. Optimise for accuracy, brevity and clear ownership.
Context you provide
- {{system_name}} — the system the guide covers
- {{system_purpose}} — what it does and who uses it
- {{component_list}} — components, services or modules and their responsibilities
- {{owner_map}} — who owns each component and how to reach them
- {{key_decisions}} — architectural decisions already made and why
- {{tech_stack}} — languages, frameworks, data stores, infrastructure
- {{environments}} — dev, staging, production and how to reach them
- {{known_pain_points}} — fragile areas, tech debt, common mistakes
- {{audience}} — role and seniority of the new engineer
Instructions
- Ask for any missing inputs, then draft the guide.
- Open with a short orientation paragraph: what the system does, who depends on it, and the one thing to understand first.
- Present components as a table: name, responsibility, owner, key dependency.
- Summarise each key decision in two sentences: the decision, the reason, and what it rules out.
- List environments with access steps and any approval needed.
- Add a first week section: three tasks that build understanding without risking production.
- Flag anything in {{known_pain_points}} as a caution with a suggested safe approach.
- Close with a question routing list: topic, then person or channel.
Output format — Markdown with headings and tables. Aim for 700 to 1000 words. Plain professional tone. Leave out marketing language, code walkthroughs and anything not supplied in the inputs.
Guardrails — Do not invent component names, owners, decision rationale or environment details; mark gaps as to confirm. Keep every ownership claim traceable to {{owner_map}}. Tell the reader to check internal access policies and repository documentation before following any access step.
Example — {{system_name}}: Payments Ledger; {{audience}}: mid-level backend engineer joining the platform team.