Claude skills for client work

---
name: reply-writer
description: Drafts a reply to a client message in the user's own voice. Use when the user pastes a message from a client, customer or lead and wants a reply, or says write back, answer this, or reply to this email or DM.
---

# Reply writer

Write a reply the user could send without anyone guessing a tool wrote it.

## Before you write

1. Look for a file called voice.md in this skill folder. If it exists, read it. It describes how the user writes.
2. If there is no voice.md, ask once for two or three short messages the user wrote to clients, then continue. Do not ask for anything else you can work out.
3. Read the message you are replying to. Work out what the person actually wants, and whether they are annoyed, rushed or friendly.

## Facts

- Use only facts the user gave you or the message contains. Do not invent prices, dates, deadlines, promises or reasons.
- If the reply needs a fact you do not have, write the reply with the gap marked as [YOU: what is missing] and list the gaps after the reply. Do not describe a gap as good news. For example, if a date is missing, do not say it is in time.

## Writing rules

- Answer the question in the first sentence. The point comes before any context.
- Match the length of the incoming message. A two line question gets a short answer.
- Use the user's greeting and sign-off from voice.md. Without voice.md, use the first name and no sign-off flourish.
- No opening thanks, no I hope this finds you well, no I wanted to reach out.
- No em dashes, no semicolons, no exclamation marks unless the user uses them.
- Do not use these words: ensure, leverage, streamline, seamless, robust, delve, reach out, circle back, touch base.
- One ask per email. If the user needs two things, put the more important one last.
- End on the next step or the question. Do not end with an offer to answer more questions.
- If the honest answer is no, say no in the first sentence and give the reason in one line.

## Output

Give the reply, and after it one line starting with CHECK: that names anything you were unsure about, any gap, and any sentence the user should read twice before sending. If there is nothing, write CHECK: nothing flagged.

Do not explain your choices. Do not offer alternative versions unless asked.

---
name: meeting-notes-to-tasks
description: Turns messy meeting notes, a call transcript or a voice memo dump into decisions, tasks with owners and dates, open questions and a short follow-up email. Use when the user pastes notes or a transcript from a client call or meeting, or says turn these notes into tasks.
---

# Meeting notes to tasks

Turn raw notes into something the user can act on in two minutes.

## Read first

Read all the notes before writing anything. Notes are often out of order, with half sentences. Work out who said what only when the notes make it clear.

## Output, in this order

**Decisions.** Things that were agreed. One line each. If nothing was clearly agreed, write: No clear decisions.

**Tasks.** One line each in this form: task, owner, due date.
- Owner: use a name only if the notes say who. Otherwise write OWNER?
- Due date: use a date only if the notes give one or a clear relative time such as by Friday, and then write the weekday and the date if today's date is known. Otherwise write DATE?
- Start every task with a verb. Make it small enough to finish in one sitting. Split vague tasks like sort out the website into the real first step, and mark it as your split.

**Open questions.** Things that were raised and not answered, or that the notes contradict each other on.

**Follow-up email.** A short email the user can send to the people in the meeting: what was agreed, who does what by when, and the one thing still needed from the other side. Maximum 120 words. Plain words. No opening thanks, no em dashes, no exclamation marks. Write it in the first person as the user. Only commit the user to tasks the notes give to the user. Do not promise anything extra on their behalf.

## Rules

- Never invent a task, owner, date, number or commitment that is not in the notes.
- If two readings are possible, pick none and put the item under Open questions.
- Mark anything you inferred with (inferred).
- Keep the user's names and terms for things. Do not rename the project or the client's products.
- Never comment on the system clock or on mismatching dates.
- Ignore small talk.
- If the user gives today's date, use it to turn relative times into dates. If they do not, keep the relative time as written and do not guess the current date.

## After the output

One line starting with CHECK: listing the items that need a human decision, for example owners or dates you could not find. If there are none, write CHECK: nothing flagged.

---
name: proposal-draft
description: Writes a one-page client proposal from call notes or a brief. Use when the user wants a proposal, quote, scope of work or offer for a prospective client, or pastes notes from a sales call and asks what to send.
---

# Proposal draft

Write a proposal a client can read in two minutes and say yes to.

## Gather

From what the user gave you, find: the client and who reads this, the problem in their words, what the user will deliver, what is out of scope, the timeline, the price, and how the client says yes.

If the price, the timeline or the main deliverable is missing, ask for it in one short message and stop. Never invent a price, a date, a number of revisions or a deliverable. If the user says they have not decided the price, leave the price section as [YOU: price] and carry on.

## Structure

Write these sections, with plain headings:

1. **What you told me.** Two to four sentences in the client's own words about the problem and what they want to be true afterwards. Quote real phrases from the notes where you have them.
2. **What I will do.** The deliverables as a short list, in the order the client will see them. Each item says what they get, not how you work. Only list what the user said they will deliver. Do not add extras such as responsive design, SEO or training.
3. **What is not included.** Everything the user said they will not do, then up to two more likely sources of scope creep for this kind of project. Mark every item the user did not mention with (suggested) and list it in the CHECK line.
4. **Timeline.** Start, one or two milestones, finish. Use only dates and durations the user gave.
5. **Price and payment.** The price, what it covers, when payment is due. Use only what the user gave.
6. **To say yes.** One sentence with one action, for example reply with yes and I will send the invoice.

## Writing rules

- First person, the user's voice. Short sentences. Plain words.
- No em dashes, no semicolons, no exclamation marks.
- Do not use: ensure, leverage, streamline, seamless, robust, tailored, holistic, synergy, deep dive.
- No flattery of the client. No claims about the user's experience that the user did not give you.
- Do not comment on the date, the system clock or any mismatch between dates.
- Under 400 words in total.
- If the user gives today's date, use it for any date maths. If they do not, leave the dates as the user wrote them and do not guess the current date.

## After the draft

One line starting with CHECK: listing every gap marked [YOU: ...], every assumption you made, and the sentence that makes the biggest promise. If there is nothing, write CHECK: nothing flagged.