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 week

A concrete path from a Brief to a plan you can execute:

1. Read and annotate the Brief. Ask clarifying questions in comments wherever it's ambiguous.
2. Generate a Plan from the Brief — an ordered task breakdown — or build it with your lead.
3. Identify technical risks, dependencies, and unknowns up front. You're done when the path from "start" to "shipped" has no surprises you haven't named.

Post-creation next steps

Once the Plan exists:

1. Review your Plan with the PM and lead designer to surface conflicts early, while they're cheap to fix.
2. Estimate effort and identify the critical path.
3. Flag blockers explicitly: "Can't start Y until X is done."
4. Reorder the Plan so tasks run in dependency order.
5. Check design readiness: do you have the design details you need, or is design still exploring? Don't start work that design hasn't settled.
6. Begin work on the lowest-dependency tasks. When the Brief is aligned and ready, hand it 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-week workflow

1. Monday: read the Brief; ask clarifying questions in comments.
2. Tuesday: generate the Plan from the Brief; identify unknowns.
3. Wednesday: sync with PM and designer on dependencies.
4. Thursday: refine the Plan and estimate tasks.
5. Friday: reorder the Plan by dependency; 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.