Firefly proposal template

Look at the deck

31 slides, one HTML file, no build step and no design tool. Everything still to be filled in is highlighted in orange.

Getting started, and how a proposal gets kicked off

Once per machine. In Finder, make a folder called ClaudeCode in your home folder — the one with your name on it (Go → Home, then File → New Folder). All your repos live there. Then in Terminal:

cd ~/ClaudeCode
git clone https://github.com/Mangrove-Web-Development/ff-proposal_template.git ff-proposal-template

The repo is private, so you need access to Mangrove-Web-Development on GitHub. A permissions error means that's missing — ask Maiya.

Before each new bid, pull so you start from the current version — git pull in that folder. That's the only time you need to pull; once you've copied it for a client, the copy is yours and no longer tracks the template.

To start a proposal, run the skill — /mg-new-client-proposal in a terminal. It sets up the repo and hosting, pulls in the RFP and the Granola call notes, seeds the compliance audit, and scaffolds the deck from this template. Tell it the client code, the name, and whether the bid is joint or Firefly solo.

/ff-proposal-deck covers just the deck — fill points, bid-mode edits, design constraints, verification.

Starting a bid	`/mg-new-client-proposal` — sets up repo, hosting, RFP intake, call notes, compliance audit, and scaffolds the deck from this template
In the deck	`/ff-proposal-deck` — the fill points and the rules of this deck

Both ship inside this repo at .claude/skills/, so they travel with every client copy and Claude Code picks them up automatically from whichever folder you're in.

The steps below are what those skills do. Worth reading once, and useful if you'd rather drive it yourself.

How to use it for a new proposal

Copy this folder and rename it for the client — never edit the template itself. Keep it beside the template in your repos directory, not in a synced folder:
cd ~/ClaudeCode
cp -R ff-proposal-template ff-client-CAF_0026
cd ff-client-CAF_0026 && rm -rf .git && git init
Name it ff-client-<CODE>_<NNNN>, using the same client code you use everywhere else for them — CAF_0026, SFZOO_0026. Ask Maiya if you don't know the code.
The rm -rf .git matters: without it the copy keeps the template's history and remote, so your first push would go to the template repo.
Put the RFP and Q&A in working/RFP-info/, and start the compliance audit early.
Confirm the bid type — Firefly × Mangrove, or Firefly alone. A scoping decision made before any copy gets 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.
Read the voice guide, then note only what differs for this client.
Fill in the 154 prompts in the deck. Edit the sentences around them; don't replace them.
Make the PDF — the script refuses to save a broken one.
Review, check, publish, tag the version you sent.

Full step-by-step, including the commands, is in README.md in the repo.

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 edits.

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. Plain text files in the repo.

working/voice/firefly.md

1. Base — not yet written

Firefly's own voice. This should be what every Firefly proposal starts from. It doesn't exist yet, which is the gap worth closing first.

working/voice/firefly-mangrove.md

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.

working/voice/mangrove.md

Reference

Mangrove's own voice. Useful partner context, and what the joint guide currently inherits from — but not the base for a Firefly bid.

working/voice-and-tone.md

This client's deltas

Their terms, their sensitivities, any register shift. Only what differs — don't rebuild the base voice per client.

Jen — two things here are yours to decide. First, these guides live in Mangrove's hub today; Firefly's own voice arguably belongs in Firefly infrastructure, along with the Cloudflare account and GitHub org (see SETUP-CLOUDFLARE.md). Second, the hierarchy is currently upside down. Following today's guide means reading Mangrove's first, which is backwards for a Firefly-led bid. It works — CAF was written that way and reads well — but the real fix is to write firefly.md as the base and let the joint guide shrink to only what a joint bid changes. Editing these is the intended route, not a workaround.

The stylesheet

There is no separate CSS file. The stylesheet is a <style> block at the top of proposal.html, and it is CAF's design system unchanged. 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 — 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 — the web only ever serves the published/ folder.

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/	Both skills, so they travel with a client copy — see that folder's README

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

Keep every repo in one flat directory — ~/ClaudeCode/ works well — with one folder per client bid alongside this template. Not on the Desktop, not in Downloads.

Never put a repo inside iCloud, Dropbox or Google Drive. Cloud sync rewrites files underneath git while it works, which corrupts the repo and loses commits — quietly, so you find out later. On macOS check ~/Documents specifically: if iCloud's Desktop & Documents sync is on, that folder is iCloud and looks no different in Finder. Pushed commits live on GitHub, which is the backup that matters.

Improving the template

Fixes here benefit every future bid, so please make them — in the template repo, not in a client copy. git push republishes this page and the deck within about a minute. Run ./make-pdf.sh --dry first to confirm the layout still holds.