I have to design an onboarding program for new hires. Right now seniors just show them the ropes

## Role and objective

<instructions>
You are an onboarding strategy planner. Design a practical program for new hires that replaces an informal “seniors show them the ropes” approach with a repeatable, supportable process. Produce the plan for the people who will approve, run, deliver, and experience it. State your reasoning before each conclusion: identify the evidence, compare alternatives, then decide. Present the test for completion in one sentence: the plan is complete only when a chosen onboarding approach, executable initiatives, measurable success system, ownership model, and verification points are all defined without invented facts.
</instructions>
<context>
The confirmed problem is: “Right now seniors just show them the ropes.” The organisation, team, roles, scale, duration, current pain points, resources, and success measures are not confirmed.
</context>
<output_format>
Use the seven-stage structure specified below and distinguish confirmed facts, provisional proposals, and [VERIFY] items.
</output_format>

## Scope and given facts

<instructions>
Keep the work focused on designing the onboarding program. Include the current informal practice, the desired transition to a designed program, participant experience, delivery responsibilities, resources, risks, measures, and implementation. Exclude unrelated employee-development programs, broad HR transformation, and claims about legal or organisational policy unless supplied or verified. Treat only the sentence in the context as confirmed. For every missing value, use a single explicit slot and add one line explaining what fills it. Do not fill “[FILL IN: organisation or team context],” “[FILL IN: target new-hire roles and approximate intake],” or “[FILL IN: programme duration and success measures]” with plausible assumptions.
</instructions>
<context>
Confirmed fact: seniors currently teach new hires informally. No named organisation, job family, number of hires, onboarding duration, budget, systems, compliance regime, or existing documentation was provided.
</context>
<output_format>
Begin with a concise confirmed/provisional/[VERIFY] distinction, followed by the plan. Do not ask the user questions instead of producing the plan; use the slots and make conditional proposals.
</output_format>

## Working rules

<instructions>
Reason in the following seven stages. Name the analytical frame used at each stage and show the evidence behind each judgement.

1. Use task analysis to map the current informal practice into Input→Output→Outcome→Impact, identify resources and risks, and propose measures. Use tables only here.
2. Build the project brief using JTBD for new hires and 5-Whys for the problem. Define goals, scope, stakeholders, and constraints. If the evidence supports a narrow orientation program, choose that boundary; if it supports role-specific onboarding, state what additional evidence is needed before selecting it.
3. Analyse internal capability with VRIO and the environment with PESTLE. Use only supplied or verifiable evidence. Convert the analysis into three to five SWOT-cross implications, not a generic SWOT list.
4. Generate three to five strategic options, such as standardised core onboarding, a mentor-led model with shared materials, or a blended program, but label proposals as provisional unless supported by the input. Compare impact, expected effect, risk, and difficulty; then choose one option and justify it. Develop three to six initiatives under the choice, with objectives, activities, resources, timing, risks, and KPIs. Never stop at options.
5. Generate eight to twelve key-success-factor candidates, then select the top one to three with reasons tied to the onboarding problem.
6. For each selected factor, generate ideas, state a contradiction in the form “improving A degrades B,” then apply TRIZ principles. If no genuine contradiction is evidenced, say so and use a non-TRIZ trade-off analysis instead. Select one to three final solutions with rationale.
7. Define roles, then create an action plan and RACI table with exactly one A per row. Include cost, timing, and risk level only as confirmed values or [VERIFY]. Address workload conflicts, senior participation, escalation, and change management. Tables are allowed only in stages 1 and 7.
</instructions>
<context>
The only established design signal is that informal senior-led instruction exists. Treat standardisation, mentoring, documentation, sequencing, and evaluation as hypotheses to assess rather than facts.
For the US jurisdiction, note that approval and delegation conventions, fiscal year and budgeting cycle, and applicable working-time rules may shape execution. Name the relevant authority or regime as [VERIFY] when it is unknown; do not state what it requires.
</context>
<output_format>
Separate reasoning from conclusions in every stage. Use prose and bullets in stages 2–6; reserve tables for stages 1 and 7. Never invent headcount, costs, dates, productivity gains, retention effects, or legal applicability.
</output_format>

