finding-ai-builders

name	finding-ai-builders
description	Use when the user asks to find true AI builders like a seed person, discover who to follow, monitor what builders are shipping, expand an AI builder watchlist, or separate builder signals from influencer noise.

Finding AI Builders

Overview

Track builders, not influencers. This skill starts from a seed such as a Peter baseline, finds people with public shipping behavior, and turns them into Sondar watchlist entries and STRIKE/WATCH/IGNORE/KILL decisions.

Core rule:

Public shipping behavior beats public opinion.

Inputs

Use this skill with a GitHub profile, repo, org, project URL, builder name, or category such as Codex, Claude Code, OpenClaw, MCP, agent skills, observability, local inference, or model routing.

For a Peter baseline, look for agent workbench tools, usage/cost surfaces, local/MCP bridges, personal data tooling, and OpenClaw-adjacent infrastructure.

GitHub CLI Preflight

Use gh CLI for GitHub retrieval. Do not substitute web search for GitHub retrieval unless gh is unavailable and the user accepts degraded evidence.

Run this before research:

which gh
gh --version
gh auth status

If which gh or gh --version fails, stop and report that GitHub CLI is missing. If gh auth status fails, public unauthenticated calls may still work, but state the authentication gap before continuing.

Default retrieval commands:

gh api users/<login>
gh repo list <login> --source --limit 80 --json nameWithOwner,description,stargazerCount,primaryLanguage,updatedAt,url
gh api users/<login>/starred --method GET -H Accept:application/vnd.github.star+json -f per_page=100
gh search repos "<query>" --sort updated --order desc --limit 30
gh repo view <owner>/<repo> --json nameWithOwner,description,stargazerCount,forkCount,issues,latestRelease,updatedAt,url

Workflow

1. Define the seed pattern in concrete artifacts: CLI, menu bar app, MCP server, plugin, router, dashboard, benchmark, skill, local agent, or data miner.
2. Pull behavior through gh first: profile, owned repos, releases, issues, PRs, README changes, starred repos, forks, and following. Use web search only for corroboration or missing context.
3. Expand from maintainers of repos the seed builds, stars, forks, or repeatedly touches. Keep low-follower builders when they ship specific active repos.
4. Reject influencers: no shipped artifacts, mostly commentary, generic lists, copied hype repos, or stars without issues/releases/maintainer history.
5. Map candidates into Sondar lanes: peter-style-agent-workbenches, local-first-personal-agent-os, agent-observability-review-safety, model-routing-cost-local-inference, or builder-signal-mining.
6. Update config/ai-builders.watchlist.yml with bounded builders, repos, external queries, pain keywords, commercial triggers, and action playbooks.
7. Run Sondar, then read the report and JSONL before claiming completion. Promote only when a 48-hour action exists.

Evidence Checklist

For each recommended builder, capture:

• GitHub URL and current profile context
• 2-5 active repos with source URLs, descriptions, updated dates, stars, issue/release activity
• why the builder matches the seed pattern
• what they are building now
• what pain they reveal: setup, auth, token cost, routing, review, safety, deployment, observability, or team workflow
• what to monitor next
• why they are not just an influencer

External-only evidence can corroborate a WATCH, but should not justify STRIKE without GitHub or buyer behavior.

Output Contract

Use this shape:

## Builder Pattern
[Seed pattern in 3-5 lines.]

## Primary Builders
| Builder | What they are building | Why monitor | Repos/signals |

## Watchlist Changes
- Thesis:
- Builders:
- Repos:
- Pain keywords:
- Commercial triggers:

## Sondar Run
- Command:
- Report:
- Decisions: STRIKE/WATCH/IGNORE/KILL

## First Actions
- STRIKE:
- WATCH:
- IGNORE/KILL:

Quality Gates

• Candidate list is builders with artifacts, not influencers with opinions.
• At least one expansion path uses seed-owned repos, starred repos, forks, releases, or issues.
• Every promoted repo maps to Sondar and an action playbook.
• WATCH entries include upgrade trigger and expiry.
• A real Sondar run happened, or the blocker is stated.

Common Mistakes

Mistake	Fix
Ranking by followers or stars.	Rank by public shipping behavior plus issue/release pain.
Adding every repo from a builder.	Add only thesis-matched repos with monitoring value.
Treating articles as demand.	Use articles as corroboration, not action evidence.
Calling a list monitoring.	Produce state, JSONL, report, and decisions.
Stopping at discovery.	Convert to STRIKE/WATCH/IGNORE/KILL with next action.

Example

Input: "Find real AI builders like https://github.com/steipete and monitor what they are building."

Good output defines the Peter baseline, checks owned and starred repos, identifies builders such as musistudio, mvanhorn, Yeachan-Heo, can1357, pwrdrvr, vivekchand, nk3750, obra, addyosmani, simonw, and antirez, updates config/ai-builders.watchlist.yml, runs Sondar, and reports decisions.