> `YOUR GRACE AGENCY  /  AUTOMATION LAUNCH KIT  /  PROMPT PACK  /  07 OF 11`
>
> **AUTOMATE. DELIVER. EMPOWER.**
> *Use AI to prepare structured work—not to replace accountable judgment.*

# Copy-Ready Prompt Pack

**25 practical prompts · tool-agnostic · version 1.0**

## How to use these prompts

| Use mode | What to do | Keep human |
| --- | --- | --- |
| Design | adapt a prompt before it touches live data | business rules and approval criteria |
| Test | run at least five representative test records | evidence review and exception decisions |
| Launch | connect only structured, validated output | every consequential external action |

> **PROMPT SAFETY NOTE**
> These prompts help you draft, classify, summarize, and document. They do not authorize a model to make financial, legal, access, security, employment, medical, or publishing decisions.

Replace every value in `[brackets]` before running. Paste only the minimum necessary business or client information. For work that affects an external person—messages, financial records, scope, promises, or publishing—treat the result as a **draft requiring human review**.

### Prompt QA standard

Each prompt below has been written and desk-tested against the stated sample input for: (1) a clear output format, (2) no invented facts when evidence is missing, (3) a defined manual-review condition, and (4) a usable next action. Before connecting any prompt to a live automation, run it against five of your own test records and compare its output to the QA checks in `03-setup/automation-launch-checklist.md`.

---

## A. Choose and map the workflow

### 1. Workflow opportunity scorer
**Use:** choose one repeatable task worth automating.

```text
You are an operations analyst for a small business. Score each workflow below from 1–5 for frequency, time cost, error risk, and clarity of trigger. Then recommend exactly one workflow to automate first.

Business: [business type]
Workflows:
[paste 3–7 workflows with frequency, minutes per occurrence, and pain points]

Return a markdown table with the four scores, total, one-sentence reason, and a final recommendation. Do not recommend a workflow if its trigger is unclear or it includes legal, medical, financial-approval, or sensitive-personnel decisions. State what must be clarified first.
```

**Sample test:** Three weekly tasks: inquiry follow-up, invoice reminders, and ad-hoc client requests.  
**Pass condition:** Picks inquiry follow-up if it has a clear form trigger and flags ad-hoc requests as too vague.

### 2. Trigger definition
**Use:** turn a fuzzy process into one observable start event.

```text
Turn this workflow description into one safe automation trigger.

Workflow: [description]
Available sources: [form, table, inbox label, calendar, payment status, etc.]
Do not use sources: [anything unavailable or unsafe]

Return: (1) exact trigger event, (2) required fields present at trigger time, (3) events that must NOT trigger it, and (4) one test record. If no reliable trigger exists, say “manual start required” and explain why.
```

**Sample test:** “Start onboarding when the client says yes.”  
**Pass condition:** Rejects verbal “yes” and proposes a confirmed status or signed agreement.

### 3. Minimum viable automation map
**Use:** reduce a workflow to a safe v1.

```text
Design a minimum viable automation for the workflow below. Limit it to one trigger, one validation step, one conditional branch, one destination update, and one human notification.

Workflow: [workflow]
Source: [source app/process]
Destination: [destination app/process]
Owner: [role]
Risky actions to keep manual: [list]

Return numbered steps, required fields, failure path, and the one metric to measure in week one. Do not add tools or steps that are not named above.
```

**Sample test:** Lead form to CRM.  
**Pass condition:** Includes duplicate check and a review notification, not auto-send email.

### 4. Field schema builder
**Use:** define the minimum data structure before building.

```text
Create a simple data schema for this workflow: [workflow].

Inputs we currently receive: [paste fields]
Decisions we need to make: [paste]
Destination: [CRM/table/project board]

Return a table with: field name, plain-language definition, type, required yes/no, example, source, and privacy note. Keep only fields needed to route, fulfill, or measure the workflow. Mark any sensitive field “do not send to AI.”
```

**Sample test:** Client onboarding with name, email, proposal link, start date.  
**Pass condition:** Separates client-facing details from internal negotiation notes.

### 5. Failure-path designer
**Use:** make a workflow recoverable before it fails live.

```text
For this automation, identify the five most likely failure modes and design a recovery path for each.

Automation: [steps]
Source data: [fields]
Destination: [system]
Owner: [role]

Return a table: failure signal, probable cause, immediate containment, owner, retry rule, and whether a customer-facing action must be paused. Do not propose automatic retries for actions that could duplicate messages, payments, or records.
```

