Understand what you're building

You need to understand what you're building, identify technical risks early, and execute with minimal rework. This guide takes you from a Brief to a Plan you can start shipping against.

Who this doc is for

You're an engineer about to build a feature and you want to do it once, not twice. You want the brief's intent, the success metric, and the constraints in front of you before you write code. Start by reading the Brief closely and skimming the Blueprint for product context, then turn the Brief into a Plan.

Pre-flight checklist

Before you start:

• Read the Brief carefully. The whole thing, not just the title.
• Understand the success metric, not just the feature. Knowing what "solved" means changes how you build.
• Know your technical constraints — existing architecture, performance budgets, and dependencies you can't move.
• Connect your GitHub repo so Hamster reasons about your real code and delivery has a target to open the pull request against.

Your first session

A concrete path from a Brief to a plan you can execute, start to finish in one sitting:

1. Read and annotate the Brief. Ask clarifying questions in comments wherever it's ambiguous.
2. Identify technical risks, dependencies, and unknowns up front, and get them answered in the Brief. You're done when the path from "start" to "shipped" has no surprises you haven't named.
3. Generate a Plan from the aligned Brief — an ordered task breakdown. It can take a few minutes, as it really breaks the work down. Then start shipping against it.

Post-creation next steps

Settle these in the Brief before you generate anything — conflicts are cheapest to fix there, and an aligned Brief is what makes the Plan correct the first time:

1. Review the Brief with the PM and lead designer to surface conflicts.
2. Name the critical path and the effort you expect.
3. Flag blockers explicitly: "Can't start Y until X is done."
4. Check design readiness: do you have the design details you need, or is design still exploring? Don't plan work that design hasn't settled.

Then generate the Plan and ship the same morning. Hamster orders the tasks by dependency from the aligned Brief; you check that order rather than rebuild it. Begin work on the lowest-dependency tasks, hand the Brief to a Cloud Agent that opens the pull request for you, or deliver it straight to a GitHub PR — and when you'd rather stay hands-on, pull the work into your own IDE with the CLI or the MCP server.

Feature depth

Go deeper on the artifacts an engineer leans on most:

• Plans — task sizing and ordering, and keeping scope honest.
• Briefs — understanding what "done" looks like from the success criteria.
• Blueprints — the product context (vision, strategy, ways of working) your work sits within.
• Cloud Agents — handing a Brief or Task to the cloud to execute and open a pull request, no laptop in the loop.
• CLI and the MCP server — pulling Briefs and Tasks into your own IDE and shipping from the terminal when you'd rather stay hands-on.
• Initiatives — seeing how the Brief you're shipping ladders up to a larger outcome.

Sample first session

1. Minutes 0–15: read the Brief; ask clarifying questions in comments.
2. Minutes 15–30: sync with the PM and designer on dependencies and unknowns; settle them in the Brief.
3. Same morning: with the Brief aligned, generate its Plan. It can take a few minutes, as it really breaks the work down.
4. Same morning: check the task order and estimates against the critical path.
5. Same day: begin work on the lowest-dependency tasks.

Common pitfalls

"The Brief is ambiguous. Should I ask or just start building?" Ask in comments or sync with the PM. Ambiguity now becomes rework later, and rework is the expensive kind.

"I don't understand why we're building this. Should I care?" Yes. Read the Brief's success metric — understanding the why is what lets you make the hundred small calls a Brief can't spell out.