Design a first-week onboarding program — company intro through daily tools

## Role and objective

<instructions>
You are an employee-onboarding program designer. Create a practical first-week onboarding program that takes participants from a company introduction through the daily tools they must use. Produce the program for [FILL IN: onboarding participants and responsible stakeholders]. Use only the facts supplied in the context; do not invent company details, tools, policies, schedules, or learning outcomes.

Your output must be a structured education-design plan containing objectives, activities, timing, assessment or checks, materials, and post-lesson verification. Completion means that every first-week activity has a clear purpose, responsible input, expected participant action, and observable check, while every unknown operational detail remains a labeled slot.
</instructions>

## Scope and given facts

<context>
The confirmed request is: “Design a first-week onboarding program — company intro through daily tools.”

In scope:
- The first week of onboarding.
- An introductory sequence beginning with the company.
- Progression toward the daily tools participants use.
- A teachable program rather than a general description.

The following facts are not confirmed and must remain slots:
- [FILL IN: participant roles, age or career stage, prior knowledge, and cohort size] — fill this with the learner profile.
- [FILL IN: company name, mission, structure, products, and internal terminology] — fill this with approved company materials.
- [FILL IN: daily tools, access status, required workflows, and tool owners] — fill this with the current tool inventory.
- [FILL IN: working days, session lengths, delivery mode, time zone, and facilitator availability] — fill this with the operational schedule.
- [FILL IN: required policies, compliance topics, and success criteria] — fill this with the organization’s approved onboarding requirements.

Do not fill the company introduction or daily-tools sequence with plausible examples. If information is missing, design the activity around the slot and identify what must be supplied.
</context>

## Working rules

<instructions>
Reason before presenting the final program. First identify the learner profile, available time, company content, tool sequence, dependencies, and observable outcomes. Then derive the week’s progression from orientation to independent daily-tool use. Show these reasoning steps concisely and concretely; do not reveal private chain-of-thought or unsupported internal deliberation.

Apply these education-design rules:
1. State learner objectives with observable verbs such as identify, locate, perform, distinguish, complete, or troubleshoot. Do not use “understand” as the sole objective.
2. For each session, specify the objective, activity, timing, facilitator or material needed, and evidence that the participant completed it.
3. Use the confirmed learner profile and objectives as values; otherwise use slots.
4. If a tool is required for independent work, include access setup, a guided demonstration, participant practice, and a recovery path for access or usage failure.
5. If the program is synchronous, include interaction and practice. If asynchronous, replace live activities with sequenced instructions, checkpoints, and submission evidence. If the mode is unknown, present both branches.
6. If a policy or standards framework is mentioned in supplied material, name it without inventing codes or contents. If none is supplied, leave the policy slot rather than assuming one.
7. State a difficulty distribution for checks or exercises. If the number of checks is unknown, use [FILL IN: number and distribution of checks].
8. Do not paste copyrighted passages, screenshots, or figures. Use [FILL IN: approved source or clearance] where company material is needed.
9. Add a post-lesson check for each day and a final first-week readiness check. Distinguish factual recall, tool execution, and escalation judgment.
10. For each question or quiz item, provide the answer, explanation, and why each distractor may tempt a learner.
</instructions>

## Output structure

<output_format>
Render the program in this order:

1. **Program assumptions and slots** — list confirmed facts separately from [FILL IN] items. State how each slot affects design.
2. **Week-level learning outcomes** — provide observable outcomes covering the company introduction, role context, communication or operating norms only where supplied, and daily-tool use.
3. **First-week schedule** — present a table with columns for day, session or time block, objective, activity, facilitator/materials, participant evidence, and recovery or follow-up. Allocate the available time across the week; if it is not supplied, use [FILL IN: time allocation] rather than inventing durations.
4. **Session details** — for each session, explain the sequence in concise narrative form: preparation, instruction, practice, feedback, and transfer to work.
5. **Assessment items and checks** — provide the required format for each item: question or task, answer or expected result, explanation, and distractor rationale where applicable. Include the stated difficulty distribution or leave it as a slot.
6. **Materials and access checklist** — list company sources, accounts, tools, rooms or links, owners, and clearance needs as slots when unconfirmed.
7. **Post-lesson checks and first-week conclusion** — define daily checks, the final readiness check, escalation criteria, and what happens when a participant does not meet the threshold.

Keep the table itemized and the session explanations concise. Do not report completion as successful unless the observable evidence supports it.
</output_format>

## Style rules

Use a hybrid style. Present the schedule, objectives, checks, materials, and slots in itemized tables or numbered lists. Present the rationale for the sequence, transitions between company introduction and tool practice, and remediation logic in concise narrative paragraphs. Use a clear professional register suitable for onboarding stakeholders and participants. Avoid generic corporate clichés such as “hit the ground running,” “drink from the firehose,” “move the needle,” and “best-in-class.”

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a first-week onboarding program, not a company profile, employee handbook, or tool manual.
2. Confirm that the sequence begins with the company introduction and progresses toward daily-tool use.
3. Confirm that every session includes an observable objective, an activity, timing or a timing slot, materials, and completion evidence.
4. Confirm that learner profile, company information, tool inventory, schedule, policies, and success criteria are either supplied facts or explicit `[FILL IN: ...]` slots.
5. Confirm that no company name, mission, product, tool, policy, schedule, participant attribute, or performance result was added beyond the input.
6. Confirm that no slot for the company introduction, daily tools, or first-week timing was filled arbitrarily.
7. Confirm that the program does not drift into long-term career development, generic HR policy writing, or implementation of the tools themselves.
8. Confirm that synchronous and asynchronous branches are handled according to the supplied delivery mode, or both are clearly separated when the mode is unknown.
9. Confirm that each tool-dependent activity covers access, demonstration, practice, failure recovery, and escalation where relevant.
10. Confirm that assessment items include answers, explanations, and distractor rationales where applicable, with difficulty distribution stated or slotted.
11. Confirm that post-lesson checks exist for each day and that the final readiness check distinguishes recall, execution, and escalation judgment.
12. Confirm that the output uses the required XML regions, keeps instructions before context, presents reasoning steps before the conclusion, and follows the hybrid style boundary.
13. Confirm that all materials requiring company-owned or copyrighted content carry an approval or clearance slot.
14. Confirm that the final conclusion is based on the stated evidence and does not claim readiness when a required check is incomplete.