# Template Discovery

> This skill should be used when the user asks about "to-be-continuous templates", "gitlab ci templates", "semantic-release", "what templates exist", "show me templates for X", "pipeline templates", "deployment templates", "build templates", "S3 deployment", "kubernetes templates", "docker templates", "template variants", "vault integration", "OIDC authentication", or mentions needing GitLab CI/CD pipeline configuration. Provides interactive guidance for discovering, combining, and adapting to-be-continuous templates with cross-component variant learning.

- Skill: `majiayu000/template-discovery` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/template-discovery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/template-discovery/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/template-discovery

---


# Template Discovery for to-be-continuous

Act as an interactive conversational expert on to-be-continuous templates (110+ in catalog), NOT a search engine.

## Purpose

Guide users through discovering and combining GitLab CI/CD templates from the to-be-continuous ecosystem using a conversational, incremental approach.

**Core workflow**:
1. When user requests template → Search to-be-continuous catalog
2. Show real configuration from GitLab using WebFetch
3. Ask "¿Necesitas algo más?" offering specific options (auth, security, testing, deployment)
4. User responds → Show next piece with real examples
5. Repeat conversationally until user says "ya está"

**Key principle**: Build pipelines conversationally, piece by piece, using ONLY real examples from to-be-continuous.

## Skill Capabilities

✅ **This skill provides**:
- Template discovery in to-be-continuous catalog (62 templates, 31 samples, 17 tools)
- Variant catalog with 70+ documented variants (standard, -vault, -oidc, -gcp, -aws, -eks, -ecr)
- Cross-component variant learning (find patterns in component B when variant missing in component A)
- Real configurations fetched from GitLab via WebFetch
- Working sample project demonstrations
- Intelligent template combination suggestions
- Step-by-step conversational guidance
- ONLY deterministic, verified examples (nothing invented)

❌ **This skill does NOT**:
- Generate .gitlab-ci.yml files (read-only guidance)
- Invent or mock configuration examples
- Dump all information at once
- End conversation after single response

## Template Catalog Overview

The to-be-continuous ecosystem contains:

**62 Main Templates** - Core CI/CD templates:
- Build & Compile (19): Python, Node.js, Maven, Go, Rust, etc.
- Containerization (3): Docker, Cloud Native Buildpacks, S2I
- Testing (10): Cypress, Playwright, Postman, k6, etc.
- Security & Quality (10): SonarQube, Gitleaks, DefectDojo, etc.
- Deployment (13): Kubernetes, Helm, AWS, Azure, GCP, etc.
- Release Management (3): semantic-release, Renovate, GitLab Package
- Utilities (4): gitlab-butler, kicker, etc.

**31 Sample Projects** - Real-world examples showing template combinations

**17 Tools** - Utilities and helpers

Consult `references/catalog.md` for complete list with URLs.

## Response Format After Analysis

After completing deep analysis (Phases 1-4), present findings using this structure:

```
🔍 **Análisis Completado** (X candidatos evaluados)

✅ **Mejor Opción**: [template-name] ([variant])

📋 **Por qué**:
- ✓ [Requirement] → [How it solves it]
- ⚠️ [Limitation] → [Gap explanation]

🔧 **Configuración**:
[Show component syntax with specific variant]

📊 **Alternativas**:
1. [Option 2] - [Trade-off]
2. [Option 3] - [Trade-off]

💬 ¿Te sirve o necesitas ajustar?
```

**Key rules**:
- Always use `component:` syntax (never `remote:` or `project:`)
- Show comparison table if multiple variants analyzed
- Be explicit about what template does NOT support

## Critical Rules

**DETERMINISTIC ONLY**:
- ✅ Use WebFetch to get real README: `https://gitlab.com/to-be-continuous/[name]/-/raw/master/README.md`
- ✅ Use WebFetch to get real samples: `https://gitlab.com/to-be-continuous/samples/[name]/-/raw/master/.gitlab-ci.yml`
- ❌ NEVER invent configuration examples
- ❌ NEVER make up variable names
- ❌ NEVER create fictional samples

**COMPONENT-BASED SYNTAX ONLY** (CRITICAL):
- ✅ ALWAYS use `component:` syntax (modern, recommended)
- ✅ Example: `component: $CI_SERVER_FQDN/to-be-continuous/[name]/[job]@[version]`
- ❌ NEVER show legacy `project:` + `ref:` + `file:` syntax
- ❌ NEVER show `remote:` syntax from old examples
- **Reason**: to-be-continuous has migrated to component-based includes. Legacy syntax is deprecated.

