LogoSkills

product:solutioning-gate-check

Executes the Solutioning Gate Check workflow as the System Architect.

ํ•ญ๋ชฉ๋‚ด์šฉ
Invoke/solutioning-gate-check

/solutioning-gate-check โ€” ์„ค๊ณ„ ํ•ฉ๊ฒฉ ์ ๊ฒ€#

ํ•œ๋งˆ๋””๋กœ#

๋ณธ๊ฒฉ์ ์œผ๋กœ ๊ฐœ๋ฐœ์— ๋“ค์–ด๊ฐ€๊ธฐ ์ „์—, ์„ค๊ณ„ ๋„๋ฉด์ด ๋น ์ง„ ๊ณณ ์—†์ด ์ž˜ ๊ทธ๋ ค์กŒ๋Š”์ง€ ์ตœ์ข… ๊ฒ€์‚ฌํ•˜๋Š” ๋‹จ๊ณ„์ž…๋‹ˆ๋‹ค. ๊ณต์‚ฌ๋ฅผ ์‹œ์ž‘ํ•˜๊ธฐ ์ „ ๊ฑด์ถ• ๋„๋ฉด์„ ์ ๊ฒ€ํ•ด "์ด๋Œ€๋กœ ์ง€์–ด๋„ ๋˜๊ฒ ๋‹ค / ๋ณด์™„์ด ํ•„์š”ํ•˜๋‹ค"๋ฅผ ํŒ์ •ํ•˜๋Š” ๊ฒƒ๊ณผ ๊ฐ™์•„์š”.

๋ˆ„๊ฐ€ยท์–ธ์ œ ์“ฐ๋‚˜์š”#

  • ์•„ํ‚คํ…์ฒ˜(์„ค๊ณ„) ๋ฌธ์„œ๋ฅผ ๋‹ค ๋งŒ๋“ค๊ณ , ๋‹ค์Œ ๋‹จ๊ณ„์ธ ๊ฐœ๋ฐœ(๊ตฌํ˜„)๋กœ ๋„˜์–ด๊ฐ€๊ธฐ ์ง์ „์ธ ๊ฒฝ์šฐ
  • "์š”๊ตฌ์‚ฌํ•ญ์ด ์„ค๊ณ„์— ๋น ์ง์—†์ด ๋ฐ˜์˜๋๋Š”์ง€" ๊ฐ๊ด€์ ์œผ๋กœ ํ™•์ธํ•˜๊ณ  ์‹ถ์„ ๋•Œ
  • System Architect ์—ญํ• ๋กœ ์ง„ํ–‰ํ•˜๋ฉฐ, ๋ณดํ†ต 15~30๋ถ„ ์ •๋„ ๊ฑธ๋ฆฝ๋‹ˆ๋‹ค.

๐Ÿ‘‰ ๋Œ€์ƒ: ์•„ํ‚คํ…์ฒ˜๊ฐ€ ์žˆ๋Š” ํ”„๋กœ์ ํŠธ(Level 2 ์ด์ƒ). ์„ค๊ณ„ ๋ฌธ์„œ๊ฐ€ ์—†์œผ๋ฉด ๋จผ์ € /architecture๋ฅผ ์‹คํ–‰ํ•ด์•ผ ํ•ฉ๋‹ˆ๋‹ค.

๋ฌด์—‡์„ ํ•ด์ฃผ๋‚˜์š”#

