AI prompts and workflows

Help me scope [project] for [audience]. The goal is [outcome]. Our constraints are [budget, timing, people, and tools]. Ask up to five questions that would materially change the plan. Then summarize the agreed scope, what is out of scope, and any unanswered questions. Do not invent commitments or begin implementation.

Using our agreed scope, create one downloadable HTML file for a team planning discussion. Include a project overview, a milestone timeline, deliverables, dependencies, risks, and unresolved decisions. Let me expand each milestone to see its tasks and acceptance checks. Mark proposed owners and dates as unconfirmed. Keep CSS and JavaScript inside the file, with no remote assets, network requests, or data collection. Make it readable on a phone and usable with a keyboard. This is a draft plan for review, not approval to carry out the work.

Draft a follow-up email to [customer role] after [conversation]. The purpose is [goal], and the next step is [action]. Use a [tone] tone and stay under 150 words. Use only these notes: [approved notes]. Include a subject line. Do not invent prices, promises, dates, or prior conversations. Mark missing facts in brackets. Prepare a draft only.

Revise this draft to sound more like this writing sample: [sample]. Keep the facts and next step intact. Remove generic openings, sales language, and unnecessary words. List any claims I should check before sending. Do not send the email.

Organize these meeting notes: [notes]. Return three sections: decisions explicitly made, action items, and open questions. For each action, include task, owner, due date, and the supporting note. Write "Not assigned" or "Not agreed" when the notes do not specify an owner or date. Keep suggestions separate from decisions.

Compare the recap against the original notes. Identify any action, owner, deadline, or decision that is not directly supported. Correct the recap and give me a short list of questions to confirm with attendees. Then draft a concise team update. Do not send or create tasks.

Help me compare [options] for [business need]. My criteria are [criteria], and my constraints are [constraints]. Use this source material: [material]. Create a comparison table. Distinguish source facts from assumptions and unknowns. Refer to the supporting passage for each factual claim. Do not fill missing information with guesses. Ask me about any essential missing criterion.

Given the clarified criteria, explain which option fits best and why. Make the strongest case against it. Identify the assumptions that could change the recommendation, what evidence would resolve them, and a reversible next step. Do not invent numerical scores or treat the recommendation as a final decision.

Help me document [repeat task] for [person or role]. Here is how we do it today: [steps and notes]. The expected result is [result]. Ask up to five questions about missing inputs, decisions, exceptions, or approval points. Do not assume access to tools or records I have not described.

Turn the confirmed process into a draft procedure. Include purpose, required inputs, numbered steps, expected output at each stage, common exceptions, when to stop and ask a person, and a completion checklist. Mark unresolved details clearly. Add one fictional practice case. Do not add system access, permissions, or company policies that I have not confirmed.

Prepare a weekly update for [audience] covering [date range]. Use only these labeled notes: [notes with source and date]. Group the result into completed work, work in progress, blockers, and proposed next steps. Cite the note label for each factual item. Preserve the dates and units of any numbers. Flag missing or conflicting information.

Using these corrections: [corrections], revise the update to under 300 words. Put the most important blocker or decision first. Keep completed work distinct from plans, and proposed next steps distinct from commitments. Retain source labels and unresolved gaps. Add a short review checklist. Do not distribute the update.

Schedule a morning brief at [time, timezone] using [approved sources] and [glossary file]. Report inaccessible sources.

Summarize yesterday’s meetings and overnight messages. Link sources. Extract actions, owners, deadlines, and urgent blockers; mark missing details.

List unfamiliar terms and project names. Quote supporting context and flag ambiguous meanings. Do not guess definitions.

Ask me to define each unfamiliar term. Propose a glossary entry for my review before saving.

Save only approved definitions to [glossary file]. Update the existing scheduled task to load this glossary and repeat these steps, asking before edits. Show saved instructions.

Plan a dashboard for [business question], [period], [metrics], and [audience]. Clarify definitions; do not query data or build yet.

Use existing reports first, then approved analytics datasets. Propose new queries only if necessary; obtain review before execution. Preserve access restrictions.

Build the dashboard from verified results. Show source references, units, date range, filters, and freshness. Flag missing data; do not fabricate values.

Add a breakdown by [dimension] and adjust [chart]. Preserve metric definitions and explain any change in totals.

Draft a project charter for [workflow]. Name [owner], allowed tasks, excluded work, data boundaries, and escalation contact.

Recommend project settings for [workflow]: approved model, cost limits, relevant skills, and minimum tool permissions. Flag unsupported controls.

Draft policies requiring explicit approval before [sensitive actions]. Identify who may approve, what they must see, and how denial blocks execution.

Test an allowed action, an approval-required action, and a denied action. Verify actual tool execution and logs; record whether controls held.

Inspect [CRM workflow URL] in Chrome. Confirm the workspace and existing nodes. Do not edit yet.

Confirm you can control this browser. Work only on this draft workflow; keep outbound email and activation disabled.

