Triggers#

• When scaffolding full-stack code structure after Design stage completion
• When generating BDD test scaffolding from PRD Acceptance Criteria
• When bootstrapping a new feature module with Clean Architecture layers

Usage#

/cc-product:scaffold
/cc-product:scaffold --feature community --entity Post
/cc-product:scaffold --skip-bdd
/cc-product:scaffold --skip-tests

Options#

Prerequisites#

• Design stage completed (Solutioning Gate passed)
• Architecture Doc (docs/architecture-{slug}.md) exists
• UX Spec (docs/ux-spec-{slug}.md) exists
• PRD (docs/prd-{slug}.md) with Acceptance Criteria exists

Execution Flow#

Phase 1: Feature Extraction#

Source: cc-product (internal)

1. Parse Architecture Doc (docs/architecture-{slug}.md)

   • Extract feature list from architecture layer definitions
   • Identify primary/secondary entity per feature
   • Map feature → Clean Architecture layers (domain, data, presentation)

2. Parse UX Spec (docs/ux-spec-{slug}.md)

   • Extract screen list per feature (list, detail, form, etc.)
   • Identify screen-to-feature mapping

3. Parse PRD (docs/prd-{slug}.md)

   • Extract Acceptance Criteria per feature
   • Map AC → Gherkin-ready scenario descriptions

4. Build Feature Manifest

       features:
     - name: community          # snake_case
       primary_entity: Post      # PascalCase
       secondary_entity: Comment # PascalCase (optional)
       screens: [list, detail, form]
       acceptance_criteria:
         -  " User can view post list " 
          -  " User can create new post " 
          -  " User can add comment to post " 
        brick_match: feature-store  # cc-bricks 의 실제 11개 feature-* 모듈에서 매칭
   

Phase 2: Brick Scaffolding#

Source: cc-bricks

For each feature in the manifest:

1. Brick matching — Match feature name to the closest brick among cc-bricks 의 실제 11개 feature-* 모듈 (skills/ 참조; console brick 없음)

   • Exact match: store → feature-store
   • Keyword match: messaging → feature-chat
   • Fallback: use generic feature structure

2. Run Mason brick per feature

       mason make feature-{brick_name} \
     --project_name {project_name} \
     --org_name {org_name} \
     --org_tld {org_tld} \
     --feature_name {feature_name}
   

3. Verify scaffolded output

       feature/application/{feature_name}/
   ├── lib/src/
   │   ├── domain/        # Entity, UseCase, Repository Interface
   │   ├── data/          # Repository impl, Cache, OpenAPI Mixin
   │   ├── presentation/  # BLoC, Page, Widgets
   │   ├── route/         # GoRouter TypedRoute
   │   └── di/            # Dependency Injection
   └── test/src/          # Test directory structure
   
   backend/{project}_server/feature/{feature_name}/
   ├── model/             # .spy.yaml models
   ├── endpoint/          # CRUD handlers
   ├── service/           # Business logic
   ├── exception/         # Domain exceptions
   └── validation/        # Input validation
   

4. Commit: "feat({scope}): scaffold {feature_name} via mason brick"

Phase 3: BDD Scenario Generation#

Source: cc-flutter (bdd-scenario-agent)

For each feature with screens:

1. Generate .feature draft from PRD Acceptance Criteria, written directly to app/{app}/integration_test/features/{feature_name}.feature (documentation only, never a build target — never written into the feature package)

       /cc-flutter:bdd:generate {feature_name} \
     --entity-name {PrimaryEntity} \
     --screens  " {screen_list} " 
   

   ⛔ No build_runner/co_test_gen/bdd_test_gen/bdd_widget_test step follows this. Nothing under feature/{type}/{feature_name}/ is touched by BDD scaffolding — there is no test/src/bdd/ directory in the feature package, and no builder block is added to that package's build.yaml.

2. Step + Patrol scenario templates (hand-authored, no code generator) — this stage writes TODO-marked template files directly (not via a build tool) into:

   • app/{app}/integration_test/step/*.dart — TestDriver-based step function templates
   • app/{app}/integration_test/scenarios/{feature_name}_{scenario}_test.dart — Patrol test template; a human copies the .feature Scenario name and step order in during Development

   /// Usage: Given I am on the post list page
   /// Purpose: Navigate to post list page
   Future<void> iAmOnThePostListPage(TestDriver driver) async {
     // TODO: Implement step - fill in by hand during Development
     throw UnimplementedError('Step not yet implemented');
   }
   

   Reuse canonical shared steps from package:test_driver/shared_steps.dart before writing a new local step — see cc-flutter:bdd-canonical-steps.

3. Commit: "test({scope}): draft BDD scenario and step templates for {feature_name}"

Phase 4: Scaffold Gate#

Scaffold Gate verification per feature:

Gate fails if any check does not pass. Scaffold is revised with feedback.

Artifacts#

feature/application/{feature_name}/                 # Scaffolded feature code (per feature) — no BDD files
backend/{project}_server/feature/{name}/             # Scaffolded backend code (per feature)
app/{app}/integration_test/features/{feature}.feature            # BDD feature files (documentation, never a build target)
app/{app}/integration_test/step/                                 # Step function templates (hand-filled, no code generator)
app/{app}/integration_test/scenarios/{feature}_{scenario}_test.dart  # Patrol E2E test templates (hand-filled)

After Completion#

• Verify Scaffold Gate passed
• Update .pipeline/{slug}.yaml state
• Present context-clear handoff:

✅ Scaffold stage complete (Scaffold Gate PASSED).
  - {N} features scaffolded via Mason bricks
  - {M} .feature draft files generated
  - {K} Patrol E2E test templates created (hand-filled, no code generator)
  - {S} step function templates created (to be implemented in Development)

**Option 1 (Recommended)**: Clear context and continue to Issue Breakdown
  /clear
  Then run: /cc-product:breakdown

**Option 2**: Continue in current context
  Proceed directly to /cc-product:breakdown

Notes#

• Step function stubs are intentionally unimplemented (throw UnimplementedError) — they become the DoD for each Story in the Development stage
• The BDD Coverage Gate (Step 8.3 in /cc-dev:run) will enforce that all step stubs are implemented before PR creation
• Brick selection uses a best-match heuristic; use --brick to override if the auto-match is incorrect
• For features without a matching brick, the scaffold phase creates a minimal Clean Architecture directory structure