name: ci-cd-implement description: "Analyze a project and implement CI/CD pipelines tailored to its tech stack and deployment target. This skill should be used when a project is ready for automated testing and/or deployment. Generates GitHub Actions workflows, deployment scripts, and secrets documentation. Works as a standalone utility on any project."

ci-cd-implement

1. Package/dependency files:

   • package.json (Node.js/frontend)
   • requirements.txt / pyproject.toml (Python)
   • composer.json (PHP)
   • go.mod (Go)
   • Cargo.toml (Rust)

2. Existing CI/CD:

   • .github/workflows/ (existing GitHub Actions)
   • Dockerfile, docker-compose.yml

3. Test configuration:

   • Test commands in package.json scripts
   • pytest.ini, jest.config.js, vitest.config.ts
   • phpunit.xml

4. Linting/formatting:

   • .eslintrc, .prettierrc
   • ruff.toml, pyproject.toml [tool.ruff]
   • phpcs.xml

5. Type checking:

   • tsconfig.json (TypeScript)
   • mypy.ini, pyrightconfig.json (Python)

6. Build configuration:

   • next.config.js, vite.config.ts
   • Build scripts in package.json

7. Deployment hints:

   • .docs/deployment-strategy.md (from workflow)
   • fly.toml (Fly.io)
   • wrangler.toml (Cloudflare)
   • Caddyfile references </project-analysis>

Pipeline Options:

1. CI only - Automated testing, linting, and builds on every push/PR Best for: Projects not ready for automated deployment, or deploying manually

2. CD only - Automated deployment to your hosting target Best for: Projects with existing CI, or simple projects where you trust manual testing

3. Both CI + CD - Complete pipeline from code push to deployment Best for: Most production projects

Which would you like? [1/2/3] </prompt-to-user>

Complex project (staging + production):

• Multiple contributors
• Higher traffic expectations
• Handles user data or payments
• Existing staging/production separation
• deployment-strategy.md indicates professional uptime needs </complexity-indicators>

If unclear from analysis, default to production-only for first implementation. Note in output that staging can be added later. </environment-decision> </phase>

<skip-condition>If user selected cd_only, skip to phase 4.</skip-condition>

on: push: branches: [main, dev] pull_request: branches: [main]

jobs: test: runs-on: ubuntu-latest

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  # Language-specific setup inserted here

  - name: Install dependencies
    run: {install_command}

  # Conditional steps based on detection:

  - name: Lint
    run: {lint_command}

  - name: Type check
    run: {typecheck_command}

  - name: Test
    run: {test_command}

  - name: Build
    run: {build_command}

</ci-workflow-template>

<language-setup-templates>

<nodejs>
```yaml
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

<skip-condition>If user selected ci_only, skip to phase 5.</skip-condition>

on: push: branches: [main]

jobs: deploy: runs-on: ubuntu-latest

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  - name: Set up Node.js
    uses: actions/setup-node@v4
    with:
      node-version: '20'
      cache: 'npm'

  - name: Install dependencies
    run: npm ci

  - name: Build
    run: npm run build

  - name: Deploy to Cloudflare Pages
    uses: cloudflare/wrangler-action@v3
    with:
      apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
      accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
      command: pages deploy {build_output_dir} --project-name={project_name}

</workflow-template>

<secrets-needed>
- CLOUDFLARE_API_TOKEN: API token with Pages edit permissions
- CLOUDFLARE_ACCOUNT_ID: Your Cloudflare account ID
</secrets-needed>
</cloudflare-pages>

<fly-io>
<description>Containerized deployment via Fly.io CLI</description>

<workflow-template>
```yaml
name: Deploy to Fly.io

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Fly.io CLI
        uses: superfly/flyctl-actions/setup-flyctl@master

      - name: Deploy to Fly.io
        run: flyctl deploy --remote-only
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

on: push: branches: [main]

jobs: deploy: runs-on: ubuntu-latest

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  - name: Deploy to VPS
    uses: appleboy/ssh-action@v1.0.3
    with:
      host: ${{ secrets.VPS_HOST }}
      username: ${{ secrets.VPS_USERNAME }}
      key: ${{ secrets.VPS_SSH_KEY }}
      script: |
        cd /var/www/{project_name}
        git pull origin main
        docker compose pull
        docker compose up -d --build
        docker system prune -f

</workflow-template>

<secrets-needed>
- VPS_HOST: VPS IP address or hostname
- VPS_USERNAME: SSH username (e.g., john)
- VPS_SSH_KEY: Private SSH key for authentication
</secrets-needed>

<deploy-script>
Also generate scripts/deploy.sh for manual deployment:

