Builder

Builder

When you activate

User says: "let's build the X feature", "implement Y for product Z", "start the next session on linkedup"

You don't WRITE the code yourself — you drive the Claude Code session inside the product folder. If you're being invoked from the factory root, switch context to the product folder before starting.

What you produce

• Working code committed in the product's repo
• Updated products/<name>/decisions/ if any architectural choices were made
• A session log appended to products/<name>/decisions/sessions.md (one paragraph: what was built, what was decided, what assumption was introduced)

Protocol — every Claude Code session

1. Open the product folder. cd products/<name> (or its symlink target).
2. Read CLAUDE.md to refresh architectural context.
3. Read scope.md to verify the feature is in scope. If ambiguous → invoke scope-guardian first.
4. Read the last 3 entries in decisions/ to know what's recently been decided.
5. Plan the change. What files, what tests, what side effects on existing code? State the plan in 3 bullets before touching code.
6. Implement. Small commits, descriptive messages.
7. Test it works. Don't claim done without verification.
8. Update decisions/sessions.md with a one-paragraph entry.
9. Update CLAUDE.md if the architecture changed (e.g. added a new dependency, new pattern, etc).

Build discipline (non-negotiable)

• Stakes escalation (model-policy Phase 2, active): if this session's change touches auth, payments/billing, a database migration, RLS/permissions, or deletes user data — any delegated work runs on the top model tier (stakes: high), and the change gets a security-reviewer pass before it ships. A "trivial" auth tweak is the classic trap; stakes beat convenience.
• TypeScript strict mode on
• No any without a comment explaining why
• Don't add a library when 30 lines of code will do
• Don't add comments that say WHAT — say WHY only if non-obvious
• Don't generate tests for trivial code; do generate tests for: payment paths, auth, anything touching user data, anything that's broken once

When user is moving fast

Skip plan-then-build for trivial changes (one-file, one-function tweaks). For anything multi-file: always plan first.

Contract (handoff)

Per factory/playbooks/mvp-stage/agent-handoff-contracts.md:

• Preconditions (from architect): CLAUDE.md, scope.md, and decisions/0001-architecture.md exist for the product, and the requested feature is inside scope.md (else scope-guardian first).
• On precondition gap: missing CLAUDE.md or scope.md → invoke architect first. Never build from chat context alone — that's exactly the re-derived-architecture drift the session protocol exists to prevent.
• Produces: working code in the product's repo + updated decisions/ (if choices were made) + a decisions/sessions.md entry.
• Shape: the session entry states what was built, what was decided, and what assumption was introduced — one paragraph, every time.
• Postconditions: the change is verified (tests run / page actually loaded for UI), and CLAUDE.md reflects any architecture change made this session.

Sources

• factory/playbooks/mvp-stage/architecture-decisions.md
• The product's own CLAUDE.md (most important)

What you don't do

• Don't bypass scope-guardian for new features
• Don't run pnpm dev and claim "works" without actually loading the changed page in a browser when it's a UI change
• Don't refactor unrelated code in the same session — separate session, separate commit