YouTube Instagram TikTok How it works FAQ

The fastest way to turn talking videos into clean, searchable text. Free, private and no account required.

About

Built by Rishav Raj with one goal: free transcripts for everyone.

rishav@yttotranscript.com

Transcribe

YouTube to text
YouTube with timestamps
Instagram Reels
TikTok videos

Learn

How it works
FAQ
YouTube transcripts guide

More

Chrome extension
Contact
Privacy policy
Terms of service

© 2026 YTtoTranscript. Made for creators & researchers.

Not affiliated with YouTube, Instagram or TikTok. Respect creators’ copyright.

I Built a Complete AI Finance Team With Claude (Full Tutorial) — Transcript · YTtoTranscript

Home/Transcripts/YouTube

YouTube Transcript

I Built a Complete AI Finance Team With Claude (Full Tutorial)

Luke Finance · 3,245 words · 16 min read · EN

Watch on YouTube

Share X LinkedIn WhatsApp

Below is the complete, readable transcript of I Built a Complete AI Finance Team With Claude (Full Tutorial) by Luke Finance on YouTube. Read the full text, copy any part you need, or generate a transcript for any video with our free tool.

Claude is already good at automating a single finance task like pulling a report or maybe cleaning a data set, but a single task is one piece of a much, much bigger process and the real work is everything around it from taking the analysis and turning it into a forecast to weighing it and then shaping it into

a decision. That part still lands on one person to hold together and it's slow. It breaks between stages and every new question makes it start over. So, the real shift is using Claude to run that entire process as a team of different roles where each one owns a stage and then hands off to the next. That way it

works the same as a finance department does. Now, as a quant and finance automation developer, I'm going to show you how to build that team inside Claude with an example use case of three specialized workers that pass their own work down the line and make a real business decision about whether a growing restaurant chain should open 10

new locations next year. They carry it from raw company data to a board-ready recommendation and I'm not coordinating any of it by hand. Now, I'll build this team as a set of three roles that work as one single system. Now, finance analyst that reads the current business is important, then an FP&A strategy

partner that models the expansion and then expansion options, and then a CFO advisor that turns everything into a board decision. you want the prompts, the instruction files, and all the data sets from this video, they're in my free community and the link is in the description below. For now, let's get into it. The team I'm about to build has

one job and that's to answer a real expansion decision the way a finance department would work in real life. Now, the company is a fast-casual restaurant chain with 160 locations and a plan to grow past 300 locations by 2027. Now, management wants to open 10 new stores next year, and that's a large bet and a

Transcribe another video

Paste any YouTube, Instagram or TikTok link to get a free transcript.

Free · No sign-up · Unlimited

Add to Chrome — transcribe in one click

hard one to reverse if it goes wrong. So, before a board signs off, they need three answers. Is the current business healthy enough to carry it? Do the returns clear the company's investment bar? And what does the risk actually look like? Now, in a real company, that question moves through several people, and an analyst looks at current

performance, FP&A builds the forecast and tests it against return targets, and then the CFO reviews all of it and brings a recommendation to the board. I built that exact chain inside Claude using three workers. Setting up the project, before any worker exists, I set up the project so that the team has a

place to operate. Everything lives in one folder called Crave Kitchen Finance Team, and the work inside it is split into five areas. Now, the split matters because it lets each role work on its own data while everyone stays anchored to the same company context. And the first area is company context, and this

holds the permanent knowledge that the business runs on. An executive briefing explains the company, its strategy, and what leadership wants to achieve. A capital investment policy sets the financial rules that every expansion has to clear, like return thresholds and payback expectations, and a board investment framework defines how the board approves a major [music]

investment. The second is source data. Now, this is the operational and the planning layer. The store performance data comes from Airtable. The expansion scenarios come from Google Sheets. The market assumptions comes from Notion. Now, these do not have to sit inside the folder, they can stay in the system they already live in, and the team locates

them when it needs them. Now, the third is workers. Each of the three roles lives here as its own skill with the files and the logic it needs to do its job. The fourth is worker outputs. Now, this is the handoff layer and when one worker finishes, its deliverable lands here so the next worker can then kick it

up. The fifth is final deliverable and this is where the board presentation ends up once the workflow is done. Now, this structure also makes the handoffs visible. As each worker finishes, a new file appears in the project and you watch the store analysis land, then the business case, then the board deck in

the same way work moves from desk to desk in a real finance team. Now, with the structure in place, I can start building the team and the first worker sets the foundation for everything else that comes afterwards. Building the first worker, the finance analyst. The first worker I build is the finance analyst and I start here because this

role owns the current picture of the business and everything downstream depends on getting that picture right. So, I open a new Claude session and I attach the whole project folders so Claude can see the structure, the context files, and where everything sits. On the right, I pick the model. Now, building a worker is reasonably

heavy so I go with Opus. Now, what makes a worker reliable is not the length of the prompt, it is how the prompt is structured. So, I build every skill in this project on the same five components: trigger, objective, process, context, and rules. Now, once you have that frame, building any worker becomes

