---
name: "GitLab Stack Validator"
description: "Validates GitLab stack projects before deployment, ensuring proper architecture patterns, directory structure, secrets management, .env configuration, and Docker best practices. Use when users ask to validate a stack, check stack configuration, verify stack architecture, audit stack setup, or ensure stack deployment readiness."
---

# GitLab Stack Validator

This skill validates GitLab stack projects to ensure they follow proper architecture patterns and are ready for deployment. It focuses on **detection and reporting** of issues, working alongside companion skills (stack-creator, secrets-manager) for remediation.

## When to Use This Skill

Activate this skill when the user requests:
- Validate a GitLab stack project
- Check stack configuration before deployment
- Verify stack architecture and structure
- Audit stack for best practices compliance
- Ensure stack follows proper patterns
- Pre-deployment validation checks
- Stack health check or readiness verification

## Core Validation Principles

This skill validates stacks that follow these architecture principles:

1. **Configuration Management**: All configuration through docker-compose.yml and ./config directory
2. **Secrets Management**: Secrets stored in ./secrets and referenced via Docker secrets
3. **Environment Variables**: .env file with matching .env.example template
4. **Minimal Custom Scripts**: docker-entrypoint.sh only when containers don't support native secrets
5. **Proper Ownership**: No root-owned files (all files owned by Docker user)
6. **Temporary Files**: _temporary directory for transient files that are cleaned up after use
7. **Docker Best Practices**: Leverage docker-validation skill for Docker-specific checks

## Validation Workflow

When a user requests stack validation, follow this comprehensive workflow:

### Phase 1: Pre-flight Checks

**Step 1: Verify Stack Project**
1. Check if current directory appears to be a stack project
2. Look for key indicators:
   - docker-compose.yml exists
   - Presence of ./config, ./secrets, or ./_temporary directories
   - .env file exists
3. If not a stack project, report findings and ask if user wants to initialize one

**Step 2: Gather Context**
1. Ask user for validation scope (if needed):
   - Full validation or targeted checks?
   - Strict mode or permissive mode?
   - Output format preference (text report vs JSON)?
2. Check if .stack-validator.yml exists for custom rules
3. Note the working directory for reporting

### Phase 2: Directory Structure Validation

**Step 1: Required Directories**
1. Check for required directories:
   - `./config` - Configuration files directory
   - `./secrets` - Secrets storage directory
   - `./_temporary` - Temporary files directory
2. For each missing directory, record:
   - Directory name
   - Purpose and why it's required
   - Impact on stack functionality

**Step 2: Directory Permissions**
1. Check ./secrets has restricted permissions (700 or 600)
2. Verify other directories have appropriate permissions
3. Report any permission issues with security implications

**Step 3: Directory Ownership**
1. Scan all project directories for ownership
2. Flag any root-owned directories:
   - Directory path
   - Current owner
   - Expected owner (current user or docker user)
3. Flag any files with unexpected ownership

**Step 4: .gitignore Validation**
1. Check if .gitignore exists
2. Verify it excludes:
   - `./secrets` or `./secrets/*`
   - `./_temporary` or `./_temporary/*`
   - `.env` (should not be in git)
3. Report missing exclusions with security implications

### Phase 3: Environment Variables Validation

**Step 1: .env File Validation**
1. Check if .env file exists
2. Parse .env file for:
   - Syntax errors
   - Duplicate variable definitions
   - Empty values that might be required
3. Record all environment variable names found

**Step 2: .env.example Validation**
1. Check if .env.example exists
2. If missing, this is a **critical issue** - document why it's needed
3. Parse .env.example for variable names

**Step 3: .env Synchronization Check**
1. Compare variables in .env with .env.example:
   - Variables in .env but NOT in .env.example
   - Variables in .env.example but NOT in .env
2. This is a **critical validation point** - they must match
3. Report any mismatches with specific variable names

