From SaaS Factory
Run the build loop for the ACTIVE PHASE — canary first, parallel builder subagents (or an agent team with --team N), independent verification of every task, budget and circuit-breaker fail-fast guards, ending at the phase demo gate.
How this skill is triggered — by the user, by Claude, or both
Slash command
/saas-factory:build [batch-size] [--team N][batch-size] [--team N]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Args: $ARGUMENTS → batch B (default `bin/sf cfg get ".build.default_batch" 5`);
Args: $ARGUMENTS → batch B (default bin/sf cfg get ".build.default_batch" 5);
--team N = agent-team mode. Parallelism: .build.parallel_builders. Model
overrides: pass bin/sf cfg get ".models.builder" etc. when spawning (skip if
"inherit"). Phase: bin/sf active-phase (none → run /saas-factory:plan first).
Orchestrator context law: ids, titles, statuses, one-line notes ONLY here. Never open source files, REQ bodies, or the jsonl stores — fresh subagent contexts do all reading. That is what keeps a 5,000-req project from breaking.
Guards before EVERY round (fail fast, save tokens):
bin/sf budget check — exit 2 ⇒ STOP, show spend + options (raise cap /
continue once / abort).bin/sf phase-stats <PHASE> — attempts÷total ≥
.phases.circuit_breaker_fail_ratio ⇒ STOP: the plan is wrong; show failed
notes, offer re-plan. Never brute-force a failing phase.Loop until B processed or queue drained:
bin/sf ready 3 <PHASE> → pick tasks with disjoint files (conflicts wait).bin/sf claim <id> builder-<n>; spawn saas-factory:builder
(parallel Task calls) with EXACTLY: "You are builder-. Execute
— . <USES note>. Follow .saas-factory/README.md." Nothing more.
built → immediately spawn saas-factory:verifier: "Verify per
protocol." Fails auto-requeue with notes; 3rd strike parks for the human.done X/B · verified V · failed F · ready R · spend $S.End of batch: bin/sf counts + sf failed items. Phase fully verified ⇒
announce demo-ready and hand off to /saas-factory:demo (never skip the gate).
Requires env CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 — if missing, OFFER to
merge {"env":{"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS":"1"}} into
.claude/settings.local.json (show the diff; takes effect next session) and
use Mode A for now.
Spawn N teammates from the saas-factory:builder definition + one
saas-factory:verifier teammate; they self-serve via bin/sf next <name>
(TeammateIdle hook nudges; TaskCompleted agent hook blocks completion without
PASS evidence). Mirror the ready slice into the shared task list with deps.
Peer review (when .build.team.peer_review is true): after a builder
finishes a chunk/task, its PEER builder reviews the diff before the verifier —
the "double-check your work" an engineer would ask for, from fresh eyes.
Findings go back terse (file:line + what's wrong); the author fixes or defends;
they may DEBATE up to .build.team.debate_rounds rounds, then any unresolved
disagreement escalates to the lead (contract questions → architect). Review
comments are code-focused one-liners, never essays.
Lead: monitor, guards above between waves, relay contract blocks to an
architect subagent, never implement. Queue drained → shut down teammates,
report as Mode A. Resumable: rerun /saas-factory:build anytime — disk state
continues exactly where it left off.
npx claudepluginhub usmanali4073/claude-code-saas-factory-plugin --plugin saas-factoryGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.