the same repeatable move. Now, the trigger is what tells the skill when to take over. So, for the finance analyst, that is the start of the workflow, the moment the team picks up a business problem and the current numbers have to be understood before anyone forecasts or decides anything. Now, the objective is

the single outcome it owns. Here, it is turning raw data into a clear read on the health of the business, something that the next worker can then build on top of. The process is how it gets there. So, instead of telling it to analyze performance, I give it the actual steps. Work through profitability

and EBITDA, breakdown labor and food costs, rank the strong and weak stores, and judge expansion readiness. Spelling the process out is what keeps the output consistent from one run to the next. Now, the context is what it reads to do the job. So, the executive briefing for company strategy and the store performance data for the numbers, and

that keeps it grounded in this company instead of issuing generic finance knowledge. Now, the rules set the boundaries. It produces one file, the store analysis report, and saves it to the worker outputs folder. It is blocked from forecasting or recommending anything because those belong to the workers downstream. Now, keeping that scope tight is what stops the roles

overlapping later. Now, those five pieces are what turn a prompt into a worker, and the next two are built the same way. Claude inspects the project first, and it builds the skill as a full package rather than a single file. It writes the skill file that defines the role and its boundaries. It writes a

methodology document that fixes how every metric is calculated. So, EBITDA margins, cost percentages, and store rankings come out the same way on every single run. The benchmarks lean on the company's own targets from the briefing first, then fall back to portfolio medians where no target exists. Then, it writes a report structure document that

lays out exactly how the output workbook is organized, and it writes a Python script that reads the data and builds the workbook flexible enough to handle differences in how the data is exported. Before finishing, Claude tests the skill against sample restaurant data, checks the skill file skill file formatting, and confirms the description length is

valid. Once it packages the worker into a installable skill file, I review the generated files in the project folder. I click save skill, and the finance analyst installs into my skills, and I open the skills area to confirm it's there. And the first worker is now a reusable asset rather than a prompt I

have to rewrite every time. Building the FP&A strategy partner. The second worker is the FP&A strategy partner. Now, this is where the project moves from reading the present to modeling the future. So, I build it in the same session so that Claude already understands the project and how this role fits between the other

two. I build it on the same five components, and the fastest way to understand the worker is to see what changes inside each one. And the trigger is no longer the start of the workflow. It is the moment the store analysis lands because this worker reads that report first. Now, the objective moves

from describing the present to answering one question. Does expansion create value? Now, the process becomes forecasting, modeling the five, 10, and 15 store options, and running ROI, NPV, IRR, and payback on each. Now, the context widens to four inputs. The store analysis, the expansion scenarios, the market assumptions, and the capital investment policy. And the rules let it

recommend the strongest scenario on financial merit, but stop it short of the final call because that has to stay with the CFO advisor. One small thing happens here worth pointing out. The prompt refers to a capital investment guideline file, but the actual document in the project is named capital investment policy. The Claude catches

the mismatch, it recognizes the policy file is the one I meant, and it points the worker at the file, the correct file, instead of breaking on a name that doesn't exist. Now, that only happens because the worker is being built inside the real project against real files. Claude then builds the package. The

forecasting methodology is heavier than the first workers since it has to project the new store economics, apply market assumptions, and run the investment maths. Now, while it builds, Claude finds and fixes a few issues on its own. It reruns the test until everything executes cleanly against sample data. The most useful part of

this worker is that it does not just calculate returns. It checks each scenario against the thresholds in the capital investment policy and it flags whether it passes. I review the generated files, I save the skill, and I confirm the FP&A strategy partner is installed next to the first worker. The deliverable it produces, the expansion

business case, becomes the bridge into the executive decision. Building the CFO advisor. The third worker is the CFO advisor, and it sits at the top of the workflow. Now, this role takes what the first two workers built, and then it turns it into a decision that the board can act on. Now, I build it in the same

session on the same five components one last time. The trigger is the final handoff, both worker files sitting in the outputs folder. The objective is a decision the board can act on. Should the company open 10 new locations next year or not? The process is an executive review, challenge the assumptions, weigh strategic fit against risk and reward,

and commit to a position. Now, the context is both worker outputs along with the executive briefing and the board investment framework. And the rules force a real answer, one of proceed, or proceed with conditions, or do not proceed, with every claim tied back to the evidence that the other workers produced. A A real CFO does not

hand the board a maybe. Because the output here is a board presentation rather than a spreadsheet, Claude builds a different kind of automation, a deck generation framework instead of a workbook builder, plus a decision framework that defines how the workers stress test the earlier conclusions before it commits. Now, there is one design choice worth noting here. The

deck builder pulls the key metrics from both worker outputs and assembles every section of the presentation, but it does not stamp the final answer itself. It lays out the evidence and it leaves the judgment to the CFO advisor at run time. And that keeps the role as a decision maker rather than a calculator. Now, I

