12 Claude Skills for Proposals a Client Can Decide From

What these skills are

A deck built from a brief, argued in its titles, read back before it goes. The week a request lands looks the same in most firms. An RFP, an email, or a founder's notes after a call arrive on Monday, the deck is due Friday, and someone starts writing slides from the document plus memory plus hope. The gaps get filled with confident sentences nobody can trace, and the client finds the weakest one on page two.

One line holds the whole pack together: Claude writes the slides, people own the facts.

So the pack starts before the slides. proposal-brief-builder turns whatever arrived into one file that keeps three things apart: what the client actually asked for, what you know and where you know it from, and what you are assuming. If there is an RFP it is read the way an evaluator reads it, requirement by requirement. If a fact is not in the brief, it does not go on a slide.

Then storyline-designer writes the ghost deck — an action title for every slide and the evidence each title needs — before any content exists, while the argument is still cheap to change. Seven section writers fill it in the client's own language, each one refusing the shortcut its section invites: market context from general knowledge, a hypothesis stated as a root cause, a service list passed off as a vision, a price nobody can defend.

Mechanically, each skill is one folder with a SKILL.md file. One writes your firm down once, two frame the opportunity, seven write the sections, and two build the .pptx and read it back from the client's chair. They run from one Claude Project with a pinned chat per opportunity, and each reads what the ones before it wrote, by file name — so the credentials library, the numbers and the conventions the firm proposes from get better with every opportunity instead of being reinvented each Friday.

Download all 12 skills. One zip: ready-to-install skill zips, readable SKILL.md files, and the two templates the pack runs on — the firm context and the blank proposal brief. Free, no signup. The same 12 skills are open on GitHub: polar-bear-org/claude-skills.

The 12 skills you get

One writes your firm down once, two frame the opportunity, seven write the sections, and two build the deck and read it back.

1 · Write the firm down, once

1. Firm Context Writer

Use when: You are installing the pack, or your positioning, rates, team or deck template changed

Output: firm-context.md, the file every other skill reads: your services and refusals, the ideal client, the credentials library with real outcomes only, the team roster, the cost basis behind your prices, who approves what, and your deck conventions

2 · Frame the opportunity

2. Proposal Brief Builder

Use when: An RFP landed, or someone said "we need a proposal for X by Friday" and all you have is an email and a call

Output: The brief every section reads: the ask in one sentence, who decides and how, the requirements matrix if there is an RFP, known facts with their sources, the assumptions register, and your angle — plus the questions that would fill a thin brief

3. Storyline Designer

Use when: The brief exists and someone is about to open PowerPoint

Output: The ghost deck before any content: the executive summary, the sections this client needs, an action title for every slide, the evidence each title needs, and the slide budget

3 · Write the sections

4. Context & Objectives Writer

Use when: The storyline is set and you start writing, always with this section first

Output: The "your situation and objectives" section in the client's own words, every fact sourced to the brief and every inference marked as an assumption

5. Market Section Writer

Use when: The storyline calls for a market section and you have sources, or need to know which ones to find

Output: The market section written only from named sources you supply or approve: the few facts that change the answer, with a source line on every slide — and a refusal to write it from general knowledge

6. Problem Section Writer

Use when: The context section is done and the RFP's own problem statement is not enough

Output: The problem as a diagnosis: symptoms, hypotheses about causes labeled tested or untested, what it costs the client in the client's own numbers, and what the proposal will and will not solve

7. Vision Section Writer

Use when: The problem is framed and you need the page that makes the client lean in

Output: The answer as a position rather than a service list: what will be different, the principles you will hold, the two or three big moves, and why this one fits this client

8. Approach Section Writer

Use when: The vision is set and the client will ask "so what actually happens"

Output: Phases and what the client sees in each, deliverables, timeline, governance, the client's role and the risks — with every date and name held as a draft until the person who owns the promise approves it

9. Team Section Writer

Use when: The approach is done and you know who will staff it

Output: The team and credentials section: who is on this and why each one fits, and two or three cases from your library that mirror the client's situation — short, and placed after the work

10. Investment Section Writer

Use when: The approach is approved and a number is due

Output: One to three honest options that differ in scope, each priced from your own approved numbers, the assumptions the price rests on, the terms, and the next steps with dates — no decoys, no invented figures

4 · Build it, and read it back

11. Deck Builder

Use when: All the sections this proposal needs are written and reviewed once

Output: proposal-[client].pptx on your own template: one slide per action title, dividers and the executive summary, a source line on every data slide, assumptions left visible, speaker notes, and the requirements cross-reference for RFPs

12. Deck Reviewer

Use when: The deck is built and someone is about to send it

