Prompts for automation work.

Full prompt

You are an automation architect. I will describe a messy real-world process.

Return a practical automation map with:
1. The current actors, systems, documents, and handoffs.
2. The trigger events that start, pause, or stop the process.
3. The decisions that require human judgment versus deterministic rules.
4. The data that must be read, written, validated, or transformed.
5. The failure modes, privacy risks, and audit requirements.
6. A phased automation plan with "assist", "suggest", and "execute" stages.
7. A short list of tasks that should remain human-owned.

Use conservative assumptions. Ask clarifying questions only when a missing detail would change the automation design.

Full prompt

Act as a senior automation reviewer. Evaluate the workflow below and decide what the system should do, what the agent may recommend, and what the human must approve.

For each workflow step, produce:
- Step name.
- Current owner.
- Proposed automation level: observe, draft, recommend, execute with approval, execute automatically.
- Required evidence before execution.
- Rollback or correction path.
- Reason the boundary is appropriate.

Then summarize the safest minimum viable automation and the next two capability upgrades. Do not assume full autonomy is the goal.

Full prompt

Convert this workflow into an event-driven automation specification.

Include:
1. Event names and payload fields.
2. State transitions in plain language.
3. Idempotency keys and duplicate handling.
4. Retry policy and dead-letter conditions.
5. Human review states and notification rules.
6. Data retention, access, and audit notes.
7. A compact test plan that proves the workflow handles happy path, missing data, duplicate events, and partial failure.

Write for a product engineer and an operations lead who need to agree before implementation starts.

Full prompt

You are designing an evaluation battery for an AI agent.

Given the agent role, tool access, users, and operating constraints, create:
1. Ten representative tasks with expected outcomes.
2. Three adversarial or ambiguity-heavy tasks.
3. Three regression tasks that should never break after updates.
4. Required fixtures, mock data, and environmental assumptions.
5. A scoring rubric with pass, partial pass, and fail criteria.
6. The signals to capture during execution: tool calls, latency, citations, refusals, approvals, and error recovery.

Keep the evaluation practical enough to run before every release.

Full prompt

Review this failed agent run as a systems problem, not just a model problem.

Separate the failure into:
- User request ambiguity.
- Missing or conflicting instructions.
- Context retrieval gaps.
- Tool schema or permission issues.
- Interface feedback problems.
- Model reasoning or reliability issues.
- Missing evaluation coverage.

For each cause, give evidence from the transcript, the likely impact, and a concrete fix. End with the smallest regression test that would catch this class of failure next time.

Full prompt

Create a production readiness rubric for the agent described below.

The rubric must score:
1. Task completion and factual correctness.
2. Tool use discipline and permission handling.
3. Recovery from missing data, tool errors, or user correction.
4. Safety, privacy, and compliance behavior.
5. User experience: clarity, brevity, and appropriate confidence.
6. Observability: whether the run leaves enough trace to debug later.

Use a 0 to 3 scale for each dimension. Define what each score means, the evidence needed to assign it, and the minimum passing score for a launch-stage product.

Full prompt

Act as an operations automation lead. Review the weekly notes, tickets, emails, and calendar context below.

Return:
1. Recurring manual tasks that appeared more than once.
2. Handoffs that waited on one person or vendor.
3. Places where data was copied between systems.
4. Decisions that were made without a clear source of truth.
5. Low-risk automations we can ship this week.
6. Higher-risk automations that need policy, approval, or integration work.
7. A concise automation backlog with owner, expected impact, and next action.

Be concrete. Do not propose automation for work that is rare, unclear, or better handled by a conversation.

Full prompt

Create a vendor handoff brief for a German or DACH operating context.

Include:
- Objective and scope.
- Stakeholders and decision owners.
- Required systems, access, documents, and deadlines.
- Data protection or confidentiality notes to confirm before work begins.
- Open questions that should be resolved in writing.
- A short English summary and a short German-ready summary.
- A checklist for confirming receipt, ownership, and next milestone.

Keep the tone professional and direct. Do not invent legal advice or claim compliance has been reviewed.

Full prompt

Analyze this standard operating procedure and convert it into an automation backlog.

