Stop sending clients a spaghetti screenshot
A website rebuild proposal still opens with a screenshot of somebody's Figma, or worse, a box-and-arrow PNG that was already wrong when it was exported. The client nods. Six weeks later they ask why the form posts to a tool that was never on the slide.
Archify 2.16.0 shipped today. It is an agent skill that turns a rebuild into a verifiable HTML diagram. Creative Marketing AI should run it on the next kickoff, not next quarter. Architecture HTML is a deliverable. It ships with the repo. We do not leave kickoff without current-state and target-state files.
Version 2.16.0 landed Sunday August 30, 2026 at 06:17 AM CDT. The GitHub release is tt-a1i/archify v2.16.0. The repo, tt-a1i/archify, is also sitting on GitHub's daily trending list. Ignore the star count if you want. The changelog date is the fact that matters.
What it is
Archify is an agent skill for Cursor, Claude Code, Codex CLI, and OpenCode. You install it once, globally. This is a company tool, not a one-repo experiment.
```
npx skills add tt-a1i/archify -g
```
Cursor has a non-interactive variant in the README if you want the install logged and copy-mode explicit:
```
npx -y skills add tt-a1i/archify --skill archify --agent cursor --global --copy --yes
```
You can try it without installing:
```
npx skills use tt-a1i/archify@archify --agent codex
```
You do not need a repository. You can type a sentence.
```
Use Archify to draw: Browser -> API -> Redis cache -> PostgreSQL fallback.
```
If you do have a repo, you ask it to map from source. The project page shows a real trace of mco-org/mco at a pinned commit, with a checked JSON source next to the HTML. That is the point. The diagram is not a vibe. It is an artifact with a receipt.
The agent produces typed JSON. Archify compiles that JSON into self-contained HTML. Validation has to pass before the last good file is replaced. If the agent "fixes" a diagram by deleting labels, 2.16.0 is built to stop that habit. Semantic edge labels stay. Spacing gets repaired. That is the difference between a pretty picture and a map you can still read in week six.
Output types we will actually use: architecture, workflow, sequence, data-flow. Lifecycle exists. We will reach for it when a lead or a booking has wait states and retries, not as a default. Dark and light themes. Export copies PNG, including 1200x630 share cards for a README or a proposal. After you trace a route, you can export that path as its own card with the full diagram kept for context.
What 2.16.0 actually changed
Read the changelog, not a tweet.
Constraint-driven workflow compiler, schema v2. Columns stay logical ranks. One measured scene owns node placement, frames, routes, labels, diagnostics, and SVG serialization. That is the readable-v2 contract. Schema v1 workflows stay on byte-stable fixed-v1 geometry, so old files do not silently restyle. There is a migrate command that maps coordinates without wrecking the source. Adjacent-column capacity failures now report one cause instead of a pile of overlapping symptoms.
Viewer localization accepts en and zh-CN on meta.locale. It localizes chrome, legends, titles, accessibility copy. It does not translate the labels we authored. If we omit locale, English chrome stays. If a client ever needs a Chinese-language readout, we set the locale. We do not ask the agent to rewrite the diagram.
An optional update check can remind you a new stable exists. It does not download or install anything. You stay the person who updates. Set ARCHIFY_UPDATE_CHECK_DISABLED=1 if you do not want it talking to the network. Leave it on for the team skill install. Notify-only is the right default for a tool that sits in every rebuild repo.
The rest of the 2.16.0 release is hygiene: reproducible zip, owner review on automation, viewer dock not covering the legend, SVG markers that stay XML-safe. Useful. Not why we install it today. We install it because the compiler work is what keeps a six-week rebuild diagram from turning back into spaghetti.
Why a marketing agency should care
CMA rebuilds sites. We also wire forms, CRMs, Tara AI receptionists, analytics, pixels, and the forgotten Zapier. The failure mode is not "the homepage looked dated." It is "nobody agreed what talks to what."
A screenshot of the current WordPress admin is not a map. A Figma of the new homepage is not a map. A Miro board with twenty logos is not a map. The client needs to see DNS, CMS, forms, booking, chat, ads pixels, and the lead path from a phone call or a form submit to a human in the CRM.
I want three diagrams on every rebuild.
- Current state. What is actually live. DNS, CDN, CMS, forms, booking, chat, ads pixels, email, the forgotten Zapier, the Google Business Profile that nobody listed as a system. Architecture diagram. If we have the old codebase, generate from source. If we only have a WordPress login and a pile of plugins, write the inventory first, then generate. If it is not in the repo or in the written inventory, it does not go on the current-state map.
- Target state. What we are building. Fewer boxes. Named integrations. The managed platform, the form endpoint, Tara, analytics, redirects. Architecture diagram again. Same node IDs for systems that survive, so we can put current and target next to each other without a translator.
- Lead path. The sequence from a phone call or a form submit to a human in the CRM. Sequence diagram, not architecture. Browser or phone, vendor, calendar, SMS fallback, human handoff. The client should see where a missed call goes. If we cannot draw it, we do not know it.
Those three files are the kickoff. The 1200x630 share cards go on slide 3 of the proposal. The live HTML stays in the project folder. Named views. Route probes. A lens that compares backend and database roles. That is a meeting, not a PDF they skim.
It also keeps the agent honest. If the diagram is generated from the repo, a missing webhook shows up as a missing box. If we only have a verbal description, we still get a map we can argue with before anyone writes code.
Rebuild SOP: architecture HTML is a deliverable
Add this to the rebuild SOP. Not a suggestion. A gate.
Install. Global Archify skill on the machines that run rebuild kickoffs. Confirm with node archify/bin/archify.mjs doctor from the installed skill path, or the equivalent the README documents for the agent you use. If doctor fails, fix the install. Do not generate a "good enough" PNG in Figma as a fallback and call it Archify.
Inventory before generate. For current state, fill a one-page inventory: domain, DNS host, CMS, form handler, booking, phone, SMS, CRM, analytics, ads pixels, chat, email, file storage, the AI receptionist if present. Mark each row live, unused, or unknown. Unknown stays unknown. The agent does not get to guess "they probably have Mailchimp."
Generate current-state architecture. If a repo exists, open it and ask Archify to map the runtime path from the public homepage to the form handler. Scope: 8-12 core components, one primary path, external dependencies, trust boundaries. Supporting detail goes in cards, not extra edges. If no repo exists, feed the inventory as a description in the same shape as the README example.
Validate, then deliver. Do not screenshot the first HTML the agent dumps. Run validate. If it fails, read the receipt. Apply the supported fixes. Then deliver so the last good file is replaced only after checks pass. Check the HTML into the project folder as architecture-current.html next to architecture-current.json.
Generate target-state architecture. Same IDs for systems that remain. New IDs for systems we are adding. Do not redraw from scratch with different names for the same CRM. Check in architecture-target.html and .json.
Generate lead-path sequence. Phone missed-call, web form, and booking are three different sequences if they are three different paths. Start with the one this client actually lives on. If they live on missed calls, draw that first. Check in sequence-lead-path.html.
Share cards. Export 1200x630 for current, target, and the lead path. Those three images go in the proposal. They are not a substitute for the HTML. The HTML is what you open in the meeting.
Kickoff gate. We do not leave kickoff without current-state and target-state HTML. If the client cannot confirm a box, it stays off the current-state map and goes on a questions list. The questions list is a deliverable too.
During the build. When an integration changes, regenerate the target file. Do not edit the SVG by hand. Do not keep a parallel Miro. If someone needs a slide, they export from the HTML.
Handoff. The HTML files ship with the repo and with the client portal notes. A partner who opens architecture-target.html should be able to click the form box and see where it posts.
How I would use it this week
Install the skill in Cursor today. Global is fine.
Pick the next rebuild, even if kickoff is already scheduled. If you have the old codebase, open it and ask Archify to map the runtime path from the public homepage to the form handler. If you only have a WordPress login and a pile of plugins, write the description yourself, then generate.
Export two things on day one: the live HTML, checked into the project folder, and the 1200x630 share card, dropped on slide 3 of the proposal.
Do the same for the Tara AI receptionist path. Browser or phone, vendor, calendar, SMS fallback. Sequence diagram, not architecture. If we cannot draw the missed-call text-back, we do not know whether the receptionist add-on is wired or just licensed.
If the rebuild is already in flight, generate current and target anyway. Use them in the next status call. The first time a client clicks a route from "contact form" to "CRM," they will stop asking why the timeline includes "form endpoint work."
Meeting script, because the file is not the meeting
Open current-state HTML. Presentation stage if the room has a projector. Theme: light for a conference room, dark for a screenshare you control.
Focus the CMS box. Then the form box. Then the pixel box. Ask: "Is this still live?" If they say they turned off the old chat widget last year and it is still on the map, that is a finding. Take it off current state only after you confirm in the browser.
Switch to target-state HTML. Same IDs. Walk the boxes that disappear and the boxes that appear. The rebuild price lives in those deltas: redirects, form endpoint, receptionist, analytics. The homepage design is not the delta.
Switch to the lead-path sequence. Walk one real inquiry. "Someone calls after hours. What happens?" If the sequence ends at "voicemail" and we are selling Tara, the sequence is the reason. If it already ends at a human in the CRM, do not sell a duplicate path.
Send the HTML files after the call. Not a screenshot. The screenshot is how this whole mess started.
File naming and what not to invent
Project folder:
```
/rebuild/<client>/diagrams/architecture-current.html
/rebuild/<client>/diagrams/architecture-current.json
/rebuild/<client>/diagrams/architecture-target.html
/rebuild/<client>/diagrams/architecture-target.json
/rebuild/<client>/diagrams/sequence-lead-path.html
/rebuild/<client>/diagrams/sequence-lead-path.json
/rebuild/<client>/diagrams/share-cards/
```
JSON is the source. HTML is the compiled artifact. If they drift, regenerate from JSON. Do not patch the HTML.
I would not generate a diagram, screenshot it, and throw away the HTML. I would not let the agent invent boxes for tools the client "probably uses." I would not sell Archify as a design system. It is not. It is a verified map. I would not put deployment-ownership profile on a WordPress rebuild unless we explicitly need named owners and regions. That profile fails closed when those facts are missing. Most local rebuilds need current / target / lead path, not a cloud-ownership review.
Star counts will move. Vendors will copy the idea. The SOP still pays.
The lead
Clients do not buy wireframes of their own confusion. They buy a rebuild that names the parts and shows the path a lead takes.
Archify 2.16.0 is how the team draws that path in the same chat that writes the code. Install it. Run it on one live project before Friday. Put the HTML in the proposal.
If you want CMA to map your current site and the replacement before anyone picks a theme, that is the kickoff. Bring the domain and the tools you think you are using. We will find the ones you forgot. Start at the website rebuild path, or run the audit if you do not have a scoped rebuild yet.
