@vfarcic/dot-ai 0.161.0 → 0.162.0

package/README.md

@@ -83,6 +83,7 @@ Generate 25+ governance, legal, and automation files (LICENSE, CODE_OF_CONDUCT,
 Access curated prompts as native slash commands (`/dot-ai:prompt-name`) in your coding agent for consistent workflows across projects:
 - **PRD Management**: Create, track, and complete Product Requirements Documents (`prd-create`, `prd-next`, `prd-done`, etc.)
 - **Dockerfile Generation**: Generate production-ready, secure multi-stage Dockerfiles for any project (`generate-dockerfile`)
+- **CI/CD Generation**: Generate intelligent CI/CD workflows through interactive conversation (`generate-cicd`)
 
 📖 [Learn more →](./docs/guides/mcp-prompts-guide.md)
 

package/dist/core/unified-creation-session.js

@@ -833,7 +833,7 @@ Please try again or modify your policy description.`,
         const capabilityService = new capability_vector_service_1.CapabilityVectorService(collection);
         // Use existing searchCapabilities function - no fallback, let it throw if it fails
         const searchResults = await capabilityService.searchCapabilities(searchQuery, {
-            limit: 40 // Reduced to manage token count
+            limit: 35 // Reduced to manage token count (Haiku max: 180K tokens)
         });
         if (searchResults.length === 0) {
             throw new Error(`No relevant capabilities found for policy description: "${policyDescription}"`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vfarcic/dot-ai",
-  "version": "0.161.0",
+  "version": "0.162.0",
   "description": "AI-powered development productivity platform that enhances software development workflows through intelligent automation and AI-driven assistance",
   "mcpName": "io.github.vfarcic/dot-ai",
   "main": "dist/index.js",

package/shared-prompts/generate-cicd.md

@@ -0,0 +1,310 @@
+---
+name: generate-cicd
+description: Generate intelligent CI/CD workflows through interactive conversation by analyzing repository structure and user preferences
+category: development
+---
+
+# Generate CI/CD Workflows
+
+Generate appropriate CI/CD workflows for the current project through an interactive conversation. This prompt analyzes your entire repository, presents findings, asks about workflow preferences, and generates workflows based on your confirmed choices.
+
+## Instructions
+
+You are helping a developer set up CI/CD workflows for their project. Unlike template-based generators, you will:
+
+1. **Analyze** the entire repository - source code, automation, configs, docs, existing CI
+2. **Present findings** and workflow options to the user for decision-making
+3. **Generate** workflows based on confirmed user choices
+
+This interactive model is essential because CI/CD workflows involve **policy decisions** (PR vs direct push, release triggers, deployment strategy) that cannot be deduced from code alone—they reflect team preferences and organizational policies.
+
+### Key Rules
+
+**Verify everything**: Before adding any step, secret, or configuration, verify it by examining the actual codebase. Never assume. Ask when uncertain.
+
+**Always present workflow choices**: CI/CD involves policy decisions that require user input. Even if you detect tests and a Dockerfile, you cannot know whether tests should run on PR or main, what triggers releases, which registry to use, or how to deploy. These are workflow choices that require user input.
+
+---
+
+## Best Practices
+
+Apply these practices when generating workflows.
+
+### Use Project Automation, Not Inline Commands
+
+CI workflows should call project automation, not contain inline command logic.
+
+```yaml
+# ❌ BAD - Logic in CI, can't run locally the same way
+- run: |
+    jest --coverage --ci
+    eslint src/ --format=stylish
+
+# ✅ GOOD - CI calls project automation
+- run: npm test
+- run: npm run lint
+```
+
+**Why**: Local/CI parity, CI platform portability, easier debugging, single source of truth.
+
+**When project automation doesn't exist**, ask the user:
+
+```text
+I didn't find automation for [operation]. Would you like me to:
+1. Add it to the project (recommended for local/CI parity)
+2. Use inline command in workflow
+```
+
+### Actions for Infrastructure, Project Commands for Logic
+
+| Category | Examples | Approach |
+|----------|----------|----------|
+| **CI Infrastructure** | checkout, setup runtime, cache, registry login | ✅ Use actions |
+| **Project Logic** | build, test, lint, docker build, deploy | ✅ Use project automation |
+
+### Secret Handling
+
+Secrets are only accessible from the org/owner that has them configured. Fork PRs cannot access base repo secrets.
+
+Use conditional to skip steps when secrets unavailable:
+
+```yaml
+- name: Run integration tests
+  if: secrets.API_KEY != ''
+  run: npm run test:integration
+  env:
+    API_KEY: ${{ secrets.API_KEY }}
+```
+
+When the generated workflow requires secrets, document them clearly:
+
+```markdown
+## Required Secrets
+
+| Secret Name | Description | How to Create |
+|-------------|-------------|---------------|
+| `REGISTRY_USERNAME` | Container registry username | Your registry account username |
+| `REGISTRY_TOKEN` | Container registry access token | Registry settings > Access Tokens |
+
+**To create secrets via CLI:**
+gh secret set REGISTRY_USERNAME
+gh secret set REGISTRY_TOKEN
+```
+
+Show the `gh secret set` commands as guidance, but do NOT execute them.
+
+### Security
+
+| Practice | Description |
+|----------|-------------|
+| **Minimal permissions** | Use `permissions:` block, grant only what's needed |
+| **OIDC over long-lived tokens** | For cloud providers, prefer OIDC federation |
+| **Pin action versions** | Use SHA or version tags, never `@latest` |
+| **Disable credential persistence** | Use `persist-credentials: false` on `actions/checkout` |
+| **Prevent script injection** | Never interpolate untrusted inputs (branch names, PR titles) directly into `run:` commands |
+| **Avoid `pull_request_target`** | This trigger has access to secrets but can checkout fork code - dangerous combination |
+| **Environment protection** | Use GitHub environments with required reviewers for production deployments |
+
+### Testing
+
+| Practice | Description |
+|----------|-------------|
+| **Fail fast** | Run quick checks (lint) before slow ones (tests) |
+| **Test before build** | Don't waste time building if tests fail |
+| **Parallel jobs** | Run independent checks concurrently |
+| **Test matrix** | Consider multiple versions/platforms if relevant |
+
+### Caching
+
+Implement appropriate caching based on detected package manager and lock files.
+
+---
+
+## Process
+
+**IMPORTANT**: Execute this process SEQUENTIALLY. Each step may change the direction of the conversation. Do NOT batch all questions upfront - ask questions one phase at a time and wait for user responses before proceeding.
+
+The workflow follows three phases:
+
+```text
+┌─────────────────────────────────────────────────────────────────┐
+│ PHASE 1: ANALYZE                                                │
+│ Discover what CAN be built/tested/deployed                      │
+└─────────────────────────────────────────────────────────────────┘
+                              ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ PHASE 2: PRESENT & ASK                                          │
+│ Show findings + present workflow choices for user decision      │
+└─────────────────────────────────────────────────────────────────┘
+                              ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ PHASE 3: GENERATE                                               │
+│ Create workflows based on confirmed user choices                │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### Step 0: Determine CI Platform (BLOCKING GATE)
+
+**CRITICAL**: This is a blocking gate. Ask about CI platform FIRST and ALONE. Do NOT ask any other questions or perform any analysis until the user confirms they want GitHub Actions.
+
+Ask the user which CI/CD platform they use. Present ONLY these options:
+
+1. **GitHub Actions**
+2. **Other**
+
+**If GitHub Actions** → Proceed to Step 1 (analysis)
+
+**If Other** → STOP. Ask which platform they use, then respond:
+
+```text
+[Platform] is not yet supported. Would you like me to open a feature
+request issue at https://github.com/dot-ai-app/dot-ai/issues so we
+can prioritize adding it?
+
+1. Yes, open a feature request
+2. No, I'll use a different approach
+```
+
+Then handle the user's response (create issue or end conversation). Do NOT proceed to repository analysis for unsupported platforms.
+
+### Step 1: Comprehensive Repository Analysis
+
+**Analyze everything. The entire repository is context.**
+
+#### 1.1 Language and Framework Detection
+
+- Identify primary language(s) from source files and dependency manifests
+- Detect frameworks from dependencies
+- Note version requirements
+
+#### 1.2 Discover and Understand Existing Automation
+
+Find what automation exists and **read scripts to understand how they work** - what arguments they accept, what they handle internally, how they should be called. Don't just note that a script exists; understand it.
+
+- If automation exists for a task → use it in the generated workflow
+- Only generate raw commands if no existing automation found
+- When multiple automation options exist → ask the user
+
+**Why this matters**: Existing automation often handles setup, fixtures, environment variables, and cleanup that raw commands would miss. The maintainers chose their build system for a reason.
+
+#### 1.3 Existing CI Analysis
+
+Check for existing CI configuration. If found:
+- Analyze what's already configured and why
+- During Step 2, ask user whether to update existing workflows or create new ones
+
+#### 1.4 Container and Registry Detection
+
+- Check for Dockerfile and container configuration
+- Search for registry references in existing CI, automation, or docs
+- If no Dockerfile but project could benefit from containerization, suggest using `/generate-dockerfile` prompt
+
+#### 1.5 Branching and Release Strategy
+
+- Check for patterns in existing CI triggers
+- Look at git tags for versioning patterns
+- Check documentation for workflow hints
+
+#### 1.6 Environment and Secrets
+
+- Find environment variable documentation or examples
+- Search code for required environment variables
+- Identify what secrets the workflow will need
+
+#### 1.7 App Definition Detection
+
+Identify how the application is packaged for deployment:
+- Helm charts
+- Kustomize configurations
+- Plain Kubernetes manifests
+- Container-only (no K8s deployment)
+
+#### 1.8 Deployment Mechanism Detection
+
+Identify how the application is deployed:
+- GitOps (ArgoCD, Flux)
+- Direct deployment (Helm, kubectl)
+- Manual deployment
+- External system
+
+**For GitOps**:
+- CI must NOT deploy directly - it updates manifests, GitOps controller syncs
+- Determine if GitOps resources (ArgoCD Application, Flux Kustomization) exist
+- If not, may need to create them (same repo or separate cluster-config repo)
+- Determine where manifests live for image tag updates
+
+If unclear, ask user during Step 2.
+
+#### 1.9 Tool Manager Detection
+
+Check for existing tool/environment managers (DevBox, mise, asdf, etc.). If found, use them automatically. If none, will ask user during interactive Q&A.
+
+### Step 2: Present Findings for Confirmation
+
+**Before generating workflows, present analysis summary.** Include only what's relevant to this project - the example below is illustrative, not a template to fill out:
+
+```markdown
+## Analysis Summary
+
+I analyzed your repository and found:
+
+**Language/Framework**: Node.js 20 with Express
+**Build Command**: `npm run build` (from package.json)
+**Test Command**: `npm test` (from package.json)
+**Existing CI**: GitHub Actions workflow found (ci.yml)
+
+**App Definition**: Helm chart in `charts/myapp/`
+**Deployment Mechanism**: GitOps with ArgoCD
+
+Is this correct? Would you like to change anything?
+```
+
+**User can**:
+- Confirm findings → proceed to workflow choices
+- Correct mistakes
+- Clarify ambiguities
+
+### Step 3: Present Workflow Choices
+
+**Present choices relevant to this project based on analysis.** These are policy decisions that require user input. Only ask about what's applicable - for example, don't ask about container registry if there's no Dockerfile, or deployment strategy if it's a library.
+
+Common choices include:
+- **PR Workflow**: What should run on pull requests?
+- **Release Trigger**: What triggers a release build?
+- **Release Validation**: Should release workflow re-run checks that already passed in PR? (Re-run all = safest/slowest, Skip validation = fastest, Security scans only = compromise)
+- **Container Registry**: Where to push images? (if containerized)
+- **Environment Setup**: Native GitHub Actions or DevBox?
+- **Deployment Strategy**: GitOps, direct, or manual? (if deployed)
+
+Ask clarifying questions as needed:
+- If branching strategy unclear: "Do you use feature branches with pull requests, or push directly to main?"
+- If multiple automation options exist: "I found multiple ways to run tests. Which is the primary test command?"
+- If GitOps detected but repo location unclear: "Where are your GitOps manifests stored - same repository or separate?"
+
+### Step 4: Generate Workflow(s)
+
+Generate appropriate workflow(s) based on analysis and confirmed user choices.
+
+### Step 5: Validate Generated Workflow
+
+Before presenting to user:
+
+1. **Syntax validation**: Ensure valid YAML and GitHub Actions syntax
+2. **Reference check**: Verify referenced automation exists
+3. **Secret documentation**: List required secrets clearly
+4. **Permission check**: Ensure permissions block is minimal
+5. **Deployment check**: Verify deployment steps match selected mechanism
+
+### Step 6: Present to User
+
+Provide:
+
+1. **Generated workflow file(s)** with explanatory comments
+2. **Summary** of what was detected and decisions made
+3. **Required secrets** to configure (with setup guidance)
+4. **Required permissions and settings** - Based on what the workflow does, identify what permissions or repository settings are needed and provide instructions to configure them. Don't wait for the workflow to fail - tell users upfront what to configure.
+
+### Step 7: Validate
+
+After user approves, commit the workflows following the project's established process. Trigger the workflows, monitor runs, and iterate on any failures until they pass.
+