Command note: An alert nobody acts on is worse than no alert at all. Every alert you add trains the team to ignore the next one. Past a certain point, the real failure arrives looking like noise. Where this shows up: • A new-lead notification that fires for spam and real leads alike • A failed-workflow email that lands in an inbox nobody checks • A task created for every event, until the task list is unreadable • A Slack ping with no owner and no next step Do it now: 1) List every alert your accounts send — email, SMS, task, Slack. One line each. 2) Next to each, write who acts on it and what they do. No answer means it's noise. 3) Delete or mute anything with no owner. Don't archive it. Remove it. 4) For what remains, add the next step to the message itself, so the reader never has to guess. 5) Set a rule: nothing new gets added until something old is removed or justified. An alert is a request for action. If no one can say what action, it isn't an alert. It's clutter.

Every install of GHL Command now carries the guide library inside the product. Free or paid, same library. Say this to Claude: open the user guide It opens in your browser as a single page that works offline. Searchable job cards, plain-English guides, and copy-paste prompts with a Copy button on each one. Three moves to try it: 1) Say "open the user guide." 2) Type count in the search box. 3) Hit Copy on the prompt, paste it to Claude, and check the answer against your own account. That is the same on the free tier. Nothing there is held back for paid. Not every card has its guide written yet, and I would rather tell you that than let you find it. The ones that are written carry a "Proven live" mark, and that mark means something specific: the prompt was executed against a real account before we published it. It is enforced by the build, not by good intentions. Change a prompt without proving it live again and the release fails. The rest read "Coming in an update" and arrive on a normal restart. Nothing to reinstall, nothing to download, and no date I am going to promise you and then miss. There is also a new lesson in Start Here: "Get a verified answer in 10 seconds." It walks the whole thing end to end, using a real question a member got a bad answer to, and the three prompt rules that would have prevented it. Already installed? Fully quit Claude once and reopen it. Mac: Cmd+Q. Windows: right-click the tray icon and quit. On Claude Code: /mcp reconnect. Not installed yet? Some of the guides are open to everyone at ghlcommand.com/skills/. Read those first and decide from there. Tell me which guide you opened first.

I'm Glen, learning practical AI after years in contracting. Jerry's calendar note caught my attention because something unused can look harmless while still being connected to something important. I'd like to get better at asking ‘What still depends on this?’ before deciding an old item is ready to retire. On a job, the quiet-looking piece may still be doing work you can't see at first glance. What helps you identify those connections when reviewing a GHL account? I'm curious about a simple way to record where a calendar or form is used before changing anything.

Command note: "Done" is a feeling. A read-back is a fact. Before you tell a client something is finished, pull it back out of the system and read it as if you had never seen it. Same screen they will see, same data they will touch. What a read-back catches: • A field that saved blank because the label changed • A step that exists in the builder but never fires • A message that reads fine in the editor and wrong in the inbox • A setting you changed on the wrong sub-account Do it now: 1) Write the finish line — one sentence: "When this works, X happens for Y." 2) Re-open the thing fresh — a new tab, not the one you built it in. 3) Walk it as the end user — submit it, click it, receive it. 4) Compare to the finish line — word for word, not by feel. 5) Note what you checked — one line in the account notes, so the next person does not redo it. Building tells you what you intended. Reading it back tells you what you shipped.

I'm learning practical AI with a contractor background, and Jerry's rollback note interests me. I'd like to get better at describing a small change clearly enough that someone else could understand what happened. For a practice workflow, I can see the value of writing the intended result and the way back before changing anything. That feels familiar from planning a job: know what you're touching before you start. What do you keep in the shortest useful change note for a GHL workflow? I'd appreciate a plain example of the few details you need when you return to it later.