Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a Bonsai IFC Gherkin Acceptance Specification Engine

Format
Code-aware
Lines
81
Sections
11
Linked challenge
Build a Bonsai IFC Gherkin Acceptance Specification Engine

Prompt source

Original prompt text with formatting preserved for inspection.

81 lines
11 sections
No variables
1 code block
## Build
Formulate automated Gherkin acceptance test scenarios for architectural IFC models using ifcbimtester principles. Validate deliverable models before client handover against contractual BIM specifications.

## User
Design assurance manager

## Workflow
1. Parse design requirements into Gherkin feature files specifying mandatory IFC properties.
2. Execute ifcbimtester rules against incoming architectural IFC model structures.
3. Evaluate rule passes, warnings, and non-conformance failures across building levels.
4. Compile an interactive BIM quality assurance certificate detailing conformance metrics.

## Interface
Web verification console showing Gherkin feature files, live run logs, and downloadable compliance certificates.

## Data
Use open-source Gherkin sample tests from the IfcOpenShell bimtester repository combined with synthetic IFC object attributes.
Starter examples below are synthetic. They are not downloaded records.

## Source
[IfcOpenShell](https://raw.githubusercontent.com/IfcOpenShell/IfcOpenShell/v0.8.0/README.md)
Implements ifcbimtester, the Gherkin-based unit testing wrapper for IFC models listed in IfcOpenShell documentation.

## Tools
anthropic-claude, behave, python-ifcopenshell.
Claude accurately translates natural language contract clauses into strict Gherkin syntax without hallucinations.
Hosted Claude API for natural-language-to-Gherkin scenario synthesis and validation check verification.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Converts textual contract clauses into executable Gherkin Given-When-Then test blocks.
- Executes test runs identifying elements violating contractual IFC property rules.
- Generates clean machine-readable test failure dossiers.

## Starter Examples
```json
[
  {
    "input": {
      "contract_rule": "Every external door must have an acoustic rating of at least 30dB and an explicit fire rating.",
      "test_target_model": [
        {
          "guid": "DOOR-EXT-1",
          "type": "IfcDoor",
          "is_external": true,
          "AcousticRating": 32,
          "FireRating": "FD30"
        }
      ]
    },
    "expected_output": {
      "gherkin_feature": "Feature: External Door Acoustic and Fire Compliance\n  Scenario: Validate acoustic and fire attributes\n    Given element IfcDoor is external\n    Then AcousticRating must be >= 30\n    And FireRating must be defined",
      "tested_elements": 1,
      "passed": 1,
      "failed": 0,
      "failures": []
    }
  },
  {
    "input": {
      "contract_rule": "All primary columns on Level 1 must declare structural material strength.",
      "test_target_model": [
        {
          "guid": "COL-L1-A",
          "type": "IfcColumn",
          "level": "L1",
          "material_grade": null
        }
      ]
    },
    "expected_output": {
      "gherkin_feature": "Feature: Column Material Strength Compliance\n  Scenario: Validate column structural material\n    Given element IfcColumn on level L1\n    Then material_grade must be defined",
      "tested_elements": 1,
      "passed": 0,
      "failed": 1,
      "failures": [
        {
          "guid": "COL-L1-A",
          "issue": "Missing material_grade attribute"
        }
      ]
    }
  }
]
```

## Safety
Executes virtual validation tests on BIM files without altering construction documentation or signing off legal contracts.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.