# Una Labs Prompt Pack #1

Four small prompt patterns for content, research, coding and business work. Replace the bracketed context before you run them. Keep private credentials, personal data and confidential client information out of prompts unless the tool is approved for that data.

## Content

### 1. Turn a rough idea into a useful Reel

```text
You are my short-form content editor. Turn this rough idea into a 30–45 second Reel:

Idea: [paste idea]
Audience: [who should care]
Proof I can show on screen: [demo, screenshot, result]
CTA: [one action]

Return:
1. Three hook options in my natural voice.
2. One spoken script under 110 words.
3. A five-shot B-roll list.
4. One caption and one pinned-comment prompt.

Keep it specific. Do not invent results, clients or features.
```
### 2. Keep the voice human

```text
Rewrite the draft below in a warm, direct first-person voice. Keep the meaning and any factual limits. Remove generic AI phrasing, inflated claims, repeated setup and corporate filler. Keep sentences easy to say aloud.

Draft:
[paste draft]

Return the rewrite only, followed by a one-line note naming any claim that still needs proof.
```

### 3. Build a content series from one proof point

```text
Using only this verified proof point, create five related content angles:

Proof point: [what I actually tested or built]
Audience: [audience]
Channel: [Instagram, LinkedIn, YouTube, Discord]

For each angle give: hook, what to show, one useful takeaway and a low-pressure CTA. Do not turn one proof point into five different claims.
```

## Research

### 4. Compare tools without hype

```text
Compare these two tools for this job: [job]

Tool A: [name and official URL]
Tool B: [name and official URL]

Use current official documentation where possible. Return a compact table with: best use, setup effort, free-tier limits, privacy considerations, export or lock-in risk, and who should choose each. Mark anything you cannot verify.
```

### 5. Find the decision inside a pile of links

```text
I have these links and notes:
[paste links and notes]

Group them by actual use case, remove duplicates, flag stale or unsupported claims, and recommend the smallest useful shortlist for [audience]. Keep official links beside each recommendation. Do not treat popularity as proof of fit.
```

### 6. Turn research into a test plan

```text
Create a one-hour test plan for [tool or workflow]. I need to know whether it can handle [specific job].

Return: prerequisites, a smallest realistic sample input, step-by-step test, evidence to capture, pass conditions, failure conditions and a final recommendation format. Separate what is observed from what is inferred.
```

### 7. Check a recommendation before publishing

```text
Audit this recommendation for a public resource list:

Recommendation: [title, description and URL]
Audience: [audience]

Check whether the URL is canonical, the cost label is honest, the description overclaims anything, the tool is safe to recommend for the stated audience, and the last-verified date is defensible. Return: keep, revise or remove, with exact edits.
```

## Coding

### 8. Make a change plan before touching code

```text
You are reviewing a change request for this repository: [repo and path].

Request: [request]
Constraints: [constraints]

Before writing code, return: affected files, current behavior, smallest safe change, tests to run, and one likely regression. Do not propose a broad refactor unless the request cannot be completed safely without it.
```

### 9. Debug from evidence

```text
Diagnose this failure without guessing:

Expected behavior: [expected]
Observed behavior: [observed]
Error output: [exact error]
Recent change: [change]
Environment: [OS, runtime, versions]

Return the top three hypotheses ranked by evidence, the smallest check for each, and the fix only after identifying the strongest hypothesis. Keep unrelated warnings separate.
```

### 10. Write a release gate

```text
For this feature, define an evidence-backed release gate:

Feature: [feature]
User-facing URL or entry point: [URL]
Runtime: [runtime]

Return checks for build, lint or type validation, the main user flow, mobile behavior, external links, analytics events and production evidence. For each check specify the pass condition and the artifact or observation that proves it.
```

### 11. Review a diff like a maintainer

```text
Review this diff for correctness and scope:
[paste diff]

Report only actionable findings. Check behavior changes, security or privacy issues, broken contracts, missing tests, accidental unrelated files and whether the docs match the implementation. Rank findings by severity and include file and line references when available.
```

### 12. Explain a technical choice plainly

```text
Explain this engineering decision to a smart non-specialist:

Decision: [decision]
Options considered: [options]
Evidence: [evidence]
Constraint: [constraint]

Use one short paragraph, then a compact trade-off table. Do not hide uncertainty or claim a provider, build or deployment is successful without direct evidence.
```

## Business

### 13. Turn a service idea into a one-page brief

```text
Turn this idea into a one-page build brief:

Idea: [idea]
User: [specific user]
Pain: [problem]
Desired outcome: [outcome]
Constraints: [time, budget, platform]

Return: problem statement, non-goals, user flow, acceptance criteria, risks, launch proof and the smallest version worth shipping.
```

### 14. Make an offer easier to understand

```text
Rewrite this offer for a busy potential customer:

Offer: [offer]
Who it is for: [audience]
Proof available: [proof]
Price or next step: [price or CTA]

Return a clear headline, three benefit bullets grounded in the proof, what is included, what is not included and one honest CTA. Avoid urgency tricks and guaranteed outcomes.
```

### 15. Find the next best experiment

```text
I have these possible experiments:
[list]

Goal: [goal]
Available time: [time]
Current evidence: [evidence]

Rank the experiments by learning value per unit of effort. For the top choice give a hypothesis, smallest test, success signal, failure signal and what decision each result would support.
```

### 16. Write a useful handoff

```text
Write a handoff for someone taking over this project:

Project: [project]
Current state: [state]
What is proven: [proof]
What is not proven: [gaps]
Known risks: [risks]
Next action: [next action]

Use direct language. Separate completed work, open blockers, follow-up improvements and links to the evidence.
```