review the files, save the skill, and confirm all three workers now sit together in my skills, the master instruction file. Now, I have three workers, but on their own, they do not know when to run or in what order. And that is a job of one more file at the top of the project, and this is the

master instruction file. Now, the file is not another finance worker, it is the orchestrator. It runs the workflow, it finds the data, it invokes each worker in sequence, it checks the output, and then it controls the handoffs. It never does the analysis itself, which is the whole point. That's very important. The workers do the thinking and the

orchestrator keeps the process on the rails. Now, it starts with discovery. Before any work or any worker runs, the orchestrator locates every file that the project needs and builds a file registry that records where each one lives. And the data can be in airtable, it can be in Google Drive, it can be in Notion, or

it can be in a local folder. So, it doesn't need to assume anything. It searches, it finds the file, and it remembers the location for the rest of the run. Now, one rule matters here. The orchestrator does not download. It does not copy. It does not move. It doesn't do any of that to any of the data. It

only needs to know where each file lives. If it started duplicating files, then the team would drift out of sync with the real sources, and then it would stop being reusable across different setups. It also enforces the order very strictly. Now, the finance analyst always runs first. The orchestrator checks that its report exists before it

lets the FP&A worker start. Now, that report is missing, the workflow just stops right there because the next worker has nothing to build on, and the same gate sits between every stage. Now, once this file is in place, the project becomes a system that you can rerun. A brand new Claude session can open it,

read the master file, and then run the entire team from the top without me rebuilding a single thing. Running the team end-to-end. Now, I test the whole thing the way it would actually be used. I open a completely fresh Claude session. I attach the project folder and I give it a single instruction. Read the

master file, take over the orchestrator, and run the workflow from the top starting with file discovery. And then Claude reads the file and steps into the orchestrator role. The first thing it does is map the project. It finds the company contacts documents sitting locally, and it notices the source data folder is empty. Now, this is

intentional. The operational data is meant to live in the connected systems, not inside the project. So, it goes looking. It finds the store performance data in Airtable, the expansion scenarios in Google Drive, and the market assumptions in Notion. And then it records each one in the file registry. Then it pulls what it needs to

feed the workers without permanently moving anything. From Airtable, it reads the 25 store records covering revenue, profitability, labor, and food costs. And from Notion, it pulls the economic, labor, and inflation assumptions the FP&A worker will need later on. Then the team runs in sequence. The finance analyst goes first using the briefing and the the store data. It then

evaluates the health of the existing business, and it writes the store analysis report into the worker outputs folder. I open the folder to confirm the file is actually there before anything moves on. Now, the FP&A strategy partner runs next. It reads that report. It pulls the thresholds from the capital investment policy, and then it evaluates

the five, 10, and 15 store scenarios on ROI, NPV, IRR, and payback. Every option creates value, but the 10-store plan comes out as the most balanced between growth and execution risk. It lands there, and then it writes the expansion business case. And again, I check the folder, and the file is there. The CFO

advisor runs last. It reviews both outputs against the briefing and the board framework, and it surfaces the one tension in the whole plan. The expansion shows positive NPV, strong ROI, and an attractive IRR, but the payback period runs past the company's own policy limit. So, instead of burying that, it frames it as a board-level judgment

call, and then it builds the recommendation around it. Now, when everything finishes, the orchestrator runs the final check. Both reports sit in worker outputs, the presentation sits in final deliverables, and the numbers stay consistent across all three. Now, from one instruction, the full team has gone from raw data to a board-ready recommendation. I'm reviewing the

output. Before I trust any of it, I open the actual files. The store analysis report opens as 12 worksheets. There is an executive summary up front, then revenue, EBITDA, labor and food cost analysis, regional performance, the top and underperforming stores, and expansion readiness assessment, and a handoff section for the next worker. It

reads the way a finance team would prepare it before walking into a meeting. Now, the expansion business case is 10 worksheets. For each, there are three scenarios it lays out: capital investment, NPV, ROI, IRR, payback, and whether the option clears the investment policy. The recommended scenario tab shows the worker reach a conclusion

rather than just printing numbers, and it lands on the 10-store plan. The board recommendation deck is built for the boardroom, on the question itself. Should we open 10 new locations next year? And it puts the answer on the very next slide: proceed with conditions. From there, it walks through the strategic and financial assessment. It

compares the three scenarios side by side, and it shows why 10 wins over the safer five and the heavier 15. Now, the risks come with mitigations next to them. The recommendation spells out the conditions, the phased openings, the disciplined site selection, labor management, and capital oversight. And the final slide ties the answer back to

the evidence the earlier workers produced. Every number on it traces to a specific worker output, so the recommendation can be defended in the room. And that's the full system: three workers and a master file that runs them in order, going from raw company data to store analysis, from analysis to an investment case, and from that case to a

board decision. Now, once it is built, you do not need to rebuild it. The new data comes in, the same team runs against it, and the output updates. Now, if you want the prompts, the instruction files, and all the data sets from this video, remember they're in the free community, and the link is in the

description below, and I'll see you next time.