Build Log

Planning a 3-day bikepacking trip through the Finger Lakes National Forest. 62 miles on the Giant Revolt Advanced 2, two nights of dispersed camping, mostly gravel and forest roads.

Built a /bikepack agent to manage gear inventory, trip planning, and packing lists. It pulls order data from email, tracks everything in a structured JSON file, and knows the bike fleet.

Then published the full trip page on The Stack. Interactive Leaflet map with GPX routes for each day, color-coded with tab switching. Day cards with elevation gain, weather forecast, terrain type, sunrise/sunset, campsite pins linked to Google Maps, and downloadable GPX files. Gear broken into bike setup, camp gear, ride day kit, repair kit, clothing, and food. Meal plan mapped per day. Full packing breakdown by bag zone. Emergency contacts and water sources. Print-friendly CSS so I can check items off on paper.

Photos from previous rides used as low-opacity tile backgrounds on each section. Everything deploys to Zion with one command. The whole thing went from Gmail order scraping to live page in one evening session.

Built a research agent inside Claude Code that doesn't make things up. Based it directly on Anthropic's guide to reducing hallucinations: give the model permission to say "I don't know," extract direct quotes before analyzing, cite every claim inline, and retract anything it can't source. Layered chain-of-thought verification and confidence levels on top.

For search, it runs against my self-hosted SearXNG instance, a metasearch engine that aggregates Bing, DuckDuckGo, Brave, Reddit, and Startpage. Results get deduped and ranked by how many engines found each URL. Higher engine count means higher trust. No single search provider dependency.

The agent is a slash command in Claude Code. Type /research, ask a question, and it gathers evidence, reads the actual pages, builds a sourced report, and auto-publishes to GitHub. Run it with Claude Code's looping feature for ongoing stories and it keeps updating the report as new information drops.

Example: when LiteLLM got hit with a supply chain attack last week, /research tracked the story across 70+ outlets over four days, from the initial PyPI compromise through the Telnyx cascade, with every claim cited and verified.

People ask how The Stack works. Here is the full breakdown.

What it is: A microblog built with Astro. No CMS, no database, no admin panel. Every post is a single markdown file with frontmatter (date, text, tags). The site is static HTML deployed to a self-hosted server.

How posts get published: I type a slash command in Claude Code. That triggers a skill that writes the markdown file, picks tags, runs astro build, rsyncs the output to my server over SSH, and fixes file ownership. One command, zero browser tabs.

The stack:

• Astro 5 (static site generator)
• Marked (markdown rendering)
• rsync over SSH (deploy)
• Hetzner VPS running Apache (hosting)
• Claude Code skill (publishing workflow)

How the skill works: Claude Code supports custom skills, which are reusable prompt templates that can be triggered with a slash command. The /stack skill takes my raw text, cleans it up, generates the next sequential filename, writes the markdown, runs the deploy script, then commits and pushes to git. The deploy script builds the Astro site locally, rsyncs the dist/ folder to the server, and sets correct ownership.

Why this approach: I wanted to post without friction. A CMS adds login screens, update prompts, plugin conflicts. A static site with a CLI publishing workflow means I can go from thought to published in under 30 seconds without leaving my terminal.

How to build your own: I open sourced the whole thing as a GitHub template. Clone it, replace the placeholders, deploy. Full setup guide included: server prep, SSH keys, deploy script, Claude Code skill.

No accounts to manage. No tokens expiring. No vendor lock-in. Just markdown, a build step, and a server you control.

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.