ListRun, Agentwire, BlockDex and KitGrade
This issue shows how evidence-driven products turn directories, repositories, registries, and starter kits into artifacts builders can inspect and compare.
A directory submission, an agent-tool index, a registry claim, and a starter-kit score solve different search problems. Each product turns a messy source into something a builder can inspect, compare, or act on.
What these directories cover
These four products work across different kinds of evidence. Their pages turn repositories, signals, claims, and documentation into named artifacts that a reader can check.
---
ListRun
![]() | ListRun handles directory submissions and gives you a receipt for every submission. It fits a founder who needs a ranked list of places their product qualifies for, with a link and evidence attached to each result. The product also keeps crawler-generated filter combinations from reaching the database. This guard lowercases the user-agent string and checks it against the named crawler list. The broader crawl rules cover React Server Component payloads, comma-separated facets, pagination, free-text search, and claim paths. ListRun's own page presents the submission receipt as the artifact you receive after each directory is handled. The implementation detail matters because a robots file cannot stop a request that has already reached the application. ListRun places the refusal in middleware before the route renders, so the request does not perform a database read or produce the full page. The directory result and its supporting evidence remain the reader-facing output. |
export function isCrawler(
userAgent: string | null | undefined,
): boolean {
if (!userAgent) return false;
const ua = userAgent.toLowerCase();
return CRAWL_GUARD_AGENTS
.some((a) => ua.includes(a));
}
---
Agentwire
![]() | Agentwire is a repo index for shipped agent tooling, including MCP servers, coding-agent harnesses, and agent frameworks. It is for someone comparing projects and wanting the reason a repository appears in the index, rather than a category invented by the index itself. Each signal describes an outside affirmation or a property recorded from the repository. The function turns the signals attached to an item into one display label by walking a fixed strongest-first order. A curated list, a Hacker News thread, climbing velocity, and stars have their own meanings in the product's published taxonomy. If none of those signals is present, Agentwire uses the topic label. That small fallback keeps the index from pretending that every repository has the same kind of evidence. The page gives readers the repository title, owner, language, signals, lists, and Hacker News context that Agentwire recorded. The result is a browsable index where the source of the label stays visible beside the project. |
export function primarySignal(
signals: string[] | undefined,
): Signal {
const set = new Set(signals || []);
for (const s of SIGNAL_ORDER) {
if (set.has(s)) return s;
}
return 'topic';
}
---
BlockDex
![]() | BlockDex measures public registries and lets the person responsible for a registry prove ownership through a repository README. It suits a registry maintainer who wants a listing they can claim and an alert when the measured registry gains or loses items. The product page describes the claim as a proof step, not as a profile form. BlockDex derives the token from the registry key with SHA-256 and keeps the first twenty hexadecimal characters. The token is public because knowing it does not prove ownership. The proof comes from placing the exact value in the repository README that the registry record names. The claim flow reads the registry, finds its proof target, searches for the derived token, and only then records the claim through the database function. If the token is absent, BlockDex returns a not-proven result and does not write the claim. The reader gets a registry page, a claim state, and an alert path tied to a measured change. |
export function claimToken(key: string): string {
const h = createHash("sha256")
.update(
`compound-mention-v1:${PRODUCT_SLUG}:${key}`,
)
.digest("hex");
return `compound-${PRODUCT_SLUG}-${h.slice(0, 20)}`;
}
const by = await findProof(row, claimToken(key));
if (!by) {
return { ok: false, state: "not-proven" };
}
const state = await rpc<string>(
"blockdex_claim_apply",
{ p_subject: key, p_by: by, p_method: CLAIM_METHOD },
);
---
KitGrade
![]() | KitGrade scores SaaS starter kits on what a buyer can check before paying. It is for a developer choosing a starting point who wants the source repository, shipped capabilities, documentation depth, release history, licence, and support path recorded as evidence. The site labels hands-on testing separately from documentation review. Maintenance contributes thirty points and uses commit recency, tagged releases, and contributor count. Completeness contributes twenty-five points and checks the dependency manifest and file tree for open-source kits. Transparency contributes twenty points, including a public repository, a stated licence, readable pricing, release history, and documentation. KitGrade also records when documentation depth cannot be measured because navigation appears only after JavaScript runs. That limitation stays in the score instead of being converted into an assumption. The reader gets a score, the component breakdown, the evidence level, and the method used to produce them. |
{
key: 'maintenance',
label: 'Maintenance',
max: 30,
what: 'Whether the code is still moving',
how: [
'Recency of the last commit',
'Tagged releases in the last twelve months',
'Contributor count',
],
}
{
key: 'documentation',
label: 'Documentation',
max: 15,
what: 'Whether the documentation exists',
how: [
'A documentation site earns 7 points',
'Depth can add up to 8 more points',
'A long README earns 5 points',
],
}
---
Multiple shipped products, taken apart, few times a week. What each one does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.



