Building with To-Be-Continuous (TBC)

Knowledge base for generating GitLab CI/CD configurations using the To-Be-Continuous framework.

CRITICAL: Framework-First Principle

NEVER assume a solution. ALWAYS evaluate the framework first.

Before generating any configuration, invoke the component-research skill using the Skill tool:

Skill: component-research

This triggers the Deep Research process to determine:

• Which TBC components fit the use case
• Whether variants are needed
• If custom steps are truly required (rare)

Mandatory Workflow:

1. Invoke component-research skill (Skill tool) to evaluate fit
2. Wait for decision output with Priority 1-6 recommendation
3. Only proceed to generate configuration after decision is documented
4. If Priority 6 (custom step), document WHY TBC doesn't fit

The user may request something and be incorrect about the approach. The component-research skill disciplines correct framework usage before any generation happens.

Overview

To-Be-Continuous (TBC) is a framework of 62 modular templates organized into 8 categories for building GitLab CI/CD pipelines.

Template Categories

| Category | Count | Selection | |----------|-------|-----------| | Build | 15 | Single | | Code Analysis | 7 | Multiple | | Packaging | 3 | Single | | Infrastructure | 1 | Single | | Deployment | 11 | Single | | Acceptance | 10 | Multiple | | Other | 3 | Multiple |

Selection Rules:

• Build, Packaging, Infrastructure, Deployment: SELECT ONE or NONE
• Code Analysis, Acceptance, Other: SELECT MULTIPLE (including none)

Configuration Modes

| Mode | GitLab Version | Syntax | |------|----------------|--------| | component | 16.0+ (recommended) | $CI_SERVER_FQDN/path/template@version | | project | Self-hosted | project: "path" + ref + file | | remote | External | HTTPS URL to template |

Version Modes

| Mode | Syntax | Updates | |------|--------|---------| | major | @7 | Auto major (less stable) | | minor | @7.5 | Auto patch (recommended) | | full | @7.5.2 | None (most stable) |

Generating Configurations

When generating a TBC configuration, read and follow references/create-component.md.

Evaluating Component Fit

Before generating, invoke the component-research skill using the Skill tool. That skill executes the complete decision process with flowcharts and Deep Research protocol.

Reference Files

| Need | Reference | |------|-----------| | Decide if component fits | Invoke component-research skill (Skill tool) | | Complete template catalog | references/templates-catalog.md | | Build templates (15) | references/build-templates.md | | Deployment templates (11) | references/deployment-templates.md | | Analysis templates (7) | references/analysis-templates.md | | Variants (Vault, OIDC) | references/variantes.md | | Common presets | references/presets.md | | Best practices | references/best-practices.md | | Configuration formats | references/configuration-formats.md |

Schemas

All templates have JSON schemas in schemas/. Read schema to get valid inputs, components, and versions:

schemas/{template-name}.json

Example Configurations

Working examples in examples/:

• python-docker-k8s.yml
• node-sonar-docker.yml
• terraform-aws.yml
• java-maven-cf.yml

Validation

Use SlashCommand tool with tbc:validate.

Key Principles

1. Read schemas first - templates have specific variables, don't hallucinate
2. Transform names for component mode - lowercase with hyphens
3. Validate before presenting - use tbc:validate
4. Respect selection rules - single vs multiple per category
5. Document secret variables - they go in GitLab CI/CD settings
6. Use $CI_SERVER_FQDN for component mode