์„ค๊ณ„๊ฐ€ ์š”๊ตฌ์‚ฌํ•ญ์„ ์–ผ๋งˆ๋‚˜ ์ž˜ ๋‹ด์•˜๋Š”์ง€ ์ ์ˆ˜๋ฅผ ๋งค๊ธฐ๊ณ , ํ•ฉ๊ฒฉ/์กฐ๊ฑด๋ถ€ ํ•ฉ๊ฒฉ/๋ถˆํ•ฉ๊ฒฉ์„ ํŒ์ •ํ•œ ๋ณด๊ณ ์„œ ํŒŒ์ผ์„ ๋งŒ๋“ค์–ด ์ค๋‹ˆ๋‹ค.

  • ์ ๊ฒ€ ๊ฒฐ๊ณผ๋Š” {output_folder}/solutioning-gate-check-{ํ”„๋กœ์ ํŠธ์ด๋ฆ„}-{๋‚ ์งœ}.md ํŒŒ์ผ๋กœ ์ €์žฅ๋ฉ๋‹ˆ๋‹ค.
  • ๋ณด๊ณ ์„œ์—๋Š” ๊ธฐ๋Šฅ ์š”๊ตฌ์‚ฌํ•ญ(FR)ยท๋น„๊ธฐ๋Šฅ ์š”๊ตฌ์‚ฌํ•ญ(NFR)์ด ์„ค๊ณ„์— ์–ผ๋งˆ๋‚˜ ๋ฐ˜์˜๋๋Š”์ง€(%), ์„ค๊ณ„ ํ’ˆ์งˆ ์ฒดํฌ๋ฆฌ์ŠคํŠธ ์ ์ˆ˜, ๋ง‰ํžŒ ๋ฌธ์ œ(Blocker), ๊ฐœ์„  ๊ถŒ๊ณ ๊ฐ€ ๋‹ด๊น๋‹ˆ๋‹ค.
  • ํ•ฉ๊ฒฉ์ด๋ฉด ๋‹ค์Œ ๋‹จ๊ณ„(/sprint-planning)๋กœ, ๋ถˆํ•ฉ๊ฒฉ์ด๋ฉด ๋ณด์™„ ํ›„ ๋‹ค์‹œ ์ ๊ฒ€ํ•˜๋„๋ก ์•ˆ๋‚ดํ•ฉ๋‹ˆ๋‹ค.

์–ด๋–ป๊ฒŒ ์“ฐ๋‚˜์š”#

# ์„ค๊ณ„ ํ•ฉ๊ฒฉ ์ ๊ฒ€ ์‹คํ–‰
/solutioning-gate-check

์‹คํ–‰ํ•˜๋ ค๋ฉด ๋ฏธ๋ฆฌ ๋‘ ๊ฐ€์ง€ ๋ฌธ์„œ๊ฐ€ ์žˆ์–ด์•ผ ํ•ฉ๋‹ˆ๋‹ค.

  • ์„ค๊ณ„ ๋ฌธ์„œ: .bmad/architecture-*.md (์—†์œผ๋ฉด /architecture๋ฅผ ๋จผ์ € ์‹คํ–‰)
  • ์š”๊ตฌ์‚ฌํ•ญ ๋ฌธ์„œ: .bmad/prd-*.md ๋˜๋Š” .bmad/tech-spec-*.md (๋‘˜ ๋‹ค ์—†์œผ๋ฉด ์ ๊ฒ€ ์ง„ํ–‰ ๋ถˆ๊ฐ€)

์•ˆ์—์„œ ๋ฌด์Šจ ์ผ์ด ๋ฒŒ์–ด์ง€๋‚˜์š”#