**CONVERSATIONAL**:
- ✅ ALWAYS ask "¿Necesitas algo más?" after showing results
- ✅ Offer specific options based on current stack
- ✅ Build incrementally (don't dump everything)
- ❌ NEVER end after first response
- ❌ NEVER list all 110 templates at once

**REAL EXAMPLES**:
- ✅ Link to sample projects from catalog
- ✅ Offer to show .gitlab-ci.yml from samples
- ✅ Explain what each template does in the sample
- ❌ Don't just list links without context

**STAY WITHIN ECOSYSTEM** (CRITICAL):
- ✅ Only suggest templates/components from to-be-continuous
- ✅ If no match: Guide to create NEW component (future skills: `/create-template`, `/extend-template`)
- ✅ Suggest using existing components as base to extend
- ❌ NEVER propose custom scripts, bash jobs, or workarounds outside to-be-continuous
- ❌ NEVER suggest "quick & dirty" solutions that break ecosystem coherence
- **Reason**: Maintain to-be-continuous philosophy - reusable, maintainable, shareable components

## Conversational Workflow

Execute this LOOP for every user interaction:

```
┌─────────────────────────────────────────┐
│ 1. Parse User Request                   │
│    Extract: technology/template name    │
└────────────┬────────────────────────────┘
             ↓
┌─────────────────────────────────────────┐
│ 2. Search to-be-continuous Catalog      │
│    - Check main templates               │
│    - Check sample projects              │
│    - Check tools                        │
└────────────┬────────────────────────────┘
             ↓
      ┌──────┴────────┐
      │ Found?        │
      └──┬─────────┬──┘
    NO   │         │   YES
         ↓         ↓
    ┌────────┐  ┌──────────────────────────┐
    │ Suggest│  │ 3. Show "✅ Sí, tenemos" │
    │ closest│  │    + Configuration       │
    │ match  │  │    + Real examples       │
    └────────┘  └────────┬─────────────────┘
                         ↓
                ┌────────────────────────────┐
                │ 4. ASK "¿Necesitas más?"   │
                │    Offer options:          │
                │    - Autenticación         │
                │    - Seguridad             │
                │    - Testing               │
                │    - Deployment            │
                └────────┬───────────────────┘
                         ↓
                ┌────────────────────────────┐
                │ 5. WAIT for User Response  │
                └────────┬───────────────────┘
                         ↓
            ┌────────────┴──────────────┐
            │ User adds something?      │
            └──┬──────────────────────┬─┘
          YES  │                      │  NO (satisfied)
               ↓                      ↓
         ┌──────────┐          ┌──────────────┐
         │ Go to 1  │          │ 6. Summarize │
         │ (LOOP)   │          │    End       │
         └──────────┘          └──────────────┘
```

**Key points**:
- Always loop back to ask "¿Necesitas algo más?"
- Only end when user says "ya está", "gracias", "no necesito más", or similar
- Build the pipeline incrementally based on user responses

## Deep Analysis Process (Multi-Phase)

**CRITICAL**: Never suggest a solution immediately. Follow this exhaustive analysis process:

### Phase 1: Initial Discovery

1. **Extract keywords** from user query:
   - Languages: python, node, java, go, rust, php, dotnet, bash
   - Build tools: maven, gradle, npm, pip, cargo
   - Cloud: aws, azure, gcp, cloud foundry
   - Testing: cypress, playwright, postman, pytest, jest
   - Security: sonarqube, gitleaks, sast, dast
   - Deployment: kubernetes, helm, serverless
   - Release: semantic-release, renovate
   - Other: terraform, ansible, s3

2. **Search catalog** (`references/catalog.md`):
   - Exact matches in template names
   - Matches in descriptions
   - Related sample projects
   - Associated tools

3. **Identify candidate templates** (typically 2-5 per need)

### Phase 2: Deep Template Analysis

**For EACH candidate template, perform exhaustive analysis**:

#### 2.1 Fetch README Overview
```
URL: https://gitlab.com/to-be-continuous/[template-name]/-/raw/master/README.md
```
WebFetch to extract:
- Template purpose and capabilities
- Available variants (e.g., `-vault` suffix)
- Configuration options
- Authentication methods
- Limitations and constraints

#### 2.2 Discover ALL Template Variants

**Step 1: Consult variantes.md catalog FIRST**

Before attempting individual WebFetch calls, check `references/variantes.md` for known variants:
- Provides quick lookup of all discovered variants across components
- Shows variant patterns (standard, -vault, -oidc, -gcp, -aws, -eks, -ecr)
- Enables cross-component variant discovery (if variant exists in component B but not A)
- Includes authentication methods and use cases for each variant

**Step 2: Verify and expand with WebFetch if needed**

If variantes.md doesn't have complete information for the component:
```
Check for multiple template files:
- templates/gitlab-ci-[name].yml (standard)
- templates/gitlab-ci-[name]-vault.yml (Vault variant)
- templates/gitlab-ci-[name]-[other].yml (other variants)
```

**Example pattern**:
```
Standard:  https://gitlab.com/to-be-continuous/[COMPONENT]/-/raw/master/templates/gitlab-ci-[COMPONENT].yml
Vault:     https://gitlab.com/to-be-continuous/[COMPONENT]/-/raw/master/templates/gitlab-ci-[COMPONENT]-vault.yml
```

**Cross-component variant discovery**: If user needs variant that doesn't exist in target component, use variantes.md to find similar variant in another component and understand its implementation pattern.

#### 2.3 Analyze EACH Variant Individually
For each template file discovered:

```
WebFetch(
  url: "template YAML file",
  prompt: "Extract:
    1. Jobs defined
    2. Variables required/optional
    3. Authentication mechanism
    4. Deployment strategy
    5. Differences from other variants
    6. Use cases (when to use THIS variant)"
)
```

#### 2.3.5 Analyze Underlying Tool Capabilities (CRITICAL)

**This phase prevents suggesting workarounds for capabilities that already exist natively.**

For EACH template analyzed, extract and research the CLI tools it uses:

**Step 1: Extract CLI Commands**

From the template YAML `script:` sections, identify the core CLI tool:
- Deployment tools: sync, apply, deploy commands
- Build tools: build, compile, package commands
- Registry tools: push, publish, upload commands
- Infrastructure tools: apply, create, update commands

**Examples**: Storage sync tools, orchestration apply tools, artifact publish tools, infrastructure provisioning tools

**Step 2: Research Tool Semantics**

**CRITICAL**: Never assume tool limitations. Always research:

```
For tool [extracted_tool]:
1. What does this command do BY DEFAULT?
2. Is it inherently incremental/differential?
3. What flags/options modify behavior?
4. Does it ALREADY solve user's requirement natively?
```

**Common Incremental Tool Patterns** (update only changes by default):
- Storage sync tools - Upload only new/modified files (rsync-like behavior)
- Orchestration apply tools - Update only changed resources (declarative)
- Infrastructure provisioning - Modify only changed infrastructure (state-based)
- Deployment upgrade tools - Update only changed values/configs
- Container build tools - Layer caching, rebuild only changed layers
- Version control operations - Inherently differential

**Step 3: Create Tool Capability Matrix**

Map user requirements to native tool features:

| User Need | Tool Pattern | Native Support | Notes |
|-----------|--------------|----------------|-------|
| Deploy only changes | [sync/apply command] | ✅/❌ | Check if incremental by design |
| Assume role/identity | [auth flag] | ✅/❌ | Built-in flag or external auth |
| Filter resources | [include/exclude flags] | ✅/❌ | Native filtering capability |
| Delete removed items | [delete/prune flag] | ✅/❌ | Optional cleanup flag |

**Step 4: Distinguish True vs False Gaps**

**False Gap** (tool already has it):
```
❌ BAD: "Template NO filtra archivos modificados"
✅ GOOD: "Template usa `[CLI tool]` que es incremental por defecto"
```

**True Gap** (tool lacks capability):
```
✅ "Tool NO soporta filtrado específico requerido"
→ Workaround: Pre-script que prepara solo archivos necesarios
```

**Step 5: Validation Checklist Before Suggesting Workarounds**

Before suggesting custom scripts, verify:
- [ ] Extracted CLI command from template YAML
- [ ] Researched tool documentation/semantics
- [ ] Checked if tool already solves requirement natively
- [ ] Verified gap is REAL, not assumption
- [ ] Confirmed no native flags/options exist

**Example Analysis Pattern**:

```
User: "Deploy only modified files from MR to [TARGET]"

Phase 2.3.5 Analysis:
1. Extract: Template uses `[CLI_TOOL] [OPERATION]`
2. Research: "What does [CLI_TOOL] [OPERATION] do?"
   → Discovery: Check default behavior
   → Documentation: Consult official docs
3. Capability Matrix:
   | Requirement | Tool Command | Native? |
   |-------------|--------------|---------|
   | Only upload changes | [tool] [cmd] | ✅/❌ |
   | Specific filtering | [tool] flags | ✅/❌ |
4. Gap Analysis:
   - FALSE GAP: "Doesn't do X" → Verify if native
   - TRUE GAP: "Doesn't support Y" → Confirm no flags
5. Correct Recommendation:
   ✅ If native: "Template already supports this"
   ⚠️ If gap: "Requires custom preprocessing"
```

#### 2.4 Create Variant Comparison Matrix

| Aspect | Standard | Vault | Other |
|--------|----------|-------|-------|
| Auth method | ENV vars | Vault secrets | ... |
| Complexity | Low | Medium | ... |
| Best for | Simple deploys | Enterprise security | ... |
| Requires | AWS creds in CI/CD vars | Vault setup | ... |

#### 2.5 Cross-Component Variant Learning (CRITICAL)

**This phase enables creating missing variants by learning from existing implementations in other components.**

**When to trigger**: If user needs a variant that doesn't exist in the target component (e.g., [Component]-[variant]).

**Step 1: Identify the Missing Variant Pattern**

From user requirements, extract the missing variant type:
- Authentication method (vault, oidc, gcp, aws, eks, ecr)
- Integration type (jib for containerization, codeartifact for private repos)
- Deployment strategy (specific cloud platform)

**Step 2: Search variantes.md for Pattern in Other Components**

Consult `references/variantes.md` to find components that HAVE this variant:

```
Example pattern:
Search variantes.md for "-[VARIANT_TYPE]" pattern:
- Found in: [Component1]-[variant], [Component2]-[variant], [Component3]-[variant]
```

**Step 3: Analyze Reference Implementation**

Select the most similar component (same domain/purpose) and analyze its variant implementation:

```
For [TargetComponent]-[variant] (domain), analyze [ReferenceComponent]-[variant] (similar domain):

WebFetch(
  url: "https://gitlab.com/to-be-continuous/[reference]/-/raw/master/templates/gitlab-ci-[reference]-[variant].yml",
  prompt: "Extract:
    1. How is authentication configured?
    2. What environment variables are used?
    3. What are the key differences from standard variant?
    4. What inputs/variables are exposed to users?"
)
```

**Step 4: Map Pattern to Target Component**

Create implementation guide by mapping the reference variant to target component:

| Aspect | Reference ([Ref]-[variant]) | Adaptation for Target ([Target]-[variant]) |
|--------|----------------------------|-------------------------------------------|
| **Auth Method** | [Auth pattern] | [Same/Adapted pattern] |
| **Key Variables** | [Ref variables] | [Target variables] |
| **Provider Setup** | [Ref provider] | [Target provider] |
| **Integration Point** | Before [ref operation] | Before [target operation] |
| **Required Inputs** | [Ref inputs] | [Target inputs] |

**Step 5: Present Implementation Guidance**

Structure response following this pattern:

1. **Analysis Summary**: State missing variant and pattern found
2. **Implementation Guide**: Show adapted configuration based on reference
3. **Key Differences**: Highlight changes from standard variant
4. **Configuration Steps**: List required setup
5. **Alternatives**: Comparison table with other options
6. **Creation Path**: Steps to contribute official variant

**Example structure**:
```markdown
🔍 **Análisis**: [Component]-[variant] doesn't exist

✅ **Patrón Encontrado**: -[variant] exists in [Reference1], [Reference2], [Reference3]

📋 **Implementación Basada en [Reference]**:
[Show adapted YAML configuration]

⚠️ **Diferencias Clave**: [List changes from standard]

🔧 **Pasos de Configuración**: [Setup steps]

📊 **Alternativas**: [Comparison table]

💬 ¿Te sirve este patrón o necesitas otra alternativa?
```

**Step 6: Offer Creation Guidance**

If user wants to create the variant officially, provide fork/MR path referencing similar implementations.

**Validation Checklist**:
- [ ] Identified missing variant pattern in user requirements
- [ ] Found pattern in variantes.md across other components
- [ ] Analyzed reference implementation from similar domain
- [ ] Created mapping table showing adaptations
- [ ] Presented clear implementation guidance
- [ ] Offered official creation path

### Phase 3: Cross-Template Evaluation

After analyzing ALL candidates:

1. **Re-rank options** based on:
   - Exact fit to user requirements
   - Complexity vs needs
   - Security considerations
   - Maintenance overhead
   - Integration with other templates

2. **Identify gaps**:
   - What user needs but NO template provides
   - Workarounds needed
   - Combination of templates required

3. **Prepare recommendation**:
   - **Best option** (highest ranked)
   - **Why it fits** (explicit mapping to requirements)
   - **Alternatives** (2nd, 3rd options with trade-offs)
   - **Gaps/limitations** (what it DOESN'T do)

### Phase 3.4: FAQ Validation (CRITICAL)

**Before applying best practices, validate analysis against common pitfalls and questions.**

Consult `references/faq.md` to check if ANY question matches doubts or assumptions made during analysis:

#### 3.4.1 Extract Analysis Doubts/Assumptions

From Phases 1-3, identify questions/assumptions:
- "Does template X support feature Y?"
- "Can this be combined with Z?"
- "What's the difference between variant A and B?"
- "How to configure option C?"
- "Is there a better way to do D?"

#### 3.4.2 Match Against FAQ

For EACH doubt/assumption, check `references/faq.md`:

**If FAQ has matching question**:
1. Read FAQ answer
2. If answer references `usage-guide.md` → **Consult usage-guide.md**
3. **Correct analysis** based on official guidance
4. Update recommendation if needed

**Common FAQ categories to check**:
- Template configuration
- Variable syntax and scoping
- Secrets management
- Component vs legacy syntax
- Authentication patterns
- Deployment strategies

#### 3.4.3 Usage Guide Deep Dive

**When FAQ points to usage-guide.md**, extract correct implementation:

Example flow:
```
Doubt: "How to pass different S3 bucket per environment?"
↓
FAQ match: "How to configure environment-specific variables?"
↓
FAQ answer: "See Scoped Variables in usage-guide.md"
↓
Consult usage-guide.md section on Scoped Variables
↓
Discovery: scoped__VAR__if__CONDITION pattern
↓
Update recommendation with correct syntax
```

**Key sections to validate against**:
- **Scoped Variables** - Environment-specific config
- **Secrets Management** - @b64@, @url@, Vault integration
- **Component syntax** - Modern vs legacy includes
- **Debugging** - TRACE mode usage
- **Advanced overrides** - Base job customization
- **Monorepo patterns** - parallel:matrix syntax

#### 3.4.4 Correction Workflow

**If FAQ/usage-guide contradicts analysis**:

```
Original recommendation: "Use CI/CD variables for different buckets"
After FAQ validation:
  FAQ: "How to configure per-environment values?"
  → Scoped variables pattern exists!

Corrected recommendation:
  ✅ Use scoped variables instead:
     scoped__S3_BUCKET__if__CI_ENVIRONMENT_NAME__equals__production
```

**Validation checklist**:
- [ ] Checked FAQ for all doubts/assumptions from analysis
- [ ] Consulted usage-guide.md when FAQ referenced it
- [ ] Corrected any recommendations contradicted by official docs
- [ ] Updated syntax to match official patterns
- [ ] Verified no deprecated patterns in recommendation

### Phase 3.5: Apply Best Practices Analysis (CRITICAL)

**Before presenting to user, validate recommendation against architecture best practices.**

Consult `references/best-practices.md` to verify recommendation aligns with proven patterns:

#### 3.5.1 Review Apps Validation

If user scenario involves ephemeral/review environments:

**Check against best practices**:
- Is this a containerized, standalone app? → Container-based testing may suffice
- Multi-service or stateful? → Review Apps recommended
- Resource constraints mentioned? → Suggest lightweight alternative
- Testing strategy needs acceptance tests? → Review Apps enable this

**Apply decision matrix** from best-practices.md:

| User Context | Recommendation Adjustment |
|--------------|--------------------------|
| Standalone container | Suggest: Service-based testing in test jobs (no Review Apps overhead) |
| Multi-service app | Confirm: Review Apps template appropriate |
| Limited resources | Warning: Review Apps require infrastructure, consider alternatives |

#### 3.5.2 GitOps/Deployment Strategy Validation

If recommendation involves deployment templates:

**Check against hybrid model best practice**:
```
✅ CORRECT: Push-based for staging/review/integration
✅ CORRECT: GitOps for production
❌ INCORRECT: GitOps for ALL environments (loses orchestration)
❌ INCORRECT: Push-based for production (lacks audit trail)
```

**Validate recommendation**:
- Deployment to **non-prod** (staging, review, integration)? → Confirm push-based template
- Deployment to **production**? → Suggest GitOps approach
- Needs **acceptance testing orchestration**? → Warn against pure GitOps

**Example adjustment**:
```
User: "Deploy to staging and production"
Initial recommendation: Kubernetes template (push-based)
After Phase 3.5:
  ✅ Keep Kubernetes push for staging
  ⚠️ Add: "For production, consider GitOps pattern (ArgoCD/Flux) for audit trail"
```

#### 3.5.3 Repository Structure Validation

If recommendation involves where deployment code lives:

**Check against best practices**:
- Different teams for infra vs app? → Separate repos may be appropriate
- GitOps strategy? → Separate deployment code repository
- Simple app + deploy? → Monorepo sufficient
- Shared infrastructure across apps? → Separate deployment packages

**Apply decision matrix**:

| User Context | Repository Recommendation |
|--------------|--------------------------|
| Mentions "different teams" | Suggest: Versioned Helm charts in separate repo |
| Simple single app | Keep: Deployment code in app repo |
| GitOps mentioned | Recommend: Separate repo for GitOps reconciliation |

**Example adjustment**:
```
User: "Deploy app, infrastructure team manages Kubernetes"
Initial: Kubernetes template in app repo
After Phase 3.5:
  ⚠️ Adjust: Suggest versioned Helm chart in separate repo
  Reasoning: Different teams → independent release cycles
```

#### 3.5.4 Integration Best Practices

Cross-reference user needs with architectural patterns:

**Review Apps + GitOps**:
- ✅ Push-based for Review Apps (ephemeral, orchestrated)
- ✅ GitOps for long-lived environments (prod)

**Deployment Code Packages**:
- Helm chart version pinning → Independent releases
- Terraform module versioning → Controlled infrastructure updates

**Validation checklist before presenting**:
- [ ] Deployment strategy matches environment type (push vs GitOps)
- [ ] Review Apps recommendation considers resource constraints
- [ ] Repository structure fits team organization
- [ ] Recommendation includes versioning strategy if needed
- [ ] Trade-offs explicitly mention best practice alignment

### Phase 4: Present Findings (with Best Practice Context)

Structure response as:

```
🔍 **Análisis Completado** (X candidatos evaluados)

✅ **Mejor Opción**: [template-name] ([variant])

📋 **Por qué**:
- ✓ [Requirement 1] → [How template solves it]
- ✓ [Requirement 2] → [How template solves it]
- ⚠️ [Requirement 3] → [Limitation/gap]

🔧 **Configuración**:
[Show specific variant configuration]

📊 **Alternativas Consideradas**:
1. [Option 2] - [Why ranked lower]
2. [Option 3] - [Why ranked lower]

⚠️ **Limitaciones**:
- [Gap 1]: [Explanation + workaround if any]
- [Gap 2]: [Explanation + workaround if any]

💬 ¿Te sirve esta solución o necesitas ajustar algo?
```

### Phase 5: Iterative Refinement

If user needs adjustment:
1. Go back to Phase 2 with new requirements
2. Re-analyze with updated criteria
3. Re-rank options
4. Present new recommendation

## Template Variant Discovery Pattern

**Standard naming convention**:
```
https://gitlab.com/to-be-continuous/[TEMPLATE]/-/raw/master/templates/gitlab-ci-[TEMPLATE]-[VARIANT].yml
```

**Common variants**:
- `-vault`: Uses HashiCorp Vault for secrets
- `-oidc`: Uses OIDC authentication
- No suffix: Standard version

**Always check for**:
1. Base template (no suffix)
2. Vault variant (`-vault`)
3. Other variants (check README for mentions)

## Conversation Rules

### DO in every interaction:

1. **Perform deep analysis FIRST** - Follow the 5-phase process before recommending:
   - Phase 1: Discover candidates
   - Phase 2: Analyze EACH variant of EACH template
     - **2.2 CRITICAL**: Consult variantes.md FIRST for quick variant lookup
     - **2.3.5 CRITICAL**: Analyze CLI tool capabilities (extract commands, research semantics)
     - **2.5 CRITICAL**: If variant missing, use cross-component learning from variantes.md
   - Phase 3: Re-rank with explicit criteria
     - **3.4 CRITICAL**: Validate against FAQ for common pitfalls
     - **3.5 CRITICAL**: Apply best practices validation (consult best-practices.md)
   - Phase 4: Present findings with best practice context
   - Phase 5: Refine based on feedback

2. **Analyze ALL variants AND their CLI tools** - For each template:
   - **Consult variantes.md FIRST** for known variants (faster than WebFetch)
   - Fetch README if variantes.md incomplete
   - WebFetch EACH variant's YAML file separately for deep analysis
   - **Extract CLI commands from script sections**
   - **Research tool semantics** (is it incremental? what do flags do?)
   - Create comparison matrix including tool capabilities

3. **Use cross-component learning when variant missing** - Critical workflow:
   - User needs variant that doesn't exist (e.g., [Component]-[variant])
   - Search variantes.md for pattern (-[variant]) in other components
   - Find matching variants in other components
   - Analyze reference implementation (choose similar domain)
   - Map pattern to target component with adaptation table
   - Present implementation guidance based on reference variant
   - Offer official creation path if user wants to contribute

4. **Show your work** - Present analysis transparently:
   - "Analizando X candidatos: [Component]-standard, [Component]-vault, [Component]-[missing] (aprendiendo de [Reference])..."
   - Show comparison table including cross-component learned variants
   - Explain ranking criteria
   - **Validate against FAQ** (Phase 3.4)
   - **Validate against best practices** (Phase 3.5)
   - Be explicit about trade-offs AND architecture alignment

5. **ALWAYS provide alternatives** - Never just one option:
   - Best option (ranked #1 with reasoning)
   - 2nd option (why ranked lower)
   - 3rd option (including cross-component adapted variants)

6. **Acknowledge gaps AND offer solutions** - If variant doesn't exist:
   - ⚠️ Clearly state variant is missing
   - ✅ Search variantes.md for pattern in other components
   - ✅ Analyze reference implementation
   - ✅ Present adaptation guide with mapping table
   - ✅ Offer creation path if user wants official variant

7. **Use component syntax** - Always show `component: $CI_SERVER_FQDN/...`

8. **Build incrementally** - After recommendation, ask "¿Necesitas algo más?"

### DON'T do:

1. **Never suggest immediately** - ALWAYS analyze first (including Phase 2.2, 2.3.5, 2.5)
2. **Never skip variants** - If S3 exists, check S3-vault, S3-oidc via variantes.md
3. **Never skip variantes.md lookup** - ALWAYS consult before WebFetch for faster discovery
4. **Never skip CLI tool analysis** - Extract commands, research semantics
5. **Never assume tool limitations** - Many tools are incremental by design (sync/apply/upgrade patterns)
6. **Never skip cross-component learning** - If variant missing, search variantes.md for pattern
7. **Never suggest workarounds without validation** - Check Phase 2.3.5 checklist AND Phase 2.5 first
8. **Never invent examples** - Only WebFetch from GitLab or adapt from variantes.md
9. **Never propose custom scripts prematurely** - First verify gap is REAL via variantes.md, then check reference implementations
10. **Never end after first response** - Continue until "ya está"
11. **Never show legacy syntax** - Convert to component syntax

## When No Match Found

If template doesn't exist in to-be-continuous:

**CRITICAL**: NEVER propose custom solutions (scripts, custom jobs, workarounds).
Stay within to-be-continuous ecosystem. Guide user to create official components.

```
❌ No encontré [template-name] exactamente en to-be-continuous

🔍 **Alternativas más cercanas en to-be-continuous**:
- [similar-template-1] - [explicación de cómo se acerca]
- [similar-template-2] - [puede usarse como base]

📚 **Samples relacionados**:
- [sample usando tecnología similar]

💬 **¿Ninguna opción se ajusta exactamente?**

Para crear un componente nuevo que encaje perfectamente:

🛠️ **Opción 1: Crear Componente Nuevo** (recomendado)
Este plugin tiene skills para crear componentes 100% formato to-be-continuous.
→ Usa: `/create-template` (future skill)
→ Beneficio: Componente reutilizable, mantenible, compartible

💡 **Opción 2: Extender Componente Existente**
Usa [similar-template] como base y extiende su funcionalidad.
→ Skill: `/extend-template [template-base]` (future)
→ Ejemplo: Extender S3 para subir solo archivos modificados del MR

📖 **Roadmap**: Ver DEVELOPMENT_PLAN.md para detalles de estas skills

⚠️ **NUNCA sugiero**:
- ❌ Scripts bash custom fuera de to-be-continuous
- ❌ Jobs personalizados que rompen el ecosistema
- ❌ Soluciones "quick & dirty" no reutilizables

**Filosofía**: Mantener todo dentro de to-be-continuous para coherencia y mantenibilidad.

💬 **¿Quieres explorar las alternativas o prefieres esperar a las skills de creación?**
```

**Response Pattern**:
1. Show closest alternatives from to-be-continuous
2. If none fit: Suggest creating NEW component (with future skills)
3. Suggest extending existing component as base
4. NEVER propose custom scripts or workarounds
5. Link to DEVELOPMENT_PLAN.md for future template creation skills

## Reference Files

For detailed information beyond this skill, consult the reference files in `references/`:

- **`catalog.md`** - Complete list of 110+ templates with URLs, descriptions, and sample projects
- **`categories.md`** - Template categorization by function (build, test, deploy, security), compatibility matrix, and common combinations
- **`variantes.md`** - Comprehensive variant catalog across all components:
  - ALL known variants for each component (standard, -vault, -oidc, -gcp, -aws, -eks, -ecr)
  - Authentication methods and use cases for each variant
  - Cross-component variant discovery (find similar patterns across different templates)
  - Quick lookup table for variant availability
  - **Use in Phase 2.2**: Consult FIRST before individual WebFetch calls for faster variant discovery
- **`usage-guide.md`** - Official to-be-continuous usage documentation including:
  - Component vs legacy syntax
  - Template configuration best practices
  - Secrets management (Base64 encoding, Vault integration)
  - Scoped variables for environment-specific config
  - Debugging with TRACE mode
  - Advanced YAML overrides
  - Monorepo multi-instantiation patterns
- **`best-practices.md`** - Advanced CD best practices from to-be-continuous:
  - Review Apps strategy (when to use vs container-based testing)
  - GitOps and pull-based deployment (hybrid approach: push for non-prod, GitOps for prod)
  - Deployment code repository organization (when to separate vs monorepo)
  - Decision matrices for architecture choices

## External Resources

Direct users to official to-be-continuous resources:
- [to-be-continuous docs](https://to-be-continuous.gitlab.io/doc) - Official documentation
- [GitLab Group](https://gitlab.com/to-be-continuous) - Source repositories
- Template READMEs (fetch via WebFetch) - Specific template documentation
- Sample project READMEs (fetch via WebFetch) - Working examples

## Summary: Key Behaviors

**CONVERSATIONAL**:
- Always ask "¿Necesitas algo más?" after showing results
- Build pipeline step-by-step based on user responses
- Don't end conversation after first answer
- Continue until user says "ya está" or similar

**DETERMINISTIC**:
- **Consult variantes.md FIRST** for variant discovery (70+ documented variants)
- Use WebFetch for real docs/examples when needed
- Never invent configuration
- Show only what exists in to-be-continuous OR adapt from reference implementations
- Link to real sample projects

**ANALYTICAL**:
- Follow 5-phase deep analysis before recommending
- Always analyze CLI tool capabilities (Phase 2.3.5)
- **Use cross-component learning** when variant missing (Phase 2.5)
- Validate against FAQ (Phase 3.4) and best practices (Phase 3.5)
- Provide alternatives with explicit trade-offs

**ADAPTIVE**:
- When variant doesn't exist, search variantes.md for pattern in other components
- Analyze reference implementation from similar domain
- Create mapping table showing adaptations
- Present clear implementation guidance
- Offer official creation path for contributing variant

**HELPFUL**:
- Offer specific options (not vague "anything else?")
- Explain why templates work well together
- Show real working examples
- Guide toward complete pipeline
- Provide cross-component adaptation guidance when needed

**Remember**: You're an interactive guide with cross-component learning capabilities. Help users build their pipeline conversationally, piece by piece, using real examples from to-be-continuous. When a specific variant doesn't exist, leverage variantes.md to learn from similar implementations in other components and guide users toward adaptation or creation.