Contribute to Foundation Base

Publish a working foundation.

Submit a local-first app foundation that others can inspect, run, fork, remix, and customize with their AI coding agent.

View foundation standard
Local-firstAgent-readySecurity reviewedHuman reviewedMIT preferred

How publishing works

A foundation should arrive as a complete, inspectable software package, not a loose idea or a partial demo.

1

Start from the submission kit

Use templates/foundation-submission to get the required manifest shape, screenshot structure, local-first patterns, and review path.

2

Build a real demo

Place the working app in app/demo/<slug>/. It should include seeded data, a meaningful workflow, state changes, and persistence across reloads.

3

Describe the foundation

Complete foundationbase.json with title, summary, category, stack, tags, license, screenshots, setup steps, and origin status.

4

Run the checks

Validate the manifest, typecheck the app, and confirm the demo builds locally.

5

Submit for review

Send the zipped demo package for now. When the public repository is ready, the same package should move to pull requests.

What every foundation needs

Review starts faster when the package is complete, honest, and easy to run from a clean checkout.

Working demo

app/demo/<slug>/ with layout.tsx, page.tsx, and the working app component.

Manifest

foundationbase.json with listing metadata, license, stack, setup steps, screenshots, and origin status.

Local screenshots

Screenshots must be local files that match the real demo.

Seeded data

The app should show a useful workflow immediately.

Persistent local state

Changes should survive reloads through approved local-first storage patterns.

Origin declaration

Clearly mark whether the foundation is original, a remix, or a fork.

Setup notes

Include the exact commands needed to run the foundation locally.

Before submitting

Check your foundation before submitting

If these fail, fix the package before submitting. Passing checks does not guarantee publication, but it makes the foundation reviewable.

npm run check-submission -- <slug> --require-manifest npm run typecheck npm run build

Security model

Security checks come first

Every contribution starts as untrusted code. Automated checks catch obvious risks first, then a human reviewer confirms that the app works and matches its listing.

1

No network calls

Catalog demos stay local-first. Anything that phones home is rejected.

2

No code injection

Unsafe HTML and dynamic code execution are blocked before human review.

3

No cookies or hidden storage

State should be inspectable and use Foundation Base approved local-first patterns.

4

No external resources

Assets, screenshots, and demo code must ship inside the foundation package.

5

No secrets or environment variables

A foundation should run from a fresh download without keys, accounts, or private config.

6

No external screenshot URLs

Reviewers need local proof that matches the submitted app.

Security reviewed does not remove all risk. It means the foundation has passed Foundation Base’s current review standard.

What we are defending against

Foundation Base treats submitted software as untrusted until it passes automated checks and human review.

Malicious code

A submitted foundation may intentionally try to run unsafe code.

Hidden network behavior

A demo may try to send data to an outside server.

Supply-chain risk

A dependency or install script may do something unexpected.

Fake listings

Screenshots, descriptions, or manifests may not match the real demo.

Agent manipulation

A project may include instructions that trick AI coding agents into making unsafe changes.

Review status levels

Review status should be explicit. Nothing should auto-publish in V1; all submissions require manual approval.

1

Submitted

Received but not public.

2

Checks Passed

Manifest validated, obvious banned patterns rejected, and local build confirmed.

3

Human Reviewed

A reviewer inspected the demo, code, screenshots, manifest, and license.

4

Agent-Ready Reviewed

The /agent package exists and matches the actual project.

5

Published Foundation

The foundation is accepted into the public library.

Agent-ready packaging

Make it easy for AI agents to understand

A strong foundation should include an /agent folder so Claude Code, Codex, Cursor, and other coding agents can understand the project quickly and modify it safely.

/agent/START_HERE.md/agent/PROJECT_MAP.md/agent/RULES.md/agent/RECIPES.md/agent/TESTS.md/agent/DEPLOY.md/agent/agent.json

Listing source of truth

The manifest becomes the listing

foundationbase.json is the source of truth for the listing. It tells reviewers and future builders what the foundation is, what it includes, how it runs, and how it can be reused.

The manifest should describe what actually exists. Do not overstate features or hide limitations.

{
  "title": "Personal CRM Foundation",
  "summary": "A local-first relationship tracker with contacts, notes, follow-ups, and reminders.",
  "category": "CRM",
  "tags": ["crm", "personal", "local-first"],
  "stack": ["Next.js", "TypeScript", "Local Storage"],
  "license": "MIT",
  "origin": "original",
  "screenshots": [
    "/screenshots/personal-crm-dashboard.png"
  ],
  "setup": [
    "npm install",
    "npm run dev"
  ]
}

Review signal

Foundation review score

87Overall Foundation Score

This score is not a guarantee of safety. It is a review signal that helps reviewers and builders understand readiness.

Manifest completeness92
Local-first behavior88
Security check readiness90
AI readiness82
Demo quality86
Documentation80
License clarity94

Future review architecture

Hosted demos need stronger isolation

For hosted demos, Foundation Base should not run untrusted submissions on the same origin as the main app. A better V1+ path is a separate sandbox domain such as sandbox.foundationbase-demos.app/<slug> or <slug>.foundationbase-demos.app.

  • Ephemeral containers or VMs
  • No production secrets
  • No production database access
  • No persistent credentials
  • Network disabled where possible
  • Read-only mounted submissions where possible
  • Separate demo origin
  • Sandboxed iframe for demos
  • Strict Content Security Policy
  • No cookies or auth on the demo origin

Review code before running it.

Foundation Base reviews foundations against its current standards, but all software carries risk. Review code before running it. Run unknown projects in a sandbox, container, or VM. Never add secrets until you understand what the app does.

More than a template drop

Accepted foundations should keep improving through proof, remixes, updates, collections, and directed build challenges.

Standalone listings

Accepted foundations get a dedicated page with screenshots, demo, download, stack, license, setup notes, and update history.

Built With This

Builders can share what they shipped from a foundation.

Remixes

Forks and variants can point back to the parent foundation and explain what changed.

Creator updates

Maintainers can improve foundations over time without losing original listing history.

Collections

Curated groups help people find the right foundation for a specific job.

Challenges

Directed prompts can create useful supply around household tools, no-backend SaaS starters, and niche business remixes.

Manual review only

Submit the first version

Until the public repository is ready, send the zipped demo folder. When the repo opens, the same package will move to pull requests.

Study accepted foundations