majiayu000 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:
- Invoke
component-researchskill (Skill tool) to evaluate fit - Wait for decision output with Priority 1-6 recommendation
- Only proceed to generate configuration after decision is documented
- 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.ymlnode-sonar-docker.ymlterraform-aws.ymljava-maven-cf.yml
Validation
Use SlashCommand tool with tbc:validate.
Key Principles
- Read schemas first - templates have specific variables, don't hallucinate
- Transform names for component mode - lowercase with hyphens
- Validate before presenting - use
tbc:validate - Respect selection rules - single vs multiple per category
- Document secret variables - they go in GitLab CI/CD settings
- Use
$CI_SERVER_FQDNfor component mode