Start from the submission kit
Use templates/foundation-submission to get the required manifest shape, screenshot structure, local-first patterns, and review path.
Contribute to Foundation Base
Submit a local-first app foundation that others can inspect, run, fork, remix, and customize with their AI coding agent.
A foundation should arrive as a complete, inspectable software package, not a loose idea or a partial demo.
Use templates/foundation-submission to get the required manifest shape, screenshot structure, local-first patterns, and review path.
Place the working app in app/demo/<slug>/. It should include seeded data, a meaningful workflow, state changes, and persistence across reloads.
Complete foundationbase.json with title, summary, category, stack, tags, license, screenshots, setup steps, and origin status.
Validate the manifest, typecheck the app, and confirm the demo builds locally.
Send the zipped demo package for now. When the public repository is ready, the same package should move to pull requests.
Review starts faster when the package is complete, honest, and easy to run from a clean checkout.
app/demo/<slug>/ with layout.tsx, page.tsx, and the working app component.
foundationbase.json with listing metadata, license, stack, setup steps, screenshots, and origin status.
Screenshots must be local files that match the real demo.
The app should show a useful workflow immediately.
Changes should survive reloads through approved local-first storage patterns.
Clearly mark whether the foundation is original, a remix, or a fork.
Include the exact commands needed to run the foundation locally.
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 buildSecurity model
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.
Catalog demos stay local-first. Anything that phones home is rejected.
Unsafe HTML and dynamic code execution are blocked before human review.
State should be inspectable and use Foundation Base approved local-first patterns.
Assets, screenshots, and demo code must ship inside the foundation package.
A foundation should run from a fresh download without keys, accounts, or private config.
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.
Foundation Base treats submitted software as untrusted until it passes automated checks and human review.
A submitted foundation may intentionally try to run unsafe code.
A demo may try to send data to an outside server.
A dependency or install script may do something unexpected.
Screenshots, descriptions, or manifests may not match the real demo.
A project may include instructions that trick AI coding agents into making unsafe changes.
Review status should be explicit. Nothing should auto-publish in V1; all submissions require manual approval.
Received but not public.
Manifest validated, obvious banned patterns rejected, and local build confirmed.
A reviewer inspected the demo, code, screenshots, manifest, and license.
The /agent package exists and matches the actual project.
The foundation is accepted into the public library.
Agent-ready packaging
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.jsonListing source of truth
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
This score is not a guarantee of safety. It is a review signal that helps reviewers and builders understand readiness.
Future review architecture
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.
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.
Accepted foundations should keep improving through proof, remixes, updates, collections, and directed build challenges.
Accepted foundations get a dedicated page with screenshots, demo, download, stack, license, setup notes, and update history.
Builders can share what they shipped from a foundation.
Forks and variants can point back to the parent foundation and explain what changed.
Maintainers can improve foundations over time without losing original listing history.
Curated groups help people find the right foundation for a specific job.
Directed prompts can create useful supply around household tools, no-backend SaaS starters, and niche business remixes.
Manual review only
Until the public repository is ready, send the zipped demo folder. When the repo opens, the same package will move to pull requests.