Quickstart
Set up one project, add stack context, and open the first useful ShipFoundry update.
The fastest path is to configure one real project, add the stack items that shape its roadmap, then review the first relevant update with the trust state visible.
When To Use This
Use this guide when you are setting up the first ShipFoundry project in an account.
Do not start by connecting every tool. ShipFoundry works best when the first setup is small, accurate, and tied to a real product you actively maintain.
How It Works
ShipFoundry needs enough product context to decide whether an external update matters. The minimum useful setup is:
- an account
- a plan
- one project
- project context
- tracked stack items
- one required read-only GitHub repository connection
Step-By-Step
- Create an account.
- Choose a plan.
- Create the first project.
- Add a short project summary, goals, constraints, and important repo areas.
- Add tracked stack items such as Next.js, Vercel, Supabase, Stripe, Resend, PostHog, Sentry, OpenAI, Anthropic, or Bun.
- Connect GitHub and choose the repository ShipFoundry may inspect read-only.
- Review the relevant updates list.
- Open the recommended brief and confirm its output lane.
- Use copy/paste or MCP to hand bounded work to a user-owned agent, or explicitly export it to Linear.
- Record the outcome after review or implementation.
What ShipFoundry Does
- Uses the project profile and tracked stack to shape relevance.
- Shows matched stack items and available source evidence.
- Checks the connected repository and adds repo evidence when the bounded match-specific search finds applicable proof.
- Produces a brief that can become a local-agent task packet or Linear issue.
- Keeps outcome history tied to the update and project.
What ShipFoundry Does Not Do
- It does not treat a required repository connection as proof that every update affects your code.
- It does not require Linear before a user-owned agent can work from a task packet.
- It does not infer every external tool from the repo.
- It does not automatically mark an update adopted.
- It does not replace your own review of local repo state.
First Project Setup Checklist
| Setup Item | Good Enough For Launch |
|---|---|
| Product summary | One paragraph explaining what the product does and who it serves. |
| Goals | Two to five current product or technical goals. |
| Constraints | Known limits such as budget, compliance, complexity, migration risk, or team bandwidth. |
| Important repo areas | Paths, services, packages, or app surfaces that should shape recommendations. |
| Tracked stack | The frameworks, platforms, APIs, SDKs, models, auth, billing, analytics, observability, deployment, and devtools that matter. |
| Ignored sources | Vendors or topics that should not create work for this product. |
Troubleshooting
If you do not see updates, add stack items that map to currently covered sources and wait for source processing.
If updates look generic, improve the product summary, goals, constraints, and tracked stack item precision.
If repo evidence does not appear, confirm GitHub is connected, the repository is selected, and the update is code-relevant.
Related Pages
- Product context: Product Overview
- Evidence boundary: GitHub Repo Evidence
- Next setup step: Investigation Briefs
- Agent workflow: Agent Workflows
- Example artifact: Sample Engineering Spike
- Product CTA: Start 7-Day Trial
Was This Page Useful?
Send a short note if this page is unclear, overclaims a capability, or is missing the proof you expected.
Send Docs Feedback for Quickstart