Cortivex Pipeline Templates
Templates are pre-built, tested pipeline configurations for common development workflows. They are ready to run immediately and serve as starting points for customization.
Built-in Template Directory
| # | Template | Description | Nodes | Est. Cost | Est. Duration |
|---|---|---|---|---|---|
| 1 | pr-review | Review PRs for security, quality, and auto-fix issues | 5 | $0.05 | 3m |
| 2 | full-test-suite | Generate comprehensive unit, integration, and E2E tests | 4 | $0.08 | 5m |
| 3 | js-to-typescript | Migrate JavaScript source files to TypeScript | 4 | $0.12 | 8m |
| 4 | dependency-update | Update dependencies safely with testing | 3 | $0.03 | 3m |
| 5 | security-audit | Deep security analysis with written report | 3 | $0.06 | 4m |
| 6 | documentation-refresh | Analyze codebase and regenerate all documentation | 4 | $0.07 | 5m |
| 7 | bug-hunt | Find bugs, fix them, generate tests, and validate | 4 | $0.06 | 5m |
| 8 | performance-audit | Profile performance, fix bottlenecks, and verify | 3 | $0.05 | 4m |
| 9 | onboarding-guide | Generate onboarding documentation for new developers | 3 | $0.05 | 4m |
| 10 | nightly-review | Comprehensive nightly security and quality scan | 4 | $0.05 | 5m |
| 11 | pre-release-check | Full pre-release validation: security, tests, perf, changelog | 4 | $0.06 | 6m |
| 12 | api-design | Design API from codebase analysis with tests and docs | 4 | $0.08 | 6m |
| 13 | refactor-module | Analyze, refactor, test, and review a module | 4 | $0.08 | 6m |
| 14 | coverage-boost | Analyze gaps and generate tests to boost coverage | 4 | $0.08 | 7m |
| 15 | changelog-release | Generate changelog, update docs, and create release PR | 3 | $0.03 | 2m |
Using Templates
Running a Template
/cortivex run <template-name>
Examples:
/cortivex run pr-review
/cortivex run security-audit --verbose
/cortivex run full-test-suite --dry-run
/cortivex run pr-review --param pr_number=42 --param branch=feature/auth
Getting Template Info
/cortivex templates info <template-name>
Shows the full template YAML with node definitions, configurations, and dependency graph.
Dry Run
Always available with any template:
/cortivex run <template-name> --dry-run
Output:
Dry Run: pr-review
===================
Nodes: 5
Estimated Cost: $0.05
Estimated Duration: 3m
Execution Plan:
1. SecurityScanner (parallel: none) ~15s ~$0.004
2. CodeReviewer (after: SecurityScanner) ~45s ~$0.018
3. AutoFixer (after: CodeReviewer) ~30s ~$0.012
4. TestRunner (after: AutoFixer) ~60s ~$0.008
5. PRCreator (after: TestRunner) ~8s ~$0.003
No issues found. Ready to run.
Customizing Templates
Copy and Modify
To customize a template:
/cortivex templates copy pr-review --as my-pr-review
This creates a copy in your custom pipelines directory. Edit the copy freely.
Common Customizations
Change a model for a specific node:
nodes:
- id: code_review
type: CodeReviewer
config:
model: claude-sonnet-4-20250514 # override default
Add a node to an existing template:
Insert the node definition and update depends_on references to maintain the DAG.
Remove a node:
Delete the node definition and update any depends_on references that pointed to it.
Change scope or parameters:
nodes:
- id: security_scan
type: SecurityScanner
config:
scan_depth: deep # override default "standard"
severity_threshold: low # override default "medium"
Add conditions:
nodes:
- id: security_scan
type: SecurityScanner
condition:
if: "changed_files.any(f => f.path.startsWith('src/auth/'))"
skip_message: "No auth files changed, skipping security scan"
Add retry logic:
nodes:
- id: test_run
type: TestRunner
retry:
max_attempts: 3
backoff: exponential
base_delay_seconds: 5
Sharing Templates
Export a Template
/cortivex templates share my-pr-review --output my-pr-review.yaml
Produces a standalone YAML file that can be shared with teammates.
Import a Template
/cortivex templates import ./shared/team-review.yaml --as team-review
Imports a YAML template file into your local template registry.
Team Template Repository
For teams, store shared templates in a git repository:
my-org/cortivex-templates/
pr-review-strict.yaml
nightly-security.yaml
release-process.yaml
Configure the remote repository:
cortivex_config({
action: "set",
key: "template_repos",
value: ["https://github.com/my-org/cortivex-templates"]
})
Templates from remote repos are available with their prefix:
/cortivex run my-org/pr-review-strict
Best Practices for Pipeline Design
1. Start with Analysis
Always begin pipelines with an analysis node (ArchitectAnalyzer, SecurityScanner, CodeReviewer) before modification nodes. Analysis output provides context that makes modifications more accurate.
2. Validate After Modification
Every modification node (AutoFixer, RefactorAgent, TypeMigrator) should be followed by a validation node (TestRunner, LintFixer). Never end a pipeline on a modification without verification.
3. Keep Pipelines Focused
A pipeline should do one thing well. Instead of a 15-node mega-pipeline, compose smaller pipelines:
/cortivex run security-audit
/cortivex run pr-review
/cortivex run documentation-refresh
4. Use Conditions to Save Cost
Add conditions to skip nodes when they are not relevant:
condition:
if: "changed_files.length > 0 && changed_files.any(f => f.endsWith('.ts'))"
5. Set Appropriate Timeouts
Set timeout_seconds based on expected duration, not on worst case:
- LintFixer: 30s
- TestRunner: 300s (5m) for most projects, up to 900s (15m) for large suites
- TypeMigrator: 600s (10m) for large codebases
6. Use Haiku for Lightweight Nodes
Nodes that do not require deep reasoning (LintFixer, TestRunner, ChangelogWriter, PRCreator) can use claude-haiku-4-20250414 at a fraction of the cost with equivalent results.
7. Leverage the Learning System
After several runs, check cortivex_insights to see if the system has learned optimizations for your specific repository. Apply high-confidence insights to your custom templates.
8. Name Pipelines Descriptively
Use names that describe the workflow, not the trigger:
- Good:
security-audit,pr-review-strict,nightly-quality-check - Bad:
pipeline1,my-pipeline,test
Template File Format
All templates follow this YAML structure:
name: template-name
version: "1.0"
description: What this pipeline does
tags: [tag1, tag2]
estimated_cost: "$0.05"
estimated_duration: "3m"
# Optional: parameters that can be overridden at runtime
params:
branch:
type: string
default: main
description: Target branch
coverage_threshold:
type: number
default: 80
description: Minimum test coverage percentage
# Node definitions
nodes:
- id: unique_node_id
type: NodeType
depends_on: [] # list of node IDs this depends on
config:
key: value
condition: # optional
if: "expression"
skip_message: "reason"
retry: # optional
max_attempts: 3
backoff: exponential
fallback_for: other_node_id # optional
Refer to the individual template YAML files in the templates/ directory for complete, runnable examples.
Reasoning Protocol
Before selecting or customizing a template, reason through:
- Does a built-in template cover this use case? Check the template directory table above. If a template covers 80%+ of the need, customize it rather than building from scratch.
- What customizations are needed? Lis