How To Build Claude Skills For Finance Work
Most finance professionals who use Claude are reprompting it from scratch every session. They open a new conversation, re-explain the dataset, re-specify the format, re-describe the tone, re-list the locations. Then they clean up the output, because Claude didn’t quite hit the format they had in their head. Then they do it all again next month.
This isn’t a prompting problem. It’s an architecture problem. And Claude Skills are the fix.
This article walks through exactly how to build Claude Skills for finance work — from the basics of what a skill is and how to set one up, to three specific skills you can build this week, to a meta-skill that chains them together and takes raw numbers all the way to a formatted slide deck with no manual steps in between.
Why Most Finance Professionals Are Using Claude Wrong
Reprompting feels like a small friction. Type a little more, get the output, move on. But add it up across a close cycle and it’s not small. Every time you re-explain your variance commentary format, every time you remind Claude what the three locations are, every time you paste output into a slide and manually reformat it — that’s invisible work. And invisible work doesn’t compound.
The finance teams getting real leverage from AI right now aren’t writing better prompts. They’re building infrastructure. A prompt helps you once. A skill helps you — and your whole team — every time.
The other problem with prompts is consistency. When you prompt ad hoc, your output varies based on how specifically you wrote the instructions that day. Hand the same prompt to two different analysts and you’ll get two different outputs. Skills eliminate that. The standard lives in the skill, not in the person running it.
What Claude Skills Actually Are
A Claude Skill is a saved system prompt — a permanent instruction set that loads automatically every time you open a conversation inside that skill. It tells Claude what role it’s playing, what format to use, what context it’s working with, and what the output should look like.
That’s it. There’s no code. There’s no configuration beyond writing instructions. The skill interface inside Claude lets you name it, write the prompt, upload supporting files, and save it. After that, every new conversation starts with your full context already loaded.
Think of it this way. Every time you prompt Claude from scratch, you’re briefing a consultant from the beginning. Every time you use a skill, you’re working with an analyst who already read the process doc, knows the client, and remembers the format you use. The briefing is done. You just hand them the data.
What lives inside a skill: the role definition, format requirements, output structure, terminology standards, and any context files you upload (like a dataset or a template). What doesn’t live there: the actual data you’re analyzing. That comes in fresh each session. The skill holds the rules; you supply the numbers.
Setting Up the Claude Skills Interface
Creating a skill takes about ten minutes the first time. Here’s the exact process.
Open Claude and navigate to the Projects panel. Click “New Project” (Claude’s current interface calls these Projects, but the logic is identical to Skills — a saved system prompt with uploaded context). Give it a clear name. Naming conventions matter when you’re building a library: use something specific enough that you’d know what it does six months from now. “Variance Commentary — Coffee Shop” is better than “Finance Tool.”
Next, write the system prompt. This is the core of the skill. Be specific about four things: the role Claude is playing, the format the output should follow, what to flag or prioritize, and how to close. Vague instructions produce vague output. If your commentary format has a specific section order, write it out explicitly. If you want dollar variances before percentages, say so. If there’s a threshold that triggers an escalation flag, put the number in.
Then upload your context file. For finance skills, this is usually the dataset you’re working from — a GL export, a budget file, or a prior-period comparison. Uploading a file gives Claude a document to reference without replacing its general knowledge. It can cross-reference what’s in the file with what it already knows about accounting, financial analysis, and reporting.
Save the skill. It now appears in your Projects panel and is available every time you open Claude. Open a new conversation inside it and Claude starts with your system prompt already active.
One thing worth knowing: skills are editable. As your process evolves — format changes, new locations added, escalation thresholds updated — you update the system prompt and every future run reflects the change. The skill is a living standard, not a frozen template.
Build 1: The Variance Commentary Skill
This is the most immediately useful skill for most FP&A teams. You’ve got actuals and budget numbers. You need commentary. The same commentary, every month, in the same format, to the same audience.
Here’s what the system prompt for this skill needs to contain.
First, the role: “You are a senior financial analyst for [company/portfolio]. Your job is to write executive-ready variance commentary based on actual vs. budget data.” This anchors Claude in the right register — analytical, professional, specific.
Second, the format. Write it out explicitly. If your standard format is portfolio summary first, then location breakdown, then priority flags, then action items — list those sections in order. Tell Claude how many sentences the summary should be. Tell it what counts as a priority item (a specific dollar threshold, a percentage threshold, or both). Tell it how many action items to include.
Third, the escalation logic. “Flag any variance greater than 5% as a priority item” is more useful than “flag significant variances.” Specific thresholds produce consistent flags. Vague instructions produce inconsistent judgment.
Once the skill is built, using it is straightforward. Open a new conversation inside the skill, paste in the raw actuals and budget numbers, and send. No format instructions. No reminders about tone or structure. The skill holds all of that.
What comes back is structured commentary that matches your format standard — portfolio summary, location breakdown, flags, action items — on the first pass. The cleanup time drops dramatically because the format isn’t being negotiated every session. It’s fixed.
For the Coffee Shop portfolio, this skill takes Seattle, Portland, and Denver actuals against budget and produces location-specific commentary with variance percentages, directional language, and a set of action items — all in the format the finance team uses for their monthly deck. The analyst’s job becomes reviewing the output and making judgment calls, not building the write-up from scratch.
Build 2: The PowerPoint Formatting Skill
Commentary is one problem. Slides are another. And for most finance teams, the work doesn’t end when the commentary is written — it ends when the deck is ready. Reformatting a written analysis into a slide structure is one of those tasks that takes longer than it should and produces inconsistent results, because every person who builds the deck makes slightly different choices about what goes on which slide and how much text belongs in the body.
A PowerPoint formatting skill standardizes that too.
The system prompt for this skill encodes the slide logic: how many slides, what goes on each one, how long the body text should be, whether the location breakdown is one slide per location or a summary grid. You’re not building the PowerPoint inside Claude — you’re building the outline and copy that someone (or a connected tool) uses to populate the template.
For the Coffee Shop setup, the skill produces a 7-slide outline: title slide, portfolio summary, one slide per location, a priority flags and action items split, and an appendix note. Body text is capped at 30 words per slide. Bullets replace prose wherever the content is list-shaped.
The input to this skill is the commentary output from the variance commentary skill. You take what the first skill produced and paste it into the second one. The slide skill doesn’t need to re-analyze the numbers — it just needs to reformat the commentary into slide-length copy with the right structure.
The output is a labeled, slide-by-slide outline that maps directly to a PowerPoint template. Drop it in, format, present.
The time savings here are real, but the more important benefit is consistency. Every deck produced by this skill has the same structure. Different analysts, different months, same format. That matters when the CFO is comparing March’s deck to February’s and the layout is identical.
Build 3: The Meta-Skill That Chains Both
This is where it gets interesting.
Instead of running two separate skills — commentary first, then slides — you build one skill that does both in sequence. One input: raw actuals and budget numbers. Two passes: first the commentary, then the slide structure. One output, clearly labeled, ready to split into two deliverables.
The system prompt for a meta-skill tells Claude to run two explicit passes and label each one in the output. Pass 1 writes the commentary following the same format as the standalone commentary skill. Pass 2 converts that commentary into the slide outline following the same structure as the formatting skill. The skill labels the output with a clear divider so you know exactly where the commentary ends and the slides begin.
The practical effect: you open a conversation inside the meta-skill, paste in the raw numbers, and get back a full variance report — commentary and deck structure — in one response. No switching between skills. No copy-paste handoff between tools. One run, one output.
Here’s what that looks like with the Coffee Shop data. Three locations worth of actuals and budget numbers go in. Out comes a portfolio summary with location detail and action items, followed immediately by a 7-slide outline with the commentary already scoped to slide-length copy. The whole thing is ready to hand to someone who can build the deck or drop it into an automated template.
Case Study: The Coffee Shop Close Process
Before these skills existed, the Coffee Shop variance report worked like this. An analyst exported actuals from the GL, compared them to the budget in Excel, wrote commentary in a Word doc using last month’s as a starting point, and then reformatted the whole thing into slides by copying text and adjusting manually. Total time: somewhere between two and four hours depending on how messy the month was.
After the meta-skill was built, the process is: export actuals, paste into Claude, review output, populate template. The analysis judgment — what to flag, how to characterize a variance — still belongs to the analyst. But the formatting work, the write-up structure, and the slide logic are handled by the skill.
The output for March looked like this. Portfolio summary: favorable overall by $4,500 driven by Denver revenue outperformance, partially offset by Seattle COGS overage. Seattle flagged as a priority item — COGS variance of 5.5% over budget. Action items included a review of Seattle labor costs and a follow-up on Portland revenue shortfall drivers. Seven slides, formatted to the team’s standard, body text under 30 words per slide.
First pass. No cleanup on format. Review time cut from two hours to about 20 minutes.
Where Skills Break Down
Skills are only as good as the instructions inside them. If the system prompt is vague, the output will be inconsistent. If the format in the prompt doesn’t match the format the team actually uses, the skill produces output that needs to be restructured every time.
The fix is iteration. Build the skill, run it on a real dataset, review the output, and update the system prompt based on what was off. Most skills need two or three revision cycles before they’re producing output that requires minimal review. That iteration time is front-loaded — after it’s done, the skill runs clean.
The other limitation is process change. When your commentary format changes — new section added, different escalation threshold, additional location — the skill needs to be updated. This is less work than it sounds (edit a few lines in the system prompt) but it requires someone to own the skill and keep it current. If nobody owns it, it drifts and the output quality drops.
Finally, skills work best for processes that are genuinely repeatable. If every variance report requires significantly different analysis based on factors the skill can’t anticipate, a skill won’t replace judgment — it’ll just give you a starting structure. That’s still useful, but it’s not the same as full automation.
How to Roll This Out to Your Team
Start with one skill, not a library. Pick the process that happens most frequently and produces the most inconsistent output. Build a skill for that one thing. Run it for a month. Refine the system prompt based on what doesn’t quite land. Then hand it to someone else and see what happens when they run it.
That last step matters. A skill that produces great output when you run it but falls apart when someone else does is telling you something: either the instructions are too context-dependent on knowledge the other person doesn’t have, or the system prompt needs to be more explicit about something you assumed was obvious.
Once the skill is clean enough that another analyst can run it and get the same output, it’s ready for the team. Add it to a shared project space, document it with a one-paragraph description of what it does and what input it expects, and move on to the next one.
The shift this represents isn’t about any individual skill. It’s about moving from “AI helps me do my work” to “AI runs the process and I review the output.” That’s a different relationship with the tool — and it’s a different value proposition to make to your CFO when they ask what the finance team is actually doing with AI.
The standard lives in the skill. The judgment still lives with the analyst. That’s the right split.