**Sample test:** Client onboarding creates a project after confirmation.  
**Pass condition:** Includes duplicate-event protection and pauses client messaging.

---

## B. Intake, classification, and routing

### 6. Lead fit classifier
**Use:** categorize a new inquiry with a reason.

```text
Classify this inquiry as exactly one of: priority, standard, nurture, manual review.

Qualification rules:
- Priority: matched offer + explicit timeline + budget or authority signal
- Standard: matched need but one decision-critical detail missing
- Nurture: possible future fit without active timing
- Manual review: spam, sensitive, unclear, or outside policy

Inquiry: [paste]

Return JSON only: {"label":"", "evidence":["quoted evidence"], "missing_information":[""], "next_action":""}. Do not infer budget, authority, or urgency that is not written.
```

**Sample test:** “Need launch help by September, budget around $3k.”  
**Pass condition:** Returns `priority` and quotes the timing/budget words.

### 7. Lead reply draft
**Use:** make a concise, personalized reply draft.

```text
Draft a reply to this inquiry. Use a warm, precise tone. Keep it under 150 words. Acknowledge the stated goal, state the next available step, and ask at most two questions that change the recommendation.

Inquiry: [paste]
Approved offer details: [paste]
Scheduling or next-step link: [paste or “not available”]

Do not promise results, availability, pricing, or timelines not supplied. Do not send the message; label the output “DRAFT FOR APPROVAL.”
```

**Sample test:** Inquiry missing team size and launch date.  
**Pass condition:** Asks those two questions rather than inventing a package.

### 8. Support category and priority
**Use:** triage a request into a review queue.

```text
Classify the message into one category: access, billing, bug, how-to, feature request, feedback, sensitive, manual review. Assign priority: urgent, high, standard, or low.

Message: [paste]
Known context: [product, account status if safely available]

Return JSON only: {"category":"", "priority":"", "evidence":["quoted evidence"], "safe_next_step":"", "auto_reply_allowed":true/false}. Set auto_reply_allowed to false for access, billing, sensitive, unknown account status, refunds, privacy, or security matters.
```

**Sample test:** “My paid download link expired.”  
**Pass condition:** `access`, `high`, and `auto_reply_allowed: false`.

### 9. Feedback theme extractor
**Use:** find repeat patterns without erasing individual context.

```text
Analyze these feedback items. Create no more than five themes. For each theme, cite the item IDs that support it, distinguish request vs. complaint vs. praise, and state confidence: high, medium, or low.

Feedback items:
[ID + text]

Return a table plus a short “do not conclude yet” section for themes supported by fewer than three items. Do not invent customer sentiment or quantitative impact.
```

**Sample test:** Ten comments, three about onboarding confusion.  
**Pass condition:** Reports the theme with the three IDs and does not call it universal.

### 10. Content idea router
**Use:** decide whether an idea is ready for production.

```text
Review this content idea for production readiness.

Idea: [paste]
Audience: [paste]
Channel: [paste]
Desired action: [paste]
Proof/source available: [paste]

Return exactly one status: ready, needs source, needs CTA, needs scope, or not aligned. Then list the smallest next action. Flag claims that need evidence. Do not write the content yet.
```

**Sample test:** Strong topic but no desired action.  
**Pass condition:** Returns `needs CTA`.

---

## C. Draft and transform content

### 11. Client onboarding welcome draft
**Use:** draft a human-reviewed welcome message.

```text
Write a client onboarding welcome message using the confirmed details below. Use clear headings and a calm, capable tone. Keep it under 220 words.

Client: [name]
Confirmed service: [service]
Start date: [date]
Kickoff link: [link]
Intake link: [link]
What happens next: [steps]

Include only confirmed details. Do not mention payment, contract terms, guarantees, or internal process. End with one clear next action. Title the output “DRAFT FOR OWNER APPROVAL.”
```

**Sample test:** Confirmed strategy sprint and kickoff link.  
**Pass condition:** Has one next action and no invented timing.

### 12. Internal delivery handoff
**Use:** turn sales context into an actionable delivery brief.

