The Logistics, Operations & Project Management Library Planned, tracked, reported.

Drafts a project charter from your goals, constraints, and stakeholder list. Use it at the start of any project to get sponsor alignment and scope boundaries written down before work begins.

## Context
You are a project management assistant helping me draft a project charter for [PROJECT NAME] at [ORGANIZATION NAME]. The project sponsor is [SPONSOR NAME AND TITLE]. The project manager is [PM NAME AND TITLE]. The target completion date is [TARGET COMPLETION DATE]. The project addresses this business need or problem: [BUSINESS NEED OR PROBLEM]. Budget ceiling: [BUDGET CEILING]. Key stakeholders: [STAKEHOLDER LIST].

## Task
Draft a project charter with these sections:
1. Project purpose: one paragraph. What problem this solves and why it matters now.
2. Scope summary: what is included and what is explicitly excluded.
3. Objectives: three to five measurable outcomes, each written as "By [TARGET COMPLETION DATE], [measurable result]."
4. Key deliverables: a bulleted list.
5. Constraints and assumptions: two separate bulleted lists.
6. Stakeholders: a table with name, role, and interest in the project.
7. High-level timeline: four to six milestone rows with milestone name and target date.
8. Budget ceiling: state the figure and note that detailed estimates follow in the planning phase.
9. Authority and approval: who approves scope changes and who signs off on completion.

## Standards
- Plain professional language. Short paragraphs.
- Do not invent dates, dollar figures, percentages, or metrics I did not provide. Where a field is needed and not given, write "[TO BE CONFIRMED]" and flag it.
- Objectives must be specific and measurable. If the business need as stated does not support a measurable objective, flag it rather than invent one.
- Keep the full charter under 600 words.
- This is not legal or financial advice. Contracts and budgets require review by the appropriate authority.
- If any named input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

Project Charter: Atlas Warehouse Consolidation
Northwind Industrial Supply | Prepared June 2026

Project purpose
Northwind operates two regional warehouses that were never designed to work together. Duplicate inventory, split shipments, and redundant staffing cost the company time and money every week. This project consolidates operations into one upgraded facility by end of Q3 2026, reducing per-order fulfillment time and eliminating duplicate overhead.

Scope summary
In scope: physical relocation of inventory from Site B to Site A, rack installation, updated inventory management system configuration, and staff redeployment plan.
Out of scope: system procurement (already contracted), HVAC upgrades at Site A, and any customer-facing portal changes.

Objectives
- By September 30, 2026, complete physical consolidation of all Site B inventory into Site A.
- By September 30, 2026, achieve a picking error rate no higher than the current Site A baseline of [TO BE CONFIRMED].
- By October 31, 2026, reduce fulfillment labor hours per order by [TO BE CONFIRMED] percent compared to the pre-consolidation combined baseline.

Key deliverables
- Finalized floor layout plan for Site A
- Completed rack installation
- Migrated and reconciled inventory records
- Staff redeployment plan with training schedule
- Consolidated operations go-live sign-off

Constraints
- Budget ceiling: $220,000 (approved)
- Site B lease expires October 1, 2026 (hard deadline)
- No fulfillment disruption during peak August order period

Assumptions
- Site A rack permits are approved by July 15
- Current Site B staff will be offered positions at Site A
- Inventory system vendor will support migration with two on-site days

Stakeholders
| Name | Role | Interest |
|---|---|---|
| Dana Rosenthal | VP Operations (Sponsor) | On-time delivery, cost control |
| Marcus Webb | Warehouse Director (PM) | Operational continuity |
| Yolanda Ferris | IT Manager | System migration |
| Site A and B Supervisors | Operations leads | Staff transition |

High-level timeline
| Milestone | Target date |
|---|---|
| Charter approved | June 20, 2026 |
| Floor layout finalized | July 10, 2026 |
| Rack installation complete | August 1, 2026 |
| Inventory migration complete | September 15, 2026 |
| Go-live | September 30, 2026 |
| Site B cleared | October 1, 2026 |

Budget ceiling: $220,000. Detailed estimates to follow in the planning phase.

Authority: Scope changes require written approval from Dana Rosenthal. Project completion sign-off: Dana Rosenthal and Marcus Webb.

Note: Two objectives contain [TO BE CONFIRMED] placeholders. Confirm baseline metrics before sponsor signature.

Builds a task-level schedule outline with durations, dependencies, and assigned roles from your WBS and milestone plan. Use it to turn your work breakdown into an ordered task list ready to load into a scheduling tool.

## Context
You are a project management assistant helping me build a schedule outline for [PROJECT NAME] at [ORGANIZATION NAME]. Project start date: [PROJECT START DATE]. Target completion date: [TARGET COMPLETION DATE]. WBS or task list: [WBS OR TASK LIST]. Key milestones with dates: [MILESTONE LIST]. Available roles or resources: [ROLES AND RESOURCES]. Working days per week: [WORKING DAYS PER WEEK]. Known non-working periods (holidays, blackout windows): [NON-WORKING PERIODS].

## Task
Build a schedule outline as a table with these columns:
- Task ID (sequential)
- Task name
- WBS reference (if provided)
- Duration (in working days)
- Predecessors (task IDs this task depends on)
- Assigned role
- Milestone flag (yes or no)
- Notes (constraints or assumptions for this task)

After the table:
1. Calculate the total schedule duration in working days and confirm whether it fits within the start and end dates.
2. Identify the critical path: the chain of tasks where any delay pushes the end date.
3. List the top three schedule risks visible from the task list and dependencies.

## Standards
- Durations are in working days, not calendar days. Account for [WORKING DAYS PER WEEK] and the non-working periods I listed.
- Do not invent durations or dates for tasks where I have not provided enough information. Write [ESTIMATE NEEDED] and flag it.
- Critical path is based on the dependencies I provide, not assumptions.
- Do not add tasks outside the WBS or task list I provided.
- Schedule risks must be grounded in the task list and constraints, not pulled from a generic risk library.
- Recompute the total duration from the task durations before stating whether the schedule fits. Show the math.
- If any named input is missing or the task list is incomplete, ask before building the schedule.

Sample output. Generated by AI from sample inputs:

Schedule Outline: Atlas Warehouse Consolidation
Northwind Industrial Supply | Start: June 2, 2026 | End target: September 30, 2026 | 5-day work week | Blackout: August 2-31 (fulfillment peak)

| ID | Task | WBS | Duration (days) | Predecessors | Role | Milestone | Notes |
|---|---|---|---|---|---|---|---|
| T1 | Charter approved | 1.6.1 | 0 | None | Sponsor | Yes | Project start milestone |
| T2 | Site A layout survey | 1.1.1 | 3 | T1 | Warehouse Director | No | Must access Site A during off-peak hours |
| T3 | Draft floor layout | 1.1.2 | 5 | T2 | Warehouse Director | No | |
| T4 | Layout review and approval | 1.1.3 | 3 | T3 | Sponsor | Yes | Target July 10 |
| T5 | Submit rack permits | 1.2.1 | 2 | T4 | Facilities Lead | No | External dependency; permit turnaround [ESTIMATE NEEDED] |
| T6 | Permits received | 1.2.1 | 0 | T5 | Facilities Lead | Yes | Hard target July 15 |
| T7 | Schedule rack installer | 1.2.2 | 3 | T6 | Facilities Lead | No | |
| T8 | Rack installation | 1.2.3 | 10 | T7 | Contractor | No | Must complete before August 2 blackout |
| T9 | Load inspection | 1.2.4 | 2 | T8 | Third-party inspector | Yes | Target August 1 |
| T10 | System reconfiguration | 1.3.2 | 8 | T4 | IT Manager | No | Vendor support days included |
| T11 | Inventory record audit | 1.3.1 | 5 | T1 | Warehouse Supervisors | No | Can run parallel to layout work |
| T12 | Physical inventory transfer | 1.3.3 | 15 | T9, T10, T11 | Warehouse Supervisors | No | Starts September 1 after blackout |
| T13 | Post-transfer count verification | 1.3.4 | 3 | T12 | Warehouse Supervisors | No | |
| T14 | Staff redeployment plan | 1.4.1-4 | 20 | T1 | HR Lead | No | Runs parallel; complete by September 20 |
| T15 | Go-live acceptance | 1.5 | 0 | T13, T14 | Sponsor | Yes | Target September 30 |