ํฌ๊ฒŒ ์š”๊ตฌ์‚ฌํ•ญ์„ ๊บผ๋‚ด โ†’ ์„ค๊ณ„์™€ ๋Œ€์กฐ โ†’ ํ’ˆ์งˆ ์ฑ„์  โ†’ ํ•ฉ๊ฒฉ ํŒ์ • ์ˆœ์œผ๋กœ ์ง„ํ–‰๋ฉ๋‹ˆ๋‹ค.

  1. ๋ฌธ์„œ ์ฝ๊ธฐ โ€” ์„ค๊ณ„ ๋ฌธ์„œ์™€ ์š”๊ตฌ์‚ฌํ•ญ ๋ฌธ์„œ๋ฅผ ๋ถˆ๋Ÿฌ์™€ ํ•ต์‹ฌ ํ•ญ๋ชฉ(์š”๊ตฌ์‚ฌํ•ญ ๋ชฉ๋ก, ๊ธฐ์ˆ  ์Šคํƒ, ๋ฐ์ดํ„ฐยทAPI ์„ค๊ณ„ ๋“ฑ)์„ ์ •๋ฆฌํ•ฉ๋‹ˆ๋‹ค.
  2. ๊ธฐ๋Šฅ ์š”๊ตฌ์‚ฌํ•ญ(FR) ๋Œ€์กฐ โ€” ๊ฐ ๊ธฐ๋Šฅ ์š”๊ตฌ์‚ฌํ•ญ์ด ์„ค๊ณ„์˜ ์–ด๋А ๋ถ€ํ’ˆ(์ปดํฌ๋„ŒํŠธ)์— ์—ฐ๊ฒฐ๋๋Š”์ง€ ํ™•์ธํ•˜๊ณ , ๋น ์ง„ ํ•ญ๋ชฉ์„ ์ฐพ์•„ ๋ฐ˜์˜๋ฅ (%)์„ ๊ณ„์‚ฐํ•ฉ๋‹ˆ๋‹ค.
  3. ๋น„๊ธฐ๋Šฅ ์š”๊ตฌ์‚ฌํ•ญ(NFR) ๋Œ€์กฐ โ€” ์„ฑ๋Šฅยท๋ณด์•ˆยทํ™•์žฅ์„ฑ ๊ฐ™์€ ํ’ˆ์งˆ ์š”๊ตฌ์‚ฌํ•ญ์ด ์‹ค์ œ๋กœ ํ•ด๊ฒฐ์ฑ…๊ณผ ํ•จ๊ป˜ ๋‹ด๊ฒผ๋Š”์ง€, ํ•ด๊ฒฐ์ฑ…์ด ์ถฉ๋ถ„ํ•œ์ง€ ํ‰๊ฐ€ํ•ฉ๋‹ˆ๋‹ค.
  4. ์„ค๊ณ„ ํ’ˆ์งˆ ์ฑ„์  โ€” ์‹œ์Šคํ…œ ์„ค๊ณ„ยท๊ธฐ์ˆ  ์Šคํƒยท๋ฐ์ดํ„ฐยทAPIยท๋ณด์•ˆยทํ™•์žฅ์„ฑยท์‹ ๋ขฐ์„ฑยท๋ฐฐํฌยท์ถ”์ ์„ฑ ๋“ฑ ํ•ญ๋ชฉ๋ณ„ ์ฒดํฌ๋ฆฌ์ŠคํŠธ๋กœ ์ ์ˆ˜๋ฅผ ๋งค๊น๋‹ˆ๋‹ค.
  5. ํ•ฉ๊ฒฉ ํŒ์ • ๋ณด๊ณ ์„œ ์ž‘์„ฑ โ€” FR/NFR ๋ฐ˜์˜๋ฅ ๊ณผ ํ’ˆ์งˆ ์ ์ˆ˜๋ฅผ ์ข…ํ•ฉํ•ด ํ•ฉ๊ฒฉ(PASS)ยท์กฐ๊ฑด๋ถ€ ํ•ฉ๊ฒฉ(CONDITIONAL PASS)ยท๋ถˆํ•ฉ๊ฒฉ(FAIL) ์ค‘ ํ•˜๋‚˜๋กœ ํŒ์ •ํ•˜๊ณ  ๋ณด๊ณ ์„œ๋ฅผ ์ €์žฅํ•ฉ๋‹ˆ๋‹ค.
  6. ์ƒํƒœ ์—…๋ฐ์ดํŠธ์™€ ๋‹ค์Œ ๋‹จ๊ณ„ ์•ˆ๋‚ด โ€” ํ•ฉ๊ฒฉ์ด๋ฉด ์ง„ํ–‰ ์ƒํƒœ๋ฅผ ๊ฐฑ์‹ ํ•˜๊ณ  ์Šคํ”„๋ฆฐํŠธ ๊ณ„ํš(/sprint-planning)์œผ๋กœ, ๋ถˆํ•ฉ๊ฒฉ์ด๋ฉด ๋ณด์™„ ํ›„ ์žฌ์‹คํ–‰์„ ์•ˆ๋‚ดํ•ฉ๋‹ˆ๋‹ค.

