What the agent does
The agent starts from the list, not from a search engine. awesome-selfhosted's README.md groups projects under ### headings, and the Analytics section is a flat list where each line carries the project's name and site, a one-line description, a link to its source code, its license and its platform in backticks: Matomo is GPL-3.0 PHP, Plausible Analytics is AGPL-3.0 Elixir, GoatCounter is EUPL-1.2 Go, Superset is Apache-2.0 Python. Some lines carry a ⚠ mark, which the list's legend defines as "depends on a proprietary service outside the user's control"; the agent keeps that flag in its notes. It reads the file over the web from the public repository, so the request needs no resources entry.
For each project with a GitHub source link, it reads the repository's public page and API: the date of the latest commit on the default branch, the latest release and its date, the star count and the license GitHub detects. It skips any project with no commit in the last 90 days and records why, so the list of skipped projects is as checkable as the list of kept ones. Where the license in the README and the one GitHub detects differ, it notes both instead of picking one.
For each project it keeps, it reads the README and recent release notes to find one specific feature that connects to your product, such as a ClickHouse backend, a public API for events or a plugin system, and writes a two-sentence note to the maintainer that names that feature. It adds one row per project to your Notion database through the Notion connection, filling only the columns that exist: the repository URL, license, stars, last release and the note.
Finally it sends you one Slack message with the database link, how many projects it added and how many it skipped for inactivity. It contacts no maintainer, opens no issue and stars no repository; the notes are drafts for a person to send.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "From https://github.com/awesome-selfhosted/awesome-selfhosted, take the projects in the Analytics section of README.md. For each one with a GitHub source repository, check the date of its latest commit on the default branch. For each with a commit in the last 90 days, add a row to the Notion database `Partnerships` with the repository URL, license, stars, latest release and its date, and a two-sentence partnership note to the maintainer that cites one specific feature from the project's README or release notes. Fill only existing columns; do not add or change columns or options. List the projects you skipped and why in your final answer. Then send me one Slack message with the database link and the counts. Do not contact any maintainer or act on any repository.",
"connections": [
"notion",
"slack"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is a set of new rows in your Notion database, one per active project in the category, each with the repository link, license, stars, latest release and a short note that cites a feature you can verify by following the link. The Slack message gives you the database link and the counts. The session's result lists every project in the section with its outcome: added, skipped for inactivity, skipped for having no GitHub repository, or flagged for a license mismatch.
The transcript keeps every page and API response the agent read and every Notion write, so a stale star count or a wrong release date can be traced to the moment it was read. Numbers like stars and release dates are as of the run; the transcript's timestamps say when that was.
Before anyone writes to a maintainer, a reviewer checks that each cited feature exists in the current release, that the note does not imply a relationship that does not exist, and that a project's license fits the partnership you have in mind. A copyleft license such as AGPL-3.0 changes what a commercial integration can look like, and the row puts it next to the note for that reason.
Run it on every Monday morning
A weekly schedule can rerun the same request so the database tracks the category as it changes: new projects added to the list, projects that went quiet, new releases. Ask in the prompt to update existing rows by repository URL instead of adding duplicates, and to mark rows whose project no longer qualifies.
To cover more categories, start one run per section heading, each with the same prompt and a different category name. Each run is independent, so a slow category does not hold up the others; a key runs at most max_concurrent sessions at once (4 by default).
The use case this job follows, with its automation and trigger: Draft outreach from your CRM.
Why run it on Rush?
This is research across dozens of repositories where every number has to be current and every claim has to point to a source. On Rush the agent reads the list, the repositories and their release notes in its own sandbox with a browser, and the trajectory keeps each page and API response it relied on, so a partnership note can be traced back to the release notes that justify it.
It also keeps the boundary clear. The run can write to your Notion and message you in Slack, through the two connections the request names, and it acts on no repository and sends nothing to a maintainer. A person decides who to contact, with the evidence in front of them.
Frequently asked questions
Why start from awesome-selfhosted instead of a GitHub search?
Because the list is curated: each entry is a working, self-hostable project with its license and platform recorded, and entries are reviewed when added. A search returns forks, abandoned experiments and demos. The agent still checks activity itself, since a listed project can go quiet after it was added.
Will it hit GitHub's rate limits?
One category is a few dozen repositories, which fits in unauthenticated public reads, and the agent can read the public repository pages when an API call is refused. For a whole list of several hundred categories, split the work into one run per category rather than one large run.
Can it find the maintainer's email?
It records where a maintainer asks to be contacted when the project says so publicly, such as a contact page, a sponsorship page or a SECURITY or CONTRIBUTING file. It does not scrape commit emails, and the prompt keeps it from contacting anyone. Respecting how maintainers ask to be reached is part of a good first note.