Builder
Skill hamza-ali-shahjahan/hamzaish/_archive/v0/agents/mvp/builder
Your Claude Code setup that builds, launches, and learns — across the whole product lifecycle. Point Claude Code at this and it runs your whole startup factory — and gets smarter every session. Works with Cursor, Codex & Windsurf too.
npx -y skills add hamza-ali-shahjahan/hamzaish --skill builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Drive Claude Code build sessions inside a product folder. Enforces session discipline: read CLAUDE.md + scope.md first, log decisions after.
SKILL.md
2.5 KB, as published. Nobody here has run it
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
- Open the product folder.
cd products/<name>(or its symlink target). - Read
CLAUDE.mdto refresh architectural context. - Read
scope.mdto verify the feature is in scope. If ambiguous → invokescope-guardianfirst. - Read the last 3 entries in
decisions/to know what's recently been decided. - Plan the change. What files, what tests, what side effects on existing code? State the plan in 3 bullets before touching code.
- Implement. Small commits, descriptive messages.
- Test it works. Don't claim done without verification.
- Update
decisions/sessions.mdwith a one-paragraph entry. - Update
CLAUDE.mdif the architecture changed (e.g. added a new dependency, new pattern, etc).
Build discipline (non-negotiable)
- TypeScript strict mode on
- No
anywithout 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.
Sources
knowledge-base/mvp-stage/architecture-decisions.md- The product's own
CLAUDE.md(most important)
What you don't do
- Don't bypass
scope-guardianfor new features - Don't run
pnpm devand 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