---

name: building-with-tbc description: This skill should be used when the user asks to "generate gitlab-ci.yml", "create GitLab CI pipeline", "configure GitLab CI/CD", "use To-Be-Continuous templates", "setup TBC templates", "create CI/CD for Python/Node/Go/Java project", "configure Docker build in GitLab", "setup Kubernetes deployment in GitLab", "add SonarQube to GitLab CI", "configure Terraform with GitLab", or mentions "TBC", "To-Be-Continuous", "Kicker". version: 1.0.0

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