A pattern for running your full client sales and delivery cycle — from discovery call to signed contract to weekly standups — using Claude Code slash commands wired to Fireflies, HubSpot, and Vercel.
This is an idea file. Copy-paste it into Claude Code or your preferred LLM agent. Its goal is to communicate the high-level idea; your agent builds out the specifics in collaboration with you.
The Core Idea
Most teams manage their client pipeline through a mix of tools that don't talk to each other. The discovery call happens in one place. The deck gets built in another. The proposal lives in a folder. The contract gets emailed. Invoices get created manually. The CRM gets updated if someone remembers. Every handoff is a gap where things fall through.
The real problem is that the content and context from every client interaction stays siloed. The transcript from the discovery call never makes it into the deck. The pricing from the proposal never makes it into the invoice. The deal in the CRM never reflects what was actually built and sent.
The idea here is different. Every slash command in this system reads from the same shared context layer: a client folder with call transcripts, a HubSpot deal with a running log of every output, and a set of skills files that carry your copywriting voice, pricing tiers, and design system. When you run /new-demo-deck, it pulls the Fireflies transcript automatically, reads your brand and copy skills, builds the deck, and logs the URL back to the HubSpot deal. Every command does the same thing: read context, build output, write results back. The pipeline doesn't just generate assets. It keeps everything in sync.
What it handles — across a full client lifecycle:
A qualified lead comes in after a discovery call. You run one command. It pulls the transcript, reads your design system and copywriting rules, and returns a full interactive demo deck in under 10 minutes.
The demo goes well. You run another command. It reads what changed during the demo call, adjusts scope and pricing, and returns a formal proposal. No rewriting from scratch.
The client signs. You run three commands: SOW, kickoff deck, invoice batch. All linked to the same HubSpot deal. All using the same design and copy rules you defined once.
Whoever closes this loop — from first call to signed contract to weekly standups — without manual handoffs wins on time. Most teams only automate the obvious part (the deck) and still lose hours on everything after it.
Architecture
Four layers:
Call transcripts — immutable, read-only source files. Fireflies records every call and the system pulls transcripts per client. The agent reads from here, never rewrites.
Skills layer — reference documents the agent consults before writing anything. Your copywriting rules, pricing tiers, design system, and diagram patterns live here. Updated by you, inherited by every command automatically.
Commands layer — the workflow drivers. Each slash command is a markdown file with numbered steps: what to ask, what to read, what to build, where to save. Eleven commands covering the full pipeline from first email to weekly standup.
HubSpot + Vercel — the output layer. Every deck gets a shareable Vercel link. Every link, invoice, sales plan, and output gets logged back to the HubSpot deal record. The deal becomes the single source of truth for the full client relationship.
The Pipeline
Lead comes in. Another agent scores the discovery call transcript against your ICP. If qualified, it creates the HubSpot deal and fires the signal that kicks this pipeline off.
Run /new-demo-deck. The command pulls the Fireflies transcript for that client, reads your design system and copywriting skills, and builds every slide including a Mermaid architecture diagram. It checks the HubSpot deal — creates one if the other agent hasn't yet — and logs the deck URL back to the record. First v1 in under 10 minutes.
Demo happens. Run /demo-proposal. The command reads the demo call transcript from Fireflies, extracts what changed, adjusts scope and pricing, and asks what else to add before writing a word. The proposal inherits the same design and voice as the demo deck.
Run /hormozi-sales-plan. Reads prior transcripts, the qualification scorecard from the lead scoring agent, and deal history. Generates a word-for-word call script and pushes it to the HubSpot deal record. Your meeting prep agent picks it up from there.
Client decides to move forward. Run /sow. Turns the agreed proposal into a signed-ready Statement of Work formatted for e-signature. No formatting fights. Saved to the client folder and linked on the deal.
Run /create-invoices. Creates a draft HubSpot invoice for every payment milestone in the SOW. Each one linked to the deal, contact, and company automatically. Drafts sit in HubSpot for review before sending.
Client signs. Run /new-pm-deck. Reads the signed proposal, extracts deliverables and timeline, and builds a kickoff deck with scope confirmation, discovery questions, architecture diagram, and action items. Show up to kickoff with something that looks like it took a week.
Every week. Run /add-weekly-update. Your dev sends a markdown update. The command reads git commits, parses what was built, updates the architecture diagram, surfaces open questions for the client, and appends a new standup page to the PM deck. The link the client already has updates automatically.
Loop closes. Results from every client engagement — what closed, what stalled, what got flagged in the qualification scorecard — feed back into the skills layer. You update pricing guidelines when rates change. You update copywriting rules when something lands better. Every future deck inherits the update.
Configuration (Your Skills Layer)
The skills layer is what makes this yours instead of generic. At minimum, create these files in .claude/skills/:
proposal-copywriting.md: Your voice rules. No em dashes. Short sentences. Second-person to the client. No passive voice. Words to use and words to avoid. Section-by-section rules for heroes, problem statements, solution sections, and pricing blocks. This is the most important file — it controls the voice of everything the system produces.
pricing-guidelines.md: Your engagement models, pricing ranges, and how you structure multi-tier options. Your minimum project size, typical range, retainer rate, and standard phase structure. Every pricing section in every deck reflects your real rates without you specifying them each time.
brand-design-system.md: Your colors, typography, border radius rules, section background patterns, and spacing conventions. Define your accent color, your heading font, your mono font for labels, and your light/dark alternation pattern for sections. One file, inherited by every deck.
proposal-mermaid.md: Rules for generating architecture diagrams. Which direction to use for different diagram types, node color assignments, subgraph naming conventions, what to avoid. Keeps every architecture diagram visually consistent without you specifying it per deck.
roi-business-case.md: A five-line framing structure for every pricing section. Current state cost → future state savings → net benefit → investment → ROI ratio. Frames every proposal as a business case, not a price quote.
pricing-guidelines.md: Tiers, engagement models, what's included at each tier. The commands read this before writing any scope or pricing section.
The skills layer is a living set of documents. Every time a command produces something you wouldn't have written, update the relevant skill. After a few client cycles, the system knows your voice and standards better than a new hire would.
What to Build First
Step 1 — Scaffold the web app. Ask Claude Code to create a Next.js app with TypeScript and Tailwind CSS. The app renders proposal configs as interactive web pages. Each proposal is a TypeScript object with metadata, a theme, and a sections array. The app reads those configs and renders them at /[slug]. You never touch HTML directly — the AI codes the slides, you write the content. The core insight here: AI is better at coding than at editing slide decks in various apps, so get AI to code you slides that look good.
Step 2 — Build your design system. Before writing any proposals, define your visual rules and save them as .claude/skills/brand-design-system.md. It's important to have 1–3 good templates to work with before you build any commands. Consider starting in v0 to get a template you like, then have Claude Code analyze it to extract the design system. Establish colors, typography, border radius, section patterns, and spacing conventions. Get one great-looking template before building the commands.
Step 3 — Create your skills layer. Write the five skill files above. Start with copywriting and pricing — those two files do the most work. Point every command at the skills it needs before it writes anything. This is the step most people skip and then wonder why the output sounds generic.
Step 4 — Create your slash commands. In .claude/commands/, create a .md file for each workflow step. Write each as a numbered list: what to ask, what files to read, what to generate, where to save. Start with /new-demo-deck — it's the highest leverage command and the one you'll run most. Add /demo-proposal, /sow, /create-invoices, and /add-weekly-update in that order.
Step 5 — Set up your content folder. Establish a consistent structure before running any commands. Keep transcripts in content/calls/[client-slug]/. Keep deck configs in content/proposals/[client-slug]/. Keep SOWs and email drafts in the same client folder. Every command uses the same slug as its key so related files always group together.
Step 6 — Wire your tools.
Fireflies: Set up a FIREFLIES_API_KEY environment variable. Create a script at scripts/fetch-fireflies-transcripts.js that pulls call transcripts via the Fireflies GraphQL API and writes them to content/calls/[client-slug]/[YYYY-MM-DD]-[topic].md. Build the /new-demo-deck command to call this script automatically when it runs. Eventually you wire this so a qualified lead triggers the fetch without you running the command at all.
HubSpot: Set up a HUBSPOT_ACCESS_TOKEN environment variable. Create shared modules for deal lookup (finds by name or email), deal creation (creates if not found), and property updates (logs deck URLs, sales plans, invoice status back to the deal record). Build every command to call the lookup module first — if the deal exists, use it; if not, create it and continue. The deal becomes the single source of truth for every client.
Step 7 — Push to GitHub and deploy on Vercel. Connect your repository to Vercel for automatic deployment. Every time you generate a new deck and push to GitHub, Vercel redeploys in about 60 seconds. The link you sent the client updates automatically. Set up a custom domain so links read as proposals.yourcompany.com/[slug] instead of a Vercel URL.
Step 8 — Run your first real deck. Take a recent discovery call, drop the transcript into content/calls/[client-slug]/, and run /new-demo-deck. Answer the four questions it asks. Review the output. Edit the skills files based on what was off. Run it again on the next prospect. The first deck takes the most calibration — by the fifth, it writes itself.
Tips
Start with the skills layer before the commands. The most common mistake is building all the commands first and then wondering why the output doesn't sound right. Your copywriting rules and design system do more work than any individual command. Wire them first, point everything at them, and every command benefits immediately.
The Fireflies integration is the highest-leverage tool connection. Most of the time a deck sounds generic because it's not grounded in what the client actually said. When the command pulls the transcript automatically and uses the client's exact language in the deck, the output quality jumps immediately. Wire this before HubSpot.
Use the HubSpot deal as your state machine. Every command writes its output URL or artifact back to the deal. When you look at a deal in HubSpot, you can see the demo deck URL, the proposal URL, the SOW status, the invoices, and the latest sales plan all in one record. This also means any other agent you build can read from the same deal and pick up where this one left off.
Run the qualification scorecard before this pipeline starts. This system works best when a lead has already been scored and a HubSpot deal already exists before you run /new-demo-deck. Build or connect a separate qualification agent that listens to discovery calls, scores the lead, and creates the deal. Then this pipeline picks up from there. The handoff between the two agents is the deal record.
Every skills update compounds. When you change one line in proposal-copywriting.md, every future deck, proposal, SOW, and sales plan inherits it. This is the part that gets dramatically better over time. The system isn't just faster than manual — it gets more accurate to your voice and standards every time you use it and refine it.
Getting Started
Paste this file into Claude Code and say:
"Here is an idea file for a Claude Code slide deck agent system. I want to build this for my company. Ask me questions about my business, desired workflow, design system, and tooling before we start. My business: [describe what you do and who your clients are]. My tools: [confirm which of Fireflies/HubSpot/Vercel you have or want to set up]. Start by creating the folder structure, the initial skills files, and a Next.js app that can render proposal configs as web pages at /[slug]. Then help me build the /new-demo-deck command first."
The agent will scaffold the app, create the .claude/ folder structure, and stub out your first skills files with placeholder content for you to fill in. Fill in your actual copywriting rules and pricing before running your first real deck. Iterate on the skills layer from there — after three or four decks, you will have a system that sounds like you wrote everything yourself.