nezam-build-modes

skill_id	nezam-build-modes
name	nezam-Build Modes
tier	3
description	Development method overlays for NEZAM. Modifies phase execution and gate thresholds without changing the SDD pipeline structure.
version	1.0.0
certified	false
updated	"2026-05-12T00:00:00.000Z"
changelog	[]

Build Modes Skill

Purpose

Apply a development method overlay to the NEZAM SDD pipeline. Overlays modify how phases execute and what gate thresholds apply — they do NOT change the pipeline structure (gates remain G0→G1→G2→...→G6).

Loaded by swarm-leader when build_mode is non-empty in onboarding.yaml.

Available Modes

Mode 1: SDD (Default)

build_mode: "sdd" — Full Specification-Driven Development

• 6 development phases, all required
• Gate threshold: score ≥ 70% to pass each gate
• All planning artifacts required before development
• Full test coverage requirement: ≥80% on critical paths
• Ship requires: security audit + Lighthouse pass + WCAG 2.2 AA

When to use: Production applications, client projects, anything that needs governance documentation, multi-developer teams.

Phase sequence:

G0 → Planning → G1 → Phase 1 Foundation → Phase 2 Core → Phase 3 Integration
    → Phase 4 Content → Phase 5 Hardening → G5 → Phase 6 Ship

---

Mode 2: Lean MVP

build_mode: "lean" — Rapid MVP delivery

• Phases 1+2 merged into "MVP Core" (4 phases total, not 6)
• Gate threshold: score ≥ 50% (not 70%)
• Planning artifacts: PRD + Architecture required; SEO, IA, Content are optional (deferred)
• Test coverage: ≥50% on critical paths
• Ship requires: basic functionality test pass (security audit deferred to post-launch)

When to use: Prototypes, hackathons, internal tools, early-stage startups validating product-market fit.

Phase sequence:

G0 → Light Planning → G1 → Phase 1 MVP Core → Phase 2 Polish
    → Phase 3 Hardening (lite) → G3 → Ship

Modified gates:

• G0→1: PRD + DESIGN.md required (SEO/IA/Content deferred)
• G1→2: MVP Core complete (phases 1+2 merged threshold)
• G2→3: Polish complete
• G3→ship: Basic security + manual test pass

---

Mode 3: TDD (Test-Driven Development)

build_mode: "tdd" — SDD pipeline + test-first gates

• Full SDD 6-phase pipeline (same as SDD mode)
• ADDITIONAL gate per feature: tests must be written BEFORE implementation
• Gate threshold: score ≥ 70% (same as SDD) PLUS test-first evidence required
• Each sub-task must have a corresponding test file committed before feature code
• Test coverage minimum: ≥90% on critical paths (higher than SDD)

When to use: High-reliability systems, payment flows, auth systems, API services where correctness is critical.

Additional gate per feature (within each phase):

Write test → Commit test → Implement feature → Run test → Pass → Merge
         ↑ Gate: test must exist before implementation

swarm-leader enforcement: When build_mode: tdd — before approving any feature task as "done":

1. Check that a test file for the feature was committed BEFORE the implementation file
2. If not → mark task as REQUIRES_TEST_FIRST and block merge
3. Report in /check output with TDD compliance score

---

Mode 4: API-First

build_mode: "api-first" — Reversed pipeline: API contract before everything else

• Reversed planning sequence: API spec → IA → Design → PRD (not PRD → IA → Design → API)
• Gate threshold: score ≥ 70% (same as SDD)
• OpenAPI/GraphQL spec required as the planning source of truth
• PRD is derived FROM the API spec, not the other way around

When to use: Backend-heavy projects, public APIs, headless architectures, microservices, B2B integrations.

Modified planning sequence:

G0 → API Spec (OpenAPI/GraphQL) → IA → Design → PRD (derived) → Architecture → Scaffold

Additional artifacts required:

• .nezam/core/plans/api/API_SPEC.yaml or API_SPEC.graphql — the API contract
• .nezam/core/plans/api/API_DECISIONS.md — versioning, auth, rate limiting decisions
• PRD must include ## API Alignment section confirming PRD matches API spec

swarm-leader enforcement: When build_mode: api-first:

1. Block /plan seo until .nezam/core/plans/api/API_SPEC.yaml exists
2. Route planning to api-logic-manager first, then IA, then design-lead
3. Require PRD to contain ## API Alignment section before locking

---

Mode Selection (during /start Step 2.5)

Present this menu when build_mode is empty:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Step 2.5 — Choose your development approach
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  A) SDD — Full Specification-Driven Development
     Best for: production apps, client projects, teams
     6 phases · strict gates · full audit trail

  B) Lean MVP — Rapid prototyping mode
     Best for: MVPs, hackathons, early validation
     4 phases · relaxed gates · ship faster

  C) TDD — Test-Driven Development overlay
     Best for: payment flows, APIs, high-reliability systems
     SDD + test-first gates · 90% coverage target

  D) API-First — API contract before everything else
     Best for: backend services, headless, B2B integrations
     Reversed planning: API spec → IA → Design → PRD

  Enter A / B / C / D:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

After selection:

1. Write build_mode: "sdd"|"lean"|"tdd"|"api-first" to onboarding.yaml
2. Write build_mode_set_at: <timestamp> to onboarding.yaml
3. Confirm selection: "✅ Build mode set to [name]. [One sentence on what changes.]"
4. Continue to next /start step (PRD menu)

Mode-Specific Gate Thresholds

Mode	Gate threshold	Coverage target	Security audit	Ship speed
sdd	70%	≥80% critical	Required	Standard
lean	50%	≥50% critical	Deferred	Fast
tdd	70% + test-first	≥90% critical	Required	Standard
api-first	70%	≥80% critical	Required	Standard

Anti-Patterns

• Do not switch build_mode mid-project without a full rollback to G0
• Do not use lean for projects with payment, auth, or PII handling
• Do not use api-first when the UI is the primary design surface
• Do not disable test-first enforcement in tdd mode for "just this feature"