Total working days on critical path: T1-T4-T6-T8-T9-T12-T13-T15
Working days available June 2 to September 30, excluding August 2-31: approximately 83 days.
Critical path length: 0+3+5+3+2+0+3+10+2+15+3+0 = 46 days. Fits within available time with buffer, but only if permits arrive on schedule.

Schedule risks:
1. Permit turnaround (T5-T6) is external. If permits slip past July 15, rack installation cannot finish before the August 2 blackout, pushing go-live past September 30.
2. The August 2-31 blackout freezes the physical move window. Any task starting the physical transfer (T12) must wait until September 1 regardless of readiness.
3. Vendor support days for system reconfiguration (T10) are not yet confirmed. A vendor scheduling conflict delays T10 and T12.

Turns your raw project notes into a formatted status report ready for distribution. Use it at the end of any reporting period when you need a clean document without spending an hour writing from scratch.

## Context
You are assisting a [ROLE: e.g., project manager, logistics coordinator, operations lead] who needs to produce a status report for [PROJECT NAME] covering [REPORTING PERIOD: e.g., Week 3, June 1-7]. The audience is [AUDIENCE: e.g., the project team, the program manager, the client]. Overall status: [OVERALL STATUS: Red, Amber, or Green]. This status was determined by the person running the project, not by the AI.

Project notes to work from:
- Accomplishments this period: [ACCOMPLISHMENTS]
- Planned work not completed and reason: [INCOMPLETE WORK]
- Planned work for next period: [NEXT PERIOD PLAN]
- Schedule: [SCHEDULE STATUS: e.g., on track, 3 days behind]
- Budget: [BUDGET STATUS: e.g., within budget, $4,200 over]
- Open risks and issues: [RISKS AND ISSUES]
- Decisions needed: [DECISIONS NEEDED: or "none"]

## Task
Produce a status report with these sections:
1. Header: project name, reporting period, date, prepared by [PREPARER NAME], overall status (Red/Amber/Green).
2. Summary: two to three sentences on where the project stands. Lead with the most important fact.
3. Accomplishments: bulleted list from my notes.
4. Next period plan: bulleted list from my notes.
5. Schedule and budget: one line each, restating the status I provided.
6. Risks and issues: each as a short entry with description and current action.
7. Decisions needed: if any, state them clearly with the owner and needed-by date I supply.

## Standards
- Restate all dates, dollar figures, percentages, and statuses exactly as I provided them. Do not compute, estimate, or adjust any number.
- Overall status (Red/Amber/Green) must match what I set above. Do not reassess it.
- Plain, direct language. One idea per sentence. Under 400 words for the full report.
- Do not invent accomplishments, risks, or issues not in my notes.
- If a section field above is blank, write "None reported" for that section and do not fill it in.
- If any named input is missing or ambiguous, ask me before drafting rather than guessing.

Sample output. Generated by AI from sample inputs:

Project Status Report
Project: Atlas Warehouse Migration
Prepared by: Dana Ruiz, Project Manager
Reporting Period: Week 3, June 1-7, 2026
Overall Status: AMBER

Summary
The Atlas migration is three days behind the baseline schedule due to a delayed rack delivery from the vendor. Electrical rough-in is complete and all staff have completed safety orientation. Recovery plan is in place; the team expects to return to schedule by June 14 if the racks arrive as now confirmed.

Accomplishments
- Electrical rough-in completed in all four aisles (June 3)
- 47 of 50 staff completed forklift safety orientation
- Interim storage layout finalized and signed off by operations lead

Next Period Plan
- Receive and stage rack shipment (ETA June 9)
- Complete remaining 3 safety orientations
- Begin rack assembly in Aisles 1 and 2

Schedule: 3 days behind baseline. Recovery plan active; revised milestone dates distributed June 6.
Budget: Within approved budget. No variances to report this period.

Risks and Issues
- Rack delivery delay (Northwind Shelving): Racks originally due June 2 now confirmed for June 9. Vendor confirmed in writing. Monitoring closely.
- 3 staff not yet oriented: Rescheduled for June 8.

Decisions Needed
- None this period.

Writes a one-paragraph executive update from your project notes. Use it when a senior leader needs the bottom line fast and does not need the full status report.

## Context
You are assisting a [ROLE] who needs a brief executive update on [PROJECT NAME] for [EXECUTIVE AUDIENCE: e.g., the Deputy Director, the VP of Operations, the client executive]. The update covers [REPORTING PERIOD]. Overall status: [OVERALL STATUS: Red, Amber, or Green].

Key facts to include:
- Where things stand: [CURRENT SITUATION]
- The most important thing that happened: [KEY DEVELOPMENT]
- Any issue or risk the executive needs to know about: [KEY ISSUE OR RISK: or "none"]
- Any decision or action needed from the executive: [EXECUTIVE ACTION NEEDED: or "none"]
- Schedule and budget standing: [SCHEDULE STATUS], [BUDGET STATUS]

## Task
Write one tight paragraph of four to six sentences. Lead with the overall status and the most important fact. Follow with any issue the executive must know. End with the decision or action needed, if any. If no action is needed, close with one sentence on what happens next.

## Standards
- Four to six sentences only. No bullet points, no headers, no attachments referenced.
- Restate all figures, dates, and statuses exactly as I provided them. Do not interpret, estimate, or adjust them.
- Plain language an executive outside the project can understand in 30 seconds.
- No jargon, no project-management acronyms. Spell out any term that is not universally understood.
- Do not add context, background, or reassurance I did not supply.
- If any key fact above is missing, ask me before drafting.

Sample output. Generated by AI from sample inputs:

The Atlas Warehouse Migration is AMBER this week. Rack delivery from Northwind Shelving arrived three days late, putting the installation schedule three days behind the June 20 baseline completion date. The vendor has confirmed a revised delivery for June 9, and the project team has a recovery plan in place to close the gap by June 14. The project remains within the approved budget with no cost variances this period. No executive decision is needed at this time; the team will report status again on June 13.

Drafts a clear, factual memo delivering bad news on a project: a missed milestone, a budget overrun, or a schedule slip. Use it when the news is real and the team or sponsor needs to hear it without spin.

## Context
You are a project communications assistant helping [YOUR NAME OR ROLE] draft a memo that delivers bad news on [PROJECT NAME]. The audience is [AUDIENCE: team, sponsor, client, or leadership]. The news is [BAD NEWS SUMMARY]. The memo must be honest and complete without being alarmist. Readers need the facts, the cause, the impact, and what happens next.

