ASTRO SITE PLAYBOOK
Astro Site Playbook helps agencies introduce Astro without inventing a new delivery method from scratch, particularly teams adding it alongside an established WordPress practice. It connects a working starter, shared conventions, coding agent instructions and quality checks so each project does not have to establish them again.
It gives your team another appropriate foundation to choose from, without making the first suitable client project fund the agency's Astro learning curve.
THE GAP AFTER DAY ONE
A starter can provide components and a working first page. It does not necessarily tell the next developer why those choices were made, when they can change or what must be checked before the site ships.
Without an agreed method, each Astro project accumulates its own prompts, naming conventions and implementation decisions. Repeated setup erodes project margin, while senior developers carry the resulting review and rework.
The problem is not a lack of boilerplate. It is the absence of a delivery system around it.
Your team can decide when Astro fits, estimate from a known foundation, deliver against shared checks and hand over the result without relying on the person who introduced it.
WHERE ASTRO FITS
Astro is well suited to content-led marketing, editorial, brochure, portfolio and documentation sites where fast pages and a static-first architecture are useful.
WordPress remains the right choice where its editing experience, plugin ecosystem or established client workflow is the better fit. The decision should be made project by project.
Astro Site Playbook gives your agency a prepared way to choose Astro when it fits, without inventing the delivery approach during the client engagement.
ONE SYSTEM
A production-minded Astro starter with structured content, semantic design tokens, accessible components, metadata and form foundations represented in working code.
One human-readable source of truth separates enduring principles, agency conventions and replaceable provider defaults. The next developer can see not just what the system does, but why.
Coding agents are AI tools that can inspect a repository, make changes and run its checks. Their instructions point back to the team's playbook, so developers and agents work from the same decisions.
Automated checks cover builds, design tokens, colour contrast, metadata, forms and accessibility. Manual checks remain explicit where automation cannot provide enough evidence.
The result is not that every website looks the same. It is that the parts clients should never have to worry about are handled consistently.
SEE IT, THEN ADAPT IT
Version 2.0.5 is the final public release, available under the MIT licence. Its documentation, test suite, release history and CI results remain public, so you can see how the parts fit together and how the system is verified.
It is no longer maintained. Treat it as a worked example of the approach, not a foundation for new client projects.
Most agencies already have useful practices spread across repositories, review comments and individual experience. I turn that knowledge into an agency-specific playbook, working foundation, agent adapters and quality checks.
The reference release shows the approach. The engagement turns your existing practice into an agreed, implemented and tested way of working, drawing on the wider set of coding agent skills I now use for Astro builds.
HOW IT WORKS
I use coding agents to accelerate analysis and implementation. I remain responsible for the questions asked, decisions made and evidence that the finished system works.
I review representative repositories and recurring delivery problems. Conversations with the team expose the rules that have never been written down.
We distinguish practices worth standardising from historical accidents, then agree what is shared and what remains project-specific.
I produce the agreed playbook, working foundation, agent adapters and quality checks.
We apply the system to a representative project and resolve any ambiguity. Your team receives the system, its reasoning and the process for changing it without me.
A GOOD FIT
Astro Site Playbook is likely to fit if:
It is not intended for highly stateful applications, authenticated dashboards, real-time collaboration products or projects that require a client-framework architecture throughout.
I will say so if Astro or this playbook is the wrong foundation for the work.
COMMON QUESTIONS
No. Version 2.0.5 is the final public release, and the repository is archived as a reference. Its functionality now forms part of a wider set of coding agent skills I use for Astro builds, and engagements draw on those rather than on the archived release.
No. We identify which principles protect the outcome, which conventions help your team and which defaults should be replaced. Consequential departures are documented rather than hidden.
Yes. The included providers are replaceable reference implementations. Hosting, forms, email delivery and content services can follow your existing stack and the project.
Before any private material is inspected, we agree which tools may be used, what repository access is required and the boundaries for handling the data. The workflow follows the confidentiality requirements of the agency and its clients rather than assuming every repository can be treated in the same way.
Yes. I can adapt the delivery system, contribute to the first implementation or take responsibility for both. The scope will make clear which role I am taking.
Yes. The engagement can be delivered remotely across the UK and internationally. On-site work is usually in London and the South East, with other locations considered by arrangement.
START WITH WHAT YOU HAVE
Tell me how your agency builds sites now, which project you think might suit Astro and what is making adoption uncertain. In half an hour, I will tell you what an agency-specific playbook would need to cover, or whether Astro is the wrong choice.
Half an hour, no charge. No sales sequence afterwards.