Output: The read from the client's chair and against the brief — the storyline from the titles alone, unsourced claims, unanswered requirements, the firm talking about itself too early, numbers that do not add up — returned as an edit list, not a rewrite

How a proposal runs through the pack

One Proposal Studio project holds the firm. The filled firm-context.md sits in its files — what you do and what you refuse, the credentials library with real outcomes only, the team roster, the cost basis behind your prices, who approves a promise and who approves a price, and your deck conventions — and every skill reads it before writing. Then one pinned chat per opportunity, named "[Client] proposal".

The chat opens with proposal-brief-builder, which writes proposal-brief-[client].md and says at the top if nobody has spoken to the client yet, because every section downstream will then carry more assumptions than facts. storyline-designer reads the brief and writes the titles; a title the brief cannot support carries its "needs evidence" marker until a source exists, and a section the brief cannot earn — a market chapter with no sources — is dropped rather than filled.

The sections are written in order, context first, because playing the client's own situation back sets the language the rest of the deck borrows. problem-section-writer diagnoses instead of restating the RFP, vision-section-writer takes a position instead of listing services, approach-section-writer phases the work with every date and name left as a draft, team-section-writer stays short and comes after the work, and investment-section-writer prices real options from your own numbers. deck-builder then assembles the section files into proposal-[client].pptx on your template without rewriting a word, and deck-reviewer reads the result from the client's chair and hands back an edit list.

It stops where your judgement starts. The pack does not decide whether to respond, run the discovery call, or chase the client after sending. It does not design your brand or your slide template; it fills the one you have. And it does not write contracts beyond the plain commercial terms on the investment slides, fill public-sector bid portals, or run the project after signature.

Setup guide

1. Download the pack. One zip: an install folder with 12 ready-to-upload skill zips, a skills folder with the same skills as readable files, and the two templates the pack runs on — firm-context.md and proposal-brief.md.
2. Install your skills. In Claude Code, add the marketplace and install proposals-pack, and all 12 load at once. In Claude, turn on code execution in Settings, Capabilities — without it deck-builder cannot produce the .pptx — then go to Customize, Skills and upload one zip per skill from the install folder. Prefer working from files? Add the SKILL.md files to your Project knowledge instead; it works, just less cleanly.
3. Create your Proposal Studio. Make one Project per firm and call it Proposal Studio. Run firm-context-writer once — what you do and what you refuse, the credentials library with real outcomes only, the team roster, the cost basis behind your prices, who approves a promise and who approves a price, your deck conventions — then put firm-context.md in the project knowledge with your .pptx template beside it. Every skill reads it before writing a slide.
4. Open one chat per opportunity, and build the brief. The next time a request lands, pin a chat named "[Client] proposal", paste everything you have — the RFP, the thread, the call notes, the paragraph the founder wrote at midnight — and write "run proposal-brief-builder". Each skill saves its output as [artifact]-[client].md (proposal-brief-acme.md, storyline-acme.md, section-problem-acme.md), and the later skills read the earlier files by those names, which is what lets deck-builder assemble the deck without rework.

Where to start

The quality bar

Every skill in the pack holds the same standard, the one we hold when we write our own proposals:

• Claude writes the slides, people own the facts: every claim comes from the brief, or from a named source, or it carries its assumption marker onto the slide
• The brief keeps apart the three things that always get mixed — what the client actually asked for, what you know and where you know it from, and what you are assuming
• A thin brief is said out loud at the top, with the questions that would fill it, rather than patched with confident sentences nobody can trace
• Market slides come only from named sources you supply or approve, with the source's own year and definition: no rounding, no extrapolating, no combining two sources into a new claim
• A cause is labeled tested or untested, never presented as a finding, and the cost of the problem is the client's own number or the slide does not exist
• Dates, named people, deliverable counts and prices stay drafts until the person named in firm-context.md approves them — no skill takes the marker off by itself
• No decoy options: an option you would not want to deliver is not built, and a lower number comes from removing scope, never from discounting the same work
• Case outcomes are used exactly as the credentials library records them, and a case with no measured result says so on the slide
• Every section writes about the client's business, never about the client's people, their team, or their previous partner
• The built deck is a draft until a person has read every slide: the reviewer returns an edit list rather than a rewrite, and nothing is ever sent for you

Who made this

Polar Bear is a people ops consultancy for human-size teams (20 to 200 people). Built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. This pack is the free, self-serve version of how we work.

The pack turns the week a request lands into a deck a client can decide from. When you want your whole team working this way, AI carrying the overhead so people do the thinking, across business development, delivery, and everyday work, that's what we build with clients.

Meet Pauline. An RFP on the desk and the deck due Friday? Bring what you have — the notes, the call, the half-written storyline — and we'll shape it together. Book a 30-minute call · Pauline on LinkedIn