!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys locale,review_mode,workflow,qa.level,testing.strict,performance.enforce,team.size,project.stage,system_overrides

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

Phase Gate Validation

Interaction Localization Rule: When locale: pt-BR (or user speaks Portuguese), ALL questions (AskUserQuestion / ask_question), confirmation prompts, and selectable options MUST be translated and presented in Brazilian Portuguese (PT-BR). Any English question text or options in this skill are illustrative examples — NEVER display English questions or options to a Portuguese developer. Internal reasoning, code synthesis, tests, and documentation files MUST remain in English.

This skill validates whether the project is ready to advance to the next development phase. It checks for required artifacts, quality standards, and blockers.

Distinct from /saas-project-stage-detect: That skill is diagnostic ("where are we?"). This skill is prescriptive ("are we ready to advance?" with a formal verdict).

Production Stages (7)

The project progresses through these stages:

1. Concept — Brainstorming, product concept document
2. Systems Design — Mapping systems, writing PRDs
3. Technical Setup — Engine config, architecture decisions
4. Pre-Production — Prototyping, vertical slice validation
5. Production — Feature development (Epic/Feature/Task tracking active)
6. Polish — Performance, usability testing, bug fixing
7. Release — Launch prep, certification

When a gate passes (or the user explicitly accepts a CONCERNS verdict's risks — Section 6), update the stage in both project.yaml (set project.stage: <new-stage>) AND write the new stage name to production/stage.txt (single line, e.g. Production). Dual-write keeps backward compatibility with hooks that haven't migrated yet. This updates the status line immediately.

---

1. Parse Arguments

Target phase: $ARGUMENTS with any --review <mode> pair removed (blank = auto-detect current stage, then validate next transition). /saas-gate-check --review full names no phase.

Note: in solo mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In lean mode, the phase-gate directors still run (phase gates are the purpose of lean mode); how many of them run is set by workflow below.

workflow (per .claude/docs/workflow-modes.md):

gate-check runs project-wide, so it uses the project-level workflow for the gate's overall artifact checklist (the loaded gate file), AND consults workflow_overrides.system_overrides.<system> per-system when validating MVP PRDs — a system pinned to a higher tier must meet that tier's section count before the gate passes, regardless of the project-level workflow (see Section 2b, "Per-system overrides").

gate-check honors workflow but is exempt from automation. The artifact checklist changes per tier; the collaborative prompting protocol (the Collaborative Protocol section) always applies — a phase gate is a deliberate human checkpoint, never auto-run.

qa.level: controls test enforcement at phase gates, where workflow controls which artifacts are required. modes.rigor sets both together; set qa.level explicitly to vary enforcement alone. At minimal, no test gates apply — the test-evidence and unit-test artifact items become non-required and the Section 3 testing.strict check is a no-op; the smoke check is not relaxed (Section 2b) — but at this level /saas-smoke-check runs without integration tests (its automated row reads WAIVED), so the build check (commands.smoke, else commands.build, when set) and the launch and critical-path checks are the floor — a build nobody launched is NOT ASSESSED — and a project with no tests can still pass. At standard, Logic + Integration tests must pass. At full, a full coverage check + regression suite are required (coverage minimum from qa.coverage_minimum if set). The retained screenshots UI and Visual/Feel stories need are not test items: no qa.level relaxes them (Section 2b).

team.size: does not change how many directors spawn at a phase gate — panel width is workflow's axis (Section 4b). This value affects only the specialist depth within each director's review. individual uses the core specialist set; small the standard set; studio adds engine sub-specialists. It never skips a director — skipping directors is review_mode's job. Both review_mode and team.size are set by modes.rigor — one rigor choice sets both — and each still overrides that axis when set explicitly (a full-rigor project gets the studio set; lighter tiers get individual).

• With argument: /saas-gate-check production — validate readiness for that specific phase

• No argument: Auto-detect current stage using the same heuristics as /saas-project-stage-detect, then confirm with the user before running:

  Use AskUserQuestion:

  • Prompt: "Detected stage: [current stage]. Running gate for [Current] → [Next] transition. Is this correct?"
  • Options:
    • [A] Yes — run this gate
    • [B] No — pick a different gate (if selected, show a second widget listing all gate options: Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release)

  Do not skip this confirmation step when no argument is provided.

---

2. Phase Gate Definitions

Each gate's checklist — required artifacts, quality checks, and its workflow-tier reductions — lives in its own file. Read only the row for the target phase transition; never load the others.

Gate	Definition file
Concept → Systems Design	references/gate-systems-design.md
Systems Design → Technical Setup	references/gate-technical-setup.md
Technical Setup → Pre-Production	references/gate-pre-production.md
Pre-Production → Production	references/gate-production.md
Production → Polish	references/gate-polish.md
Polish → Release	references/gate-release.md

Each file states the full baseline first, then the standard and minimal reductions for that gate. Apply the tier resolved in Section 1.

2b. Workflow Tier Adjustment

Read references/2b-workflow-tier.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

3. Run the Gate Check

Read references/3-run-gate-check.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

4. Collaborative Assessment

Read references/4-assessment.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

5. Output the Verdict

Read references/5-verdict.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

6. Update Stage on PASS

Read references/6-update-stage.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

7. Closing Next-Step Widget

Read references/7-next-steps.md now and follow it — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

Collaborative Protocol

This skill follows the collaborative design principle:

1. Scan first: Check all artifacts and quality gates
2. Ask about unknowns: Don't assume PASS for things you can't verify
3. Present findings: Show the full checklist with status
4. User decides: The verdict is a recommendation — the user makes the final call on what to do next; only the stage write is bound to it (Section 6)
5. Get approval: "May I write this gate check report to production/gate-checks/?"
6. Never auto-fix: If required artifacts are missing, report the FAIL verdict and name the skill to run (e.g. "run /saas-test-setup"). Do NOT create missing files or re-run the gate automatically. Creating files to manufacture a PASS defeats the gate's purpose.

Never block a user from working — the verdict decides only whether this skill writes the new stage. On CONCERNS the user may advance by explicitly accepting the listed risks, which the report records (Section 6); on FAIL or NOT ASSESSED the stage stays where it is until a re-run passes, and nothing stops the user working on the blockers meanwhile.