ํŒ์ • ๊ธฐ์ค€ ์š”์•ฝ: ํ•ฉ๊ฒฉ์€ FR 90% ์ด์ƒยทNFR 90% ์ด์ƒยทํ’ˆ์งˆ 80% ์ด์ƒยท์น˜๋ช…์  ๋ง‰ํž˜ ์—†์Œ, ์กฐ๊ฑด๋ถ€ ํ•ฉ๊ฒฉ์€ ๊ฐ๊ฐ 80%ยท80%ยท70% ์ด์ƒ์ด๋ฉฐ ๋ง‰ํžŒ ๋ฌธ์ œ์— ๋Œ€์‘ ๊ณ„ํš์ด ์žˆ์„ ๋•Œ, ๊ทธ ๋ฏธ๋งŒ์ด๊ฑฐ๋‚˜ ํ•ด๊ฒฐ ์•ˆ ๋œ ์น˜๋ช…์  ๋ฌธ์ œ๊ฐ€ ์žˆ์œผ๋ฉด ๋ถˆํ•ฉ๊ฒฉ์ž…๋‹ˆ๋‹ค.


โš™๏ธ ์ƒ์„ธ ์˜ต์…˜ยท์‹คํ–‰ ๋ช…์„ธ (๊ฐœ๋ฐœ์ž / AI ์—์ด์ „ํŠธ์šฉ)

Workflow Overview#

Goal: Validate architecture completeness and quality before moving to implementation

Phase: 3 - Solutioning (Gate)

Agent: System Architect

Inputs: Architecture document, PRD or tech-spec

Output: Validation report with pass/fail and detailed findings

Duration: 15-30 minutes

Required for: Level 2+ projects (or any project with architecture)


Pre-Flight#

  1. Load context per helpers.md#Combined-Config-Load
  2. Check status per helpers.md#Load-Workflow-Status
  3. Verify architecture exists:
    • Check for: .bmad/architecture-*.md
    • If not found, ask user for path or inform that /architecture must run first
  4. Load requirements document:
    • Check for PRD: .bmad/prd-*.md
    • If no PRD, check for tech-spec: .bmad/tech-spec-*.md
    • If neither, gate check cannot proceed

Validation Process#

Use TodoWrite to track: Pre-flight โ†’ Load Docs โ†’ Extract Requirements โ†’ Validate Coverage โ†’ Check Quality โ†’ Generate Report โ†’ Update Status

Approach: Thorough, systematic, quality-focused.


Part 1: Load and Parse Documents#

Load Architecture Document:

  1. Read architecture document from .bmad/architecture-*.md
  2. Extract key sections:
    • Architectural drivers
    • System components
    • Technology stack
    • Data architecture
    • API design
    • NFR coverage sections
    • FR traceability
    • NFR traceability

Load Requirements Document:

  1. Read PRD or tech-spec
  2. Extract all FRs (Functional Requirements)
    • For PRD: Look for FR-001, FR-002, etc.
    • For tech-spec: Extract from requirements list
  3. Extract all NFRs (Non-Functional Requirements)
    • For PRD: Look for NFR-001, NFR-002, etc.
    • For tech-spec: Extract from performance, security, other NFR sections

Create baseline:

Requirements Baseline:
- Total FRs: {count}
- Total NFRs: {count}
- Critical FRs (Must Have): {count}
- Epics (if PRD): {count}

Part 2: Validate FR Coverage#

