Your first mission
Start a website, a blog or docs in onboarding. SHIP builds the site with your brand, opens a pull request with a preview, and publishes the site when you merge.
Onboarding can start you with a site. You make a repository from a SHIP template, and the first mission builds the site with your brand and your facts. When you merge its pull request, SHIP publishes the site at its own address. This page follows the site path of onboarding from the first choice to the live site.
Choose what to build
After you name your organization, onboarding asks what you want to build.
| Choice | What you get |
|---|---|
| Build a website | The Website template: a home page, features, pricing and an FAQ. |
| Start a blog | The Blog template: posts with authors, tags, feeds and search. |
| Create docs | The Docs template: pages with a sidebar, search and a table of contents. |
| Use my own repo | A repository that you already have on GitHub. |
Use my own repo is the path for every other project. It continues as Set up describes, and its first mission adds a ship.yml to your repository. You can also connect a repository that you made from a SHIP template. If its project plans work in GitHub Issues, SHIP offers the site mission of its kind instead.
Make the repository and install the app
GitHub makes the repository of a site from the template, in your own account. Then the GitHub App gets access to it.
Make the repository
Select Use this template. GitHub opens its form for a new repository from the template. Make the repository in the account where you install the GitHub App.
Install the GitHub App
Select Install on GitHub. If you give the app access to selected repositories only, select the new repository.
A site plans its work in GitHub Issues, so this step does not ask for Linear.
Connect a model provider
Connect at least one model provider, as for every project. One credential is enough to run a whole mission. LLM credentials explains how to connect one.
Set up the site project
SHIP looks for the new repository among the repositories that the GitHub App can reach. When it finds the repository, it names it and suggests the name of the repository as the name of the project. The project takes its work from GitHub Issues in that repository, and SHIP opens its pull requests there.
If SHIP cannot find the repository, make it from the template on GitHub, or give the app access to it. Then select Check again. If GitHub reports more than one repository from the template, SHIP uses the newest one and tells you which one.
Describe your site
The last step is the form of the first mission. It asks for the brand, the facts of the site, the site address and the brand rights confirmation. The brand page explains the three brand sources and the record that SHIP keeps of the confirmation.
Each kind asks for its own facts.
| Kind | Facts |
|---|---|
| Website | The main audience, and one to three products or services. |
| Blog | The author, and the topic of the first post. |
| Docs | The product name, the product website, and three to seven pages. |
The site address is https://<slug>.letsship.app, and the name of the repository is the first suggestion. A slug has 3 to 40 characters: a-z, 0-9 and single hyphens. SHIP refuses a reserved name and an address that another site holds. SHIP holds the address when you start the mission.
Select Start mission. If your workspace has no credits left, SHIP refuses the start, and the form links to Billing.
Follow the mission
SHIP then files an issue in the GitHub Issues of the repository, with your facts and the acceptance criteria. The mission is a normal mission, and the Tester checks each criterion on the preview. Each starter has these criteria, and the criteria of its kind:
brand/brand.dna.jsonholds your brand, anddna lintreports no errors.dna site checkpasses on the build output.- Every page shows the brand name and the logo.
origininsite.config.tsis the site address.- CI passes.
| Kind | Criteria of the kind |
|---|---|
| Website | The home page has a hero, a feature grid with one feature for each product or service, a call to action and a FAQ. An "About" page exists. The site holds no invented prices, customers or quotes. |
| Blog | The post list shows one post about the topic, by the author. /feed.xml and /llms.txt list that post. The sample posts of the template return 404. |
| Docs | The sidebar shows a "Quick start" page and one page for each item of the outline. Search finds each page by its title. /llms.txt lists each page. |
| Waitlist | The site is one page with a hero, the waitlist form and a FAQ. The hero names what people join for. A sign-up on the preview shows the success message. The site holds no invented prices, customers, quotes or launch date. |
A waitlist is built on the website template. Only Start from scratch makes one, because SHIP takes the sign-ups of a site that it made.
The pull request has a preview at https://<slug>--pr<n>.letsship.app, where <n> is the number of the pull request. Open the preview to see the site before you merge.
Merge and go live
When you merge the pull request, SHIP builds the default branch and publishes the site at its address. SHIP adds a comment with the live address to the merged pull request, and the timeline of the mission shows that the site is live. The last screen of onboarding also shows the address when the site is live.
Each later push to the default branch publishes the site again. The Sites page of the console lists each deploy, and Manage a site explains it.
Each site gets one first mission. If you start it again, SHIP shows the mission that started first and files no second issue.
Start the mission without the console
An agent starts the same mission with the MCP tool create_mission and starter. From a terminal, use ship mission create --starter <kind>. ship templates starters lists the criteria of each starter, and ship templates presets lists the looks. With --kits, it lists only the three brand kits that a founder sees on the site form.
How is this page?