Route leads using [rules]. Draft a personalized email from the assigned owner with [owner-specific calendar links] and [approved talking points]. Send drafts to [review queue], never directly to leads.

Add and connect the required nodes. Preserve unrelated logic. Flag missing routing decisions instead of guessing. Keep the workflow inactive.

Test every route, missing fields, and repeat submissions. Verify owner, sender, calendar link, and review destination. Show results before activation.

Make every word justify its existence. Apply these rules to prose, never to code. Keep technical terms intact; use everyday words elsewhere only where precision survives.

## Writing rules

1. Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
2. Never use a long word where a short one will do.
3. If it is possible to cut a word out, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than say anything outright barbarous.

## Review

Read for meaning, audience, and tone before editing. Keep the author’s claims, intent, and voice. Preserve facts, names, numbers, links, qualifications, and uncertainty. Do not invent an actor to force an active sentence or strengthen a claim by cutting a needed qualifier.

Cut filler, repetition, stock phrases, and needless transitions. Choose short, concrete words and direct verbs. Keep enough context for the reader to follow the thought. Favor natural prose over rigid rules or the shortest possible text.

Leave code, commands, identifiers, technical terms, and attributed quotations unchanged unless the user asks to edit them.

Return the revised copy by default. If the user asks only for critique, give focused findings instead. Add notes only when requested or needed to flag an ambiguity or a change in meaning; keep them brief.

Before delivering, review every prose output, including any notes, against all six rules. Ask of each word: does it add meaning, preserve precision, or help the sentence read naturally? Cut it if it does none of these.

Help me create a sample course layout for prospective Hiatt Co customers. Hiatt Co teaches small-business owners and teams how to use AI in their work.

The example should help a customer understand who the course serves, what participants will practice, what they will leave with, and how we could adapt it to their team.

Create a customer-facing example, not a complete curriculum or a confirmed offer.

Starting context:

- Course idea: [topic or working title]
- Audience and current skills: [who will attend]
- Business tasks they want to improve: [tasks]
- Format and available time: [format, duration, or undecided]
- Tools participants can use: [tools or undecided]
- My initial braindump: [paste notes or dictated text]

1. Build a shared course notebook

Create a small Markdown wiki for this course. Include:

- Brief: audience, business need, scope, and constraints.
- Learning outcomes: what participants should be able to do.
- Course outline: sections, sequence, and proposed timing.
- Decisions: confirmed choices, assumptions, and open questions.
- Feedback: my comments and how they affect the course.

Treat my notes as source material. Separate confirmed decisions from suggestions and unresolved ideas. Do not turn tentative remarks into commitments. Ask only questions whose answers would materially change the course; otherwise proceed with labeled assumptions.

2. Develop the sections

Break the course into sections that can be drafted independently.

For each section, define:

- A clear title and practical purpose.
- An observable learning outcome.
- A short explanation or demonstration.
- A hands-on exercise using fictional or anonymized business material.
- A concrete output participants will create.
- A review check that shows whether the exercise worked.
- Proposed timing and prerequisites.

If parallel agents are available, assign each a separate section file and have them read the shared brief first. Keep shared decisions under one coordinator. Reconcile terminology, difficulty, dependencies, and timing before combining their work.

3. Turn the outline into a customer example

Create a self-contained HTML page I can open locally and share with a prospective customer.

Show:

- Course title and a plain-language description.
- Intended audience and prerequisites.
- What participants will practice and leave with.
- An agenda with expandable section details.
- One representative exercise with an example prompt and expected output.
- What the customer would need to provide.
- Options for adapting the course to different teams.

Make it readable on phones, printable, and usable with a keyboard. Keep assets local and avoid external dependencies.

Label it “Sample course outline — adapted after a planning conversation.” Clearly mark proposed durations and tool requirements. Do not invent prices, testimonials, credentials, guaranteed results, or approved commitments.

Keep internal planning notes out of the customer page.

4. Integrate my feedback

After each draft, give me the HTML page and a brief report of changes and unresolved decisions.

I will respond with dictated braindumps. Integrate them into the notebook, flag contradictions, and update affected sections. Preserve earlier decisions unless I change them. Keep a short decision history.

5. Run a course review

Create a reusable review checklist or skill for the whole course. Run it before presenting the first draft and after substantial revisions.

If agents are available, use independent reviewers for learning design, business relevance, timing, accuracy, accessibility, and copy. Look for:

- Vague or untestable outcomes.
- Missing prerequisites or gaps in the sequence.
- Exercises that do not support the stated outcomes.
- Too much material for the proposed time.
- Unsupported claims or unconfirmed tool capabilities.
- Repetition, filler, jargon, and sales language.
- Differences between the course plan and customer page.

Fix supported findings and rerun affected checks. Bring unresolved decisions to me. Do not schedule unattended work unless I ask.

Start by organizing my initial braindump and producing the first sample layout.