Stack Configuration

---
name: stack-configuration
description: Technology stack selection and configuration skill
type: skill
knowledge: [stack-capabilities.json]
---

# Stack Configuration Skill

Configures technology stack based on requirements and matches to available blueprints.

## When to Use

- When configuring a new project's technology stack
- When matching requirements to blueprints
- When customizing stack options

## Prerequisites

- Access to `stack-capabilities.json` knowledge file
- Understanding of available blueprints and their capabilities
- Knowledge of programming languages and frameworks
- Familiarity with testing approaches (TDD, BDD, layered)
- Clear project requirements (language, domain, team size)

## Process

### Step 1: Parse Language Requirements
- Identify primary language
- Check for secondary languages
- Validate language is supported

### Step 2: Identify Frameworks
For each mentioned framework:
- Match to known frameworks in `stack-capabilities.json`
- Identify dependencies
- Check compatibility

### Step 3: Match Blueprint
Search blueprints for best match:

```python
for blueprint in blueprints:
    if blueprint.primaryLanguage == requirements.primaryLanguage:
        match_score = calculate_framework_match(blueprint, requirements)
        if match_score > threshold:
            return blueprint
```

### Step 4: Configure Tools
Based on stack, suggest:
- Test frameworks
- Linters
- Formatters
- Type checkers

### Step 5: Select Testing Approach

Present testing mode options to the user:

```
Select your testing mode:

BASIC MODES:
[ ] tdd-only - Test-Driven Development only
    - Code-based unit tests with Given-When-Then structure
    - Developer-focused, fast feedback
    - No BDD artifacts

[ ] bdd-only - Behavior-Driven Development only
    - Gherkin feature files with step definitions
    - Stakeholder-readable specifications
    - No separate unit tests

[ ] layered - TDD + BDD (Test Pyramid)
    - Unit tests (TDD) for implementation details
    - Acceptance tests (BDD) for business behavior
    - Both maintained independently

TRANSLATION MODES:
[ ] bdd-drives-tdd - Outside-In Development
    - Write BDD scenarios first
    - Generate unit test stubs from scenarios
    - Full traceability from scenario to tests

[ ] tdd-documents-bdd - Documentation Generation
    - Write unit tests normally
    - Generate feature files from tests
    - Stakeholder docs from existing tests

[ ] synchronized - Bidirectional Sync
    - Changes to either propagate to the other
    - Single source of truth with dual views
    - Full traceability and conflict detection
```

Based on selection, configure:

| Mode | TDD | BDD | Translation | Traceability | Practice |
|------|-----|-----|-------------|--------------|----------|
| tdd-only | ✓ | - | - | - | - |
| bdd-only | - | ✓ | - | - | Three Amigos |
| layered | ✓ | ✓ | - | Optional | Three Amigos |
| bdd-drives-tdd | ✓ | ✓ | BDD→TDD | ✓ | Three Amigos |
| tdd-documents-bdd | ✓ | ✓ | TDD→BDD | ✓ | - |
| synchronized | ✓ | ✓ | Bidirectional | ✓ | Three Amigos |

**Translation capabilities:**

| Direction | Description | Use Case |
|-----------|-------------|----------|
| BDD→TDD | Generate test stubs from scenarios | Outside-in development |
| TDD→BDD | Generate features from tests | Legacy documentation |
| Bidirectional | Keep both in sync | Single source of truth |

**Traceability features:**
- Link scenarios to implementing tests
- Link tests back to source scenarios
- Coverage matrix reports
- Orphan detection (unlinked artifacts)

**Framework mapping by stack:**

| Stack | TDD Framework | BDD Framework |
|-------|---------------|---------------|
| Python | pytest | behave, pytest-bdd |
| TypeScript | jest, vitest | cucumber-js |
| Java | JUnit | cucumber-jvm |
| C# | NUnit, xUnit | SpecFlow |
| Kotlin | JUnit, Kotest | cucumber-jvm |

### Step 6: Output Configuration
Generate stack configuration object:

```yaml
stack:
  primaryLanguage: "{LANGUAGE}"
  frameworks:
    - name: "{FRAMEWORK}"
      version: "{VERSION}"
  tools:
    testing: "{TEST_FRAMEWORK}"
    linting: "{LINTER}"
    formatting: "{FORMATTER}"
  testingApproach:
    mode: "{TESTING_MODE}"  # tdd-only, bdd-only, layered, bdd-drives-tdd, tdd-documents-bdd, synchronized
    tdd:
      enabled: true|false
      framework: "{TDD_FRAMEWORK}"
    bdd:
      enabled: true|false
      framework: "{BDD_FRAMEWORK}"
      featureDirectory: "features/"
      stepDirectory: "features/steps/"
    translation:
      enabled: true|false
      direction: "{DIRECTION}"  # bdd-to-tdd, tdd-to-bdd, bidirectional
    traceability:
      enabled: true|false
      reportFormat: "markdown"  # markdown, json, html
  blueprint: "{BLUEPRINT_ID}"
```

**Example configurations by mode:**

```yaml
# bdd-drives-tdd mode
testingApproach:
  mode: "bdd-drives-tdd"
  tdd:
    enabled: true
    framework: "pytest"
  bdd:
    enabled: true
    framework: "behave"
  translation:
    enabled: true
    direction: "bdd-to-tdd"
  traceability:
    enabled: true

# synchronized mode
testingApproach:
  mode: "synchronized"
  tdd:
    enabled: true
    framework: "pytest"
  bdd:
    enabled: true
    framework: "behave"
  translation:
    enabled: true
    direction: "bidirectional"
  traceability:
    enabled: true
```

## Blueprint Matching Rules

| Primary Language | Key Framework | Blueprint |
|------------------|---------------|-----------|
| Python | FastAPI | `python-fastapi` |
| Python | Django | `python-django` |
| TypeScript | React | `typescript-react` |
| TypeScript | Next.js | `typescript-nextjs` |
| Java | Spring | `java-spring` |
| C# | .NET | `csharp-dotnet` |
| ABAP | (any) | `sap-abap` |

## Best Practices

- **Prioritize team familiarity over trendiness**: Choose technologies the team knows well rather than the latest frameworks, unless there's a compelling business reason
- **Verify framework compatibility before selection**: Check version compatibility matrices and known conflicts between frameworks, libraries, and tools in the stack
- **Consider long-term maintenance**: Evaluate community support, update frequency, and migration paths when selecting stack components
- **Document stack decisions and rationale**: Record why specific technologies were chosen so future team members understand the context
- **Plan for testing approach early**: Select testing frameworks and approaches during stack configuration, not as an afterthought
- **Validate blueprint match quality**: Ensure the selected blueprint truly matches project requirements; don't force-fit a blueprint that's only partially compatible

## Fallback Procedures

- **If language not supported**: Report and ask user for alternative
- **If no blueprint matches**: Create custom configuration from patterns
- **If frameworks conflict**: Report conflict and ask user to choose

## References

- `knowledge/stack-capabilities.json`
- `blueprints/*/blueprint.json`