Halfway through the agency engagement, I realized I was building two things. The first was a landing page. The second was a system.
The landing page ships once. The system ships every time their team starts a new client project. One of these is obviously more valuable, and it isn't the one with the hero section.
The Accidental Product
It started with a CLAUDE.md file. I needed Claude Code to stop guessing the client's font stacks and start using Neue Haas Grotesk Display for headlines and Libre Franklin for body text. So I wrote a project CLAUDE.md with their design tokens, CSS prefix, and coding conventions.
Then I noticed I was explaining the same component patterns repeatedly — "build a hero section with a two-column desktop layout that stacks to mobile with the form prioritized." That became the /component skill.
Then I needed to scaffold a project, which became /new-project. And a pre-launch check, which became /preflight. And a way to track project progress, which became the adapted /playbook command.
By the time I looked up, I had 9 custom skills, 5 guides, 4 templates, and a 4-phase agency playbook. A full AI development package that any developer on their team could install in 10 minutes and use on every future engagement.
Two Deliverables Per Step, Scaled Up
The Playbook has this principle: every step produces two things. A process template (reusable instructions) and a project output (filled-in deliverable specific to this project).
The agency engagement followed the same pattern, just at a larger scale:
| Process (reusable) | Project (client-specific) |
|---|---|
| Global CLAUDE.md with coding standards | Client CLAUDE.md with Bootstrap 5 + jQuery conventions |
/component skill with 12 section types | Landing page built with /component patterns |
| Playbook with 4 agency phases | Client playbook-state.md tracking their project |
| Visual QA guide | 5 rounds of QA feedback from Nick and Ryan |
The reusable pieces outlive the project. That's the consulting leverage.
What Went Into the Package
30 files organized for two audiences:
For Nick (non-technical): OVERVIEW.md — what the package is, why it matters, and business impact. No terminal commands. No file paths. Written in "this saves your team time and money" language.
For Ryan (developer): README.md → guides/getting-started.md — installation in 10 minutes, first project scaffolded in 2 more, all 9 skills available immediately.
For the full team: guides/maintaining-the-system.md — how to create new skills, keep CLAUDE.md current, and improve the process after every project. This is the guide that makes the package self-sustaining instead of something that collects dust in a Slack thread.
The maintaining guide was the last thing I wrote and probably the most important. A toolkit that only the person who built it understands has a half-life measured in weeks.
The "Recommend But Don't Force" Lesson
The biggest efficiency gain for the client isn't in the package. It's migrating from Adobe XD to Figma for their design-to-code pipeline. I know this. The research is clear. Figma's MCP server eliminates the screenshot annotation workflow that ate five rounds of revision on this project alone.
But I can't make that decision for them. The dev lead was immediately on board. The design team — who are "very well-versed in XD" — need a separate conversation. Forcing a tool change onto a team that didn't ask for it is a great way to create a package nobody uses.
So the package ships with:
- Full XD fallback workflow (their current reality)
- Figma MCP setup guide (ready when they are)
- A recommendation framed as "here's what I'd suggest and why" not "you need to do this"
The Figma guide will either get used in a month or sit there for a year. Either way, it's there when the team is ready, and it doesn't gate anything else in the package.
The Bootstrap Decision
Ryan confirmed Bootstrap 5 over Slack. His exact reasoning: "We use jQuery for simpler syntax, not for Bootstrap's built-in features." This meant: Bootstrap 5 (no jQuery dependency) + jQuery loaded separately for their DOM shorthand patterns.
That one answer shaped the entire starter boilerplate, every /component output, the CLAUDE.md JavaScript section, and the /new-project scaffolding. Asking the right question before building saves more time than any skill or template.
I also learned their Bootstrap 4.4.1 dist was completely stock — no customizations. They were using Bootstrap as a CSS foundation and doing everything else custom. Good. Means the AI package doesn't need to account for framework modifications.
What I'd Do Differently
I'd build the CLAUDE.md and /new-project skill before starting the landing page build, not after. Extracting conventions after the fact is harder than establishing them upfront. The landing page would have gone faster if the design tokens and component patterns were defined in Session 1 instead of emerging organically over several sessions.
This is now explicit in the agency adaptation: Phase 1 (Design & Setup) comes before Phase 2 (Build), and /new-project is the first thing you run, not a retrospective artifact.
// The value equation:
// Landing page = one client, one project
// AI package = every client, every project
// Time spent: roughly equal
// ROI: not even close