**Step 4: Environment Variable Security**
1. Scan .env for potential secrets:
   - Variables with names containing: password, secret, key, token, api
   - Base64-encoded looking values
   - Long random strings
2. If secrets detected in .env, flag as security issue
3. Suggest moving to ./secrets and Docker secrets instead

### Phase 4: Docker Configuration Validation

**Step 1: Invoke docker-validation Skill**
1. Use the docker-validation skill to validate:
   - docker-compose.yml syntax and best practices
   - Dockerfile(s) if present
   - Multi-stage builds
   - Security configurations
2. Collect all findings from docker-validation
3. Integrate into overall stack validation report

**Step 2: Stack-Specific Docker Checks**
1. Review docker-compose.yml for stack patterns:
   - Secrets are defined in top-level `secrets:` section
   - Services reference secrets via `secrets:` key (not environment variables)
   - Volume mounts follow patterns (./config, ./secrets, ./_temporary)
   - Networks are properly defined if multi-service
   - Service dependencies use `depends_on` correctly

**Step 3: Version Check**
1. Ensure docker-compose.yml does NOT have version field at top
2. This follows modern Docker Compose specification
3. If version field present, flag for removal

### Phase 5: Secrets Management Validation

**Step 1: Secrets Directory Check**
1. Verify ./secrets directory exists
2. Check permissions are restrictive (700)
3. Verify it's excluded from git

**Step 2: Docker Secrets Validation**
1. Parse docker-compose.yml for secrets definitions
2. For each secret definition:
   - Verify the secret file exists in ./secrets
   - Check file permissions (600 or 400)
   - Verify not tracked by git
3. Report missing secret files

**Step 3: Secret References Validation**
1. Check each service's `secrets:` section
2. Verify referenced secrets are defined in top-level secrets
3. Flag any undefined secret references

**Step 4: Environment Variables vs Secrets**
1. Scan service environment variables for potential secrets
2. Look for patterns like:
   - *_PASSWORD
   - *_SECRET
   - *_KEY
   - *_TOKEN
   - API_*
3. If sensitive data in environment, suggest using secrets instead

**Step 5: Secret Exposure Check**
1. Check for secrets in:
   - docker-compose.yml (hardcoded values)
   - .env file (should be in ./secrets instead)
   - Configuration files in ./config
   - Any shell scripts
2. Report any exposed secrets as **critical security issues**

### Phase 6: Configuration Files Validation

**Step 1: Config Directory Structure**
1. List all files in ./config directory
2. Organize by service (if applicable)
3. Check for proper organization

**Step 2: Config File Validation**
1. For common config file types, validate syntax:
   - YAML files (.yml, .yaml)
   - JSON files (.json)
   - INI files (.ini, .conf)
   - TOML files (.toml)
2. Report any syntax errors

**Step 3: Config vs Secrets Separation**
1. Scan config files for potential secrets
2. Look for hardcoded passwords, tokens, keys
3. Flag any secrets that should be in ./secrets instead

**Step 4: Config Ownership**
1. Check all config files for ownership
2. Flag any root-owned config files
3. Report expected ownership (current user)

### Phase 7: Script Validation

**Step 1: docker-entrypoint.sh Detection**
1. Search for docker-entrypoint.sh files
2. For each found:
   - Document location
   - Check if truly necessary
3. Validate it's only used when container doesn't support native secrets

**Step 2: Script Permissions**
1. Check docker-entrypoint.sh is executable (chmod +x)
2. Verify ownership (should not be root)
3. Report permission issues

**Step 3: Script Content Validation**
1. Scan script for:
   - Hardcoded secrets (critical issue)
   - Proper secret handling from /run/secrets/
   - Error handling
   - Syntax errors (if bash/sh)
2. Report any issues found

**Step 4: Necessity Check**
1. Review if docker-entrypoint.sh is truly needed
2. Check if service supports native Docker secrets
3. Suggest removal if unnecessary

### Phase 8: Temporary Directory Validation

