init-project — project initialization (stack selection → generator activation)

Follow the canon (spec/standards/spec_driven_standard.md). This skill turns an empty repository into an SSOT-driven project, where most of the code is derived from declarations rather than written by hand.

Central Principle (do not violate)

The LLM writes the spec and business-logic-in-slots. The deterministic generator writes everything derivable from the SSOT schema and validates the LLM's output against it.

Reproducibility requires: everything derivable from the schema (models, DTOs, migrations, scaffold, CI) is generated by a deterministic script (0 tokens, bit-for-bit reproducible), NOT by the LLM. The LLM phase is limited to authoring the spec and business logic within validated templates. Economics: the repeatable path is cheaper than "compile once" (break-even ~17 repetitions).

Layer Boundary

Workflow (10 steps)

1. Project Description → Domains (LLM)

Ask for / accept the project description. Identify: domains and Bounded Contexts, core vs supporting, architectural style (monolith / modular-monolith / microservices — default modular-monolith, microservices only when triggered by: >1M req/day, >50 engineers, independent scaling), data flow (source→processing→persistence→consumers).

2. Grounding / DNA (LLM + human approve)

ssot-kit's grounding lives in CLAUDE.md + spec/product/vision.md — not a separate dna.yaml. Fill them: CLAUDE.md project name, stack, and Mission / feature filter (the outcome by which features are cut); spec/product/vision.md with the product intent + immutable principles + data-integrity rules. This is the grounding anchor (Spec Kit constitution.md / Kiro steering analogue) — done FIRST, shown for approval. Principles change only with human approval.

3. Stack Selection (Layer A: questionnaire → composition)

Read stack_questions.yaml. Walk the axes top-down, respecting when: (conditional gating — show a child axis only if its parent opened it). One axis = one choice (XOR). After each choice check compatibility: if the combination is in forbid — don't offer it / reject with a reason; require — ask for the dependency first. Duality: for a human — interactive; for an agent/CI — accept a ready-made blueprint.lock.yaml without asking questions.

4. Recording the Choice (Layer B: → SSOT)

Assemble blueprint.lock.yaml (a snapshot, see blueprint.schema.yaml): stack, activated_standards, activated_generators — from the activates blocks of the chosen values. This is the machine-readable project manifest (idempotency + future re-activation). Flag axes with codegen: llm-fallback — for these, zero-token codegen is unavailable, and the LLM writes the code (canon mode).

5. Activating the Stack Pack

Based on the pack from the chosen activates, wire in the package from packs/<pack>/pack.yaml. v1: the real pack is packs/python-fastapi/. Copy/wire its standards into the project's spec/standards/ and register the generators.

6. Scaffold (deterministic script, 0 tokens)

spec/ already ships with the kit (api/ data/ domain/ product/ standards/). Add the app skeleton: app/{db,api,services,schemas}, tests/, scripts/, CHANGELOG.md, CI, .env.example. Fill CLAUDE.md placeholders. NOT via the LLM — via packs/<pack>/scaffold.

7. SSOT Schemas (LLM writes the spec)

From the domain description, fill in (replacing the kit's example stubs): spec/data/schema.yaml (tables/columns — migrations derive from it), spec/api/openapi.yaml (API contract, SoT for back+front), spec/domain/entities.yaml (nouns + relations), spec/domain/invariants.yaml (domain invariants — for a money domain, a mandatory checklist: no-negative, append-only, integer-minor-units, idempotent-writes, audit-trail).

8. Generation Pipeline (deterministic generators, 0 tokens)

Run the pack's activated generators on the real spec files: spec/data/schema.yaml → app/db/models.py (gen_sqlalchemy_models) · spec/api/openapi.yaml → app/api/ (gen_fastapi_app) · Alembic scaffold (gen_alembic_env). Verify: same spec → same code. Generator versions are pinned in blueprint.lock.

9. Generation Boundaries (guard)

Lay out what_ai_can/cannot_generate (following the main-repo model 04_generation_rules): AI does NOT generate code without a spec, does NOT change the DNA, does NOT make L0-L1 decisions without review. Record this in spec/standards/.

10. Business Logic (LLM within validated templates)

Only what cannot be derived from the schema goes into app/services/. Every LLM output goes through structural validation against the SSOT schema. Write behavioral tests (TDD). Everything else is derivative.

Summary

The developer describes what (schemas), the pipeline implements how (generation). You write 100 lines of YAML — you get 1000+ lines of production code. Manual code is ~20% (business logic, complex queries, integrations, tests).

Skill Files

init-project/
├── SKILL.md                 # this workflow
├── stack_questions.yaml     # SSOT of selection axes (12 axes + activates + compatibility)
├── blueprint.schema.yaml    # schema for blueprint.lock.yaml
└── packs/
    └── python-fastapi/      # ✅ REAL pack (v1)
        ├── pack.yaml        # manifest: standards + generators + scaffold
        └── generators/      # deterministic (0 tokens): models/app/alembic/pytest

Other stacks (ts/go axes) → LLM-fallback until their packs appear (North-Star staged: the door is open).