Project: [PROJECT NAME]
Audience: [AUDIENCE]
Bad news: [BAD NEWS SUMMARY]
Root cause or contributing factors: [ROOT CAUSE]
Impact on schedule, budget, or scope: [IMPACT]
Response actions already taken or planned: [RESPONSE ACTIONS]
Next decision or checkpoint: [NEXT DECISION OR DATE]

## Task
Draft a memo with these sections: Situation, What Happened, Impact, What We Are Doing, What We Need from You (if anything), Next Update.

## Standards
- Lead with the news in the first sentence. Do not bury it.
- State impact in concrete terms: days delayed, dollars over budget, scope removed. Use only figures from [IMPACT].
- Root cause should be factual, not defensive. One paragraph.
- Response actions are specific: who is doing what, by when. Use only actions from [RESPONSE ACTIONS]. Do not invent commitments.
- Tone is professional and direct. No hedging language that softens the facts into ambiguity.
- Under 400 words.
- Do not invent dates, costs, percentages, or status ratings not provided in the inputs above.
- If any named input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

MEMO
To: Atlas Warehouse Migration Steering Committee
From: Project Manager, Dana Reyes
Date: June 13, 2026
Subject: Schedule slip, Atlas migration Phase 2

Situation. Phase 2 of the Atlas warehouse migration will miss its June 20 go-live date. The new target date is July 11, 2026, a 21-day slip.

What Happened. The network infrastructure upgrade required by Northwind IT took 14 additional days due to a permit delay from the building owner. A vendor configuration error discovered on June 9 added 7 more days of rework. Both issues surfaced after the May 30 schedule baseline was set.

Impact. Go-live moves from June 20 to July 11. The delay pushes the Phase 3 kickoff by three weeks. No budget overrun is projected at this time; the vendor rework is covered under the existing contract warranty.

What We Are Doing. Northwind IT completed the network upgrade on June 12. The vendor is correcting the configuration error with a completion target of June 18. Daily stand-up calls resume Monday to monitor progress.

What We Need from You. Confirm the July 11 go-live date is acceptable or advise of any downstream constraints by June 17.

Next Update. Written update on June 20 with a revised go/no-go assessment.

Builds a structured risk register from the threats you identify, scoring each by likelihood and impact and noting current controls. Use it at the start of a project or after a major scope change to get all known risks on paper and prioritized.

## Context
You are a project management assistant helping [PROJECT MANAGER NAME] build a risk register for [PROJECT NAME] at [ORGANIZATION NAME]. The project involves [PROJECT DESCRIPTION]. The project is currently in [PROJECT PHASE] and is scheduled to complete by [TARGET COMPLETION DATE]. Key stakeholders include [KEY STAKEHOLDERS]. The risk identification inputs below come from the project team.

Risk inputs from the team:
[RISK INPUTS]

## Task
Build a risk register table with these columns: Risk ID, Risk Description, Category (schedule / cost / scope / resource / external / safety), Likelihood (1 to 5), Impact (1 to 5), Risk Score (Likelihood x Impact), Priority (High if score 15 or above, Medium if 8 to 14, Low if 7 or below), Current Controls, Risk Owner, and Status (Open).

After the table, provide:
1. A top-3 list of the highest-scoring risks with one sentence on why each deserves immediate attention.
2. Any risk categories that appear underrepresented based on the project description, so the team can decide whether to dig deeper.

## Standards
- Assign Risk IDs sequentially: R-001, R-002, and so on.
- Use only the risks and controls the team provided. Do not invent risks, scores, owners, dates, or controls.
- If a risk input is vague, write the description as clearly as possible and flag it with "(Needs clarification)" in the Description field.
- Do not invent dollar figures, schedule estimates, or percentage probabilities. Use the 1-to-5 scale only.
- Keep each risk description to one sentence: what could go wrong and what it would affect.
- The Risk Owner column lists names or roles only if the team provided them; otherwise leave it blank.
- If any required input is missing or ambiguous, ask before building the register.

Sample output. Generated by AI from sample inputs:

Risk register for Project Atlas -- Northwind Logistics Warehouse Migration, Phase 2 (Planning).

| Risk ID | Risk Description | Category | Likelihood | Impact | Score | Priority | Current Controls | Risk Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | Key migration vendor may miss the delivery window, delaying warehouse cutover by two or more weeks. | Schedule | 3 | 5 | 15 | High | Weekly vendor check-in; milestone payment tied to delivery. | Ops Director | Open |
| R-002 | Legacy inventory system may not map cleanly to the new warehouse management system, requiring rework. | Scope | 4 | 4 | 16 | High | Data mapping review scheduled for Week 3. | IT Lead | Open |
| R-003 | Trained staff turnover during migration window could reduce throughput at go-live. | Resource | 2 | 4 | 8 | Medium | Cross-training plan drafted; not yet executed. | HR Lead | Open |
| R-004 | Permit approval for dock expansion may be delayed by the city, pushing Phase 3 start. | External | 2 | 3 | 6 | Low | Permit submitted; city timeline is 30 business days. | Facilities | Open |
| R-005 | Budget variance from fuel and freight cost increases may exceed contingency reserve. | Cost | 3 | 3 | 9 | Medium | Contingency reserve in place; freight costs not yet locked. | (Needs clarification) | Open |

Top 3 risks:
1. R-002 (Score 16) -- A data mapping failure at this scale can halt the go-live entirely; the Week 3 review is the critical gate.
2. R-001 (Score 15) -- Vendor delivery is on the critical path; any slip cascades directly to cutover.
3. R-005 (Score 9) -- Freight cost volatility is active now; the contingency size needs confirmation against current quotes.

Underrepresented category: Safety. A warehouse migration involves physical relocation of equipment and personnel working in a changed environment. The team may want to add at least one safety risk before baselining.

Writes a formal change request document including the reason for the change, the scope of the change, and a structured impact analysis covering schedule, cost, and resources. Use it any time a proposed change to scope, schedule, or budget needs to go through a formal approval process.

## Context
You are a project management assistant helping [REQUESTOR NAME] draft a change request for [PROJECT NAME] at [ORGANIZATION NAME]. The change request is being submitted to [APPROVING AUTHORITY].

Change description (what is changing and why):
[CHANGE DESCRIPTION]

Change type: [CHANGE TYPE] (scope / schedule / budget / resource / technical / other)

Reason and justification:
[CHANGE JUSTIFICATION]

Alternatives considered before requesting this change:
[ALTERNATIVES CONSIDERED]

Proposed impacts on schedule:
[SCHEDULE IMPACT]

Proposed impacts on budget:
[BUDGET IMPACT]

Proposed impacts on resources:
[RESOURCE IMPACT]

Risks introduced or reduced by this change:
[CHANGE RISKS]

Requested effective date:
[REQUESTED EFFECTIVE DATE]

## Task
Draft a change request document with these sections:
1. Change Request Summary (one paragraph: what, why, and the requested effective date).
2. Change Description (detailed explanation of what is changing).
3. Justification (why this change is necessary or beneficial).
4. Alternatives Considered (what other options were evaluated and why they were rejected).
5. Impact Analysis (schedule, budget, resource impacts in table form).
6. Risks Introduced or Reduced.
7. Recommendation (one sentence: approve, deny, or defer, written as a blank for the approver to fill in).
8. Signature block with Requestor, Approver, and Date fields.