For each backlog item, include:
1. Current manual step.
2. Proposed automation or assistive feature.
3. Trigger and output.
4. Required integrations or data sources.
5. Risk level and reason.
6. Measurement: time saved, error reduction, visibility, or consistency.
7. The first test that proves the automation works.

Group the backlog into quick wins, needs integration, and needs policy review.

Full prompt

Build a category positioning brief for the product below.

Cover:
1. Primary audience and the expensive problem they recognize.
2. Category name and adjacent categories to avoid.
3. What the product replaces, augments, or makes unnecessary.
4. Proof points we can support today.
5. Claims we should avoid until we have evidence.
6. Search phrases and LLM classification phrases to earn.
7. A concise homepage description, product page description, and social bio.

Use credible language. Do not create customer claims, market leadership claims, or unsupported metrics.

Full prompt

Create a launch-ready SEO outline for an automation software product page.

Return:
- Search intent and target query cluster.
- Page title and meta description options.
- H1 and section headings.
- Questions the page should answer for human buyers and AI answer engines.
- Internal links to relevant product, prompt, blog, and contact pages.
- Structured-data recommendations.
- Claims that are safe, claims that need evidence, and claims to avoid.

The voice should be confident, specific, and grounded in what exists today.

Full prompt

Write launch announcement copy from the facts below.

Create:
1. A 500-word launch note.
2. A 120-word website announcement.
3. Three short social posts.
4. A founder email to early subscribers.
5. A list of claims removed because they were not supported.

Tone: calm, precise, product-led. Avoid fake urgency, fake customer proof, and words like "revolutionary" unless the facts justify them.

Full prompt

Convert these open questions into a research brief.

Include:
1. Decision the research must support.
2. Hypotheses and what would disprove each one.
3. Evidence we already have versus evidence still needed.
4. Source types to prioritize and source types to treat cautiously.
5. Interview or test questions if human feedback is needed.
6. A time-boxed research plan.
7. The decision threshold: what evidence is enough to act.

Separate facts, assumptions, and recommendations. Flag uncertainty plainly.

Full prompt

Map the competitive landscape for the product or workflow below.

Do not create a generic feature checklist. Compare alternatives by:
- Buyer job and urgency.
- Current workaround.
- Workflow fit.
- Integration and switching burden.
- Trust, privacy, and governance requirements.
- Where each alternative is strong.
- Where each alternative leaves room for a focused product.

End with a sober positioning recommendation and the evidence we still need before making stronger claims.

Full prompt

Review this webpage copy for AI answer-engine and search readiness.

Evaluate:
1. Entity clarity: who operates the product and where.
2. Category clarity: what the product is and is not.
3. Product relationships and internal links.
4. Proof quality and unsupported claims.
5. Schema or machine-readable signals that should be added.
6. Questions the page answers well.
7. Questions a crawler or evaluator would still have.

Return prioritized edits. Keep recommendations factual and avoid gaming language.

Full prompt

Act as a product designer reviewing a workflow before launch.

For the flow below, identify:
1. The user's goal and likely anxiety at each step.
2. Friction caused by unclear labels, missing state, or too many choices.
3. Places where automation should assist without taking control.
4. Required empty, loading, success, error, and recovery states.
5. Copy that should be shorter, clearer, or more specific.
6. Accessibility and keyboard considerations.
7. The smallest change that would make the flow feel more trustworthy.

Prioritize changes by user risk, implementation cost, and launch impact.

Full prompt

Review this interface as if it were an instrument for operating automation.

Assess:
- Immediacy: does the system answer quickly enough?
- Reversibility: can users safely undo or correct actions?
- Spatial memory: do users know where things live?
- Feedback: does motion, state, and copy explain what changed?
- Control: can users move from overview to detail without losing context?
- Trust: are automated actions visible, explainable, and interruptible?

Give concrete product changes. Avoid broad aesthetic advice unless it affects comprehension or control.

Full prompt

Turn the user story below into launch-ready product requirements.

Include:
1. User goal and business goal.
2. In-scope behavior and out-of-scope behavior.
3. Acceptance criteria.
4. Data, permissions, and integration assumptions.
5. Empty, loading, error, and success states.
6. Edge cases and abuse cases.
7. Analytics or operational signals to capture.
8. A short release checklist.

Keep the requirements testable. Flag any ambiguity that should be resolved before design or engineering starts.