Boris-Style Prompt Writer
Write high-quality prompts for any LLM or AI assistant, using the methodology Boris (Anthropic, the creator of Claude Code) shared in his "Pro Tips & Tricks" talk.
The skill exists because most users write prompts that are too long, too prescriptive, and missing the things that actually matter — a feedback loop, a planning step, the right anchor. Boris's approach inverts this: keep the prompt short, let the model explore, give it a way to check its own work, and sink reusable context into files rather than re-pasting it. The principles were developed for Claude Code, but they generalize to any modern LLM (ChatGPT, Gemini, Cursor, etc.).
When to use
Trigger this skill when any of the following is true:
- The user explicitly asks to write or improve a prompt for any LLM or AI assistant.
- The user describes a task in natural language and the next reasonable step is to phrase it as a prompt.
- The user pastes a long prompt and asks why it isn't working, or asks to shorten or refine it.
- The user asks "how should I phrase this" or "what's a good way to ask [model] to...".
Do not trigger for: writing marketing copy, writing user-facing UI text, or writing prompts for image-generation models. This skill is specifically for instruction prompts addressed to an LLM or AI agent.
Target model — universal vs. Claude-Code-specific advice
Before writing, identify what the user is prompting:
- Claude Code: full toolkit applies — , references, slash commands, the shorthand, plan mode by natural language.
- Claude (claude.ai, API): most principles apply, but no or . Use system prompts / Projects for persistent context.
- ChatGPT / Gemini / other chat LLMs: the universal principles apply (short, plan-first, feedback-loop, no padding). Replace with the model's equivalent (Custom Instructions, system prompt, Projects, Gems, etc.). The "explore the codebase" pattern only works if the model has tools to do so.
- Cursor / Windsurf / Copilot Chat: editor-integrated; works (different syntax), per-project rules files work, plan-first works.
- Agent frameworks (autonomous tools): emphasize the feedback loop heavily — these run without supervision.
If the target isn't obvious from context and it materially changes the prompt, ask.
Core principles (in priority order)
These come straight from Boris's talk. Apply them in this order when writing or evaluating a prompt.
1. Short beats long
A prompt that fits in two sentences usually works better than one that fills the screen. The reason isn't aesthetic — it's that a long prompt eats the context window, repeats things Claude already knows, and over-constrains the solution space. If you find yourself writing more than ~5 lines, ask whether half of it belongs in
instead.
2. "Make a plan first" is the single highest-ROI addition
The most reliable upgrade you can make to almost any non-trivial prompt is appending some form of:
"Before you write code, make a plan and run it by me for approval."
This works because the model is genuinely good at planning when asked to, and most bad results come from skipping the planning step. You do not need plan mode, a special flag, or a system prompt — the plain-English instruction is enough.
3. Don't spec every detail — let Claude explore
If the task involves an existing codebase, the prompt should usually point Claude at the right starting place ("look at how
is implemented", "check git history for why this function has 15 args") rather than describing the full solution. Claude is good at finding patterns and similar code; it's wasteful to re-describe what the codebase already contains.
4. A feedback loop beats detailed instructions
When the deliverable is verifiable (UI matches a mock, tests pass, lint passes, screenshot is similar), the prompt should give Claude a way to verify rather than telling it how to do every step. The pattern:
"Do X. Then run [tests / take a screenshot / lint]. Iterate until [success criterion]."
This typically beats a multi-paragraph spec because the model can self-correct using ground truth.
5. Persistent context goes in files / settings, not prompts
If you find yourself pasting the same architecture notes, style rules, or common commands into every prompt, that's a signal — those belong in the target's persistent-context mechanism:
- Claude Code: (project), (personal), (global), nested (subdirectory).
- Claude.ai: Projects, system prompts.
- ChatGPT: Custom Instructions, Projects, system prompts.
- Gemini: Gems, system instructions.
- Cursor / Windsurf: / , per-project rules.
- API usage: system prompt, fixed context block.
The prompt should be about this specific task, not background.
Workflow
Step 1 — Decide if you have enough information
Before writing the prompt, you need to be able to answer these four questions. If any is unclear, stop and ask the user.
| Question | Why it matters | What it changes |
|---|
| Which model / assistant is this prompt for? (Claude Code, Claude.ai, ChatGPT, Cursor, Gemini, etc.) | Determines which model-specific features (@file, CLAUDE.md, Projects, etc.) are available | Vocabulary and anchors |
| What is the deliverable? (Q&A / small edit / new feature / bug fix / refactor / debug / non-code task) | Determines which template to use | Template choice |
| Can the assistant verify its own output? (tests, screenshots, lint, build, manual check by user) | Determines whether to add an iteration loop | The "run X and iterate" line |
| Is this one-shot, or should the assistant plan first? | Most non-trivial tasks benefit from a plan; pure Q&A does not | The "make a plan first" line |
| Are there existing files, patterns, or persistent-context files (, , etc.) the assistant should anchor on? | Determines whether to add file references or "look at how X works" | Context anchors |
Step 2 — If anything is unclear, ask 1–3 clarifying questions
Use the
tool.
Cap at 3 questions. Beyond that the user feels interrogated and the skill's benefit (saving them time) disappears.
Choose questions from this menu based on what's actually unclear — don't ask things you already know from context.
If target model / assistant is unclear and would change the answer:
- Question: "Which assistant is this prompt for?"
- Options: Claude Code (CLI) / Claude.ai (web/desktop) / ChatGPT / Cursor or Windsurf / Other (say which)
If deliverable is unclear:
- Question: "What do you want Claude to do?"
- Options: Answer a question about the code / Make a small edit / Build a new feature / Fix a bug / Refactor existing code
If verification is unclear:
- Question: "Can Claude check its own work after each attempt?"
- Options: Yes — there are tests / Yes — visual (I'll diff screenshots) / Yes — a CLI / build / lint will tell us / No — I'll review manually
If scope is unclear:
- Question: "Roughly how big is this task?"
- Options: A single line or two / A few files / A whole module or feature / I don't know — that's what I want Claude to figure out
If planning preference is unclear (only ask if deliverable is small edit or larger):
- Question: "Want Claude to propose a plan first, or just try it?"
- Options: Plan first, then approve / Just try it, I'll course-correct / Plan only — no code yet
If codebase anchors are unclear:
- Question: "Are there existing files or patterns Claude should look at first?"
- Options: Yes — I'll @-mention them / Look at git history / Look at similar features — Claude can find them / No, this is greenfield
Step 3 — Pick a template and fill it in
Use the closest matching template from this set. These mirror the patterns Boris uses in his own daily work.
Template A — Codebase Q&A
[Question]. Look through git history if it helps.
Examples:
Why does parseConfig take 12 arguments? Look through git history.
How is the RateLimiter class actually used? Show me real call sites, not just text matches.
What did I ship this week? Use my git username from the log.
Template B — Small edit (1 file, clear change)
[Task]. Make the change, then [verify].
Examples:
Rename the env var DB_URL to DATABASE_URL everywhere it's used. After changing files, run the test suite.
Add a "Cancel" button next to "Save" in @components/UserForm.tsx. Match the existing button styles.
Template C — Medium edit, plan-first
[Task]. Make a plan and run it by me before writing code.
Examples:
Replace the in-memory rate limiter with Redis. Plan first, then ask before changing files.
The auth middleware is leaking session tokens in logs — fix it. Make a plan first.
Template D — Build / UI work with feedback loop
[Task]. Use [feedback tool] to check after each change. Iterate until [success criterion].
Examples:
Implement the dark theme to match @design/dark-mock.png. Use puppeteer to screenshot the page, diff against the mock, iterate until visually close.
Build the /pricing page from @design/pricing.fig export. Screenshot at desktop + mobile widths after each change. Iterate until both match.
Make the failing tests in @tests/checkout.test.ts pass. Run the test suite after each change.
Template E — Bigger feature, explore + plan
[Feature]. First explore the codebase to find similar patterns. Then make a plan and ask for approval. After implementing, run [verification].
Example:
Add an audit log for all admin actions. First look at how existing logging works in the codebase, then propose a plan, ask before writing code. Once implemented, run the test suite.
Template F — Git / GitHub operation
Literally those words. Claude reads
to match the project's commit format, creates a branch if needed, pushes, and opens a PR. Don't over-specify.
Template G — Bug fix (root cause, not symptom)
[Bug description, including how to reproduce]. Find the root cause, don't just patch the symptom. Make a plan first.
Step 4 — Add the optional power-ups (when applicable)
These small additions punch above their weight:
| Add this | When |
|---|
| Whenever a specific file is the anchor for the task. |
| When the "why" of existing code matters. |
| When you want to mark a clear no-go zone (more effective than positively specifying what to change). |
Step 5 — Output
Return two things to the user:
- The final prompt, in a fenced code block so it's copy-pasteable.
- A one-line note explaining why the prompt is structured this way (which 1–2 principles you applied).
If applicable, add a brief tip:
- If the prompt references the same architecture / style facts twice or more, suggest moving them to .
- If the user is about to do many similar prompts, suggest writing a instead.
Output examples
These show what the skill produces. Notice the prompts are short and the explanation is one sentence.
Example 1 — User input was complete
User: "I want Claude Code to add JWT auth to my Express app. There are tests."
Skill output:
Add JWT auth to the Express app. Look at how existing middleware is structured first, then make a plan and run it by me. After implementing, run the test suite and iterate until it passes.
Uses Template E (medium-size feature, explore + plan + feedback loop) because there's a test suite to verify against.
Example 2 — User input was vague, skill asked
User: "help me prompt Claude to fix my CSS"
Skill asks:
- "What's broken in the CSS?" — options: Layout is off / Colors wrong / Responsive issues / I don't know — Claude should figure it out
- "Can Claude check the result visually?" — options: Yes, screenshot it / Yes, I'll eyeball it / I have visual regression tests
After user answers (e.g., "layout is off on mobile" + "yes screenshot it"):
The mobile layout on @pages/Home.tsx is broken. Screenshot it at 375px wide using puppeteer, find what's off, fix it, and re-screenshot. Iterate until the layout looks right.
Uses Template D (feedback loop) because puppeteer gives Claude a way to self-verify.
Example 3 — Existing prompt, asked to improve
User: pastes a 30-line prompt full of architecture details and style rules
Skill response: identify the parts that are reusable context (architecture, style, common commands) and suggest moving them to
, leaving the prompt itself focused on the task.
Implement the payment retry logic described in @docs/retry-spec.md. Plan first, ask before writing code, then run the test suite.
Original prompt was 30 lines; 25 of them were repeated architecture / style context that should live in
. Kept only the task-specific part.
Anti-patterns (don't do these)
- Polite filler ("Please could you help me with..."). It wastes context and the model doesn't care. Use a direct verb.
- Pasting the same architecture / style notes into every prompt. Put them in once.
- Long lists of step-by-step instructions for tasks that have a verification signal. Give it the verification signal instead and let it iterate.
- Asking for a 3000-line feature in one shot. Ask for a plan, review, then implement in stages.
- Generating a 200-line "perfect prompt" to save the user time. The whole point of the skill is shorter prompts. If your output is longer than the user's question, you're doing it wrong.
When this skill should hand off
This skill writes the prompt — it doesn't run it. After producing the prompt:
- The user usually copies it into Claude Code themselves.
- If they ask "now run it", that becomes a separate task and this skill is done.