```bash
#!/bin/bash
set -e

echo "Deploying {project_name} to VPS..."

# SSH to VPS and deploy
ssh {username}@{host} << 'EOF'
  cd /var/www/{project_name}
  git pull origin main
  docker compose pull
  docker compose up -d --build
  docker system prune -f
  echo "Deployment complete!"
EOF

#!/bin/bash
set -e

if [ -z "$1" ]; then
  echo "Usage: ./scripts/rollback.sh <commit-hash>"
  exit 1
fi

echo "Rolling back to $1..."

ssh {username}@{host} << EOF
  cd /var/www/{project_name}
  git fetch origin
  git checkout $1
  docker compose up -d --build
  echo "Rolled back to $1"
EOF

on: push: branches: [main]

jobs: deploy: runs-on: ubuntu-latest

steps:
  - name: Checkout code
    uses: actions/checkout@v4

  - name: Deploy via rsync
    uses: burnett01/rsync-deployments@6.0.0
    with:
      switches: -avzr --delete --exclude='.git' --exclude='.github' --exclude='.env'
      path: ./
      remote_path: ${{ secrets.REMOTE_PATH }}
      remote_host: ${{ secrets.FTP_HOST }}
      remote_user: ${{ secrets.FTP_USERNAME }}
      remote_key: ${{ secrets.SSH_KEY }}

</workflow-template>

<secrets-needed>
- FTP_HOST: Shared hosting server hostname
- FTP_USERNAME: FTP/SSH username
- SSH_KEY: Private key for SSH access (or use FTP credentials)
- REMOTE_PATH: Path on server (e.g., /home/user/public_html)
</secrets-needed>

<alternative-ftp>
If SSH not available, use FTP action instead:

```yaml
      - name: Deploy via FTP
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./
          server-dir: ${{ secrets.REMOTE_PATH }}

This document lists the secrets required for the CI/CD pipelines.

GitHub Actions Secrets

Add these secrets in your repository settings: Settings -> Secrets and variables -> Actions -> New repository secret

Required Secrets

Setup Instructions

{target_specific_instructions}

Verification

After adding secrets, trigger a workflow run to verify configuration:

git commit --allow-empty -m "test: verify CI/CD pipeline"
git push

Check the Actions tab for workflow results.

</secrets-template>

<target-instructions>

<cloudflare-instructions>
### Cloudflare Pages Setup

1. Log in to Cloudflare Dashboard
2. Go to **My Profile -> API Tokens -> Create Token**
3. Use "Edit Cloudflare Workers" template or create custom with Pages permissions
4. Copy the token as CLOUDFLARE_API_TOKEN
5. Find Account ID in dashboard URL or **Workers & Pages -> Overview** sidebar
</cloudflare-instructions>

<fly-instructions>
### Fly.io Setup

1. Install Fly CLI: `curl -L https://fly.io/install.sh | sh`
2. Authenticate: `flyctl auth login`
3. Create deploy token: `flyctl tokens create deploy -x 999999h`
4. Copy the token as FLY_API_TOKEN
</fly-instructions>

<vps-instructions>
### VPS (Hostinger) Setup

1. Generate SSH key pair (if not exists):
   ```bash
   ssh-keygen -t ed25519 -C "github-actions-deploy"

1. Add public key to VPS:

   ssh-copy-id -i ~/.ssh/id_ed25519.pub john@your-vps-ip
   

2. Copy private key content as VPS_SSH_KEY
3. Set VPS_HOST to your VPS IP or hostname
4. Set VPS_USERNAME to your SSH username (john) </vps-instructions>

1. Get FTP/SSH credentials from Hostinger hPanel
2. Set FTP_HOST to the server hostname
3. Set FTP_USERNAME to your FTP username
4. For SSH: Generate and add key pair, copy private key as SSH_KEY
5. For FTP: Set FTP_PASSWORD (less secure than SSH)
6. Set REMOTE_PATH to your document root (e.g., /home/user/public_html) </shared-instructions>

Project: {project_name} Deployment Target: {deployment_target} Pipelines Generated: {ci_and_or_cd}

Files Created

{files_list}

Workflow Status

WORKFLOW TERMINATION POINT - FULL AUTOMATION

Your project now has complete CI/CD automation:

• Automated testing on every push/PR (if CI generated)
• Automated deployment to {target} (if CD generated)

This completes the Skills workflow.

Next Steps

1. Review generated workflows

   • Check .github/workflows/ files
   • Verify commands match your project

2. Configure secrets

   • Open CICD-SECRETS.md for instructions
   • Add secrets in GitHub repository settings

3. Test the pipeline

   git add .
   git commit -m "ci: add CI/CD pipeline"
   git push
   

4. Monitor first run

   • Go to repository -> Actions tab
   • Watch workflow execution
   • Debug any failures

{additional_notes}

Happy deploying! </summary-template>

Status: Phase 0: Project Brief (project-brief-writer) Phase 1: Tech Stack (tech-stack-advisor) Phase 2: Deployment Strategy (deployment-advisor) Phase 3: Project Foundation (project-spinup) <- TERMINATION POINT (localhost) Phase 4: Test Strategy (test-orchestrator) - optional Phase 5: Deployment (deploy-guide) <- TERMINATION POINT (manual deploy) Phase 6: CI/CD (you are here) <- TERMINATION POINT (full automation) </workflow-status>

NOT supported: localhost (no CI/CD needed for localhost) </deployment-targets-supported>

This is a TERMINATION POINT - workflow complete after this skill. </workflow-position>

Mention this option when users seem uncertain about their progress. </status-utility>