Building with To-Be-Continuous (TBC)

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

Selection Rules:

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

Configuration Modes

Version Modes

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

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