**Step 1: Directory Check**
1. Verify ./_temporary exists
2. Check it's in .gitignore
3. Verify permissions

**Step 2: Content Check**
1. List contents of ./_temporary
2. Check for:
   - Leftover files that should be cleaned
   - Large files consuming space
   - Old files (> 7 days old)
3. Report if not empty with details

**Step 3: Usage Validation**
1. Check if ./_temporary is properly mounted in docker-compose.yml
2. Verify services use it for temporary files
3. Flag if not being utilized

### Phase 9: File Ownership Audit

**Step 1: Comprehensive Ownership Scan**
1. Use `find . -type f -user root 2>/dev/null` to find root-owned files
2. Exclude expected directories (.git, node_modules, vendor)
3. List all root-owned files found

**Step 2: Categorize Issues**
1. Group by directory:
   - ./config files owned by root
   - ./secrets files owned by root
   - Application files owned by root
2. Report with specific paths

**Step 3: Impact Assessment**
1. For each root-owned file:
   - Explain why this is problematic
   - Impact on stack operations
   - Potential errors that may occur

### Phase 10: Report Generation

**Step 1: Compile All Findings**
1. Organize findings by category:
   - Directory Structure
   - Environment Variables (.env sync)
   - Docker Configuration
   - Secrets Management
   - Configuration Files
   - Scripts (docker-entrypoint.sh)
   - Temporary Directory
   - File Ownership
2. Assign severity levels:
   - ❌ **CRITICAL**: Security issues, missing required components, .env mismatch
   - ⚠️ **WARNING**: Best practice violations, potential issues
   - ✅ **PASS**: No issues found

**Step 2: Generate Validation Report**

Create a comprehensive report with this structure:

```
🔍 GitLab Stack Validation Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stack: [directory name]
Date: [timestamp]
Mode: [strict/permissive]

📊 SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Passed: [count]
⚠️  Warnings: [count]
❌ Critical: [count]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 DETAILED FINDINGS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[For each validation category]

[Category Icon] [Category Name]: [STATUS]
[If issues found:]
   ❌ [Issue description]
      Location: [file/directory path]
      Impact: [what this affects]
      Details: [specific information]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🎯 OVERALL STATUS: [PASSED/FAILED/WARNINGS]

[If failures or warnings:]
🔧 RECOMMENDED ACTIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Prioritized list of actions needed]
1. [Most critical action]
2. [Next action]
...

💡 NEXT STEPS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Use stack-creator skill to fix structural issues
- Use secrets-manager skill to properly configure secrets
- Re-run validation after fixes
```

**Step 3: Provide Actionable Guidance**
1. For each issue, provide:
   - Clear description of the problem
   - Why it matters
   - Which companion skill can help fix it
   - General guidance (but not actual fix commands)
2. Prioritize issues by severity
3. Group related issues together

**Step 4: Export Options**
1. If user requested JSON output, export as:
   ```json
   {
     "stack": "directory-name",
     "timestamp": "ISO-8601",
     "summary": {
       "passed": 5,
       "warnings": 2,
       "critical": 1,
       "status": "failed"
     },
     "findings": [
       {
         "category": "environment-variables",
         "status": "critical",
         "issues": [...]
       }
     ]
   }
   ```

## Validation Categories Reference

### 1. Directory Structure
- Required directories exist
- Proper permissions
- .gitignore coverage
- Ownership correctness

### 2. Environment Variables
- .env file exists and valid
- .env.example exists
- **CRITICAL**: .env and .env.example are synchronized
- No secrets in .env

### 3. Docker Configuration
- docker-compose.yml valid (via docker-validation skill)
- No version field
- Secrets properly defined
- Volumes follow patterns
- Service dependencies correct

### 4. Secrets Management
- ./secrets directory secure
- All referenced secrets exist
- Proper permissions
- No exposed secrets
- Environment variables don't contain secrets

