A guide for small teams (1–10 people) shipping daily. Often founder-led, engineers already on Cursor or Claude Code. We'll start by connecting your tools so the AI has grounding, then walk through shipping your first brief, the IDE flow for engineers, Cloud Agents, and the Blueprint that comes out of it.
Small teams overview
~2 minutes
Video coming soon
Hamster's value compounds with how much of your team's work the AI can see. The Context Graph is the connected, summarised view of your code, docs, tickets, designs, and conversations — and it's what grounds every Brief, Plan, and chat reply in your real systems instead of generic AI guesses.
Three connections do the most work on a small team:
Add the rest as you grow into them: Slack for notifications and the brief side panel, Figma for design context, Notion for wiki pages, Meeting Agent for customer calls. See Connections overview for the full list.
Open a chat with Hamster and describe what you want to build. The AI assistant asks the right clarifying questions, pulls in any context you drop in, and produces a structured Brief.
Discovery doesn't have to start in a Brief either — spike code in your IDE to test a hunch, ideate in Figma, whiteboard with your team, then come back when the shape is clear and ask Hamster to turn the conversation into a Brief.
A Brief captures the goal, the user need, the scope, the success criteria, and the context an engineer or AI agent needs to ship the work. It's not a PRD. It's not a ticket. It's the artefact your team and the AI both read from. See Creating Briefs for the full surface.
Examples of Briefs:
Once the Brief looks right, generate a Plan. The Plan is a structured task breakdown derived from the Brief — mostly internal scaffolding for the AI agent. Glance at it before delivery to make sure the agent understood the scope; don't manage it the way a PM would in a project tool.
Top tip: If the Plan misses something, ask in the chat. Hamster regenerates the Plan from your follow-up — no need to edit it by hand.
Click Deliver. The Cloud Agent picks up the Plan, executes it, and pushes a PR to GitHub. The delivery thread streams the agent's narrative live — every tool call, every flow step, the PR push — so you see what's happening and can interrupt if the agent drifts.
Code review still happens on GitHub the way you already do it. Hamster doesn't replace your review process; it produces the PR for you to review.
Your engineers already use Claude Code, Cursor, Codex, or another AI coding tool. The fastest way to make Hamster useful for them is to expose your Context Graph, Briefs, Blueprints, and Methods to whatever they already use.
Two pieces:
This is the highest-leverage thing you can do for engineer adoption. Engineers stay in control, ship from where they live, and get the team's context for free.
A Cloud Agent is the configured environment Hamster runs deliveries in when nobody's hands are on a keyboard. It knows your repo URL, your env vars, your build and test commands.
Cloud Agents shine when a PM clicks Deliver on a Brief without an engineer in the loop, when you want parallel deliveries across the team, or for background work the team doesn't want sitting on someone's laptop. Engineers usually ship from their IDE, not from Cloud Agents — see the previous section.
If you do want Cloud Agents: configure one per active product repo. Paste your .env, hit Save, and Hamster auto-builds and snapshots the environment. Status flips to Active when it's ready, usually in under a minute.
Top tip: If your .env changes, hit Reset on the Cloud Agent. Hamster rebuilds in place — you don't reconfigure from scratch.
Once your Context Graph is connected, Hamster generates an initial Blueprint — an English representation of what your product is today, derived from your code, your existing docs, and your tickets. This is the source of truth every Brief gets refined against.
Spend an afternoon reviewing and editing what Hamster generated. Things to look for:
You're editing what Hamster proposed and adding what only you and the team know. The Blueprint is bidirectional — drop in additional docs (a Notion page, a tech spec) and it updates; edit it directly and downstream artefacts re-derive.
Top tip: Have everyone on the team read the Blueprint once it's settled. It's a good check on shared understanding — surfaces where the team has been operating on different mental models.
When a Brief lands and the PR merges, the Context Graph propagates the change back into the Blueprint — surfacing a "this part may need updating" prompt for review, or applying obvious updates automatically. Change ships, what's true updates, the Blueprint stays current.
Naming the outcome before the work isn't required to ship. Once you've delivered a few Briefs, though, the Goals and Initiatives layers stop tickets piling up.
Pick a framework your team already uses. For most small teams, OKR (Objective → 2–5 Key Results) or North Star (one primary metric → 3–5 inputs) are the natural starting points. Don't pick more than one on a small team — pick one and use it.
Attach a metric to each measurable Goal — unit, direction, target — so the team and the AI trade in the same numbers. Log results per period as you go.
Initiatives commit to a Goal. Examples for a small team:
When you write a Brief, attach it to the right Initiative. The Initiative gives you a single status surface for everything in flight that ladders up to that Goal — useful even at three people, because it stops you optimising for "tickets shipped" and points the team at the outcome.
For small teams, the default Hamster Method covers most patterns out of the box. You don't need to fork or write custom Methods until you spot a recurring kind of work where the AI is missing your team's specific way of doing it. When that happens, fork the Hamster Method into your workspace and add what's needed.
Every brief has an activity timeline that records every change — human or AI — to the brief and its plan. Alignment votes, status changes, scope edits, agent runs. It replaces "what's the latest?" Slack pings.
For non-builders on the team (a designer, a co-founder, a sales partner), the Slack brief side panel is usually the right surface. It renders the live brief inline in Slack so they don't need to log into Hamster to know what's going on.
When you've shipped 10–20 briefs and want to level up:
When you outgrow this guide, see How to use Hamster: Startups & mid-size companies.