Building a Proposal Generation Skill for Your Sales Team (Claude + PandaDoc)

Pure Proposals August 3, 2026

Key Takeaways

A Claude proposal generation skill is a saved, structured instruction set that turns a chat model into a repeatable proposal drafter, not a one-off prompt.
The skills that work best are boring, specific, and refuse to guess. They enforce templates, ground pricing in a source of truth, and flag missing data instead of inventing it.
The five parts of a working skill: role, data source precedence, workflow, guardrails, and output contract.
Without a proper skill, teams get invented pricing, hallucinated case studies, tone drift, and the wrong client names in the header.
Skill design is a governance job, not a prompt engineering job. Sales enablement owns it, revops keeps it grounded, and it gets versioned like any other sales asset.
In the AI proposal builds we deliver, the skill file is the single largest determinant of whether reps actually adopt the tool.

What Is a Claude Proposal Generation Skill?

A Claude proposal generation skill is a saved, reusable instruction pattern that tells Claude how to draft a proposal for your specific business, using your data, in your voice. It has defined inputs, explicit guardrails, and a fixed output format. Think of it as a written policy for the model, not a clever prompt.

In practice, a skill sits somewhere between “a system prompt” and “a lightweight standard operating procedure.” When a rep asks for a proposal, Claude does not start from scratch. It loads the skill, follows its instructions, uses the tools the skill points to, and returns output in the shape the skill demands.

The reason skills matter is repeatability. Any competent prompt engineer can coax a great proposal out of Claude once. A skill is what makes the twenty-third proposal, drafted by a new sales rep on a Friday afternoon, come out just as good as the first one written by the founder on a caffeine high.

Why Do Ad-Hoc Prompts Fail at Proposal Generation?

Ad-hoc prompts fail because they leave every decision to the model in the moment. The rep improvises the ask, Claude improvises the structure, and pricing gets invented from context clues. On any given day the output might be excellent. Across a hundred proposals, the variance is what kills the workflow.

The failure modes are predictable and expensive:

Invented pricing. The rep pastes some deal notes. Claude sees “45 seats” and “enterprise” and infers a price that sounds reasonable. It is not the price on your catalog. It might be twenty percent lower. The proposal ships. The rep does not catch it because Claude sounded confident.

Wrong client names. The rep is working two deals in the same thread. Claude picks the wrong company name for the header. Nobody notices until the buyer opens the PDF.

Hallucinated case studies. The proposal cites a case study client who is not a real customer, or a metric that never appeared in the actual case study. This one is dangerous because the reader may believe it and reference it back to your team.

Tone drift. One rep writes formally. Another writes like a Slack DM. The model matches whoever is prompting it. Your buyer experience becomes inconsistent across sellers.

Structure drift. No two proposals have the same section order. Legal cannot pre-approve anything because the shape keeps changing. Every proposal becomes a bespoke review cycle.

Every one of these is fixable in the skill layer. None of them are fixable at the “just use better prompts” layer, because “better prompts” is exactly the discipline you are trying not to require of every rep.

What Are the Five Parts of a Working Proposal Skill?

A working proposal skill has five parts: a role definition that pins down voice and audience, a data source precedence list that says which system wins on which fields, a step-by-step workflow, explicit guardrails for what the model must not do, and an output contract that defines what gets returned to the rep.

Role and voice

One or two sentences telling Claude who it is drafting for, in what tone, for what buyer. The trap here is generic language. “Professional and helpful” describes every SaaS proposal ever written. Be specific enough that a competitor could not use the same paragraph.

Data source precedence

An explicit order of trust. Buyer name comes from the CRM record, never the chat. Pricing comes from the catalog document, never inferred. Scope language comes from an approved template block, never invented. When sources conflict, the precedence list decides. This is the single most important section of the skill, and the one most teams skip.

Workflow

The step list Claude follows every time. Read the deal. Identify the right template. Pull matching case studies by industry tag. Apply pricing from the catalog by seat count or scope. Assemble the draft in PandaDoc. Return control to the human.

Guardrails

What Claude must never do, stated as absolutes. Never send. Never invent a number. Never fabricate a client name. Never assume a discount is authorized. When data is missing, flag it with a TODO marker rather than a plausible guess.

Output contract

What the rep gets back. A link to the draft, a one-paragraph summary of decisions made (“used the enterprise template, applied tier-two pricing based on 42 seats, flagged the SLA section because deal notes mention custom uptime terms”), and an explicit list of any TODO markers still in the draft.

Every skill we deploy inside our PandaDoc AI proposal generation engagements has these five parts. When one is missing, the failure it prevents shows up in production within a week.

How Do You Actually Write a Claude Skill for a Sales Team?

You write it as a versioned document, not as a chat message. Store the skill in a file your team owns. Give it a version number. Review it like a contract. Ship it to every rep through the same channel, whether that is a shared system prompt, a project instruction, or a saved Claude project.

Concretely, this is what a working skill outline looks like for a mid-market B2B services company. Adapt the fields, keep the shape.

# Proposal Generation Skill v2.4
# Owner: RevOps
# Last reviewed: 2026-08-01