For each FR from requirements:

  1. Check if FR is mentioned in architecture

    • Search for FR-{ID} in architecture document
    • Check FR traceability matrix (if present)
    • Check system components section
  2. Verify component assignment

    • Does the FR map to specific components?
    • Is the implementation approach clear?
    • Are dependencies identified?
  3. Record findings:

        FR-{ID}: {Name}
    โœ“ Covered | โœ— Missing
    Components: {list}
    Notes: {any concerns}
    

Generate FR Coverage Report:

### Functional Requirements Coverage

**Total FRs:** {total}
**Covered:** {covered_count} ({percentage}%)
**Missing:** {missing_count}

**Missing FRs:**
{list of FRs not addressed in architecture}

**Partial Coverage (needs clarification):**
{list of FRs with incomplete coverage}

Part 3: Validate NFR Coverage#

For each NFR from requirements:

  1. Check if NFR has dedicated section

    • Look for "NFR-{ID}" in architecture
    • Check if architectural solution is provided
    • Verify implementation notes exist
    • Check if validation approach is defined
  2. Assess solution quality:

    • Is the solution specific (not generic)?
    • Does it address the measurable target?
    • Are trade-offs documented?
    • Is it implementable?
  3. Record findings:

        NFR-{ID}: {Name}
    โœ“ Fully Addressed | โš  Partially Addressed | โœ— Missing
    Solution Quality: Good | Fair | Poor | N/A
    Notes: {assessment}
    

Common NFR categories to check:

  • Performance (response time, throughput)
  • Security (auth, encryption, compliance)
  • Scalability (concurrent users, data volume)
  • Reliability (uptime, failover)
  • Maintainability (code quality, documentation)
  • Usability (accessibility, UX)
  • Compatibility (browsers, devices, platforms)

Generate NFR Coverage Report:

### Non-Functional Requirements Coverage

**Total NFRs:** {total}
**Fully Addressed:** {full_count} ({percentage}%)
**Partially Addressed:** {partial_count} ({percentage}%)
**Missing:** {missing_count}

**Missing NFRs:**
{list of NFRs not addressed}

**Needs Improvement:**
{list of NFRs with weak or generic solutions}

Part 4: Architecture Quality Checks#

Technical Completeness:

Run systematic checklist:

### Architecture Quality Checklist

**System Design:**
- [ ] Architectural pattern is clearly stated and justified
- [ ] System components are well-defined (3-10 components)
- [ ] Component responsibilities are clear
- [ ] Component interfaces are specified
- [ ] Dependencies between components are documented

**Technology Stack:**
- [ ] Frontend technology is selected and justified
- [ ] Backend framework is selected and justified
- [ ] Database choice is explained with rationale
- [ ] Infrastructure approach is defined
- [ ] Third-party services are identified
- [ ] Trade-offs are documented for major tech choices

**Data Architecture:**
- [ ] Core data entities are defined
- [ ] Entity relationships are specified
- [ ] Database design is described
- [ ] Data flow is documented
- [ ] Caching strategy is defined (if applicable)

**API Design:**
- [ ] API architecture is specified (REST, GraphQL, etc.)
- [ ] Key endpoints are listed (10-20 for Level 2, more for 3-4)
- [ ] Authentication method is defined
- [ ] Authorization approach is specified
- [ ] API versioning strategy is stated

**Security:**
- [ ] Authentication design is comprehensive
- [ ] Authorization model is defined
- [ ] Data encryption (at rest and in transit) is addressed
- [ ] Security best practices are documented
- [ ] Secrets management is addressed

**Scalability  &   Performance:**
- [ ] Scaling strategy is defined (horizontal/vertical)
- [ ] Performance optimization approaches are listed
- [ ] Caching strategy is comprehensive
- [ ] Load balancing is addressed

**Reliability:**
- [ ] High availability design is present
- [ ] Disaster recovery approach is defined
- [ ] Backup strategy is specified
- [ ] Monitoring and alerting are addressed

