Look at the deck
Everything still to be filled in is highlighted in orange. You edit it with Claude. Talk through what the copy should say, what to cut, what a number should be, and watch it change.
Open the template deck →First time: get the template on your machine
Accept the GitHub invite first. Open the repo in a browser and accept the invitation. Nothing below works until you have, and the error you'd get instead isn't helpful.
Then in Claude Code, say these in order:
| "make a new folder…" | "make a new folder locally for FF-Proposal-Template". Creates it in the right place |
| "pull this repo" | From inside that folder. Downloads the template |
| "set up localhost…" | "set up localhost so I can preview", then open the link in the little browser inside Claude, or any browser |
| "push" | When you've made a change |
That's the whole loop. No Terminal, no git commands, nothing to install.
To start a new proposal: run the skill
/ff-new-client-proposalThat's it. It asks you for the client code (e.g. CLIENT_0026;
ask Maiya if you don't know it), the client's name, the bid
type, and where the RFP is. Then it creates the project, copies this
template, sets up hosting, reads the RFP and your intake call notes, and starts the compliance
checklist.
No Terminal, no git, nothing to clone. Claude Code does all of it.
One skill does the whole thing. Scaffold, hosting, RFP intake, voice, the deck, the review board, lock-in. It ships inside this repo, so it travels with every client project and Claude Code finds it automatically. Nothing to install.
/mg-new-client-proposal is the sibling for Mangrove-led bids. Different deck,
different voice base. Don't reach for it on Firefly work.
Then the real work, which is the writing
The skill builds the scaffolding. What it can't do is the judgment:
| Bid type | A scoping call between Jen and Maiya |
| The copy | Everything marked {{like this}} in the deck |
| The numbers | Pricing, hours, timeline. Claude must never invent these |
| References | Real people, who need asking for this bid |
| The judgment | Reading it and deciding whether it sounds like Firefly |
You don't need to remember any commands. Just tell Claude what you want:
"make the PDF" · "publish this" · "show me the deck" · "what's still to fill in?" · "tag this as v1.0, I'm sending it today" · "strip the review widget before I send"
What the skill does, step by step
Worth reading once so you know what's happening. You don't need to do any of it by hand.
- Copies this template into a new project named for the client, like
ff-client-CLIENT_0026, from the code you gave it. - Reads the RFP and Q&A, files them in
working/RFP-info/, and seeds the compliance checklist from the RFP's own structure. - Confirms the bid type: Firefly × Mangrove, or Firefly alone. Decided before any copy is written, normally Jen and Maiya. Does the scope include design, web development or data architecture? If so it's joint. Don't guess. It changes the team slide, cover, pricing and voice guide.
- Puts the voice guides in place. You read them, and note what differs for this client.
- You fill in the prompts in the deck. This is the actual work. Edit the sentences around them; don't replace them.
- Ask Claude for the PDF. It checks the layout and refuses to save a broken one.
- Review, check, publish, tag the version you sent. All things you can ask for in words.
Full detail, including the commands if you ever want them, is in README.md.
Two kinds of bid
| FF × MG | Joint. How the deck ships. "Why this team" describes both firms and both logos appear on the cover and that slide. |
| FF only | Solo. Remove the Mangrove paragraph, both Mangrove logos, and
"with Mangrove Web" from the cover byline. DECK-GUIDE.md lists all six. |
If a third firm joins, the cover has a slot for them and you copy the Firefly team slide and case study as the pattern.
Voice & tone: editable, and meant to be edited
For a Firefly proposal, Firefly's voice is the base and Mangrove's is the partner layer, not the other way round. Click any filename to read it. To change one, tell Claude what you want different.
1. Base, scaffolded
Firefly's own voice, and what every Firefly proposal should start from. It holds only what could be sourced. The site devices, quoted verbatim, and the patterns in Firefly's own sent proposals. The unknowns are marked as gaps.
2. The joint layer
What changes on a joint FF × MG bid. Currently the only guide there is, and it's written as an overlay on Mangrove's, so it carries more than a joint layer should.
Reference
Mangrove's own voice. Useful partner context, and what the joint guide currently inherits from, though not the base for a Firefly bid.
This client's deltas
Their terms, their sensitivities, any register shift. Only what differs. Don't rebuild the base voice per client.
Every filename above is a link. Open it to read the guide. To change one, edit it with Claude rather than on GitHub. That keeps the local copy and the repo in step, and the same change can go through the deck at the same time.
If a link 404s, that's sign-in, not a broken link.
The repo is private, and GitHub answers 404 rather than "no access" so it doesn't reveal that
a private repo exists. Sign in as the account that got the invite, accepting it first if you
haven't. Or read them locally, in working/voice/ in your own copy.
Jen — filling the gaps in firefly.md is the
one thing worth doing here. It's scaffolded with everything that could be sourced and nothing that
couldn't; the unknowns are marked. The most useful is where Firefly's voice differs from
Mangrove's, which isn't recorded anywhere. The joint guide describes the blend, so the
distinct edges were lost. Until it's filled, the joint guide stands in and the hierarchy
stays inverted. Worth knowing: everything observed in it comes from one sent proposal, which was written
to a blended target — if any of it isn't Firefly, it comes out.
The stylesheet
There is no separate CSS file. The stylesheet is a <style>
block at the top of proposal.html, and it is the established Firefly design system. If you
want a value, read it out of the file rather than rebuilding it.
Near the top, :root holds every color and size as a named token, so change one
and it updates everywhere. --tscale is a single dial that scales all text at once.
At the very bottom, a block marked TEMPLATE-ONLY additions holds just the
fill-point highlighting; everything above it is the real design system.
Don't swap the fonts. Stabil Grotesk has no bold weight. That's deliberate, and emphasis is carried by color and size instead. Asking for bold produces a smeared fake. Monosten handles labels and figures.
What else is in the repo
These live in the repo, not on this site, because the web only ever serves the
published/ folder. The links open them on GitHub so you can read them;
to change one, tell Claude. A 404 means you're not signed in to GitHub, or haven't accepted the
invite. The files are also right there in your own copy.
| README.md | The full how-to for running a proposal, start to finish |
| DECK-GUIDE.md | Every component and class name, the type scale, how to edit a slide safely |
| PRE-SEND-CHECKLIST.md | Run before it goes out. Content, compliance, voice, build and release checks |
| SETUP-CLOUDFLARE.md | One-time hosting setup. Read the top first |
| SETUP-BUGHERD.md | One-time review-tool setup, so comments land on the exact element |
| make-pdf.sh | Renders and checks the PDF; refuses to save a broken one |
| check-ai-tells.sh | Flags em-dash density and stock AI phrasing |
| publish.sh | Manual deploy, for when a build is stuck |
| working/ | Never published. The RFP, budgets, call notes, drafts |
| .claude/skills/ | /ff-new-client-proposal, travelling with a client copy. No install |
The folder rule
Before saving a file, ask: would it be fine for the client, or anyone with the link, to open this?
- Yes →
published/, which is served on the web. - No →
working/, which never is.
A client deck also goes behind an unguessable path rather than at the root, because it's confidential. This template sits at its root because it isn't.
Where to keep these folders
Claude Code puts projects in the right place, so you mostly won't think about this. They live in one folder in your home folder, one per bid. Not the Desktop, not Downloads, which get tidied away by accident.
Never keep a project inside iCloud, Dropbox or Google Drive. They rewrite files while syncing, which corrupts the project's history and loses work, quietly and so you find out much later. On a Mac check Documents specifically. If iCloud's "Desktop & Documents Folders" setting is on, that folder is iCloud and Finder gives no hint. Everything Claude pushes to GitHub is the backup that matters.
Improving the template
Fixes here benefit every future bid, so please make them, though in the template itself and not in a client copy.
Ask Claude to "check the layout still works" before you're done. It renders the deck and looks for broken pages, slides that aren't 16:9, and content that has overflowed, all things that are easy to cause and hard to spot by scrolling. Then ask it to "push this", and the change is live here in about a minute.