We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Build & ship · Directories and lists
Anyone can generate a list once. Keeping it accurate, navigable and worth linking to is the hard part, and it is where a directory earns its traffic. These capabilities are kind-aware: a directory Work gets every one of them, an awesome-repo Work gets all of them except head-to-head comparisons, a blog or website Work keeps the same items surface under another name — Posts and Pages, fed by this same pipeline — while comparisons, community pull-request intake, CSV import and source validation stay directory- and awesome-only, and a landing page is never cluttered with an Items tab it has no use for.
The moment a Work holds hundreds of items, the questions change. Which of these two should I pick? What is actually good here? Is this link still alive — and is it even the right link? Ever Works answers all three on a schedule, and writes every answer back into Git as YAML and Markdown you can read, diff and revert.
Taxonomy and collections are on from the first generation run: categories and tags are unconditional for directory and awesome-repo Works, and both collection switches ship defaulted to true, so the AI can assign a collection without you touching a setting. Comparisons, community pull requests and CSV/Excel import-export are the genuinely opt-in ones — each off per Work until you enable it. Source validation sits in between: it runs after a successful scheduled generation whether or not you give it a cadence of its own. Nothing here is a stub.
The generator groups items by their primary category, prioritises featured ones, and picks the best pair nobody has compared yet — pair keys are order-independent, so the same matchup is never generated twice. It researches the pair on the web through your search plugins, then runs two AI passes: one for structured data (summary, verdict, winner, and three to eight dimensions scored 1–10), one for the full Markdown article with a feature table, pros and cons, and its sources.
Turn on Extended Analysis and every comparison gains a second, deeper article across seven sections: feature breakdown, use-case fit, migration cost, technical deep-dive, pricing, ecosystem and future outlook. It is written to its own file so the standard article stays readable.
Collections are editorial groups that cut across categories — “Editor’s Picks”, “Best for Beginners”, “Top Open Source”. Give one a name, description, icon and a priority number that decides its order; the ID is slugified from the name for you. The AI assigns them during generation when a clear fit exists, and the collections_enabled website setting decides whether they appear on the deployed site. Both switches default to on — generate_collections in the Standard Pipeline plugin, collections_enabled in website settings — so you turn them off to curate by hand, not on to get started.
Every item belongs to exactly one category and may sit in at most one collection — those two are the hard rules. Tags are deliberately looser: the schema allows up to 50 per item, and the Standard Pipeline keeps generated tagging tight at one to three, which is what stops a directory turning into tag soup. It all lives as categories.yml, tags.yml and collections.yml in your data repository, so a rename is a commit.
Two independent verdicts per item, not one. Reachability catches the hard failures — a 404 or a 410 is broken, an ambiguous timeout stays unknown rather than crying wolf. Accuracy is the useful half: an AI pass decides whether the page is genuinely relevant, specific and official for that item, or merely generic, and stores its reasoning alongside a suggested replacement URL.
When a contributor opens a PR against your Work’s main repository, an hourly processor reads the diff, extracts structured items — name, description, source URL, category, tags — writes them into the data repository with a commit that links back to the PR, and comments on the thread listing what it added. It can close the PR automatically once the items land.
The History tab is an audit trail, not a metrics chart. Every generation run, item edit, taxonomy change, comparison and merged community PR records what was added, updated and removed — down to the field names that changed — with pagination and filters by activity type.
Export every item as CSV or XLSX, and import in bulk through a five-step wizard: upload, remap columns, preview per-row errors, choose a duplicate strategy, read the results. Both halves are off by default per Work — export_enabled, import_enabled, and an import_max_rows ceiling of 500 rows you can raise to 2,000 — so a public directory never hands over its whole dataset by accident.
Four screens, in order. Nothing below needs a config file or a support ticket.
Comparisons, collections and source checks all operate on items, so run the Work’s generation pipeline once before tuning anything here — that first run is also what populates categories, tags and collections. The comparison generator also wants a minimum of three items in a category — configurable from two to twenty — before it will produce a pair.
Open the Work and go to Items. Five tabs sit across the top: Browse Items, Categories, Tags, Collections and Source Health. Browse is a virtualised grid or list with search and a category filter, and each item’s menu offers Edit display, Edit content, Re-check source and Apply suggestion. Edit content opens that item’s long-form Markdown body in an editor with a Show preview toggle for live rendering, and saves it back as the item’s .md file in the data repository. On the add-item form, paste a source URL and press Retrieve to fetch the item’s details automatically, or capture a screenshot through your screenshot plugin.
Enable comparisons in the Work’s generator settings, then open Generator → Comparisons. Generate Next produces the single best remaining pair; Compare Items lets you name both sides yourself; Generate All walks the whole backlog behind a live progress bar you can stop at any point, and which stops itself after three consecutive errors. The AI Model panel overrides the provider and model for comparisons only.
A scheduler generates one comparison per enabled Work every six hours, and a separate hourly job runs the source validations that are due. On the Source Health tab, switch on Enable scheduled checks and pick a Check frequency — leave it unset and validation simply follows the Work’s main schedule. Community PR processing is its own per-Work switch — enable it and an hourly job picks up contributor pull requests, closing each one automatically once the items land unless you turn that off. The Pull requests tab is a separate surface: it lists the pull requests open on this Work’s repositories together with the agent’s review of each.
These are the boundaries we would rather you knew up front than discovered after building a process around them.
The buildable unit — websites, blogs, directories, landing pages — researched, written, coded, deployed, and kept fresh.
Learn more →Write copy, posts, listings, and pages at scale — with editorial voice, sources, and structure.
Learn more →Runs on a schedule. Keeps content current, code patched, dead links fixed — long after launch.
Learn more →Append your own instructions to every pipeline step, write the files that define an Agent, and package know-how as Skills — plain text you write, keep and can reverse.
Learn more →A generated Work is a real application — auth, payments, search, maps, 21 languages, SEO, feeds and a Git-based CMS — not a page-builder export.
Learn more →Bring a data repository, an awesome-list README, or repositories you already run under management — with config-as-code and a GitHub App.
Learn more →Describe what you want to build. Ever Works researches it, ships it, and keeps it improving — content and code, owned in your own Git.