## Role
You draft PandaDoc proposals for Acme Consulting, a B2B onboarding
services firm. Buyers are RevOps and Sales Ops leaders at Series B
to D SaaS companies. Voice is direct, confident, minimal filler.
No em-dashes. No exclamation marks. Sentences under 25 words where
practical.

## Data source precedence (highest trust first)
1. HubSpot deal record (buyer name, company, seat count, deal stage,
   notes)
2. Pricing catalog document ID `pd_cat_2026Q3` (all numbers)
3. Approved template library (scope language, section structure)
4. Case study library (only cite cases tagged with matching
   industry AND matching company size)
5. Rep chat instructions (only for overrides explicitly authorized
   in the deal notes)

If sources conflict, higher precedence wins. Never blend numbers
across sources.

## Workflow (execute in order, every time)
1. Read the HubSpot deal referenced in the rep's request.
2. If any of {company, primary contact, seat count, use case} is
   missing, stop and ask the rep for it. Do not proceed.
3. Choose the template:
   - `tpl_smb` if seat count < 25
   - `tpl_midmarket` if 25 <= seat count < 150
   - `tpl_enterprise` if seat count >= 150
4. Pull two case studies from the library tagged with the same
   industry as the deal. If fewer than two exist, use one and mark
   the second slot `TODO: case study`.
5. Apply pricing from `pd_cat_2026Q3` using seat count and selected
   scope tier. Never round. Never discount unless deal notes contain
   the string `DISCOUNT AUTHORIZED:` followed by a percentage.
6. Create the draft in PandaDoc under the selected template.
7. Return the output contract (below).

## Guardrails (absolute)
- Never send a document. Draft only.
- Never invent a price, a case study, a client name, or a metric.
- Never assume authorization for a discount, a custom SLA, or a
  payment term outside the catalog.
- If a required field is missing, insert `TODO: <what is missing>`
  in the draft rather than filling it with a plausible value.
- If the rep asks for something outside the skill's scope (redlines,
  legal advice, contract negotiation), decline and hand back.

## Output contract
Return exactly:
1. Draft URL in PandaDoc.
2. Decisions summary (3 to 6 sentences): template chosen, pricing
   tier applied, case studies selected, any assumptions made.
3. TODO list: every `TODO` marker still in the draft, with the
   field name and what the rep needs to supply.

The point of writing it this way is not aesthetic. It is that this file can be reviewed by sales leadership, edited by revops, and version-controlled like any other operational asset. When a proposal goes wrong in production, you can trace the failure back to a specific line in a specific version of the skill and fix it there.

How Should Reps Actually Use a Skill Day to Day?

Reps should not see the skill. They should see a simple project or workspace where the skill is preloaded, and their job is to point Claude at a deal and answer any clarifying questions. The skill does the work. The rep does the deal knowledge and the review.

The mistake we see most often is asking reps to paste the skill into their chat every time, or worse, to remember it. That defeats the purpose. A skill that lives in the rep’s head is not a skill; it is a hope.

Practical setup options, from lightest to heaviest:

Saved project or workspace. Claude’s project feature (or your internal Claude-powered tool’s equivalent) lets you attach a system-level instruction that applies to every conversation in that project. Put the skill there. Reps just open the project and start typing.

Slack or CRM-triggered flow. A rep types /proposal <deal-id> in Slack, or clicks a button on the HubSpot deal record. Under the hood, that call sends the skill plus the deal context to Claude and returns the draft link. Reps never see the skill at all.

Internal tool wrapper. For larger sales teams, wrap the skill in a small internal app with a form. The rep fills in the deal and any overrides, hits submit, gets a draft. This is where the Proposal Engine, our flagship PandaDoc implementation, lives for most of our clients.

Whichever surface you use, the invariant is: reps interact with a workflow, not a prompt. If the average rep can articulate the skill’s contents, you have over-shared and you will get skill drift within a month.

Which Approach Should You Choose?

Which approach fits depends on how many proposals you send, how much variance is acceptable, and how much your team can invest in setup. Ad-hoc prompts are free and give you one great proposal. Simple template prompts get you consistency at the paragraph level. Proper skill design is the only path to consistency at the workflow level.

Approach	Setup time	Consistency	Handles pricing correctly	Scales past 5 reps	Best for
Ad-hoc ChatGPT or Claude prompt	Zero	Low. Every draft varies.	Rarely. Model infers from context.	No. Every rep prompts differently.	One-off proposals, solo founders drafting occasionally.
Simple template prompt	An afternoon	Medium. Structure is stable, content drifts.	Only if the rep pastes the catalog every time.	Barely. Reps forget or edit the template.	Small teams doing under 10 proposals per month, willing to spot-check every output.
Proper skill design (versioned, grounded, guardrailed)	1 to 2 weeks including CRM grounding	High. Same shape and quality every time.	Yes. Pricing is a first-class part of the skill.	Yes. Skill is the artifact reps depend on, not each other.	Sales teams of 3+ reps sending regular proposals; anyone who has been burned by an invented number.