## Standards
- Use only the information the requestor provided. Do not invent schedule dates, cost figures, resource names, or risk ratings.
- Impact Analysis table: show baseline, proposed change, and net delta for each dimension. Use [BASELINE VALUE] as a placeholder where the requestor did not supply the current baseline.
- Tone: factual and neutral. This is a record, not a sales pitch.
- Note at the bottom: this document does not constitute a contract modification. Formal contract changes require review by the contracting authority.
- Length: 400 to 600 words of narrative, plus tables.
- If any required input is missing, ask before drafting.

Sample output. Generated by AI from sample inputs:

Change Request CR-007
Project: Atlas -- Northwind Logistics Warehouse Migration
Requestor: Operations Director, Northwind Logistics
Approving Authority: Steering Committee
Date Submitted: [INSERT DATE]
Requested Effective Date: [INSERT DATE]

1. Change Request Summary
This change request proposes to defer the Phase 2 go-live date by three weeks to allow completion of the legacy system data mapping audit, which identified a larger-than-expected number of unmapped fields. Without this extension, the migration would proceed with an incomplete data set, increasing the risk of inventory errors at go-live. The requested effective date is [INSERT DATE].

2. Change Description
The current Phase 2 go-live date will be extended by three weeks. All Phase 2 milestones shift proportionally. Phase 3 planning start date is also affected. No scope changes are proposed.

3. Justification
The Week 3 data mapping review found that 18 percent of legacy product fields do not have a direct equivalent in the new WMS. Mapping these fields manually requires an estimated three additional weeks of IT and operations effort. Proceeding on the original date would require going live with incomplete inventory records.

4. Alternatives Considered
- Proceed on the original date with a partial dataset and remediate post-go-live: rejected because inventory errors during the peak shipping period carry unacceptable operational risk.
- Reduce the scope to exclude the unmapped product categories: rejected because those categories represent core stock the warehouse cannot operate without.

5. Impact Analysis

| Dimension | Baseline | Proposed | Net Delta |
|---|---|---|---|
| Go-live Date | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Phase 3 Start | [BASELINE VALUE] | [BASELINE VALUE + 3 weeks] | +3 weeks |
| Budget | [BASELINE VALUE] | [BASELINE VALUE + extended labor cost] | To be confirmed by PM |
| Resources | IT Lead + Ops SME assigned through go-live | Same, extended 3 weeks | +3 weeks of IT Lead and Ops SME time |

6. Risks Introduced or Reduced
- Reduced: R-002 (Data Mapping Failure) likelihood decreases from 4 to 2 if the extension is used to complete the audit.
- Introduced: Extended timeline increases exposure to R-001 (Vendor Delivery Delay) if the vendor's schedule is fixed.

7. Recommendation
This change request is: [ ] Approved [ ] Denied [ ] Deferred

Comments: _______________

Approver Signature: _______________ Date: _______________
Requestor Signature: _______________ Date: _______________

Note: This document does not constitute a contract modification. Formal contract changes require review and approval by the contracting authority.

Writes a standard operating procedure (SOP) for a specific process, covering purpose, scope, steps, roles, and quality checks. Use it when you need a repeatable, written procedure that anyone on the team can follow without asking you for help.

## Context
You are an operations documentation assistant helping a logistics, operations, or project management professional write a standard operating procedure (SOP). The SOP will be used by staff performing the process and by supervisors verifying compliance. It must be clear enough for a new team member to follow without additional instruction.

Organization and department: [ORGANIZATION AND DEPARTMENT]
Process name: [PROCESS NAME]
Purpose of the process: [PURPOSE]
Scope (who performs it, what it covers, what it excludes): [SCOPE]
Step-by-step description of the process as currently performed: [PROCESS STEPS]
Roles involved and their responsibilities: [ROLES]
Tools, systems, or forms used: [TOOLS AND SYSTEMS]
Key quality checks or compliance requirements: [QUALITY CHECKS]
Effective date: [EFFECTIVE DATE]

## Task
Write an SOP with these sections: Purpose, Scope, Roles and Responsibilities, Required Tools and Systems, Procedure (numbered steps), Quality and Compliance Checks, and Document Control (version, effective date, owner).

## Standards
- Procedure steps are numbered and written in the imperative voice: 'Log in to the system,' not 'The operator should log in.'
- Each step is one action. Do not combine multiple actions in one step.
- Role assignments use the titles provided in [ROLES], not invented titles.
- Quality and Compliance Checks name the specific check, the person responsible, and the frequency.
- Do not invent step details, system names, form numbers, or compliance standards not provided in the inputs.
- If a step from [PROCESS STEPS] is ambiguous about the actor, system, or outcome, insert a bracketed note: [CLARIFY: who performs this step?] rather than guessing.
- Do not invent dates, percentages, dollar figures, cycle times, or error rates. If a metric is relevant, use [INSERT METRIC FROM YOUR RECORDS].
- This SOP is a documentation tool. It does not substitute for regulatory compliance review, safety review, or legal approval.
- If any required input is missing or unclear, ask before drafting.

Sample output. Generated by AI from sample inputs:

STANDARD OPERATING PROCEDURE
Organization: Northwind Distribution | Department: Warehouse Operations
Process: Inbound Freight Receiving
Version: 1.0 | Effective Date: July 1, 2026 | Owner: Warehouse Manager

Purpose
This SOP defines the process for receiving inbound freight shipments at the Northwind Distribution Center to ensure accurate inventory counts, timely exception reporting, and correct staging for putaway.

Scope
Covers all inbound freight from carrier delivery through system confirmation. Applies to all Receiving Technicians and the Receiving Lead. Does not cover returns processing or inbound transfers from other Northwind sites.

Roles and Responsibilities
- Receiving Technician: performs physical receipt, count verification, and system entry.
- Receiving Lead: reviews exceptions, approves discrepancy reports, and signs off on daily receiving log.
- Carrier Driver: provides bill of lading (BOL) and waits for receipt confirmation before departure.

Required Tools and Systems
- Warehouse Management System (WMS): Atlas WMS v4.2
- Mobile barcode scanner: Northwind model RS-9
- Receiving Discrepancy Report form (Form WH-12)
- Bill of lading from carrier

Procedure
1. Verify the carrier appointment in Atlas WMS before opening the dock door.
2. Check the BOL against the expected purchase order (PO) in Atlas WMS: confirm supplier name, PO number, and item count.
3. If the BOL does not match an open PO, do not unload. Notify the Receiving Lead immediately.
4. Unload the shipment onto the designated receiving dock area.
5. Count all cartons and pallets. Record the physical count on the BOL.
6. Scan each item barcode using the RS-9 scanner to confirm item and quantity against the PO in Atlas WMS.
7. If count matches the PO within tolerance [INSERT TOLERANCE FROM YOUR RECORDS], confirm receipt in Atlas WMS and print the receiving label.
8. If count does not match, complete Form WH-12 and notify the Receiving Lead before confirming receipt.
9. Stage confirmed freight in the designated putaway lane for the item category.
10. Have the carrier driver sign the BOL. Retain the original; provide a copy to the driver.
11. Log the completed receipt in the daily receiving log.

Quality and Compliance Checks
- Receiving Lead reviews all Form WH-12 discrepancy reports daily before end of shift.
- Receiving Technician verifies item barcodes at 100% of line items, not spot checks.
- Receiving Lead signs the daily receiving log each day.

Document Control
Version 1.0. Effective July 1, 2026. Owner: Warehouse Manager. Review annually or when process changes.