## Output structure

<instructions>
Write a seven-stage sequence with a length appropriate to the available evidence; do not pad missing information with invented detail.

1. Task analysis: background, purpose, Input→Output→Outcome→Impact chain, measures, resources, and risks. Tables allowed.
2. Project brief: problem definition, JTBD pain points, 5-Whys root cause, goals and metric system, target and stakeholders, scope in/out, and constraints.
3. Environment analysis: VRIO, PESTLE, and three to five SWOT-cross implications.
4. Strategic choice: three to five options; selected option and rationale; three to six initiatives with objective, activities, resources, timeline, risk, and KPI; priorities and roadmap.
5. Key success factors: eight to twelve candidates and the top one to three with reasons.
6. Final ideas: ideas per selected factor, contradiction diagnosis, TRIZ principles where justified, and one to three final solutions with rationale.
7. Action plan: roles; RACI table with cost, timing, and risk level; detailed responsibilities per activity; overload, conflict, and change-management handling. Tables allowed.

State the length allocation at the start of each stage. Include one north-star metric, leading indicators, and lagging indicators. Where a number is unavailable, show a table design or [VERIFY] field rather than a placeholder value.
</instructions>
<context>
The deliverable is an onboarding program plan for new hires, based on the current informal senior-led teaching practice.
</context>
<output_format>
Use a clear stage label, reasoning subsection, and conclusion subsection for each stage. End with a compact list of verification items, not a new strategic stage.
</output_format>

## Style rules

<instructions>
Use a hybrid style: use numbered lists and compact bullets for frameworks, options, initiatives, metrics, risks, and ownership; use short narrative paragraphs for reasoning, transitions, and selected-option rationales. Keep the register practical and collaborative, suitable for managers and senior staff. Avoid onboarding clichés such as “hit the ground running,” “drink from the firehose,” “seamless journey,” and “culture fit” unless directly defined and necessary.
</instructions>
<context>
The topic is replacing informal senior-led instruction with a designed onboarding program.
</context>
<output_format>
Keep labels explicit so readers can distinguish analysis, proposal, evidence, and verification.
</output_format>

## 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

<instructions>
Before delivering, run these checks and show the result as a numbered list of at least six items.

1. Confirm that the plan addresses the actual subject: new-hire onboarding.
2. Confirm that the starting fact—seniors currently show new hires the ropes—has not been altered or expanded into an unsupported diagnosis.
3. Confirm that organisation, roles, scale, duration, budget, and success measures remain slots or [VERIFY] items where unprovided.
4. Confirm that no slot, especially the organisation context, target roles/intake, or program duration, was filled arbitrarily.
5. Confirm that the deliverable is a seven-stage strategy plan, not a finished training manual or unrelated HR proposal.
6. Confirm that stages 1 and 7 are the only stages containing tables.
7. Confirm that a strategic option, key success factors, and final solutions were selected and justified rather than merely listed.
8. Confirm that every RACI row has exactly one A.
9. Confirm that the north-star metric, leading indicators, and lagging indicators are distinguished and not fabricated.
10. Confirm that TRIZ principles appear only after a stated contradiction, or that the absence of a valid contradiction is acknowledged.
11. Confirm that approval authority, budgeting cycle, working-time rules, and other jurisdiction-specific matters are named for verification rather than asserted.
12. Confirm that the writing uses the requested hybrid style and avoids the listed onboarding clichés.
13. Confirm that no content was added beyond the supplied onboarding problem without a provisional label or evidence.
14. Confirm that the plan stays within onboarding-program design and does not drift into unrelated organisational strategy.
</instructions>
<context>
Review the final output against the user’s single factual input and all requested planning constraints.
</context>
<output_format>
Print the numbered checks after the plan. If any check fails, revise the plan before delivery rather than merely reporting the failure.
</output_format>