list a project

choose the path that matches how you want to submit it.

If the project lives in a repo, the agent path is the faster and less painful option. The manual form is still here as backup when you want to type everything yourself.

recommended
Claude CodeCodexCursor

Use a coding agent with the repo

Best when the project already exists locally. The agent can scan the repo for factual fields, ask you only for the story fields, and submit to the same review queue.

Pulls facts from the repo instead of making you retype them.
Keeps `whyILeft`, `whatWouldMakeItWork`, and `moat` in your own words.
Lets you preview the listing before anything gets submitted.
Create an afterlife listing for this repository.
Canonical guide, media rules, and submission details: https://tryafterlife.com/agents/list-a-project
Use the repo only for factual fields. Ask me directly for whyILeft, whatWouldMakeItWork, moat, intent, and the best proof of the product: a demo video, a few screenshots, or a live link.
If using screenshots, show both what the product promised and what was actually built: include one important landing-page section when helpful, plus real in-product screens like the dashboard, workflow, or result. Do not submit a marketing-only set when a real product UI exists, and use the clearest in-product screen first.
Keep JSON internal, show a plain-English preview, and submit only after I confirm.
Do not invent facts or upload source code or secrets.
backup

Fill out the form manually

Use this when you do not have the repo open locally or you just want the direct editor. It works, but it is more manual by design.

You type every field yourself instead of letting the repo fill the factual ones.
Best as a fallback for browser-only founders or quick manual edits.
Uses the same review flow once you submit.
Both paths end up in the same manual review queue. The difference is just how much typing you want to do yourself.