Describes a process flow step by step in a format ready to hand to a diagram tool or a team member building a flowchart. Use it when you need to document a process for training, improvement analysis, or a deliverable and do not have the steps written down clearly.

## Context
You are an operations documentation assistant helping a logistics, operations, or project management professional describe a process flow clearly enough to build a process map or flowchart. The output will be used to create a visual diagram, train staff, or analyze the process for improvements.

Organization and process name: [ORGANIZATION AND PROCESS NAME]
Process start trigger (what kicks it off): [START TRIGGER]
Process end state (what does 'done' look like): [END STATE]
Step-by-step description of the process: [PROCESS STEPS]
Decision points and their outcomes (if/then branches): [DECISION POINTS]
Roles performing each step: [ROLES]
Systems or forms used: [SYSTEMS AND FORMS]
Known pain points or rework loops: [PAIN POINTS]

## Task
Produce a numbered process flow description with these components:
1. Process overview: one paragraph covering purpose, start trigger, and end state.
2. Step list: each step numbered, with the role, action, system or form touched, and output of the step.
3. Decision points: each branch labeled with the condition, the yes path, and the no path.
4. Rework loops: each known loop identified with the step it returns to.
5. Diagram notes: a short bulleted list of guidance for whoever builds the visual diagram.

## Standards
- Number steps sequentially. Decision points get a letter suffix: step 3 with a decision becomes 3A (yes path) and 3B (no path).
- Every step names the role performing it and the output produced.
- Do not invent steps, decision branches, or systems not described in the inputs.
- If a step in [PROCESS STEPS] is unclear about the actor, output, or sequence position, flag it as [CLARIFY] rather than assuming.
- Do not invent cycle times, error rates, volume figures, or percentages. If you reference a metric, use [INSERT METRIC FROM YOUR RECORDS].
- If any named input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

PROCESS MAP DESCRIPTION
Organization: Northwind Distribution | Process: Purchase Order (PO) Approval

Process Overview
This process covers the review and approval of purchase orders before they are released to suppliers. It begins when a Buyer submits a draft PO in the Atlas procurement system and ends when the PO is either approved and transmitted to the supplier or rejected and returned to the Buyer for correction.

Step List
1. Buyer: creates draft PO in Atlas procurement system, attaches supporting quote. Output: draft PO record in Atlas.
2. Atlas system: routes PO to Procurement Manager for review based on PO value. Output: system notification to Procurement Manager.
3. Procurement Manager: reviews PO for accuracy (supplier, item, price, delivery date). Output: approval decision. [Decision point: see 3A/3B]
3A. If approved: Procurement Manager approves PO in Atlas. Proceed to step 4.
3B. If not approved: Procurement Manager adds rejection notes in Atlas and returns to Buyer. Rework loop returns to step 1.
4. Atlas system: transmits approved PO to supplier via EDI. Output: PO transmitted confirmation.
5. Buyer: confirms transmission in Atlas and files confirmation email. Output: closed PO record.

Decision Points
- Step 3 branch: Condition is whether the PO is accurate and within approved supplier and budget. Yes path leads to approval and step 4. No path returns PO to Buyer for correction (rework loop to step 1).

Rework Loops
- Rejection at step 3B returns to step 1. [INSERT AVERAGE REJECTION RATE FROM YOUR RECORDS] of POs cycle through this loop.

Diagram Notes
- Use a swim lane layout: one lane per role (Buyer, Procurement Manager, Atlas System).
- Decision diamond at step 3 with two exit arrows labeled 'Approved' and 'Rejected.'
- Rework arrow from step 3B back to step 1 should be clearly labeled 'Return for Correction.'
- Atlas system actions (steps 2 and 4) are automated: use a different shape (rectangle with rounded corners or system symbol) to distinguish from manual steps.

Builds a structured plan to improve a specific operational process over a defined window. Use it when leadership has identified a process that is underperforming and wants a written plan with milestones, owners, and success measures.

## Context
You are helping an operations manager or process owner draft a continuous improvement plan. The organization is [ORGANIZATION NAME]. The process being targeted is [PROCESS NAME]. The improvement initiative is scoped to [IMPROVEMENT WINDOW, e.g., 90 days or Q3]. The reader of this plan may be a team lead, department head, or oversight committee, so it must be clear without requiring operational jargon to follow.

## Task
Produce a continuous improvement plan with the following sections:

1. Problem statement. One paragraph. What the current process does, where it falls short, and the cost of leaving it unchanged. Use only facts from the inputs below.
2. Scope. What is inside and outside this initiative. Be explicit about what this plan does not touch.
3. Current state summary. The key steps of the process as it runs today, including the handoffs and known friction points: [CURRENT STATE DESCRIPTION].
4. Improvement objectives. Two to four specific, measurable targets. Base these on: [IMPROVEMENT OBJECTIVES AND TARGETS].
5. Planned actions. A numbered list of changes to implement, each with: the action, the owner by role (not name), the target completion date, and any dependency.
6. Milestones and check-ins. A cadence for reviewing progress over [IMPROVEMENT WINDOW].
7. Success measures. How you will know the improvement held after the window closes, stated as observable conditions or measurable thresholds.
8. Risks. Two or three things that could stall the plan, and a brief mitigation for each.

Inputs for the plan:
- Current state: [CURRENT STATE DESCRIPTION]
- Objectives and targets: [IMPROVEMENT OBJECTIVES AND TARGETS]
- Known constraints: [KNOWN CONSTRAINTS]
- Stakeholders involved: [STAKEHOLDER ROLES]

## Standards
- 500 to 700 words for the full plan. Each section under a bold header.
- Tone is direct and practical. Write for a team lead who will execute this, not a consultant who will review it.
- Do not invent baseline metrics, dates, dollar figures, or target percentages. Use only the numbers the user provides. If a target is stated as a range, keep it a range.
- Do not recommend specific tools, vendors, or methodologies unless the user names them.
- Improvement objectives must be phrased in terms of observable outcomes, not activities.
- End Standards: if any named input is missing or ambiguous, ask before drafting the plan.

Sample output. Generated by AI from sample inputs:

**Continuous Improvement Plan: Warehouse Inbound Receiving Process**
Organization: Northwind Distribution | Process: Inbound receiving | Window: 90 days (July 1 - September 30)

**Problem statement**
Northwind's inbound receiving process currently takes an average of 4.2 hours from dock arrival to system entry. That delay pushes fulfillment timelines past the 24-hour commitment on priority orders and has contributed to inventory discrepancies requiring manual correction. Leaving the current process unchanged risks continued fulfillment misses and inventory inaccuracy.

**Scope**
This plan covers the steps from carrier arrival at the dock through system entry and put-away confirmation. It does not cover outbound shipping, returns processing, or the purchasing workflow upstream of receiving.

**Current state summary**
Trucks arrive and wait for a dock assignment (avg. 45 min). A receiving associate unloads and counts manually (avg. 90 min). A separate associate enters counts into the inventory system (avg. 60 min). Discrepancies are flagged and held for a supervisor review that happens once per shift (avg. 60 min wait). The entire sequence runs 4+ hours when a supervisor review is triggered.

**Improvement objectives**
1. Reduce average dock-to-system time from 4.2 hours to under 2.5 hours.
2. Reduce discrepancy-hold events by 30% through cleaner count procedures.
3. Complete the put-away confirmation step on the same shift as receipt.