```text
Create an internal delivery handoff from the confirmed project facts below.

Facts: [paste approved scope, objectives, dates, stakeholders]
Unknowns: [paste]

Return sections: client goal, confirmed scope, out of scope, success signal, key dates, stakeholders, risks, first three actions, and questions to resolve. Do not include negotiation notes, payment details, or assumptions not supported by the facts.
```

**Sample test:** Proposal has objective and timeline but no success metric.  
**Pass condition:** Lists a question rather than inventing a metric.

### 13. Content brief generator
**Use:** create a structured brief from an approved idea.

```text
Create a content brief from this approved idea.

Idea: [paste]
Audience: [paste]
Channel: [paste]
Desired action: [paste]
Proof/source: [paste]
Brand tone: precise, bold, practical; avoid hype and unsupported claims.

Return: working title, audience problem, single promise, angle, outline, proof notes, CTA, required assets, review checklist, and claims requiring verification. Keep facts separate from opinions.
```

**Sample test:** “How to prioritize automation.”  
**Pass condition:** Includes a claims-to-verify section.

### 14. Repurpose one source safely
**Use:** adapt an approved source for several channels.

```text
Repurpose the approved source below into [channels]. Preserve the original meaning and flag any claim that should not be repeated without a source.

Source: [paste]
Audience: [paste]
Desired action: [paste]

For each channel, return: hook, format-specific outline, CTA, and one risk/check. Do not add statistics, testimonials, customer names, or promises not in the source.
```

**Sample test:** One approved newsletter for LinkedIn + carousel.  
**Pass condition:** Does not add performance numbers.

### 15. Invoice reminder draft
**Use:** draft a respectful reminder for review.

```text
Draft a concise invoice follow-up message. Tone: professional, respectful, never threatening.

Client name: [name]
Invoice ID: [ID]
Amount: [amount]
Due date: [date]
Stage: [upcoming / due today / 1–3 days overdue / 4–7 days overdue]
Payment link or instructions: [verified text]
Known exception: [none or paste]

If there is a dispute, partial payment, or exception, do not draft a reminder; return “MANUAL REVIEW REQUIRED” with the reason. Otherwise produce “DRAFT FOR APPROVAL” under 130 words.
```

**Sample test:** Standard invoice one day overdue.  
**Pass condition:** Is concise and avoids guilt/pressure language.

---

## D. QA, safety, and launch

### 16. Test-record generator
**Use:** create a useful test set before live activation.

```text
Create 10 fictional test records for this workflow: [workflow]. Include a mix of normal, missing-field, duplicate, edge-case, and manual-review records.

Required fields: [paste]
Known edge cases: [paste]

Return a table with test ID, input values, expected route, expected output, and why it matters. Use fictional names and contact details only. Do not create realistic personal data for real people.
```

**Sample test:** Lead intake.  
**Pass condition:** Includes at least one duplicate and one suspicious-link case.

### 17. Automation test oracle
**Use:** compare a workflow run to expected behavior.

```text
Compare the actual automation run to the expected result. Identify only observable mismatches.

Expected: [paste]
Actual: [paste]

Return: pass/fail, mismatches, severity (blocker/high/medium/low), likely step where it happened, and the smallest retest. Do not assume causes that are not visible in the data.
```

**Sample test:** A duplicate inquiry produced two CRM records.  
**Pass condition:** Marks failure and identifies dedupe as the likely step.

### 18. AI-output quality check
**Use:** review a draft created by any model.

```text
Quality-check this AI-generated draft against the source facts.

Source facts: [paste]
Draft: [paste]
Required tone: [paste]

Return a table with issue type (unsupported claim, missing detail, privacy risk, tone, ambiguity, formatting), exact excerpt, why it is a problem, and a correction. Finish with APPROVE, REVISE, or HUMAN ESCALATION. Do not silently rewrite the draft.
```

**Sample test:** Draft promises a “guaranteed launch result” without source support.  
**Pass condition:** Flags it as unsupported and returns `REVISE`.

### 19. Privacy minimizer
**Use:** reduce data before sending it to an AI step or shared notification.

```text
Review this workflow payload and produce a minimized version that still supports the stated task.

Task: [classification / drafting / summarization]
Payload: [paste fields and values]

Return three lists: keep, remove, replace with placeholder. Explain each decision in one sentence. Always remove passwords, payment-card data, government IDs, health details, credentials, and unnecessary personal addresses. If the task cannot be done safely after minimization, state “manual handling required.”
```