### 5. Configuration Files
- Proper organization
- Valid syntax
- No embedded secrets
- Correct ownership

### 6. Scripts
- docker-entrypoint.sh only when necessary
- Executable permissions
- No hardcoded secrets
- Proper secret handling

### 7. Temporary Directory
- Exists and in .gitignore
- Empty or contains only expected transient files
- Properly utilized in compose file

### 8. File Ownership
- No root-owned files
- Consistent ownership
- Proper user/group

## Integration with Companion Skills

### stack-creator
- Recommend for: Creating missing directories, initializing structure
- Handles: Setting up new stacks, fixing structural issues

### secrets-manager
- Recommend for: Secrets configuration, secret file management
- Handles: Creating/updating secrets, proper secret setup

### docker-validation
- **Used directly during validation** for Docker-specific checks
- Provides: Docker Compose and Dockerfile validation
- Integrated into stack validation report

## Validation Modes

### Standard Mode (Default)
- Report all issues as warnings or errors
- Provide comprehensive findings
- Suggest improvements

### Strict Mode
- Fail on warnings
- Require all best practices
- Zero tolerance for deviations

### Permissive Mode
- Only fail on critical issues
- Allow warnings
- More lenient on best practices

## Configuration Support

If `.stack-validator.yml` exists in project root, respect these settings:

```yaml
# Validation mode
strict_mode: false

# Whether warnings should fail validation
fail_on_warnings: false

# Paths to exclude from validation
exclude_paths:
  - ./vendor
  - ./node_modules
  - ./_temporary/cache

# Custom validation scripts to run
custom_checks:
  - ./scripts/custom-validation.sh

# Specific checks to skip
skip_checks:
  - temporary-directory-empty
```

## Communication Style

When reporting validation results:

1. **Be Clear and Direct**: State issues plainly without hedging
2. **Be Specific**: Include exact file paths, line numbers, variable names
3. **Be Actionable**: Explain what needs to be done (without doing it)
4. **Be Helpful**: Point to companion skills that can fix issues
5. **Be Organized**: Group related issues, prioritize by severity
6. **Be Educational**: Explain why something is an issue
7. **Be Concise**: Don't overwhelm with details, but be thorough

## Critical Validation Points

These are **must-pass** criteria for production stacks:

1. ✅ .env and .env.example are fully synchronized
2. ✅ No secrets in docker-compose.yml environment variables
3. ✅ ./secrets directory exists and has restrictive permissions
4. ✅ All referenced secrets exist
5. ✅ ./secrets and ./_temporary are in .gitignore
6. ✅ No root-owned files
7. ✅ docker-compose.yml passes docker-validation
8. ✅ No secrets exposed in git
9. ✅ .env file is not tracked by git

## Important Notes

- **Read-Only**: This skill NEVER modifies files - validation only
- **Detection-Focused**: Report issues, don't fix them
- **Comprehensive**: Check all aspects systematically
- **Fast**: Complete validation in seconds
- **Integrative**: Use docker-validation skill for Docker checks
- **Companion-Aware**: Direct users to appropriate skills for fixes

## Example Validation Flow

```
User: "Validate my stack"

1. Check if docker-compose.yml exists ✅
2. Verify directory structure
   - ./config ✅
   - ./secrets ✅
   - ./_temporary ⚠️ (not in .gitignore)
3. Validate .env configuration
   - .env exists ✅
   - .env.example exists ❌ CRITICAL
4. Run docker-validation skill
   - docker-compose.yml syntax ✅
   - Secrets configuration ⚠️ (using environment vars)
5. Check secrets management
   - ./secrets permissions ✅
   - Secret files exist ✅
6. Scan for ownership issues
   - Found 3 root-owned files in ./config ❌
7. Generate report with findings
8. Suggest: Use stack-creator to add .env.example and fix .gitignore
```

---

*This skill ensures stack quality, security, and deployment readiness through comprehensive validation.*