**Planned actions**
1. Cross-train one receiving associate per shift to handle both counting and system entry. Owner: Warehouse Manager. Deadline: July 15. Dependency: system access permissions.
2. Revise the count sheet to match the PO line sequence, reducing lookup time. Owner: Operations Analyst. Deadline: July 10. Dependency: none.
3. Shift supervisor discrepancy review from batch (once per shift) to on-demand (within 20 minutes of flag). Owner: Shift Supervisor. Deadline: July 22. Dependency: supervisor scheduling review.
4. Add a mid-shift dock assignment check to reduce wait time. Owner: Dock Coordinator. Deadline: August 1. Dependency: none.

**Milestones and check-ins**
- Week 2: Actions 1 and 2 complete. First data pull on dock-to-system time.
- Week 4: All actions live. Baseline comparison review.
- Week 8: Mid-point check-in. Adjust if discrepancy hold rate has not moved.
- Week 12: Final review against all three objectives. Decision on whether changes become permanent standard procedure.

**Success measures**
At 90 days, average dock-to-system time is at or below 2.5 hours for at least 80% of receiving events. Discrepancy-hold events are down at least 30% versus the 90-day baseline before the initiative. No priority orders missed fulfillment due to an unresolved receiving delay in the final 30 days of the window.

**Risks**
1. Staff turnover during cross-training. Mitigation: document the combined procedure before cross-training begins so institutional knowledge does not leave with a single person.
2. Supervisor scheduling constraints limit on-demand review response time. Mitigation: escalation path to a backup reviewer is defined before the new cadence goes live.
3. Count sheet revision requires IT or system access that takes longer to provision than expected. Mitigation: start the access request in week one, not after the design is finished.

Turns raw inventory data into a concise action summary: what to reorder, what is overstocked, and what is moving slowly. Use it when you need a clear picture fast, before a buying decision or a leadership update.

## Context
You are a supply chain analyst helping me review inventory for [ORGANIZATION NAME]. The review covers [LOCATION OR WAREHOUSE] for the period ending [AS-OF DATE]. Inventory category or categories in scope: [CATEGORY SCOPE].

Inventory data (item number, description, on-hand quantity, unit of measure, unit cost, and average monthly usage):

[INVENTORY DATA]

## Task
Produce an inventory analysis summary with four sections:
1. Reorder candidates: items whose on-hand supply falls below [REORDER THRESHOLD] days of coverage. List item number, description, on-hand days of supply, and recommended action.
2. Overstock candidates: items whose on-hand supply exceeds [OVERSTOCK THRESHOLD] days of coverage. List item, days of supply, and the excess quantity in units.
3. Slow movers: items with average monthly usage below [SLOW MOVER THRESHOLD] units and more than [SLOW MOVER DAYS] days of supply. List item, monthly usage, and days of supply.
4. Summary counts and totals: number of items in each bucket, total unit cost of overstock excess, total unit cost of reorder candidates.

Recompute days of supply for each item using the formula: on-hand quantity divided by average monthly usage times 30. Show the computed days of supply for every item in the reorder and overstock sections.

## Standards
- Use only the quantities, costs, and usage figures I provide. Do not invent or estimate missing values.
- Show the days-of-supply formula computation for every item you categorize.
- Recompute totals and cross-check them before presenting. Flag any item whose data appears inconsistent (for example, zero usage with zero on-hand).
- Do not make purchasing recommendations beyond the threshold parameters I set. Quantity to order is my call.
- Flag any item where on-hand quantity or unit cost appears to be zero or blank, and exclude it from dollar totals.
- Note at the end that this output is based solely on the data provided and should be verified against the warehouse management system before action.

If any input field is missing or ambiguous, ask before running the analysis.

Sample output. Generated by AI from sample inputs:

Inventory Analysis Summary: Northwind Distribution Center, Atlas Warehouse
Period ending: 15 March 2025   Category: MRO Supplies

1. Reorder candidates (below 30 days of supply)

| Item # | Description | On-hand qty | Monthly usage | Days of supply | Action |
|---|---|---|---|---|---|
| MRO-0041 | Forklift hydraulic filter | 8 | 12 | 20 | Reorder |
| MRO-0087 | Pallet wrap, 18-in rolls | 24 | 30 | 24 | Reorder |
| MRO-0112 | Safety gloves, L (pair) | 15 | 22 | 20 | Reorder |

2. Overstock candidates (above 120 days of supply)

| Item # | Description | On-hand qty | Monthly usage | Days of supply | Excess qty | Excess cost |
|---|---|---|---|---|---|---|
| MRO-0003 | Box cutter blades (100-pk) | 200 | 4 | 1,500 | 184 packs | $276.00 |
| MRO-0055 | Label printer ribbon | 60 | 3 | 600 | 54 units | $324.00 |

3. Slow movers (usage below 5 units/month and above 180 days of supply)

| Item # | Description | Monthly usage | Days of supply |
|---|---|---|---|
| MRO-0003 | Box cutter blades (100-pk) | 4 | 1,500 |
| MRO-0055 | Label printer ribbon | 3 | 600 |

4. Summary
- Reorder candidates: 3 items
- Overstock candidates: 2 items (total excess cost: $600.00)
- Slow movers: 2 items

Note: Days of supply computed as on-hand quantity divided by monthly usage times 30. Output is based on data provided. Verify against the warehouse management system before placing orders.

Turns your sales and operations planning (S&OP) numbers into a plain-English summary your leadership team can read and act on. Use it when you need to brief decision-makers on demand, supply, and inventory position without handing them a spreadsheet.

## Context
You help a supply chain or operations manager prepare a sales and operations planning (S&OP) narrative for [COMPANY OR UNIT NAME]. The review period is [REVIEW PERIOD]. The audience is [AUDIENCE, e.g., leadership team, operations director, site manager]. The key figures for this cycle:

Demand data:
[DEMAND DATA]

Supply and capacity data:
[SUPPLY AND CAPACITY DATA]

Inventory position:
[INVENTORY POSITION]

Open issues or constraints:
[OPEN ISSUES]

## Task
Write a one-to-two-page S&OP narrative covering:
1. Demand summary: what the forecast says, how it compares to the prior period, and any significant changes.
2. Supply and capacity summary: whether supply can meet the forecast, and any gaps or constraints.
3. Inventory position: current stock levels versus targets, and whether safety stock is adequate.
4. Open issues and recommended actions: list each issue, the decision needed, and who owns it.
5. A one-paragraph executive summary at the top, written for a reader who will only read the first paragraph.

## Standards
- Use only the figures provided. Do not invent demand numbers, percentages, inventory levels, dates, or dollar figures.
- State gaps and shortfalls directly. Do not soften numbers with hedge language.
- Recommended actions are suggestions only. Decisions belong to the operations team.
- If a forecast number, inventory target, or constraint is missing from the inputs, note the gap rather than assuming a value.
- Tone is direct and professional. No filler phrases.
- If any named input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

S&OP Narrative: Northwind Distribution, Atlas Warehouse
Review Period: May 2026
Prepared for: Operations Leadership Team

Executive Summary
Demand for May is tracking 12 percent above April actuals, driven by a seasonal uptick in the outdoor equipment category. Supply capacity is sufficient to meet the forecast. One constraint exists: a 14-day lead time extension from Ridgeline Components (fasteners, SKU group 4xx) creates a coverage gap for weeks three and four. A decision is needed by May 9 on whether to place an accelerated order or draw down safety stock.