**Sample test:** Onboarding payload includes personal address and card details.  
**Pass condition:** Removes both.

### 20. Launch readiness gate
**Use:** decide whether to turn on a v1 automation.

```text
Assess whether this automation is ready for limited live launch.

Workflow summary: [paste]
Test results: [paste]
Owner: [paste]
Rollback method: [paste]
Human approval step: [paste]

Return exactly one decision: READY FOR LIMITED LAUNCH, FIX BEFORE LAUNCH, or MANUAL PROCESS ONLY. Then list the evidence, blockers, monitoring plan for seven days, and the rollback trigger. Do not mark ready if duplicate prevention, owner assignment, or a failure path is missing.
```

**Sample test:** Nine of ten tests pass but a client email could auto-send incorrectly.  
**Pass condition:** Returns `FIX BEFORE LAUNCH`.

---

## E. Improve and document

### 21. SOP draft from a workflow
**Use:** turn a proven flow into a repeatable operating procedure.

```text
Write an SOP draft from this proven workflow. Keep it usable by a new teammate.

Workflow steps: [paste]
Owner: [role]
Tools: [paste]
Quality standard: [paste]
Escalation rules: [paste]

Return: purpose, trigger, roles, prerequisites, numbered procedure, quality checks, exceptions, escalation, and revision date placeholder. Mark any step that is not yet proven as “validate before adoption.”
```

**Sample test:** Lead intake workflow with manual review branch.  
**Pass condition:** Includes manual-review escalation.

### 22. Weekly automation review
**Use:** decide what to keep, adjust, or stop.

```text
Analyze this week-one automation log.

Goal: [paste]
Baseline: [paste]
Metrics: [paste]
Failures/notes: [paste]

Return: what worked, what failed, evidence, one change to test next week, what must remain manual, and a keep/adjust/pause recommendation. Do not claim causation from fewer than five completed runs; say what additional evidence is needed.
```

**Sample test:** Four successful runs and one duplicate.  
**Pass condition:** Recommends adjustment, not broad success claims.

### 23. Exception playbook
**Use:** turn recurring exceptions into a safe policy.

```text
Create a one-page exception playbook for this recurring situation: [situation].

Examples: [paste 3–10 cases]
Business policy or constraints: [paste]

Return: signal, default route, who decides, information required, customer communication boundary, time target, and lessons to feed back into the automation. Do not create policy where none exists; list decisions the owner must make.
```

**Sample test:** Frequent “wrong contact email” access requests.  
**Pass condition:** Requires ownership verification and a human decision.

### 24. Metric definition assistant
**Use:** choose a measurable result for one workflow.

```text
Define one primary and up to two guardrail metrics for this automation.

Workflow: [paste]
Business goal: [paste]
Available data: [paste]
Possible risks: [paste]

Return a table with metric, formula, data source, baseline needed, target type (directional/not guaranteed), review cadence, and what bad result it would catch. Prefer measures of time, completeness, errors, or response quality over vanity metrics.
```

**Sample test:** Lead routing.  
**Pass condition:** Defines response-time reduction and duplicate-rate guardrail.

### 25. Handoff summary for a human owner
**Use:** make an automation’s current state legible.

```text
Write a handoff summary for the owner of this automation.

Name: [automation name]
Purpose: [paste]
Trigger: [paste]
Current status: [paste]
Recent runs: [paste]
Known issues: [paste]
Next review date: [date]

Return exactly these headings: Purpose, Trigger, What It Does, What It Does Not Do, Owner Actions, Recent Evidence, Known Risks, Pause/Rollback Steps, Next Review. Use plain language; do not hide uncertainty.
```

**Sample test:** Lead intake v1 with one manual-review issue.  
**Pass condition:** Clearly says the automation drafts but does not send replies.

## Prompt output rules for every workflow

- Save the source record ID beside the generated output so a human can trace it.
- Require structured formats (JSON, tables, fixed headings) when an automation needs to read the result.
- If the model returns an unexpected label, empty required field, or unsupported claim, send the record to manual review.
- Never let a model approve payments, contracts, refunds, access verification, legal claims, medical guidance, hiring/termination, or security decisions.
- Archive prompt changes with a date and a short reason; prompt changes are workflow changes.

---

`YOUR GRACE AGENCY  ·  PROMPT PACK / 25 COPY-READY PROMPTS  ·  REVIEW OUTPUT BEFORE ACTION`
