for coding agents

list this project on afterlife.

Use the short starter prompt below when you are inside the project repo. When an agent opens this URL, the rest of this page is the canonical spec: what to extract from the repo, what to ask the founder directly, how to handle screenshots and video, and how to submit without uploading code.

Starter Prompt

Keep this short. This URL is the full spec.

canonical url

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.

When Browsing This URL

Agents should treat the sections below as the source of truth. The starter prompt above only launches the task from inside a repo. Once you are on this page, follow this page directly instead of treating the starter prompt as a second nested prompt.

Canonical Flow

Inspect the repo

Read the README, package files, git history, and any public demo links. Extract only what the repo actually supports.

Draft the factual fields

Fill name, one-liner, description, stack, tags, repo URL, last commit date, commit count, stage, and category from evidence.

Ask the founder questions

Do not draft why they stopped, what would make it work, moat, or intent. Ask those questions directly and use the founder's own wording.

Choose the artifact path

Ask one simple media question: what is the best proof of the product right now, a Loom or YouTube link, a few real screenshots, or a live demo URL? If the founder shares screenshots and the product has both a landing page and a real app, include both: one important landing-page section to explain the promise, plus the core in-product screens that prove what was actually built. Keep them in journey order and use the strongest in-product screen as the cover unless the landing page is itself the product.

Preview before submit

Keep JSON internal. Show a plain-English preview of the listing and only submit after the founder confirms it.

Submit and hand off

Submit through the API, then return the project URL and claim URL so the founder can sign in later and open the prefilled editor in the app.

Interactive Flow

story

The agent should ask the founder the real reason the project stalled and what would make it work now. These answers should come from the founder, not from generated copy.

screenshots

If the founder does not already have a video, the agent should ask for a lightweight mixed set that proves both the promise and the substance: one important landing-page section if it helps explain the audience or pitch, plus one or more real in-product screens such as the dashboard, workflow, or result state. Two to four screens is enough. Most of them should be real product surfaces when a real product exists. Upload local files through afterlife and avoid random settings routes or tall full-page browser captures when a focused viewport shot would be clearer.

video

The agent should prefer a real Loom or screen recording when one already exists. If it does not, screenshots are enough for the first listing. A Remotion export can exist later as a teaser, but it should not be presented as the real demo or block the initial listing.

What Media Should Prove

Afterlife is not a gallery of ideas. The media should help a buyer, operator, or collaborator answer three questions quickly: what did this product promise, what real product exists already, and what would they actually inherit?

If the repo has both a marketing site and a real product UI, the default screenshot mix should include both. Show one important landing-page section to explain positioning, then show the real product screens that prove the thing was actually built.

Preferred order: strongest in-product screen first as the cover, then the core workflow or output, then the most useful landing-page section, then one extra proof screen if needed.

Media Upload API

If the coding agent has local screenshot files, upload them first and then place the returned URLs intolisting.screenshotUrlsin the same order the founder wants them shown. If there is both a landing page and a real product UI, include both, but put the strongest in-product screen first because it becomes the cover. Do not require the founder to manually host images elsewhere just to submit a listing.

POST https://tryafterlife.com/api/uploads/images
Content-Type: multipart/form-data

curl -X POST https://tryafterlife.com/api/uploads/images \
  -F "file=@/absolute/path/screen-1.png"

// Response:
// { "url": "https://.../screen-1.png", "objectKey": "listings/screenshots/..." }

// Use the returned url inside listing.screenshotUrls.
// The web form at https://tryafterlife.com/list/manual can also upload image files directly.

Submission API

This is the most reliable path for terminal agents. Usemode: "submit"when the founder is ready for review, ormode: "draft"to save work without submitting. If the request is not authenticated, include a top-levelfounderobject with the founder's name and email.

POST https://tryafterlife.com/api/listings
Content-Type: application/json

{
  "mode": "submit",
  "founder": {
    "name": "Founder Name",
    "email": "founder@example.com",
    "linkedinUrl": "https://linkedin.com/in/founder"
  },
  "listing": {
    "name": "Project name",
    "oneLiner": "One sentence on what it does.",
    "description": "What the product did, who it was for, and how far it got.",
    "whyILeft": "Why the founder stopped and what actually killed momentum.",
    "whatWouldMakeItWork": "What this needs from the next person to work.",
    "moat": "Optional. What is hard to replicate.",
    "stack": ["Next.js", "Convex"],
    "repoUrl": "https://github.com/owner/repo",
    "lastCommitDate": "2026-03-01",
    "commitCount": 182,
    "videoUrl": "https://www.loom.com/share/...",
    "screenshotUrls": ["https://.../screen-1.png"],
    "demoUrl": "https://product.example.com",
    "archivedUrl": "https://web.archive.org/...",
    "category": "saas",
    "tags": ["voice", "healthcare"],
    "stage": "mvp",
    "revenue": "pre-revenue",
    "age": "8 months",
    "intent": ["open_to_anything"],
    "attestationAccepted": true
  }
}

// The response always includes:
// { "projectUrl": "https://tryafterlife.com/p/project-name" }
//
// If the founder is not already signed in, the response also includes:
// { "claimUrl": "https://tryafterlife.com/claim/project-name" }