Demand Summary
The May forecast is 48,200 units across all categories, compared to 43,100 units shipped in April. The outdoor equipment category accounts for the full increase (plus 5,100 units). All other categories are flat to prior period. The forecast was last updated May 1 and reflects confirmed purchase orders through May 20. The remaining 30 percent of the month is estimated demand.

Supply and Capacity Summary
Warehouse throughput capacity is 52,000 units per month. May demand of 48,200 units is within capacity. All primary supplier commitments are confirmed except Ridgeline Components, which notified Northwind on April 28 of a 14-day extension affecting fastener delivery. Affected SKUs: 401 through 418. Expected receipt date moves from May 6 to May 20.

Inventory Position
Current on-hand: 11,400 units across all SKUs. Safety stock target: 8,000 units. Current position is above target. However, fastener SKUs (401-418) stand at 620 units on hand against a safety stock target of 900 units. These SKUs will drop below safety stock by May 14 without intervention.

Open Issues and Recommended Actions
1. Ridgeline Components lead time extension. Decision needed: accelerate order at premium freight cost, or draw down safety stock below target for two weeks. Owner: Procurement. Decision by: May 9.
2. Outdoor equipment demand estimate for May 21-31 is based on historical trend, not confirmed orders. Recommend confirming with the sales team by May 12. Owner: Sales Operations.

This narrative is AI-assisted. All figures should be verified against source system records before distribution.

Drafts a structured request for proposal that gives vendors the information they need to respond accurately. Use it when you are sourcing a service, solution, or complex supply requirement and need competitive proposals.

## Context
You are a procurement specialist helping me draft a Request for Proposal (RFP) for [ORGANIZATION NAME]. We are sourcing [WHAT IS BEING PROCURED]. This RFP will go to [NUMBER OF VENDORS] vendors. The procurement is governed by [APPLICABLE RULES OR POLICY, e.g., FAR, state procurement code, internal policy, or none specified]. Key background:

- Requirement description: [REQUIREMENT DESCRIPTION]
- Estimated budget range (if releasable): [BUDGET RANGE OR "not disclosed"]
- Period of performance or delivery timeline: [TIMELINE]
- Evaluation criteria and weights: [EVALUATION CRITERIA]
- Submission deadline: [SUBMISSION DEADLINE]
- Points of contact: [POC NAME AND CONTACT INFO]

## Task
Draft a complete RFP document with these sections:
1. Introduction and background
2. Scope of work and requirements
3. Proposal instructions (format, page limits, sections required)
4. Evaluation criteria and how scoring will work
5. Submission instructions and deadline
6. Terms, conditions, and any required certifications
7. Questions and clarification process

Use plain language throughout. Vendors of varying sizes will read this.

## Standards
- Do not invent requirements, dates, dollar figures, evaluation weights, or compliance rules the user did not provide.
- Write each requirement as a clear, testable statement. Avoid vague phrases like "world-class" or "best-in-class."
- Mark any section where the user left a variable blank with [NEEDS INPUT] so nothing is published incomplete.
- Keep the tone direct and professional. This is a legal procurement document: note that final legal and contractual review by appropriate authority is required before issuance.
- Do not invent vendor names, past contracts, or agency history.
- If a named input is missing or ambiguous, ask before drafting that section.

Sample output. Generated by AI from sample inputs:

REQUEST FOR PROPOSAL
RFP No.: NW-2026-LOG-007
Northwind Distribution LLC

1. Introduction and Background
Northwind Distribution LLC (Northwind) is a regional third-party logistics provider headquartered in Columbus, Ohio. We are issuing this RFP to solicit proposals for a warehouse management system (WMS) to support our new Atlas fulfillment center opening in Q3 2026. This RFP is governed by Northwind's internal procurement policy.

2. Scope of Work and Requirements
The selected vendor must provide:
- A cloud-hosted WMS capable of managing up to 50,000 SKUs
- Real-time inventory visibility with barcode and RFID scanning support
- Integration with Northwind's existing ERP (Microsoft Dynamics 365)
- Role-based access for warehouse staff, supervisors, and finance
- Training for up to 40 users prior to go-live
- 99.5 percent uptime SLA with a documented incident response process

Delivery and go-live: no later than August 15, 2026.

3. Proposal Instructions
Submit proposals in PDF format, maximum 30 pages, structured as follows:
- Section 1: Technical approach and system architecture
- Section 2: Implementation plan and timeline
- Section 3: Training and change management plan
- Section 4: Pricing (include one-time and recurring costs separately)
- Section 5: References (minimum three, similar scope)

4. Evaluation Criteria
Proposals will be scored on the following criteria:
- Technical capability and fit: 40 percent
- Implementation plan and timeline: 25 percent
- Pricing and total cost of ownership: 20 percent
- References and past performance: 15 percent

Northwind reserves the right to conduct demonstrations before final award.

5. Submission Instructions
Submit proposals by email to [email protected] no later than July 11, 2026 at 5:00 PM Eastern. Proposals received after this time will not be evaluated.

6. Terms and Conditions
Northwind is not obligated to award a contract as a result of this RFP. Costs incurred by vendors in preparing proposals are not reimbursable. Northwind reserves the right to cancel this RFP at any time.

7. Questions and Clarifications
Submit written questions to [email protected] by June 27, 2026. Answers will be distributed to all vendors by July 3, 2026. No oral questions will be binding.

Point of contact: Maria Chen, Procurement Manager, (614) 555-0182.

Drafts the award letter to a selected vendor and the decline letters to the vendors who were not selected, after a competitive sourcing process closes. Use it as soon as the award decision is final and documented.

## Context
You are assisting a [YOUR ROLE (e.g., procurement manager, contracting officer, operations lead)] at [ORGANIZATION NAME] who has completed a competitive sourcing process for [GOODS OR SERVICES DESCRIPTION]. The solicitation reference is [SOLICITATION NUMBER OR TITLE]. The award decision has been made and is formally documented. Selected vendor: [SELECTED VENDOR NAME]. Vendors not selected: [DECLINED VENDOR LIST (names only)]. Award value: [AWARD VALUE]. Award period: [AWARD PERIOD (e.g., 12 months, June 1 2026 through May 31 2027)]. Debriefs: [DEBRIEF POLICY (e.g., debriefs available on written request within 5 days)].

## Task
Produce two documents:
1. Award letter to [SELECTED VENDOR NAME]. State the award, the value, the period, the next step (e.g., contract execution, kickoff scheduling), and a contact name for questions: [AWARD CONTACT NAME AND EMAIL].
2. A decline letter template that fits all unsuccessful vendors. State that a selection was made, that the vendor's proposal was considered, and whether debriefs are available. Do not rank, score, or compare vendors. Leave a placeholder for the vendor name.

## Standards
- Award letter: under 200 words. Professional and direct. State the award first, then the details.
- Decline letter: under 150 words. Respectful. No criticism of the proposal. No implied promises about future opportunities.
- Do not invent the award value, award period, solicitation number, or debrief policy. Use only what I provided above.
- Both letters must name the solicitation consistently using the exact title or number I gave you.
- Do not include contract terms, payment terms, or scope language. Those belong in the contract, not the award letter.
- If any required field above is missing or unclear, ask me before drafting.

Sample output. Generated by AI from sample inputs:

AWARD LETTER

Subject: Award Notification: Solicitation 2026-LOG-041, Warehouse Management Software

Dear Ms. Reyes,

Northwind Distribution is pleased to inform Apex Systems that it has been selected for award under Solicitation 2026-LOG-041, Warehouse Management Software Implementation and Licensing.

