Prompt Crafter Skill

---
name: prompt-crafter
description: >-
  Turns a rough goal plus raw, unstructured thoughts into one clear, effective, ready-to-use prompt before diving into the actual work. Use this whenever the user opens with something like "I'm trying to get you to help me with X, I'm not sure how to phrase this, can you help me craft an effective prompt" followed by a stream-of-consciousness brain dump — or more generally whenever the user hands over messy notes, half-formed ideas, or a pile of context about something they want to do and asks for help turning it into a clear ask. Trigger this even without the words "prompt" or "craft" — phrases like "help me figure out how to ask for this," "I don't know how to phrase this," "here's my brain dump," or a wall of raw thinking followed by "can you make sense of this" are enough. Don't trigger on requests that are already clear and actionable as-is — this skill is for the fuzzy-goal-plus-raw-thoughts pattern specifically, not a general clarifying-questions tool.
---

# Prompt Crafter

## What this does

The user gives you two things:

1. **A stated goal** — often phrased as "I'm trying to get you to help me with X, not sure how to phrase this."
2. **Raw thoughts** — an unstructured brain dump about what they want, why, and everything adjacent to it.

Your job is to turn those two things into a single, well-built prompt the user can actually use — either right now in this session, or saved and pasted into a fresh one later. You are not summarizing their thoughts back to them. You are translating a fuzzy intention into a request that would reliably produce the outcome they're actually describing.

## Why this matters

People usually already know what they want — it's sitting there in the raw thoughts — but it's in associative, non-linear form: a bit of context here, a constraint buried in the middle, a preference stated as an aside. An AI (or a person) handed those raw thoughts directly will often latch onto the wrong part, miss an implicit constraint, or produce something technically responsive but not what was actually wanted. The value of this skill is doing the compression work: finding the real goal, the constraints that matter, and the shape of success, then writing that up as a prompt that front-loads all of it.

## Process

### 1. Read for the real ask

Go through the raw thoughts and pull out:

- **The core goal** — what does "done" actually look like? Often the stated goal ("help me build X") is narrower or broader than what the raw thoughts describe — trust the raw thoughts over the one-line framing when they conflict.
- **Context that shapes the approach** — who the user is, what they already have in place, what they've already tried or seen others do.
- **Constraints and preferences, including implicit ones** — a throwaway line like "it needs to be from best practices" is a real constraint; "I want it to be interactive, building as I go" is a real format preference. Don't let these get lost in the noise.
- **What's explicitly not wanted**, if anything is ruled out.
- **Scope tension** — sometimes the raw thoughts describe a sprawling vision ("everything's connected to everything, I want it all in one place") while the stated goal is narrow ("help me fix this one thing"), or vice versa. Notice this rather than silently picking one — it's usually worth naming back to the user.

### 2. Spot the gaps that actually matter

Not every ambiguity is worth a question. Ask only about things that would change what the crafted prompt says. Good candidates:

- **Scope**: is this one bounded deliverable, or an open-ended system that will keep growing?
- **Starting point**: from scratch, or is there existing material, tools, or a partial setup already in place?
- **Definition of success**: how will the user know the result actually worked, beyond "it exists"?
- **Working style**: do they want to build it together step by step, or receive something closer to a finished result?

If the raw thoughts already answer something, don't ask about it — that's a waste of the user's time and a sign you didn't read closely enough.

### 3. Ask before finalizing, not after

If real gaps remain, ask now — a small, focused set of questions (rarely more than 2-3), before writing the final prompt. Use `ask_user_input_v0` when available so the user can tap instead of type; otherwise ask inline. Resist the urge to interrogate — the raw thoughts have usually already answered most of what you'd otherwise ask.

### 4. Craft the prompt

Write one prompt the user could hand to a fresh session and get a genuinely good result from. A good prompt here:

- States the goal specifically in the first sentence or two — not "help me improve our onboarding docs" but what a good result actually means for this person.
- Includes the context the raw thoughts revealed, so nothing has to be guessed or re-explained.
- Makes constraints and preferences explicit — especially the implicit ones you pulled out in step 1.
- Says what "done" looks like, or what output/format is expected.
- Explicitly states the working style if it matters (e.g. "walk me through this interactively, building a working version as we go, rather than handing me a finished plan").
- Stays tight. This is a prompt, not a brief — cut anything not pulling its own weight. Long doesn't mean thorough.

Present the finished prompt in a clearly separated block so it's easy to copy elsewhere, with a one-line note on what it's optimized for.

### 5. Confirm before running it

After showing the prompt, ask whether the user wants to proceed with it right now in this session. Don't start executing on the underlying request until they say yes — they may want to save it, tweak it, or hand it to a different session or tool entirely. If they say yes, treat the crafted prompt as their actual request and get started.

## Example

**User opens with:**

> The prompt: I'm trying to get you to help me redo the onboarding docs for my team. Not sure how to phrase this. Raw thoughts: new people keep asking the same five questions in chat, we technically have a wiki but nobody reads it and half of it is out of date. I don't want to write a 40-page handbook nobody opens. Should probably cover how we actually work together too, not just which tools to log into — that's the part new people struggle with most. Want to build it with you piece by piece so it doesn't become another dead doc.

**Pulled from the raw thoughts:**

- Core goal: onboarding material that actually gets used and cuts down repeat questions — usability over completeness.
- Context: an existing wiki, partly outdated; new hires currently default to asking in chat.
- Constraints: explicitly not a long handbook. Must cover working norms, not only tooling.
- Working style: build it together in pieces, not receive a finished draft.
- Scope tension worth naming: "how we actually work together" is a much fuzzier, larger surface than the tooling list — worth sequencing (the concrete repeat questions first, culture layer second) rather than tackling both at once.

**Gaps worth asking about** (via `ask_user_input_v0`): whether to salvage the existing wiki or start clean, team size and how often new people join, and whether the output should be one short doc or a small set of focused pages.

**Crafted prompt (after answers), shown to the user for confirmation:**

> Help me rebuild my team's onboarding material so new hires stop asking the same questions in chat. We have an existing wiki that's partly outdated — [salvage it / start fresh]. Start with the concrete repeat questions as the first layer, then extend into how we actually work together (norms, expectations, who to ask for what), since that's where new people struggle most. Keep it short and scannable — a [single doc / small set of focused pages], explicitly not a long handbook. Build it with me section by section, asking what I want in each one rather than handing me a finished draft, so I end up with something real and current by the end. Optimize for something people actually open in week one, not something comprehensive that goes stale.

## A note on tone

The crafted prompt should sound like the user, not like a corporate brief — pull phrasing and priorities from their actual words where it fits, rather than genericizing everything into formal language.