**Development  &   Deployment:**
- [ ] Code organization is described
- [ ] Testing strategy is defined (unit, integration, e2e)
- [ ] CI/CD pipeline is outlined
- [ ] Deployment strategy is specified
- [ ] Environments are defined (dev, staging, prod)

**Traceability:**
- [ ] FR-to-component mapping exists
- [ ] NFR-to-solution mapping exists
- [ ] Trade-offs are explicitly documented

**Completeness:**
- [ ] All major decisions have rationale ( " why " )
- [ ] Assumptions are stated
- [ ] Constraints are documented
- [ ] Risks are identified
- [ ] Open issues are listed

Count:

  • Total checks: {total}
  • Passed: {passed} ({percentage}%)
  • Failed: {failed}

Part 5: Generate Gate Check Report#

Create comprehensive report:

# Solutioning Gate Check Report
**Date:** {date}
**Project:** {project_name}
**Reviewer:** {user_name} (Winston - System Architect)
**Architecture Version:** {version}

---

## Executive Summary

**Overall Assessment:** {PASS | CONDITIONAL PASS | FAIL}

**Summary:**
{2-3 sentence summary of architecture quality and readiness}

**Key Findings:**
- {Finding 1}
- {Finding 2}
- {Finding 3}

---

## Requirements Coverage

### Functional Requirements
- **Total FRs:** {total}
- **Covered:** {covered} ({percentage}%)
- **Missing:** {missing}

{Details from Part 2}

### Non-Functional Requirements
- **Total NFRs:** {total}
- **Fully Addressed:** {full} ({percentage}%)
- **Partially Addressed:** {partial} ({percentage}%)
- **Missing:** {missing}

{Details from Part 3}

---

## Architecture Quality Assessment

**Score:** {passed}/{total} checks passed ({percentage}%)

{Failed checks with details}

---

## Critical Issues (if any)

**Blockers (must fix before proceeding):**
{list of critical gaps}

**Major Concerns (strongly recommend addressing):**
{list of significant issues}

**Minor Issues (nice to have):**
{list of minor improvements}

---

## Recommendations

{3-5 specific recommendations for improvement}

---

## Gate Decision

**Decision:** {PASS | CONDITIONAL PASS | FAIL}

**PASS Criteria:**
- โ‰ฅ90% FR coverage
- โ‰ฅ90% NFR coverage (fully or partially addressed)
- โ‰ฅ80% quality checks passed
- No critical blockers

**CONDITIONAL PASS Criteria:**
- โ‰ฅ80% FR coverage
- โ‰ฅ80% NFR coverage
- โ‰ฅ70% quality checks passed
- Blockers have mitigation plans

**FAIL Criteria:**
-  < 80% FR or NFR coverage
-  < 70% quality checks passed
- Critical blockers without mitigation

**Status:** {PASS/CONDITIONAL/FAIL}

**Rationale:** {why this decision}

**Conditions (if conditional pass):**
{list of items that must be addressed during implementation}

---

## Next Steps

{recommendations based on gate decision}

**If PASS:**
โœ“ Architecture approved! Proceed to Phase 4 (Implementation)

Next: Sprint Planning
Run /sprint-planning to:
- Break epics into detailed stories
- Estimate story complexity
- Plan sprint iterations
- Begin implementation

**If CONDITIONAL PASS:**
โš  Architecture approved with conditions

You may proceed to implementation, but must address:
{list of conditions}

Review these items during sprint planning and early sprints.

**If FAIL:**
โœ— Architecture needs significant work before implementation

Required actions:
{list of required improvements}

Re-run /solutioning-gate-check after addressing these issues.

---

## Appendix: Detailed Findings

{Full details of all checks, FR/NFR mappings, quality assessment}

---

**This report was generated using BMAD Method v6 - Phase 3 (Solutioning Gate)**