The middle row is where most teams get stuck. They graduate from ad-hoc to template, feel a real productivity gain, and stop there. Then a rep sends a proposal with a fabricated case study and the whole tool goes into quarantine. Skill design is what prevents that failure, and it is not that much more work than the template step.

How Do You Ground the Skill in Real CRM Data?

You ground the skill by giving Claude programmatic access to the systems that hold the truth. For most teams that means a live connection to the CRM (usually HubSpot or Salesforce), the pricing catalog, and the PandaDoc content library. The skill then references those systems by name in its precedence list, and Claude reads from them rather than guessing.

Grounding is the difference between a skill that works in a demo and a skill that works in production. A skill that says “use the buyer name from the CRM” only works if Claude can actually read the CRM. Otherwise it politely asks the rep to paste it, the rep pastes the wrong deal, and you are back to invented client names.

The typical grounding stack for a proposal skill:

CRM connection for deal, contact, and account fields. Our PandaDoc + HubSpot integration work is often the prerequisite here, because the deal record needs the right custom properties before Claude can read anything useful.
Pricing catalog as a single source-of-truth document. Not a spreadsheet in someone’s Drive. A versioned document Claude reads on every draft.
Content library for reusable case studies, bio blocks, and legal boilerplate, each tagged with the metadata the skill uses to filter (industry, size, use case).
Template library with the actual PandaDoc templates the skill maps to.

The skill file names all four. Without that mapping, the skill has nothing to ground against and defaults back to inventing.

How Do You Version and Iterate a Skill?

Version a skill the way you version any operational document. Put it in a repository (or at minimum a shared drive with change history). Give it a version number that changes whenever the skill changes. Log the reason for each version bump. Keep an “on-call skill owner” who reviews every proposed change before it ships to reps.

Iteration comes from two feedback sources, and you want both:

Proposal review. Once a week, sales leadership picks three shipped proposals at random and reads them. Every deviation from the intended output is a bug in the skill, not a rep failure. The fix goes into the next version.

Rep escalations. When a rep works around the skill (edits the draft heavily, or generates outside the tool), that is a signal. Ask them why. If the skill was too rigid for a legitimate deal shape, loosen it. If the rep was cutting corners, tighten it.

Skill versions rarely change more than once a month once mature. The first two months are noisier. Expect three to five iterations before you settle. That is normal.

Guardrail: never let a rep edit the skill mid-conversation. If the skill is failing a specific deal, log it, hand-draft that one proposal, and fix the skill for the next batch. Ad-hoc overrides destroy the entire consistency argument.

What Does a Bad Skill Look Like in the Wild?

A bad skill looks like a long, aspirational prompt with no data grounding, vague voice guidance, no explicit guardrails, and no output contract. It reads like a pitch deck for the model rather than an instruction to it. It performs well in demos and fails within two weeks of real use.

Common patterns to avoid:

The essay skill. Two thousand words of context about the company, the market, and the buyer, with no explicit workflow. Claude has a lot to work with and no idea what to actually do.
The tone-only skill. Detailed voice guidance (“warm but authoritative, like a trusted advisor”) and nothing about pricing, templates, or data sources. Produces beautifully written proposals with wrong numbers.
The kitchen-sink skill. Every edge case the founder ever thought about, encoded as an if-then. The workflow becomes unreadable and the model quietly ignores most of it.
The unversioned skill. Nobody knows which version is live. Reps have three saved copies, all different. When something breaks, there is no source of truth to fix.

The good skill is short, structured, grounded, and versioned. If your skill is over 800 words and you cannot point to where pricing is grounded, it is a bad skill regardless of how well it writes.

Frequently Asked Questions

Do I need Claude specifically, or does this work with any AI?

The pattern works with any capable model that supports system-level instructions and tool use. Claude, GPT, and other frontier models can all execute a well-written skill. The skill design is the leverage, not the model brand. In our own client builds we default to Claude for its instruction-following consistency, but the skill pattern travels.

Can our sales team write their own skill?

Yes, and they should be involved. The best skills are drafted by revops or sales enablement with heavy input from your top reps. What you do not want is every rep writing their own private version. One skill, owned centrally, contributed to by the field.

How long before a skill starts producing usable drafts?

A first working skill takes one to two weeks including the CRM grounding work. It produces usable drafts on day one but needs three to five iterations over the first month to settle into something reps trust without heavy editing.

What happens when our pricing changes?

You update the pricing catalog document the skill references. The skill itself often does not change; only the source it points to. This is exactly why the precedence list matters. It decouples the skill from the data.

How do we know the skill is working?

Two metrics: the percentage of drafts that ship with fewer than three rep edits, and the number of pricing or client-name errors caught in review. Both should trend up and toward zero, respectively, over the first eight weeks. If either stalls, revisit the skill.

Ready to Build Your Own Proposal Skill?

Skill design is the highest-leverage hour of work you can do on an AI proposal workflow, and the easiest one to get wrong. If you would like help writing, grounding, and shipping a proposal generation skill your reps will actually use, get PandaDoc help from our team. We build these for clients across B2B services, SaaS, and agency workflows, and we will hand you a skill that survives contact with your actual sales team.