How dismissed.fyi got built
A distilled read of the direction behind the build. Not the code the agent wrote, but the account of how one person steered it from a broken icon to a live, honest product. Read it for the moves worth borrowing.
The route, plotted
Nine waypoints from a broken icon to made port. Hover any marker to read the direction that set it, and how it steered the build.
From a broken icon to a working board
The project already had a shape: a WordPress "hall of shame" that catalogs plugins for hijacking the admin screen with nag notices. Day one was not about scaffolding it. It was about making it honest. The builder opened not with a spec, but with a screenshot and a defect.
Can you fix the close/x icon in the admin notice recreations? Some of them are being displayed as a "no" badge.
That set the rhythm for the entire day: see it, screenshot it, direct the fix. The second heading pulled the thread that actually mattered. The board claimed a plugin had twenty-one notices, yet showed almost none of them.
Can you do some troubleshooting why some list a bunch of notices but there aren't anything visual collected… I would expect if there are 21 admin notices that there should be 21 catalogued artifacts. Maybe we need to improve the scanning/importing?
The agent traced it to the scan-and-import path. Notice what the builder did not do: stop and review the fix line by line. Instead they authorized scale. "Yes, kick off a fleet scan to backfill," and, once it was running, "Continue the backfill… run aggregate.py and wp dismissed import, then report top offenders." This is direction as delegation, not micromanagement. Set the objective, hand over the how.
Then the landmarks did the heavy lifting. Rather than describe what was broken, the builder handed over six screenshots across the session. Each one was a specific, unambiguous piece of evidence:
Landmarks two through five all pointed at a single truth. The scanner could find a notice in source but could not always render it, so the board was padding itself with reconstructed placeholders that looked broken. The builder's response is the most instructive moment of the day. It was not a bug report. It was a product decision:
I don't think it matters where it's captured or reconstructed. Can we remove the "reconstructed" label?
That single call collapsed a whole class of visual noise. Stop drawing a distinction the visitor does not care about. The day closed on polish, "We need a max, maybe top 20 on the homepage," and a fresh batch of URLs to fix. Board honest, board bounded.
What came next
The first heading of each session, read in order, is the project's biography: polish, then reach, then stewardship.
Fix the SPA analytics. "most of the traffic is only tracking the initial page load." Instrument the client-side route changes.
Explore a single-plugin deep audit. "what info can be gathered if we ran a target audit on an individual plugin." Probing the ceiling.
Backfill the top 20 wp.org plugins using the WP Beacon mirror as the source of truth.
Review coverage. "Which items still need to be backfilled?" Turning the board into a work-list.
Point it at the whole fleet. "target all 3000+ sites… hunt for any with remote-injection."
Close a privacy leak. "this artifact is both leaking user info and is a duplicate." A correctness-and-safety fix.
Answer a plugin author. a real email from a developer whose plugin was listed. The board meeting the people it names.
Audit the top 20 for accuracy. "make sure they're accurate and nothing is missing." Stewardship, not building.
What to borrow
Across twenty sessions the pattern holds, and the pattern is the transferable part. If you want to build this way, steering an agent toward a real, shipped product rather than a demo, these are the moves worth copying.
Sixty-two screenshots changed hands, almost never a prose description of a bug. A pasted image collapses a paragraph of explanation into a shared, unambiguous fact, and the agent can act on it at once.
The builder authorized a three-thousand-site scan without dictating the loop. Say what "done" looks like, let the agent choose the path, and review the outcome rather than every step.
The highest-leverage instruction all day was "drop a label," not "change this function." Spend your attention on what the visitor should see and let the agent own the implementation beneath it.
Eleven of twenty sessions opened straight into a saved workflow. Once a task is understood, capture it as a command, so the live conversation is freed for judgment calls instead of rote steps.
If you built this again
Knowing what the build learned, here is how you would steer a similar board from the start, detours removed. Copy a prompt and adapt it.
Front-loads the full spec and the scan-and-import pipeline the original build only discovered mid-stream, and asks for a plan before code.
Collapses the reconstructed-versus-captured detour that cost the original build most of a day.
Delegates scale and bounds the board in a single message, the way the original build eventually did.
This recap is the output of an editor pass over the project's agent transcripts. A deterministic extract (command-center flow) pulls the direction, the agent trace, and the embedded screenshots. A single model pass captions each image and writes the narrative you just read.
Every quoted heading is verbatim. Landmark captions were recovered from images embedded in the transcript, then summarized. The originals are never reproduced or shared.