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 · Bring your own
You do not have to start from an empty prompt. Point Ever Works at a repository you already own and it works out what it is looking at: a structured data repo it can copy verbatim, a curated list it can use as research seeds, or a repo it should manage in place without moving a single file. The repositories, the YAML, and the history stay yours throughout — importing is how an existing project comes under management, not how it gets replaced.
Paste a URL and the analyzer decides which of these it is, then shows you the item and category counts before anything is created.
A repo carrying .works/works.yml and a data/ folder is copied item for item: every YAML item, its markdown body, categories.yml and tags.yml land in the new Work's own repositories. No AI is involved and nothing is rewritten — it is a faithful transfer, run in the background.
Any README with section headers and five or more list-style links qualifies. The source is treated as a list of URLs to research rather than text to copy: workers visit each link and write original descriptions, then keep discovering alternatives and newer projects. The default expansion target is 2.5x, so the source ends up as at most 40% of the finished collection.
Already run an Ever Works-format data repo? Link it and the platform manages it where it is — nothing is cloned or moved, and the Work is owned by the source repo's own account or org. It needs write access, because the platform commits updates, and it can create the missing markdown and website companion repos for you.
Three or four screens, from a URL to a live Work. Open /works/new?mode=import — the Import Existing card on the New Work page goes to the same place.
Paste a repository URL — GitHub, GitLab and Bitbucket URL formats are all parsed, with GitHub the fully wired path — or switch to My Repositories and pick one of yours. The analyzer detects the type, counts items and categories, checks whether the target slug is already taken and suggests alternatives, and — if the repo carries .works/works.yml — reads it so the form arrives pre-filled with the name, model, providers and cadence.
A data repository stops at Choose Import Method first: Import & Copy is always offered, and Link Existing appears alongside it only when the analyzer found write access. An awesome list skips that screen and lands straight on the form. There you name the Work and set Repository Owner — your personal account or one of your organizations — as the destination the new repositories are created under. Two toggles matter: Keep synchronized, offered on awesome imports, pulls future updates from the source, and Restore .works/works.yml settings applies the AI provider, model, schedule and related repositories from the file. An awesome source adds its own research controls here — expansion target, enrichment options, and whether to generate a fresh README repository or point back at the source — and the button reads Start Import & Research.
Data-repo and awesome imports return immediately with a history id and run as a background task with a two-hour ceiling, so you can close the tab; the Work moves through generating to generated, or to error with a typed code such as REPO_ACCESS_DENIED or UNSUPPORTED_FORMAT. Link Existing skips all of that and is marked generated on the spot.
You end with three repositories — data, markdown and website — and the usual workspace tabs: Items, Generator, Deploy, Knowledge Base, Tasks, Activity and Settings. Awesome imports also get a weekly sync schedule that opens a pull request rather than committing straight to the branch, so new upstream entries arrive as something you review.
Import is one door. These are the others — for repos that are not Works at all, for infrastructure-as-code, and for agents that never touch a UI.
Settings → GitHub App lists every installation of the Ever Works app with its account type, target and repository snapshot. Sync refreshes that snapshot from GitHub and Onboard turns one repository into a managed Work. Push events on a data repo can also re-render into the main repo within a minute — that instant-sync path is behind two feature flags and ships off by default.
Settings → Repositories holds account-level repos — URL, name, mount path, default branch, credential — that you attach to Agents so a session starts with the code already checked out. Stored .env files are listed as paths and sizes only; contents leave the API solely through an explicit, owner-gated Reveal, and a repo from a GitHub App installation imports in one click.
One YAML file at the data-repo root carries the name, initial prompt, model, website repo, deploy provider, schedule cadence and plugin choices — plus a per-kind spec for website, landing-page, blog, directory, awesome-repo and company. A published JSON Schema drives editor completion and validation stays advisory, so a schema complaint can never take a live site offline. Every successful generation writes the file back with your unknown fields preserved.
An agent can go from nothing to a deployed site in one call: POST /api/register-work with a repo URL and a GitHub token creates the account, reads the manifest, and returns a status URL and a subdomain. The CLI wraps the same endpoint as ever-works work register --repo …, an Idempotency-Key makes retries safe, and later pushes to the manifest reconcile on their own.
Settings → Data exports everything as versioned JSON — works, items, taxonomy, comparisons, schedules, advanced prompts, plugin settings — and imports it with a preview plus per-slug Skip, Overwrite or Rename. Secrets never travel: exports write MASKED: placeholders, and import skips any value still masked instead of writing a broken key.
Import is a dashboard-and-API feature today. The CLI covers manifest-driven registration but has no import command, and detection is deliberately narrow — a repo that is neither an Ever Works data repo nor a recognisable awesome list is refused with a reason rather than guessed at.
The buildable unit — websites, blogs, directories, landing pages — researched, written, coded, deployed, and kept fresh.
Learn more →Code and content both live in your own Git, and the platform is open source under AGPLv3 — nothing is locked in.
Learn more →Everything the dashboard does is an authenticated REST call — documented with OpenAPI, callable with an API key, and observable through signed webhooks.
Learn more →Create, generate, deploy and register Works, manage plugins and the knowledge base from your terminal — npm install -g ever-works-cli.
Learn more →The features that make a directory or an awesome list worth maintaining — comparison pages, editorial collections, a real taxonomy, link validation, community pull requests and a changelog.
Learn more →Run several organizations from one account, invite people into them, grant real per-Work roles — and get the security defaults underneath all of it.
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.