Award value: $184,000
Award period: July 1, 2026 through June 30, 2027

Next step: Our contracts team will send the agreement for signature within five business days. Please direct any questions to Marcus Webb, Procurement Manager, at [email protected].

Thank you for your proposal and your interest in working with Northwind.

Sincerely,
Procurement Division
Northwind Distribution

---

DECLINE LETTER TEMPLATE

Subject: Notification of Selection: Solicitation 2026-LOG-041, Warehouse Management Software

Dear [VENDOR NAME],

Thank you for submitting a proposal under Solicitation 2026-LOG-041, Warehouse Management Software Implementation and Licensing. After careful review, Northwind Distribution has selected another vendor for this award.

We appreciate the time your team invested in responding. If you would like a debrief, please submit a written request to [email protected] within five business days of this notice.

We hope to see your firm in future solicitations.

Sincerely,
Procurement Division
Northwind Distribution

Builds a timed agenda for a team meeting based on the topics, owners, and time available you provide. Use it before any standing or ad hoc meeting where scattered discussion is wasting time.

## Context
You are helping [YOUR NAME], a [YOUR ROLE] at [ORGANIZATION NAME], build a meeting agenda for [MEETING NAME]. The meeting is [MEETING LENGTH] minutes long and will be held on [MEETING DATE]. Attendees: [ATTENDEE LIST OR ROLES]. The stated purpose of this meeting: [MEETING PURPOSE]. Topics to cover, in the order I want to address them: [TOPIC LIST WITH OWNERS AND ROUGH TIME ESTIMATES]. Any standing items that open or close every meeting: [STANDING ITEMS]. Materials or pre-reads attendees should bring: [PRE-READ MATERIALS].

## Task
Build a timed meeting agenda with these sections in order:
1. Header: meeting name, date, time, location or link, and expected attendees.
2. Meeting purpose: one sentence stating what we need to accomplish by the end.
3. Timed agenda items: each item on its own line with time block, topic, owner, and expected output (decision, information shared, action assigned, or discussion).
4. Standing items: opening and closing items if I provided them.
5. Pre-read list: materials attendees should review before arriving.
6. Parking lot: a blank section at the bottom for items raised but not scheduled.

## Standards
- Total time blocks must add up to exactly [MEETING LENGTH] minutes. Show the running total.
- Use only the topics, owners, and time estimates I provided. Do not invent agenda items.
- Label each item with its expected output type. A meeting where no one knows why an item is on the agenda wastes everyone's time.
- Keep language short and direct. Each item title should be five words or fewer.
- Do not promise decisions or outcomes in the agenda. State what will be attempted.
- If a bracketed input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

**Weekly Ops Sync**
Northwind Distribution | Operations Team
Date: Wednesday, June 18, 2026 | 9:00 to 9:50 AM
Location: Conference Room B / Teams link in invite
Attendees: Ops Manager, Warehouse Lead, Transport Coordinator, Inventory Analyst

**Purpose:** Confirm Atlas warehouse migration status, resolve the inbound dock scheduling conflict, and assign Week 26 closeout actions.

**Agenda**

0:00 to 0:05 (5 min) - Opening and attendance | Owner: Ops Manager | Output: Information
0:05 to 0:15 (10 min) - Atlas migration status update | Owner: Warehouse Lead | Output: Information + decisions on open items
0:15 to 0:25 (10 min) - Inbound dock scheduling conflict | Owner: Transport Coordinator | Output: Decision
0:25 to 0:35 (10 min) - Week 26 inventory closeout | Owner: Inventory Analyst | Output: Action assignments
0:35 to 0:45 (10 min) - Open items from last week | Owner: Ops Manager | Output: Decision or defer
0:45 to 0:50 (5 min) - Action item recap and close | Owner: Ops Manager | Output: Action

Running total: 5 + 10 + 10 + 10 + 10 + 5 = 50 minutes.

**Pre-reads**
- Atlas migration tracker (shared drive, last updated June 16)
- Inbound dock schedule for weeks 25 and 26

**Parking Lot**
(Items raised during the meeting that need a future slot go here.)

Builds a structured agenda and talking points for a recurring status meeting. Use it before any weekly or biweekly team sync where you need to surface progress, blockers, and next steps without letting the meeting run long.

## Context
You are helping [YOUR NAME AND ROLE] prepare for a recurring [MEETING CADENCE: e.g., weekly, biweekly] status meeting for [PROJECT OR TEAM NAME]. The meeting includes [ATTENDEES OR ROLES]. Date of this meeting: [MEETING DATE]. Current project phase or milestone: [CURRENT PHASE]. Items to cover from the last meeting: [CARRYOVER ITEMS]. Updates from each workstream this period: [WORKSTREAM UPDATES]. Open blockers or issues needing the group's attention: [BLOCKERS]. Decisions the group needs to make today: [DECISIONS NEEDED]. Action items from the last meeting and their current status: [PRIOR ACTION ITEMS STATUS].

## Task
Produce a clean meeting agenda with three parts: a one-paragraph opening framing the current state of the project, an ordered list of agenda items with a time allocation and owner for each, and a pre-written closing that captures the standing action-item format you want the note-taker to use. Include a parking lot section at the end for items that come up but are out of scope for today.

## Standards
- Plain language. No management jargon.
- Agenda items must come from the workstream updates and blockers I supply. Do not invent progress, milestones, or risk items.
- Time allocations must add up to the total meeting length I specify. If I do not specify a length, ask before assigning times.
- Blockers should be stated as specific questions the group needs to answer, not as vague problem statements.
- Do not invent action item owners, due dates, or resolution statuses for prior action items.
- If [WORKSTREAM UPDATES] or [BLOCKERS] are missing or vague, ask me to clarify before drafting.
- This prompt is a planning aid. Confirm all statuses, dates, and metrics with your own project records before the meeting.

Sample output. Generated by AI from sample inputs:

Atlas Warehouse Migration | Weekly Status Meeting
Northwind Distribution | Tuesday, June 17, 2026 | 9:00-9:45 a.m.
Facilitator: Dana Kowalski, Project Manager

Project State
We are in Phase 2 (rack installation and network cabling) with a target completion of July 11. Phase 1 closeout is complete. Three action items from last week are closed; one is open and on today's agenda.

Agenda
1. (2 min) Quick wins from last week | Dana
2. (8 min) Workstream updates
   - Rack installation: 60 of 120 sections complete. On track. | Marcus
   - Network cabling: Vendor started Monday. Pull schedule due Friday. | Priya
   - IT provisioning: Server migration window confirmed for July 5-6. | Chen
3. (10 min) Open blocker: The fire suppression inspection is scheduled for June 30, but the vendor needs a 10-day clear before we can stage inventory. Does that change our Phase 3 start date, or do we adjust the inspection slot? Decision needed today. | Dana
4. (10 min) Prior action items review
   - Order dock levelers (due June 13): CLOSED. Delivery confirmed July 2.
   - Confirm backup power specs with facilities (due June 13): CLOSED.
   - Security badge access list to HR (due June 13): OPEN. Priya to update today.
5. (10 min) Decisions and direction
   - Go/no-go on moving Phase 3 start from July 14 to July 21 based on inspection constraint
6. (5 min) Close + action items

Action Item Format (for note-taker)
Item | Owner | Due Date | Status

Parking Lot
Topics raised today that are out of scope for this meeting go here. Owner assigned to bring back next week.