CTO Sortie Workflows
Autonomous SDLC workflows for the CTO agent, powered by Sortie.
Architecture
.ai/agents/cascadeguard/
├── ORG.md # Shared org context (all agents)
├── workflows/ # Generic SDLC workflows (tool-agnostic)
│ ├── plan.md
│ ├── implement.md
│ ├── review.md
│ ├── bugfix.md
│ └── triage.md
└── cto/
├── identity.yaml # Agent identity
├── JOB_DESCRIPTION.md # Role definition
├── AGENTS.md # Full agent instructions
└── sortie/ # Sortie workflow files
├── README.md # This file
├── PLAN.workflow.md # Plan creation workflow
├── TRIAGE.workflow.md # Issue triage workflow
├── IMPLEMENT.workflow.md # Implementation workflow
├── BUGFIX.workflow.md # Bug fix workflow
└── REVIEW.workflow.md # PR review workflow
hosts/
├── mac.env # Host-specific env for local Mac
├── mac.md # Host documentation
├── k8s-lab.env # Host-specific env for k8s cluster
└── k8s-lab.md # Host documentation
Layered Context Model
Each Sortie workflow composes context from multiple layers:
┌─────────────────────────────────────────┐
│ Sortie WORKFLOW.md (front matter) │ ← Sortie-specific config
│ tracker, hooks, agent, ci_feedback │ (not shared with other tools)
├─────────────────────────────────────────┤
│ Prompt template (body) │ ← References shared context:
│ - Identity (identity.yaml) │
│ - Org context (ORG.md) │
│ - SDLC (sdlc.md) │
│ - Workflow steps (workflows/*.md) │
│ - Steering docs (.ai/steering/*) │
│ - Issue data (Go template vars) │
├─────────────────────────────────────────┤
│ Generic workflows (workflows/*.md) │ ← Shared across tools
│ plan, implement, review, bugfix, etc. │ (BMAD, Sortie, manual)
├─────────────────────────────────────────┤
│ ORG.md │ ← Shared across all agents
│ repos, team, artefacts, conventions │ in this org
├─────────────────────────────────────────┤
│ SDLC, steering, skills │ ← Shared across all orgs
│ .ai/projects/cascadeguard/sdlc.md │ in this workspace
│ .ai/steering/*.md │
│ .ai/skills/*/SKILL.md │
└─────────────────────────────────────────┘
All paths in prompt templates are relative to workspace root. The workspace root itself is configured per-host via env vars.
Workflows
| Workflow | Watches | Hands off to | Purpose |
|---|---|---|---|
| TRIAGE | triage | backlog | Assess new issues, add layers/priority |
| PLAN | backlog | todo | Create implementation plans |
| IMPLEMENT | in-progress | review | Build the solution, open PR |
| BUGFIX | in-progress + label:bug | review | Diagnose and fix bugs |
| REVIEW | review | done | CTO review of PRs |
Running
Per-host configuration
Each host has an .env file in hosts/ that sets the workspace root and any host-specific overrides:
# On Mac
sortie --env-file hosts/mac.env .ai/agents/cascadeguard/cto/sortie/IMPLEMENT.workflow.md
# On k8s-lab (workspace mounted at /workspace)
sortie --env-file hosts/k8s-lab.env .ai/agents/cascadeguard/cto/sortie/IMPLEMENT.workflow.mdPer-repo targeting
Each workflow defaults to cascadeguard/cascadeguard-app. Override via env var:
# Target a different repo
SORTIE_TRACKER_PROJECT=cascadeguard/cascadeguard \
sortie --env-file hosts/mac.env .ai/agents/cascadeguard/cto/sortie/IMPLEMENT.workflow.mdOr create a per-repo .env file:
# hosts/mac-cascadeguard-core.env
SORTIE_WORKSPACE_ROOT=/Users/craig/src/workspace-root
WORKSPACE_ROOT=/Users/craig/src/workspace-root
SORTIE_TRACKER_PROJECT=cascadeguard/cascadeguardThe hooks use $SORTIE_TRACKER_PROJECT to derive the clone URL, so changing the project env var is all that’s needed to retarget a workflow.
Running all CTO workflows for a repo
for f in .ai/agents/cascadeguard/cto/sortie/*.workflow.md; do
sortie --env-file hosts/mac.env "$f" &
doneEnvironment Variables
| Variable | Required | Description |
|---|---|---|
SORTIE_GITHUB_TOKEN | Yes | GitHub PAT with repo access |
ANTHROPIC_API_KEY | Yes | Anthropic API key for Claude |
SORTIE_TRACKER_PROJECT | No | Override target repo (default: cascadeguard/cascadeguard-app) |
SORTIE_WORKSPACE_ROOT | No | Override workspace root path |
GitHub Org Project Board
Sortie’s GitHub adapter works with repo-level issues (label-based state machine), not GitHub org-level Projects (ProjectV2). The org project board at https://github.com/orgs/cascadeguard/projects/2 is useful for:
- Board-level visibility — CTO/CEO/CMO see cross-repo status in one view
- Strategic planning — high-level items live on the org board
- Sub-task decomposition — org board items get broken into repo-level issues for implementation
The workflow is:
- Board creates strategic items on the org project board
- CTO/CEO decomposes into repo-level issues with appropriate labels
- Sortie picks up repo-level issues and runs the SDLC workflows
- Status flows back to the org board via GitHub’s project automation
This means board-level interactions (strategy, prioritisation, cross-repo coordination) happen on the org project, while Sortie handles the per-repo implementation lifecycle.
Extending to Other Agents
To add workflows for another agent (e.g., full-stack engineer):
- Create
sortie/directory under the agent’s folder - Copy and adapt workflow files, changing:
- Identity references to the new agent
- Budget and concurrency limits
query_filterto scope to appropriate issues (e.g.,label:frontend)
- The generic workflows in
workflows/andORG.mdare shared — no duplication needed
Extending to Other Repos
Override SORTIE_TRACKER_PROJECT via env var — no workflow file changes needed. The hooks use $SORTIE_TRACKER_PROJECT to derive the clone URL automatically.
For repos with different toolchains, you may need to adjust self_review.verification_commands in the IMPLEMENT and BUGFIX workflows (e.g., go test ./... instead of npm run test).