Save report:

  • Path: {output_folder}/solutioning-gate-check-{project-name}-{date}.md
  • Use Write tool

Display Summary to User#

Show concise summary:

โœ“ Solutioning Gate Check Complete!

Architecture Assessment:
- FR Coverage: {percentage}%
- NFR Coverage: {percentage}%
- Quality Score: {percentage}%

Gate Decision: {PASS | CONDITIONAL PASS | FAIL}

{Brief rationale}

Full report: {file_path}

Update Status#

If PASS or CONDITIONAL PASS:

Per helpers.md#Update-Workflow-Status:

  1. Update solutioning-gate-check status to "PASS" or "CONDITIONAL"
  2. Add gate check report path
  3. Save status file

If FAIL:

  • Update status to "FAIL"
  • Do NOT proceed to Phase 4
  • User must address issues and re-run

Recommend Next Steps#

If PASS:

Excellent! Your architecture is solid and complete.

โœ“ Ready for Phase 4: Implementation

Next: Run /sprint-planning to:
- Break epics into detailed user stories
- Estimate story points
- Plan sprint iterations
- Begin development with confidence

Your planning documentation is complete:
โœ“ Product Brief
โœ“ PRD
โœ“ Architecture (validated)

If CONDITIONAL PASS:

Your architecture is approved with minor conditions.

โš  Proceed to implementation, but track these items:
{list of conditions}

Next: Run /sprint-planning

Address conditions during early sprints.

If FAIL:

Architecture needs improvement before implementation can begin.

Required actions:
{top 3-5 issues}

After addressing these:
1. Update architecture document
2. Re-run /solutioning-gate-check
3. Then proceed to /sprint-planning

Helper References#

  • Load config: helpers.md#Combined-Config-Load
  • Load status: helpers.md#Load-Workflow-Status
  • Save document: helpers.md#Save-Output-Document
  • Update status: helpers.md#Update-Workflow-Status
  • Recommend next: helpers.md#Determine-Next-Workflow

Validation Logic#

FR Coverage Calculation:

Covered FRs = FRs with component assignments
Coverage % = (Covered / Total) * 100

NFR Coverage Calculation:

Fully Addressed = NFRs with complete architectural solutions
Partially Addressed = NFRs mentioned but solution incomplete
Coverage % = ((Fully + Partial) / Total) * 100

Quality Score Calculation:

Quality % = (Passed Checks / Total Checks) * 100

Pass Thresholds:

  • PASS: FRโ‰ฅ90%, NFRโ‰ฅ90%, Qualityโ‰ฅ80%, No blockers
  • CONDITIONAL: FRโ‰ฅ80%, NFRโ‰ฅ80%, Qualityโ‰ฅ70%, Mitigated blockers
  • FAIL: Below conditional thresholds or critical blockers

Tips for Effective Gate Checks#

Be Objective:

  • Apply consistent criteria
  • Document findings clearly
  • Don't let personal preferences override standards

Be Constructive:

  • Identify issues specifically
  • Suggest concrete improvements
  • Acknowledge what's done well

Be Pragmatic:

  • Perfect is the enemy of good
  • CONDITIONAL PASS is often appropriate
  • Some issues can be addressed during implementation

Be Thorough:

  • Don't skip NFR coverage check
  • Quality checklist matters
  • Traceability ensures nothing is forgotten

Notes for LLMs#

  • Approach: thorough, systematic, quality-focused
  • Use TodoWrite to track 6 validation parts
  • Apply objective pass/fail criteria (no subjective judgment)
  • Generate comprehensive report even if architecture fails
  • If FAIL, provide specific, actionable feedback
  • CONDITIONAL PASS is valid when core architecture is solid but details need work
  • Reference helpers.md for all common operations
  • Update workflow status based on gate decision
  • Hand off to Scrum Master only if PASS or CONDITIONAL PASS

Remember: The gate check protects implementation quality. Better to catch architectural gaps now than discover them mid-development when they're expensive to fix.