Building a Claude skill for Proposals

I think most people who use Claude regularly have had this experience: you are doing something for the third or fourth time, pasting in context, re-explaining your preferences, adjusting the output to match your voice, and somewhere in the middle of it you think: I have done this exact thing before.
And then you finish the task and move on.
That gap between noticing and doing something about it is where a lot of workflow improvement dies. Not because building a skill is complicated, but because in the moment you are just trying to get the thing done. The meta-work feels like a distraction.
I caught myself in that gap recently with proposals.
How it came up
We already had a proposal template. It worked, but I had outgrown the design. It no longer felt like our current work. I opened Claude Design and built something new from scratch. Better layout, right typography, the kind of thing I would actually want to send to a client.
Once I had it, I wanted to get it into something I could update for new clients without rebuilding from scratch each time. My first instinct was Canva. Design in Claude, maintain in Canva going forward. Except when I exported, Claude Design did not produce a Canva document. It produced a website. Wrong format entirely, nothing editable in the way I needed.
So I had an HTML file that looked exactly right and nowhere obvious to take it.
I sat with that for a moment and the question shifted. The HTML file was already the output. It opens in any browser, prints to PDF when a client needs one. The only thing missing was a way to populate it for a new project without doing it by hand every time.
And that is when I thought: this is exactly what a skill is for.
What a skill actually solves
The proposal has the same structure every time. Situation analysis, scope options, timeline, investment, about section. What changes is the client, the project, and the specific language for each section. That is a pattern. Patterns are what skills are built around.
A Claude skill is a folder with a SKILL.md that tells Claude when to trigger and how to behave, plus any supporting files it needs. In this case the supporting file is the HTML template. The SKILL.md describes the proposal structure, the voice rules, what to ask before generating, and how to audit the output before handing it off.
When I start a conversation with a brief or meeting notes and mention I need to write a proposal, the skill triggers. Claude reads the brief, writes the content for each section, populates the template, and hands me a file I open in the browser. I review, adjust where needed, print to PDF if the client needs one.
The first test was not perfect. Spacing issues, leftover content from the original template, page numbers hardcoded instead of calculated dynamically. Each problem meant going back into the SKILL.md and being more specific. Vague instructions produce vague output. The more precisely you describe what you want, the less you have to fix afterwards.
The second test was noticeably better. That is how skill-building works. You do not get it right the first time. You get it usable, and then you refine it with real use.

The thing I actually want to say
I have been using Claude seriously for long enough to know that skills exist and that building them is not hard. I still almost did not build this one.
There is always a reason to skip it. You are under time pressure. The manual version is fine for now. You will do it properly later. Later almost never comes.
What actually worked for me was treating the moment of frustration as a trigger rather than just a feeling. When I noticed I was about to do the same manual thing again, I stopped and asked whether thirty minutes now would save that time on every future proposal. The answer was obviously yes.
The skill took longer than thirty minutes to get right. But now it exists, and the next proposal starts with a brief instead of a blank page. That is already a different situation.
Notice the pattern, act on it. The specific workflow almost does not matter.
What comes next
The skill is v1 and I will keep refining it with real use. The bigger question it opened up is whether a PDF is even the right format for a proposal. A printed document made sense when that was how things were shared. There are more interesting options now, like a proposal as a personalized web page, something the client experiences rather than downloads. I am thinking about what that looks like. Probably the next article.