Onboarding a new hire: a Project that answers for you

Here's a list of the documents I want to upload into the onboarding
Project for a new [position] in [department]:

[paste the list of document names, one sentence per item on what it
contains]

Go through the list and split the documents into three groups:
1. SAFE — a new hire may see this from day one.
2. CHECK FIRST — likely contains a part that doesn't belong there
   (for each, note what specifically tends to be sensitive in a
   document like this, and what I should look for before uploading).
3. DO NOT UPLOAD — belongs elsewhere, note why for each.

Then write what you think is missing from the list for a new hire
in this position to find their footing in the first month.
Base this on the names and descriptions — don't guess at the actual
content of the documents.

Project instructions "Onboarding [department]":

You are a guide for a new colleague in the role of [position] at
[company]. You answer their questions about our procedures, tools,
and people.

Rules that always apply:
1. Answer EXCLUSIVELY from the uploaded documents. Don't use general
   knowledge about how this is usually done elsewhere.
2. For every answer, state which document you're drawing from.
3. When the answer isn't in the material, or is ambiguous, say so
   explicitly with the sentence "this isn't in our documents" and
   recommend who the new hire should ask (based on the
   responsibilities overview). Never guess or fill in a likely
   procedure.
4. Answer briefly and step by step. For procedures, number the
   steps and state who approves what and up to what limit.
5. When asked about anything with an approval limit or legal impact
   (discounts, contracts, exceptions, payments), always add that
   the final decision belongs to the person named in the approval
   matrix.
6. The new hire is new: explain internal abbreviations whenever you
   use them, and don't assume familiarity with our systems.
7. Never recommend working around a procedure, even if asked
   whether there's a faster way.

At the end of every answer, add the line: "Not sure? Ask
[owner's name] — and let me know so we can add it to the
documents."

I want to test whether you're sticking to the instructions. Answer
these five questions and clearly flag for each one whether the
answer comes from the documents or not:

1. [a question the uploaded documents do answer]
2. [a question the documents do NOT answer, but that sounds like it
   obviously should — e.g. "what's our notice period"]
3. [a question where the documents make two different claims]
4. [a question about something with an approval limit]
5. [a question phrased the way a new hire would actually ask it,
   badly — write it colloquially and imprecisely]

At the end of every answer, write: SOURCE: [document name]
or SOURCE: not in the documents.

Based on the uploaded documents, put together a starter set for a
new colleague in the role of [position].

Create:
1. Twenty questions the new hire is likely to have in the first
   week, based on the documents — phrased the way they would
   actually ask them, not the way a manual would phrase them.
2. Split them into blocks: first day, first week, first month.
3. For each question, name the document it can be answered from.
4. Five questions the documents do NOT answer, that the new hire
   should ask a person instead — name who, for each one.

Output as a clean list I can paste into a welcome email.

I need to do [task, e.g. put together a proposal for a new client].
I've never done this here before.

Based on our documents, tell me:
1. The step-by-step process — what to do, in what order.
2. Which system or template to use for it, and where to find it.
3. Who approves it, and up to what limit.
4. What the most common mistake is, or what to watch out for.
5. What's missing from the documents that I need to ask a person
   about — and who exactly.

Write it as if this were my third day and I didn't know the
abbreviations.

I got this task and I'm not sure I'm understanding it correctly:

[paste the brief, email, or message from a colleague]

Based on our documents, explain to me:
- exactly what's being asked of me, and how I'll know it's done
- what internal abbreviations and system names appear in the brief
  and what they mean
- what our standard process is for this type of task
- what information is missing from the brief and what I should ask
  about

Where you're not sure because it isn't in the documents, say so and
tell me who to ask.

I've written this:

[paste your draft — a proposal, an email to a client, minutes, a
report]

Compare it to our templates and procedures and tell me:
1. How it differs from our standard form (specifically, with a
   reference to the template).
2. What's missing according to our rules.
3. What would pass here and what wouldn't — and why.
4. Whether there's anything in here that exceeds my authority and
   needs someone else's approval.

Don't rewrite it for me — just tell me what to fix.

Here's a list of questions our onboarding Project couldn't answer
over [the past three weeks]:

[paste the list of questions]

Turn this into a documentation plan:
1. Group the questions into topic areas.
2. For each area, determine whether an entire document is missing,
   or just part of an existing one (and which one).
3. Rank the areas by how many questions touched them and how big a
   problem a wrong answer would cause.
4. For the three most important areas, propose an outline for the
   document we should write — headings and bullet points of what
   should go in it.
5. Flag areas that probably aren't written down anywhere and only
   live in people's heads.

Don't write the documents themselves — just the plan and outlines.

Here's the data from the first month of onboarding a new colleague
in the role of [position]:

Questions to AI by week: [numbers]
Questions to colleagues by week: [numbers]
Questions with no answer in the documents: [list]
New hire's feedback: [paste text]
For comparison, the previous hire without a Project: [what you
remember]

Assess:
1. What can responsibly be claimed from these numbers, and what
   can't — be cautious, this is one person over a short period.
2. How the ratio of AI questions to colleague questions changed
   over time, and what that suggests.
3. Which types of questions still go to people, and whether that's
   correct.
4. Three specific changes for the next hire, ranked by impact.

Don't overstate what data from a single hire can tell you.

Go through every document uploaded in this Project and prepare
material for the quarterly review:

1. List the documents and, for each one, state what period it's
   from — based on the date in the title, in the text, or on
   details mentioned in it.
2. Flag documents that look stale: they refer to systems, prices,
   roles, or people that no longer show up in other documents.
3. Find contradictions: where two documents claim different things
   about the same subject. For each contradiction, give both
   versions and the document names.
4. Find places that reference a document or attachment that isn't
   in the Project.
5. List the names and roles that appear in the documents, so I can
   check whether those people still own that responsibility.

Don't delete or edit anything — just give me a list to decide from.
Sort by the riskiest findings first.

Here's a description of the role I'm taking over from a departing
colleague, and the list of documents that exist for it:

Role and responsibilities: [description]
Existing documents: [list]
Who's taking over: [position, experience]

Prepare a structured handover questionnaire:
1. Forty questions for the departing colleague, grouped by area of
   responsibility — questions the listed documents don't answer.
2. Focus on: recurring routines and their deadlines, exceptions and
   agreements that are never written down, relationships and
   contacts (who responds to what, who coordinates what with whom),
   work in progress, pitfalls and things that have gone wrong in
   the past.
3. For each question, note why it matters — what happens if I don't
   have the answer.
4. Mark ten questions as critical, in case the handover ends up
   being just one hour.

Don't ask about anything already covered in the listed documents.