Build Log

Most people push-prompt. There's a better way.

At my day job, I work on a small team at a university library that hosts AI sessions for staff, helping them find ways to use AI tools in their everyday work. This was our second session in the series, focused on prompt engineering.

The session was entry-level, built around giving people a way to prompt that they could use the next day. Here's what we covered.

Push vs. Pull: Two Ways to Prompt

While researching for this session, I came across the terms "push" and "pull" prompting. Turns out I'd been doing both without realizing there were names for them. Once I saw the distinction, it made it a lot easier to explain to others.

Most people "push" prompt. They figure out exactly what they need, write it all out, and hand it over. That works for simple tasks.

But for anything complex or fuzzy, there's a better approach: pull prompting.

Instead of giving the AI turn-by-turn directions, you give it the destination and let it drive. The key sentence:

"Act as an expert [role]. I need [outcome]. Ask me all the questions you need to create this for me."

Two things happen at once: you give it an expert role and let it drive the information gathering instead of guessing what to include.

Then you just answer the questions. It asks about things you might not have thought to mention. It figures out what to ask, and you just answer. You still make the calls.

When to use which:

If you can describe exactly what you want in one sentence, push. If you'd need a whole paragraph to explain it, pull.

We also covered the 4-Part Prompt Formula

Every good prompt has four ingredients:

1. Role: Tell the AI who to be. "Act as an experienced academic librarian" narrows the output. Without it, you get the average of everything.
2. Context: Give it the background. The more relevant detail, the more relevant the response.
3. Command: Be explicit. Not "write something about this." Say "write a 3-sentence reply declining this request politely and suggesting an alternative."
4. Format: Tell it how you want the answer. Bullet points, a table, a short paragraph. If you don't specify format, it defaults to long, because long looks thorough.

The takeaway I left them with:

Pick one task you do every week that feels repetitive. A recurring email, a meeting summary, a document you always have to read and pull key points from. Try push first. Then try pull. See which one fits.

AI tools are first-draft machines. You are the editor. That doesn't change.

Spent the evening auditing and overhauling my entire agent ecosystem against Anthropic's published best practices. 20 agents, all getting smarter.

The process: kicked off a Research agent to pull every relevant Anthropic engineering post (Building Effective Agents, Context Engineering, Writing Tools for Agents, Effective Harnesses). Then ran parallel Explore agents to map every skill file and context doc in the system. Fed all of that into a Plan agent to design the changes.

Four phases shipped:

1. Progressive disclosure for the four largest context docs. Tank, Keeper, Link, and Forge were loading 400-900 lines of context on every invocation. Now they load a slim core (infrastructure overview, key IPs, safety rules) and pull in reference files only when the task actually needs them. Troubleshooting docs, runbooks, and architecture patterns stay out of context until relevant.

2. Standard error handling across all 20 agents. Three rules: retry once then report, never claim success if something errored, and if blocked, say what worked and what didn't. Simple, but none of them had it before.

3. Pipeline handoff contract for the prospect workflow. Radar, Signal, Ghost, and Morpheus now share a formal data contract defining exactly what fields pass between each stage. No more informal handoffs.

4. State persistence for infrastructure agents. Tank and Keeper now write checkpoints during multi-step work so they can resume if a session dies mid-task instead of starting over.

The whole thing ran in about an hour. Plan mode kept the scope tight. Three background agents split the context docs in parallel while I handled the other phases. No content lost, just reorganized for efficiency.

The key insight from Anthropic's docs: context is a finite resource with diminishing returns. Every line your agent loads that it doesn't need is stealing attention from the lines it does.

Ran the new pipeline on 8 Finger Lakes wineries and breweries tonight. Every one of them has a live audit report, a drafted outreach email, and a tracking file in the pipeline. Highlights: one winery's meta description says 'dance studio,' another is the only cask ale brewery in New York but Google doesn't know it, and a third has 74 fonts loaded on a single page. The Finger Lakes wine trail deserves better websites.

Spent the afternoon hardening the new production server. SSH lockdown, automated offsite backups with encryption, OS-level security updates on autopilot, WAF verified active, HSTS on all domains, database tuned, and external uptime monitoring watching everything at 5-minute intervals. Also wired up server-side resource alerts. Went from 'Plesk is installed' to 'production-ready' in one session. The old CentOS box is looking more disposable by the day.

Built a one-command prospect audit system using Claude Code. I type /radar and a domain, and about 5 minutes later there's a branded, client-ready report page live on my website. Here's what happens under the hood.

4 agents, each with a Matrix codename:

1. Radar (the orchestrator) coordinates everything. It receives the target domain, dispatches the two scanning agents in parallel, collects their results, generates the report, builds the site, deploys it, and verifies it's live.

2. Niobe (SEO audit) runs niobe-scan.py, a Python scanner I wrote that checks 7 categories: technical SEO, on-page SEO, performance, structured data, security headers, content freshness, and local SEO. It crawls the site, pulls headers, checks SSL certs, parses meta tags, tests page speed, looks for schema markup. Outputs structured JSON with scores and findings.

3. Seer (brand positioning audit) runs seer-scan.py, another Python scanner that evaluates 4 categories: first impression, messaging and voice, digital footprint, and brand cohesion. It analyzes the homepage hero, CTA placement, color palette, navigation complexity, and does web searches for competitive context. Also outputs structured JSON.

4. Keeper (production deployment) handles the GoDaddy VPS. After the report page is generated, the Astro site gets built and rsync'd to the production server where brooksnewmedia.com is hosted.

The custom scripts:

• niobe-scan.py: Python script with UA rotation, rate limiting, and Cloudflare detection. Checks SSL, headers, meta tags, structured data, sitemap, robots.txt, page speed, content dates, NAP consistency, Google Business Profile.
• seer-scan.py: Similar architecture but focused on brand signals. Analyzes hero content, CTA presence, color count, font consistency, nav complexity, social presence, review platforms.

Both scripts output JSON that Claude Code's agents parse and interpret. The agents add the qualitative analysis: what the numbers mean, what to prioritize, how to pitch the fix.

The report itself is an Astro page generated from a template, styled to match my Brooks New Media site. It's a hidden page (not in navigation), so I can share the direct URL with the prospect as a leave-behind. Letter grades, color-coded score cards, a merged top-10 priority list, and a custom 3-month "here's how we'd fix this" pitch at the bottom.

The whole thing runs from Claude Code in my terminal. One command, four agents, two Python scanners, one Astro template, one production deploy.