SAW — SAFe Agentic Workflow
AI Agent Harness for Multi-Agent Team Workflows
A Production-Tested Three-Layer Architecture for Coordinated AI Teams
Supported AI Providers
Template Repository - Click "Use this template" above to create your own AI agent harness. After cloning, run
bash scripts/setup-template.shto customize for your project. See TEMPLATE_SETUP.md for details.
What This Is
A production-tested AI agent harness for teams that want structured AI workflows.
Multi-provider support: Works with Claude Code (Anthropic), Gemini CLI (Google), Codex CLI (OpenAI), and Cursor IDE (Anysphere).
Built on SAFe methodology (Scaled Agile Framework), adapted for AI agent teams. Works for any team with repeatable processes: Software, Marketing, Research, Legal, Operations.
Includes:
- 20 Model-Invoked Skills - Domain expertise that loads automatically (Skills 2.0 frontmatter)
- 24 Slash Commands - Workflow automation for common tasks
- 11 SAFe Agent Profiles - Specialized roles with clear boundaries
- Three-Layer Architecture - Hooks → Commands → Skills
- Agent Teams - Multi-agent orchestration with SAFe quality gates (experimental)
- Dark Factory - Persistent autonomous agent teams via tmux on remote servers (guide)
- Knowledge Vault - Evidence-verified knowledge base with a drift-detecting validator (guide)
Origin: 5 months production use, 169 issues, 2,193 commits. Implements patterns from 6 Anthropic engineering papers and SAFe methodology.
Quick Start (30 seconds)
Claude Code (Anthropic)
# Copy harness to your project
cp -r .claude/ /your-project/.claude/
# Customize placeholders across all provider files ({{TICKET_PREFIX}}, {{PROJECT_NAME}},
# and the rest) in one pass:
bash scripts/setup-template.sh
# Start working
/start-work TICKET-123
Gemini CLI (Google)
# Copy harness to your project
cp -r .gemini/ /your-project/.gemini/
# Install Gemini CLI (if needed)
npm install -g @google/gemini-cli
# Authenticate
export GEMINI_API_KEY="your-api-key"
# Start working
/workflow:start-work TICKET-123
Codex CLI (OpenAI)
# Copy harness to your project
cp -r .codex/ /your-project/.codex/
cp -r .agents/ /your-project/.agents/
# Install Codex CLI (if needed)
npm install -g @openai/codex
# Authenticate
export OPENAI_API_KEY="your-api-key"
# Start working (natural language, no slash commands)
codex
Cursor IDE (Anysphere)
# Copy rules to your project
cp -r .cursor/ /your-project/.cursor/
# Open in Cursor
cursor /your-project
# Rules activate automatically based on file context
# Use @rule-name to invoke agent roles manually
That's it. Your AI assistant now has your team's workflow patterns built in.
Keeping Your Harness Updated
Already using the harness and a new version is out? You have two paths:
Automated (multi-domain, manifest-based):
# Initialize sync metadata (first time only)
./scripts/sync-claude-harness.sh init
./scripts/sync-claude-harness.sh manifest init --yes
# Preview and apply (syncs all domains in your manifest's sync_scope)
./scripts/sync-claude-harness.sh sync --version v2.11.1 --dry-run
./scripts/sync-claude-harness.sh sync --version v2.11.1
# Sync specific domains only
./scripts/sync-claude-harness.sh sync --version v2.11.1 --scope .claude,.gemini
Manual (full release, all providers):
git remote add harness https://github.com/bybren-llc/safe-agentic-workflow.git
git fetch harness main --tags
git diff v2.10.0..v2.11.1 --stat # See what changed
git checkout harness/main -- .codex/agents/ # Cherry-pick what you need
bash scripts/sync-claude-harness.sh --dry-run # Preview, then drop --dry-run to apply
The sync script protects your customizations via a manifest (required since v2.10.0). It won't overwrite files you've marked as protected. See the Harness Sync Guide for the full reference and Upgrade Guide for rollback options.
The Three-Layer Architecture
┌──────────────────────────────────────────────────────────────────────┐
│ Claude Code Harness │
├──────────────────────────────────────────────────────────────────────┤
│ LAYER 1: HOOKS │ Automatic guardrails (format checks, blockers) │
│ LAYER 2: COMMANDS │ User-invoked workflows (/start-work, /pre-pr) │
│ LAYER 3: SKILLS │ Model-invoked expertise (pattern discovery) │
└──────────────────────────────────────────────────────────────────────┘
Philosophy: Process as service, not control. Everything exists to reduce cognitive load on already-solved problems.
Choose Your Path
For Practitioners - I want to use this today
Getting Started
- Run
bash scripts/setup-template.shto customize placeholders - Read the Getting Started Guide for the full walkthrough
- Run
/start-workon your first ticket
Adopting into an existing repo? See the Workspace Adoption Guide. Upgrading from a previous version? See Keeping the Harness Updated. Syncing your fork with upstream? See the Harness Sync Guide. Planning a multi-issue program? See the SAFe x AI-DLC Methodology. Building a knowledge base? See the Knowledge Vault.
Key Commands
| Command | Purpose |
|---|---|
/start-work | Begin ticket with proper workflow |
/pre-pr | Validate before pull request |
/end-work | Complete session cleanly |
/check-workflow | Quick status check |
Full Command Reference
Workflow (8): /start-work, /pre-pr, /release, /end-work, /check-workflow, /update-docs, /retro, /sync-linear
Local Operations (3): /local-sync, /local-deploy, /quick-fix
Remote Operations (5): /remote-status, /remote-deploy, /remote-health, /remote-logs, /remote-rollback
For Researchers - I want to understand the methodology
Research Foundation
This harness implements patterns from 6 Anthropic engineering papers (see below).
See docs/whitepapers/ for methodology deep-dives and comparative analysis.
For Leaders - I want to understand adoption
Adoption Requirements
- At least one supported AI tool: Claude Code, Gemini CLI, Codex CLI, or Cursor IDE
- Git repository
- Team buy-in for structured workflows
Why Teams Choose SAW
- Structured autonomy: AI agents work within clear boundaries and quality gates
- Evidence-based delivery: Every deliverable requires verifiable evidence, not "trust me"
- Stop-the-line authority: Any agent can halt work for quality or security concerns
- Multi-provider flexibility: Same workflow across Claude Code, Gemini CLI, Codex CLI, and Cursor IDE
Known Limitations
- Claude Code has the deepest integration; Gemini CLI, Codex CLI, and Cursor IDE support is newer
- Non-SWE domain adaptations (marketing, research) are documented but not yet validated in production
Gemini CLI Integration
Why Gemini CLI? - Unique capabilities and when to use it
Gemini CLI Unique Features
Gemini CLI offers capabilities that complement Claude Code:
| Feature | Gemini CLI | Claude Code |
|---|---|---|
| Shell Injection | !{command} - Execute shell, inject output into prompt | Via Bash tool only |
| File Injection | @{file} - Inject file contents into prompts | Via Read tool only |
| Built-in Sandbox | Google Cloud sandboxing | MCP sandboxing |
| Model Options | Gemini 3 Flash, Gemini 3.1 Pro Preview | Claude Opus, Sonnet, Haiku |
| Command Format | TOML | YAML + Markdown |
| Namespaced Commands | /workflow:start-work | /start-work |
| Hooks | settings.json hooks section | hooks-config.json |
| MCP Servers | settings.json mcpServers | settings.local.json |
| Hook Migration | gemini hooks migrate --from-claude | N/A |
| Plan Mode | /plan command, plan-then-execute | N/A |
| Policy Engine | YAML policies, seatbelt profiles | N/A |
| Browser Agent | Built-in experimental agent | MCP (claude-in-chrome) |
| Extensions | Bundled skill/MCP/command packages | N/A |
| Checkpointing | /restore session recovery | N/A |
| Audio/Video | Native multimodal (Gemini 3+) | N/A |
When to Use Gemini CLI
Choose Gemini CLI when you need:
- Shell command output directly in prompts (
!{git log --oneline -5}) - File contents injected into context (
@{package.json}) - Plan mode for complex multi-step tasks (
/plan) - Audio/video transcription and analysis (Gemini 3+ multimodal)
- Policy engine for fine-grained tool control
- Google Cloud integration and Gemini model family access
Choose Claude Code when you need:
- Agent subprocesses with tool restrictions
- Claude model family access
- Production-tested workflow (5+ months validated)
Gemini CLI Quick Reference
# Installation
npm install -g @google/gemini-cli
# Authentication (choose one)
export GEMINI_API_KEY="your-api-key"
# or
gcloud auth application-default login
# Start Gemini CLI
gemini
# List available commands
/help
# List available skills
/skills
Command Syntax Differences
| Action | Claude Code | Gemini CLI |
|---|---|---|
| Start work | /start-work {{TICKET_PREFIX}}-123 | /workflow:start-work {{TICKET_PREFIX}}-123 |
| Pre-PR check | /pre-pr | /workflow:pre-pr |
| Local sync | /local-sync | /local:sync |
| Remote deploy | /remote-deploy | /remote:deploy |
| Search patterns | /search-pattern "pattern" | /search-pattern "pattern" |
Gemini CLI Documentation
- Official Docs: geminicli.com
- Installation: geminicli.com/docs/get-started/installation/
- Authentication: geminicli.com/docs/get-started/authentication/
- Custom Commands: geminicli.com/docs/cli/custom-commands/
- Skills: geminicli.com/docs/cli/skills/
Implementing Anthropic's Research
This harness directly implements patterns from Anthropic's engineering papers:
| Paper | What We Implement |
|---|---|
| Building Effective Agents | 11-agent team structure |
| Effective Harnesses | Three-layer architecture |
| Agent Skills | 20 model-invoked skills |
| Skills Announcement | Skills 2.0 frontmatter, trigger patterns |
| Code Execution with MCP | Tool restrictions per role |
"The best harness is one you forget exists." — Agent Perspective
SAFe Foundation
For Agile Practitioners - Deep dive into SAFe integration
This harness maps SAFe roles to AI agents:
| SAFe Role | Agent | Responsibility |
|---|---|---|
| Business Systems Analyst | BSA | Requirements, acceptance criteria |
| System Architect | System Architect | Architecture decisions, ADRs |
| Product Owner | POPM (human) | Final approval on deliverables |
| Scrum Master | TDM | Coordination, blocker escalation |
| Release Train Engineer | RTE | CI/CD, release coordination |
SAFe Concepts Implemented
- Epic → Feature → Story → Enabler hierarchy in specs
- Sprint cycles with velocity tracking (or Bolts — see below)
- Evidence-based delivery with Linear integration
- Specs-driven workflow - BSA plans, developers execute
Program Cadence: SAFe x AI-DLC
SAFe gives this harness its structure. But SAFe's cadence assumes human squads on week-long sprints, and agent teams do not move at that speed — a team of specialized agents can elaborate, build, and verify a unit of work in hours.
So the harness also ships the SAFe x AI-DLC fusion: SAFe keeps the hierarchy, WSJF, role boundaries, and Definition of Done; AWS's AI-Driven Development Life Cycle supplies the cadence and the human checkpoint. In a program that adopts the fusion, the Bolt takes the sprint's place. Adoption is per-program; the standard sprint path stays valid.
Inside such a program, each concept below stands in for its SAFe counterpart:
| Concept | Stands in for | Definition |
|---|---|---|
| Bolt | The sprint | An hours-to-days swarm with an entry gate and a hard exit. Exits on evidence, not a date. |
| Unit of Work | The Feature | One coherent outcome. A project in the tracker. |
| Mob Elaboration | Sprint planning | Decompose, list unknowns, ask questions — before writing any code. |
| The loop | The stand-up | AI plans → AI asks → human validates business context → AI executes. |
The human validation step is not optional. Agents own the build; humans own the judgment — secrets, security policy, branch protection, risk thresholds, and signing the Definition of Done always route to a human with options and a recommendation.
Using It
| Resource | Purpose |
|---|---|
| Methodology guide | Read this first — vocabulary, worked example, when not to use a Bolt |
safe-ai-dlc skill | The method encoded for agents (Claude, Gemini, portable; Cursor as a rule) |
| Program template | Scaffolding for a new program document |
linear-sop skill | Program structure: initiative → project → milestone → issue |
Use it when work spans many issues and needs cadence — turning an audit, epic, or initiative into
an executable program. For a single ticket, the standard safe-workflow path is correct. And if the
problem space is still unclear, run a spike instead: forcing an ambiguous epic into one Bolt just
relocates the ambiguity into the code.
Knowledge Vault
Agent teams need a shared map of the system, and a map nobody can prove is current will quietly
become wrong. The knowledge-vault/ subsystem is an evidence-verified knowledge base: every
concept records the commit its claims were checked against, so staleness is something you
compute, not something you feel.
Built on Open Knowledge Format v0.1 (Google, Apache-2.0), which gives portability. This harness adds the rigor layer that gives trust: a strict frontmatter contract, a zero-dependency validator, an anti-hallucination link rule, and a drift mechanism.
In the project this method came from, an independent architecture audit called the vault "the single strongest KT asset in the repo" and told new developers to trust it over the project's own canonical context file — because the vault's claims were verified against a SHA and the canonical file's had silently drifted.
Run It
| Prompt | Who it is for |
|---|---|
| BUILD-PROMPT.md | Every adopter — the generic multi-agent build prompt. Fill in your project, taxonomy, and watch-list, then run it. |
| SAW-VAULT-BUILD.md | This repo's maintainers — pre-scoped to {{PROJECT_SHORT}} and runnable as-is, with a ready-to-file ticket breakdown. |
# Prove the tooling works before you trust it
node knowledge-vault/scripts/validate-vault.mjs --vault knowledge-vault/templates/starter-bundle
| Resource | Purpose |
|---|---|
| Knowledge Vault README | Start here — 30-second quickstart |
| Guide | The method, and why each rule exists |
| Adoption Playbook | Steps, taxonomy choice, CI gating, ticket breakdown |
| Obsidian Guide | Graph, canvases, Bases, and the config treaty |
vault-sync skill | Drift detection and repair (Claude, Gemini, portable; Cursor as a rule) |
The reading layer
Because an OKF bundle is a directory of plain markdown, Obsidian opens it with no conversion
step, and that is where the vault stops feeling like a docs folder: a graph view of the
concept graph (colour-grouped by directory, with orphans deliberately visible because an orphan is
a defect), canvases for relationships a linear document cannot show, and Bases saved
queries including a drift dashboard listing every concept whose verified_against has fallen
behind. knowledge-vault/templates/obsidian/ ships the app, graph and core-plugin config; the
canvases and Bases views ship inside the vault itself. Bases needs Obsidian 1.9+.
Obsidian is not required: no community plugins are needed, and the vault degrades to plain markdown in any editor. But the graph, canvases and dashboard are a large part of what you get.
The 11-Agent Team
| Agent | Role | When to Use |
|---|---|---|
| BSA | Requirements & specs | Starting any feature |
| System Architect | Architecture review | Significant changes |
| FE Developer | Frontend implementation | UI components |
| BE Developer | Backend implementation | API routes, server logic |
| Data Engineer | Database & migrations | Schema changes |
| QAS | Quality assurance | Test validation |
| Security Engineer | Security validation | RLS, vulnerability checks |
| Tech Writer | Documentation | Guides, technical content |
| DPE | Data provisioning | Test data, seeds |
| RTE | Release coordination | CI/CD, deployments |
| TDM | Coordination | Blockers, escalation |
See AGENTS.md for complete reference with invocation examples.
Domain Adaptation Guide
The harness patterns work beyond software engineering:
Marketing Team Example
| SWE Concept | Marketing Adaptation |
|---|---|
| BSA (specs) | Campaign Brief Writer |
| Code Review | Asset Review |
/pre-pr | /pre-launch |
| Pattern Library | Brand Guidelines |
Research Team Example
| SWE Concept | Research Adaptation |
|---|---|
| User Stories | Research Questions |
| Test Cases | Validation Criteria |
| CI/CD | Peer Review Pipeline |
| Documentation | Literature Notes |
What Makes This Different
Round Table Philosophy
Human and AI input have equal weight. No hierarchy, just expertise.
Stop-the-Line Authority
Any agent can halt work for architectural or security concerns.
Pattern Discovery Protocol
"Search First, Reuse Always, Create Only When Necessary"
Evidence-Based Delivery
All work requires verifiable evidence. No "trust me, it works."
vNext Workflow Contract (v1.4)
Note from the Author: It became apparent early on that some of the autonomy and alignment we'd lost in our original harness was not going to work. This re-introduces strong solo and larger orchestration hats with selection criteria. Gates for QAS cover all scenarios.
Complete Agent Flow
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ SAFe AGENTIC WORKFLOW - vNext │
└─────────────────────────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ USER/POPM │
│ Creates │
│ Linear │
│ Ticket │
└──────┬───────┘
│
▼
┌────────────────────────┐
│ BSA │
│ • Defines AC/DoD │
│ • Pattern discovery │
│ • Creates spec │
└────────────┬───────────┘
│
┌──────────────────┴──────────────────┐
│ STOP-THE-LINE GATE │
│ AC/DoD exists? YES → Proceed │
│ NO → STOP │
└──────────────────┬──────────────────┘
│
┌──────────────────────┼──────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ BE-DEVELOPER │ │ FE-DEVELOPER │ │ DATA-ENGINEER │
│ Exit: "Ready │ │ Exit: "Ready │ │ Exit: "Ready │
│ for QAS" │ │ for QAS" │ │ for QAS" │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
└──────────────────────┼──────────────────────┘
▼
┌─────────────────────────────────┐
│ QAS (GATE OWNER) │
│ • Iteration authority │
│ • Bounce back repeatedly │
│ • Final evidence to Linear │
│ Exit: "Approved for RTE" │
└────────────┬────────────────────┘
▼
┌─────────────────────────────────┐
│ RTE (PR SHEPHERD) │
│ • PR creation (from spec) │
│ • CI/CD monitoring │
│ • NO code, NO merge │
│ Exit: "Ready for HITL Review" │
└────────────┬────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 3-STAGE PR REVIEW │
│ Stage 1: System Architect (pattern) │
│ Stage 2: ARCHitect-in-CLI (architecture) │
│ Stage 3: HITL ({{AUTHOR_NAME}}) → MERGE │
└─────────────────────────────────────────────┘
Exit States
┌─────────────────┬───────────────────────────────────────────┐
│ Role │ Exit State │
├─────────────────┼───────────────────────────────────────────┤
│ BE-Developer │ "Ready for QAS" │
│ FE-Developer │ "Ready for QAS" │
│ Data-Engineer │ "Ready for QAS" │
│ QAS │ "Approved for RTE" │
│ RTE │ "Ready for HITL Review" │
│ System Architect│ "Stage 1 Approved - Ready for ARCHitect" │
│ HITL │ MERGED │
└─────────────────┴───────────────────────────────────────────┘
Gate Quick Reference
┌─────────────────┬─────────────────┬─────────────────────────┐
│ Gate │ Owner │ Blocking? │
├─────────────────┼─────────────────┼─────────────────────────┤
│ Stop-the-Line │ Implementer │ YES - no AC = no work │
│ QAS Gate │ QAS │ YES - no approval = stop│
│ Stage 1 Review │ System Architect│ YES - pattern check │
│ Stage 2 Review │ ARCHitect-CLI │ YES - architecture check│
│ HITL Merge │ {{AUTHOR_NAME}} │ YES - final authority │
└─────────────────┴─────────────────┴─────────────────────────┘
Role Collapsing ({{TICKET_PREFIX}}-499)
┌─────────────────────────────────────────────────────────────┐
│ ROLE COLLAPSING AUTHORITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ COLLAPSIBLE: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ RTE (Release Train Engineer) │ │
│ │ • PR creation can be done by implementer │ │
│ │ • Use when: Simple PRs, single-agent work │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ NOT COLLAPSIBLE (Independence Gates): │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ QAS (Quality Assurance Specialist) │ │
│ │ • ALWAYS spawn subagent - never self-review │ │
│ │ • Rationale: Self-review bias, quality enforcement │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Security Engineer │ │
│ │ • ALWAYS spawn subagent - never self-audit │ │
│ │ • Rationale: Security blindness, conflict of interest│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Collapsed Workflow Example
Standard Workflow:
Implementer → QAS → RTE → HITL
│
└─ RTE handles PR creation
Collapsed Workflow (RTE collapsed):
Implementer → QAS → [Implementer handles PR] → HITL
│
└─ QAS gate ALWAYS present, never collapsed
Note: Quality gates are immutable. QAS and SecEng cannot be collapsed.
Part 1: Core Workflow Architecture - Complete flow diagrams
1.1 Complete Agent Flow (Detailed)
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ SAFe AGENTIC WORKFLOW - vNext │
└─────────────────────────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ USER/POPM │
│ Creates │
│ Linear │
│ Ticket │
└──────┬───────┘
│
▼
┌────────────────────────┐
│ BSA │
│ • Defines AC/DoD │
│ • Pattern discovery │
│ • Creates spec │
└────────────┬───────────┘
│
┌──────────────────┴──────────────────┐
│ STOP-THE-LINE GATE │
│ ┌────────────────────────────────┐ │
│ │ AC/DoD exists? │ │
│ │ • YES → Proceed │ │
│ │ • NO → STOP, route to BSA │ │
│ └────────────────────────────────┘ │
└──────────────────┬──────────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ BE-DEVELOPER │ │ FE-DEVELOPER │ │ DATA-ENGINEER │
│ │ │ │ │ │
│ Owns: │ │ Owns: │ │ Owns: │
│ • API routes │ │ • UI components│ │ • Schema/DB │
│ • Server logic │ │ • Client logic │ │ • Migrations │
│ • SAFe commits │ │ • SAFe commits │ │ • SAFe commits │
│ │ │ │ │ │
│ Must NOT: │ │ Must NOT: │ │ Must NOT: │
│ • Create PRs │ │ • Create PRs │ │ • Create PRs │
│ • Merge │ │ • Merge │ │ • Merge │
│ │ │ │ │ • Skip ARCHitect│
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
│ Exit: "Ready for QAS" │
└──────────────────────┼──────────────────────┘
│
▼
┌─────────────────────────────────┐
│ QAS │
│ (GATE OWNER) │
│ │
│ Powers: │
│ • Iteration authority │
│ • Bounce back repeatedly │
│ • Route to specialists │
│ • Final evidence to Linear │
│ │
│ Tools (Linear MCP): │
│ • mcp__{{MCP_LINEAR_SERVER}}__ │
│ create_comment │
│ • mcp__{{MCP_LINEAR_SERVER}}__ │
│ update_issue │
│ • mcp__{{MCP_LINEAR_SERVER}}__ │
│ list_comments │
└────────────┬────────────────────┘
│
┌────────────────┴────────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ BLOCKED │ │ APPROVED │
│ │ │ │
│ Routes to: │ │ Exit State: │
│ • Implementer │ │ "Approved │
│ • Tech Writer │ │ for RTE" │
│ • Sys Architect│ │ │
└────────┬────────┘ └────────┬────────┘
│ │
│ (Loop until fixed) │
└──────────────────────────────────┤
│
▼
┌─────────────────────────────────┐
│ RTE │
│ (PR SHEPHERD) │
│ │
│ Owns: │
│ • PR creation (from spec) │
│ • CI/CD monitoring │
│ • Evidence assembly │
│ • PR metadata edits │
│ │
│ Must NOT: │
│ • Write product code │
│ • Merge PRs │
│ • Approve own work │
└────────────┬────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ 3-STAGE PR REVIEW │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ STAGE 1: System Architect │ │
│ │ • Pattern compliance │ │
│ │ • RLS enforcement │ │
│ │ • Technical validation │ │
│ │ → Exit: "Stage 1 Approved" │ │
│ └─────────────────┬───────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ STAGE 2: ARCHitect-in-CLI │ │
│ │ • Comprehensive review │ │
│ │ • Architecture validation │ │
│ │ • Security verification │ │
│ │ → Exit: "Stage 2 Approved" │ │
│ └─────────────────┬───────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ STAGE 3: HITL ({{AUTHOR_NAME}}) │ │
│ │ • Final human review │ │
│ │ • Merge authority │ │
│ │ → Action: MERGE │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
1.2 Exit States Flow (with Handoff Statements)
┌─────────────────────────────────────────────────────────────────────────────┐
│ EXIT STATE PROGRESSION │
└─────────────────────────────────────────────────────────────────────────────┘
IMPLEMENTATION QAS RTE HITL
───────────── ───── ───── ──────
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Coding │ │ Validating │ │ Shepherding│ │ Reviewing │
│ Testing │ │ Iterating │ │ CI/CD │ │ Merging │
│ Commits │ │ Evidence │ │ Assembling │ │ │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │ │
▼ ▼ ▼ ▼
╔═════════════╗ ╔═════════════╗ ╔═════════════╗ ╔═════════════╗
║ "Ready ║ ────▶ ║ "Approved ║ ────▶ ║ "Ready for ║ ──▶ ║ MERGED ║
║ for QAS" ║ ║ for RTE" ║ ║ HITL Review"║ ║ ║
╚═════════════╝ ╚═════════════╝ ╚═════════════╝ ╚═════════════╝
│ │ │
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Handoff │ │ Handoff │ │ Handoff │
│ Statement: │ │ Statement: │ │ Statement: │
│ │ │ │ │ │
│ "BE/FE/DE │ │ "QAS valid- │ │ "PR #XXX │
│ impl done │ │ ation done │ │ ready for │
│ for {{TICKET_PREFIX}}-X. │ │ for {{TICKET_PREFIX}}-X. │ │ HITL review.│
│ All valid- │ │ All PASSED. │ │ CI green, │
│ ation pass. │ │ Approved │ │ reviews │
│ AC/DoD │ │ for RTE." │ │ complete." │
│ confirmed. │ │ │ │ │
│ Ready for │ │ │ │ │
│ QAS." │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
1.3 Stop-the-Line Gate (Mandatory)
┌─────────────────────────────────────────────────────────────────────────────┐
│ STOP-THE-LINE GATE (MANDATORY) │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────┐
│ TICKET ARRIVES │
│ (Linear {{TICKET_PREFIX}}-X) │
└────────┬────────┘
│
▼
┌─────────────────────────┐
│ CHECK: AC/DoD EXISTS? │
└────────────┬────────────┘
│
┌─────────────────┴─────────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ YES │ │ NO │
│ │ │ │
│ AC/DoD is │ │ AC/DoD missing │
│ defined and │ │ or unclear │
│ clear │ │ │
└────────┬────────┘ └────────┬────────┘
│ │
▼ ▼
┌─────────────────┐ ╔═════════════════╗
│ PROCEED │ ║ FULL STOP ║
│ │ ║ ║
│ Begin │ ║ • Do NOT ║
│ implementation │ ║ proceed ║
│ │ ║ ║
│ │ ║ • Route back ║
│ │ ║ to BSA/POPM ║
│ │ ║ ║
│ │ ║ • You are NOT ║
│ │ ║ responsible ║
│ │ ║ for inventing║
│ │ ║ AC/DoD ║
└─────────────────┘ ╚═════════════════╝
┌───────────────────────────────────────────────────────────────────────────┐
│ POLICY: Implementation agents (BE/FE/DE) must verify AC/DoD exists │
│ before starting ANY work. This is a hard gate, not optional. │
└───────────────────────────────────────────────────────────────────────────┘
1.4 QAS Iteration Loop
┌─────────────────────────────────────────────────────────────────────────────┐
│ QAS ITERATION AUTHORITY │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────┐
│ WORK ARRIVES │
│ "Ready for QAS"│
└────────┬────────┘
│
▼
┌─────────────────────────┐
│ QAS VALIDATES WORK │
│ │
│ • Run test suites │
│ • Check AC/DoD │
│ • Verify evidence │
│ • Review documentation │
└────────────┬────────────┘
│
┌─────────────────┴─────────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ ALL PASS ✓ │ │ ISSUES FOUND │
│ │ │ │
│ • Tests pass │ │ • Tests fail │
│ • AC/DoD met │ │ • AC incomplete│
│ • Evidence OK │ │ • Docs missing │
│ • Docs match │ │ • Pattern issue│
└────────┬────────┘ └────────┬────────┘
│ │
▼ ▼
╔═════════════════╗ ┌─────────────────┐
║ APPROVED ║ │ BLOCKED │
║ ║ │ │
║ Post evidence ║ │ Route to: │
║ to Linear ║ │ │
║ ║ │ ┌───────────┐ │
║ Exit: "Approved║ │ │Code bugs │──┼──▶ @be-developer
║ for RTE" ║ │ └───────────┘ │ @fe-developer
╚═════════════════╝ │ ┌───────────┐ │
│ │Validation │──┼──▶ Implementer
│ │fails │ │
│ └───────────┘ │
│ ┌───────────┐ │
│ │Doc gaps │──┼──▶ @tech-writer
│ └───────────┘ │
│ ┌───────────┐ │
│ │Pattern │──┼──▶ @system-architect
│ │violation │ │
│ └───────────┘ │
│ ┌───────────┐ │
│ │AC/DoD │──┼──▶ @bsa
│ │missing │ │
│ └───────────┘ │
└────────┬────────┘
│
│ (Fix and return)
│
▼
┌─────────────────┐
│ REPEAT UNTIL │
│ ALL PASS │
│ │
│ QAS has full │
│ iteration │
│ authority │
└─────────────────┘
Part 2: Role Definitions - Contract specifications for each role
2.1 Role Ownership Matrix
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ ROLE OWNERSHIP MATRIX │
├─────────────────┬───────────────────────────────────────────────────────────────────────┤
│ │ RESPONSIBILITIES │
│ ROLE ├───────────┬───────────┬───────────┬───────────┬───────────┬──────────┤
│ │ CODE │ COMMITS │ PR │ MERGE │ EVIDENCE │ GATE │
├─────────────────┼───────────┼───────────┼───────────┼───────────┼───────────┼──────────┤
│ BE-Developer │ ✓ │ ✓ │ ✗ │ ✗ │ Partial │ ✗ │
│ FE-Developer │ ✓ │ ✓ │ ✗ │ ✗ │ Partial │ ✗ │
│ Data-Engineer │ ✓ │ ✓ │ ✗ │ ✗ │ Partial │ ✗ │
├─────────────────┼───────────┼───────────┼───────────┼───────────┼───────────┼──────────┤
│ QAS │ ✗ │ ✗ │ ✗ │ ✗ │ ✓ │ ✓ │
├─────────────────┼───────────┼───────────┼───────────┼───────────┼───────────┼──────────┤
│ RTE │ ✗ │ Metadata │ ✓ │ ✗ │ Assembly │ ✗ │
├─────────────────┼───────────┼───────────┼───────────┼───────────┼───────────┼──────────┤
│ System Architect│ Review │ ✗ │ Stage 1 │ ✗ │ Review │ Stage 1 │
│ ARCHitect-CLI │ Review │ ✗ │ Stage 2 │ ✗ │ Review │ Stage 2 │
├─────────────────┼───────────┼───────────┼───────────┼───────────┼───────────┼──────────┤
│ HITL ({{AUTHOR_NAME}}) │ Review │ ✗ │ Stage 3 │ ✓ │ Final │ Stage 3 │
└─────────────────┴───────────┴───────────┴───────────┴───────────┴───────────┴──────────┘
Legend:
✓ = Owns/Authorized
✗ = Not Authorized
Partial = Captures during work, QAS collects
Review = Read-only review authority
Metadata = PR title, labels, body only (not code)
Assembly = Collects from all agents
2.2 Implementation Agents Contract (BE/FE/DE)
┌─────────────────────────────────────────────────────────────────────────────┐
│ IMPLEMENTATION AGENT CONTRACT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ PRECONDITION (Mandatory Gate): │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Verify AC/DoD exists → If missing, STOP and route to BSA/POPM │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ OWNS: MUST NOT: │
│ ├─ Code changes ├─ Create PRs │
│ ├─ Atomic SAFe commits ├─ Merge to dev/master │
│ └─ Local validation └─ Invent AC/DoD │
│ │
│ MUST DO: │
│ ├─ Run validation loop until ALL pass │
│ ├─ Confirm ALL AC/DoD satisfied │
│ ├─ Commit own work (SAFe format) │
│ └─ Provide handoff statement │
│ │
│ EXIT STATE: "Ready for QAS" │
│ │
│ HANDOFF TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ "[BE/FE/DE] implementation complete for {{TICKET_PREFIX}}-XXX. │ │
│ │ All validation passing. AC/DoD confirmed. │ │
│ │ Ready for QAS review." │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.3 QAS Gate Owner Contract
┌─────────────────────────────────────────────────────────────────────────────┐
│ QAS GATE OWNER CONTRACT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ROLE: GATE (not just validator) │
│ ─────────────────────────────── │
│ Work does NOT proceed without QAS approval. │
│ │
│ OWNS: MUST NOT: │
│ ├─ Independent verification ├─ Modify product code │
│ ├─ Iteration authority ├─ Skip AC/DoD verification │
│ ├─ QA artifacts └─ Approve incomplete work │
│ └─ Final evidence to Linear │
│ │
│ LINEAR MCP TOOLS: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • mcp__{{MCP_LINEAR_SERVER}}__create_comment (post evidence) │ │
│ │ • mcp__{{MCP_LINEAR_SERVER}}__update_issue (update status) │ │
│ │ • mcp__{{MCP_LINEAR_SERVER}}__list_comments (read context) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ ROUTING AUTHORITY: │
│ ┌────────────────┬──────────────────┬───────────────────────────────┐ │
│ │ Issue Type │ Route To │ Action │ │
│ ├────────────────┼──────────────────┼───────────────────────────────┤ │
│ │ Code bugs │ @be/fe-developer │ Return with specific issues │ │
│ │ Validation fail│ Implementer │ Return with failure output │ │
│ │ Doc mismatch │ @tech-writer │ Route for documentation fix │ │
│ │ Pattern issue │ @system-architect│ Escalate for pattern review │ │
│ │ AC/DoD missing │ @bsa │ Cannot approve without AC │ │
│ └────────────────┴──────────────────┴───────────────────────────────┘ │
│ │
│ EXIT STATE: "Approved for RTE" │
│ │
│ HANDOFF TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ "QAS validation complete for {{TICKET_PREFIX}}-XXX. │ │
│ │ All criteria PASSED. Evidence posted to Linear. │ │
│ │ Approved for RTE." │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.4 RTE PR Shepherd Contract
┌─────────────────────────────────────────────────────────────────────────────┐
│ RTE PR SHEPHERD CONTRACT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ PREREQUISITE (QAS Gate): │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Work MUST have QAS approval ("Approved for RTE" status) │ │
│ │ Evidence MUST be posted to Linear │ │
│ │ If QAS not approved → STOP and wait │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ OWNS: MUST NOT (NEVER): │
│ ├─ PR creation (from spec) ├─ Merge PRs (HITL only) │
│ ├─ CI/CD monitoring ├─ Write product code │
│ ├─ Evidence assembly ├─ Approve own work │
│ ├─ PR metadata (title, labels, body) └─ Have merge cmd examples │
│ └─ Coordination between agents │
│ │
│ IF CI FAILS: │
│ ┌────────────────────────────┬─────────────────────────────────────┐ │
│ │ Failure Type │ Route To │ │
│ ├────────────────────────────┼─────────────────────────────────────┤ │
│ │ Structural/pattern issues │ System Architect │ │
│ │ Implementation bugs │ Original implementer (BE/FE/DE) │ │
│ │ NEVER fix code yourself │ --- │ │
│ └────────────────────────────┴─────────────────────────────────────┘ │
│ │
│ EXIT STATE: "Ready for HITL Review" │
│ │
│ HANDOFF TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ "PR #XXX for {{TICKET_PREFIX}}-YYY is Ready for HITL Review. │ │
│ │ All CI green, reviews complete, evidence attached. │ │
│ │ Awaiting final merge approval from {{AUTHOR_NAME}}." │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.5 System Architect Stage 1 Contract
┌─────────────────────────────────────────────────────────────────────────────┐
│ SYSTEM ARCHITECT STAGE 1 CONTRACT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ROLE: Stage 1 of 3-Stage PR Review Process │
│ ─────────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Stage 1: System Architect (you) - Technical/pattern validation │ │
│ │ Stage 2: ARCHitect-in-CLI - Comprehensive review │ │
│ │ Stage 3: HITL ({{AUTHOR_NAME}}) - Final merge authority │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ OWNS: MUST NOT: │
│ ├─ Pattern compliance review ├─ Merge PRs │
│ ├─ RLS enforcement verification ├─ Skip to Stage 3 │
│ ├─ Architecture validation └─ Approve security bypasses │
│ └─ Stage 1 gate authority │
│ │
│ VALIDATION CHECKLIST: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] RLS context enforced (no direct Prisma calls) │ │
│ │ [ ] withUserContext/withAdminContext/withSystemContext used │ │
│ │ [ ] Authentication checks present │ │
│ │ [ ] Pattern library followed │ │
│ │ [ ] TypeScript types valid │ │
│ │ [ ] Error handling comprehensive │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ EXIT STATE: "Stage 1 Approved - Ready for ARCHitect" │
│ │
│ HANDOFF TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ "Stage 1 review complete for PR #XXX ({{TICKET_PREFIX}}-YYY). │ │
│ │ Pattern compliance verified, RLS enforced. │ │
│ │ Approved for ARCHitect-in-CLI review (Stage 2)." │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Routing Quick Reference
┌─────────────────────────────────────────────────────────────────────────────┐
│ ROUTING CHEAT SHEET │
├─────────────────┬───────────────────────────────────────────────────────────┤
│ Issue │ Route To │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Code bugs │ @be-developer / @fe-developer │
│ Validation fail │ Original implementer │
│ Doc mismatch │ @tech-writer │
│ Pattern issue │ @system-architect │
│ AC/DoD missing │ @bsa │
│ CI failure │ Implementer (code) or Architect (infra) │
│ Blocked > 4hrs │ @tdm │
└─────────────────┴───────────────────────────────────────────────────────────┘
What Changed and Why - vNext Contract Changelog
Why This Upgrade Matters
This contract establishes proper SAFe governance for an AI agent team - treating agents as accountable team members with clear boundaries, not autonomous actors.
Key Changes Summary
| Category | Before | After | Why |
|---|---|---|---|
| AC/DoD Check | Optional/informal | Stop-the-Line Gate (mandatory) | Agents shouldn't invent requirements |
| QAS Role | Report producer | Gate Owner with iteration authority | Quality is enforced, not just documented |
| RTE Role | Could touch code/merge | PR shepherd only (no code, no merge) | Clear separation of concerns |
| Exit States | Informal "done" | Explicit states per role | Clear chain of custody |
| Evidence | Scattered | Linear as system of record | Auditable, traceable delivery |
| PR Review | Undefined stages | 3-stage process | Layered review with clear ownership |
| Role Collapsing | Not defined | {{TICKET_PREFIX}}-499: RTE collapsible, QAS/SecEng not | Flexibility with safety |
Detailed File Changes
Harness Files Updated (10):
| File | Change | Rationale |
|---|---|---|
.claude/README.md | Added Role Execution Modes | Clarify solo vs multi-agent operation |
.claude/commands/start-work.md | Added Stop-the-Line gate | Agents must verify AC/DoD exists |
.claude/agents/be-developer.md | Added Precondition, Ownership, Exit | Clear boundaries for implementers |
.claude/agents/fe-developer.md | Added Precondition, Ownership, Exit | Clear boundaries for implementers |
.claude/agents/data-engineer.md | Added Precondition, Ownership, Exit | Clear boundaries for implementers |
.claude/agents/qas.md | Upgraded to Gate Owner + Linear MCP | QAS is a gate, not just validator |
.claude/agents/rte.md | Added QAS prerequisite, removed merge | RTE shepherds, doesn't merge |
.claude/agents/system-architect.md | Added Stage 1 review role | First stage of 3-stage review |
.claude/commands/search-pattern.md | Added Grep tool parameters | Better pattern search UX |
.claude/skills/orchestration-patterns/SKILL.md | Fixed command references | Documentation accuracy |
New Documentation Added (4):
| File | Purpose |
|---|---|
docs/sop/AGENT_CONFIGURATION_SOP.md | Tool restrictions, model selection per role |
docs/guides/AGENT_TEAM_GUIDE.md | Comprehensive agent team reference |
docs/workflow/WORKFLOW_COMPARISON.md | TDM role clarification (coordinator, not orchestrator) |
docs/workflow/WORKFLOW_MIGRATION_GUIDE.md | Guide for transitioning to vNext |
Project Docs Updated (6):
| File | Change |
|---|---|
AGENTS.md | Exit States table, role updates |
README.md | vNext workflow diagrams, Author's Note |
CONTRIBUTING.md | Exit States, Gate Reference, Role Collapsing |
docs/sop/AGENT_WORKFLOW_SOP.md | v1.4 with vNext sections |
docs/workflow/TDM_AGENT_ASSIGNMENT_MATRIX.md | v1.4 updates |
docs/workflow/ARCHITECT_IN_CLI_ROLE.md | Role Collapsing Authority |
Version History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2025-12-23 | Claude Code (Opus 4.5) | Initial vNext contract (Phases 1-2) |
| 1.1 | 2025-12-23 | Claude Code (Opus 4.5) | Phase 3 docs + errata |
| 1.2 | 2025-12-23 | Claude Code (Opus 4.5) | Alignment fixes (TDM role, QAS write policy) |
| 1.3 | 2025-12-23 | Claude Code (Opus 4.5) | {{TICKET_PREFIX}}-499: Role collapsing policy |
Source Document
Full knowledge transfer document: {{TICKET_PREFIX}}-497-vnext-workflow-contract-kt.md
Appendix A: Quick Reference Cards - Printable cheat sheets
A.1 Exit State Quick Reference
┌─────────────────────────────────────────────────────────────┐
│ EXIT STATE CHEAT SHEET │
├─────────────────┬───────────────────────────────────────────┤
│ Role │ Exit State │
├─────────────────┼───────────────────────────────────────────┤
│ BE-Developer │ "Ready for QAS" │
│ FE-Developer │ "Ready for QAS" │
│ Data-Engineer │ "Ready for QAS" │
│ QAS │ "Approved for RTE" │
│ RTE │ "Ready for HITL Review" │
│ System Architect│ "Stage 1 Approved - Ready for ARCHitect" │
│ ARCHitect-CLI │ "Stage 2 Approved - Ready for HITL" │
│ HITL │ MERGED │
└─────────────────┴───────────────────────────────────────────┘
A.2 Gate Quick Reference
┌─────────────────────────────────────────────────────────────┐
│ GATE CHEAT SHEET │
├─────────────────┬─────────────────┬─────────────────────────┤
│ Gate │ Owner │ Blocking? │
├─────────────────┼─────────────────┼─────────────────────────┤
│ Stop-the-Line │ Implementer │ YES - no AC = no work │
│ QAS Gate │ QAS │ YES - no approval = stop│
│ Stage 1 Review │ System Architect│ YES - pattern check │
│ Stage 2 Review │ ARCHitect-CLI │ YES - architecture check│
│ HITL Merge │ {{AUTHOR_NAME}} │ YES - final authority │
└─────────────────┴─────────────────┴─────────────────────────┘
A.3 Routing Quick Reference
┌─────────────────────────────────────────────────────────────┐
│ ROUTING CHEAT SHEET │
├─────────────────┬───────────────────────────────────────────┤
│ Issue │ Route To │
├─────────────────┼───────────────────────────────────────────┤
│ Code bugs │ @be-developer / @fe-developer │
│ Validation fail │ Original implementer │
│ Doc mismatch │ @tech-writer │
│ Pattern issue │ @system-architect │
│ AC/DoD missing │ @bsa │
│ CI failure │ Implementer (code) or Architect (infra) │
│ Blocked > 4hrs │ @tdm │
└─────────────────┴───────────────────────────────────────────┘
See Agent Workflow SOP v1.4 for complete details.
Important Caveats
- Multi-provider: Supports Claude Code, Gemini CLI, Codex CLI, and Cursor IDE
- Template-ready: All project-specific values use
{{PLACEHOLDER}}tokens - Provider maturity varies: Claude Code has the deepest integration; other providers are newer
- Domain examples: Non-SWE adaptations (marketing, research) are documented but not yet validated
Repository Structure
.claude/ # Claude Code harness (primary provider)
├── commands/ # 24 slash commands for workflow automation
├── skills/ # 20 model-invoked skills for domain expertise
├── agents/ # 11 SAFe agent profiles
├── team-config.json # Agent Teams settings (optional, experimental)
└── SETUP.md # Installation and customization guide
.gemini/ # Gemini CLI harness (secondary provider)
├── commands/ # 30 TOML commands (namespaced: /workflow:*, /local:*, /remote:*, /media:*)
├── skills/ # 19 model-invoked skills (team-coordination is Claude-only)
├── settings.json # Configuration (model, hooks, policy, security)
├── GEMINI.md # System instructions
└── README.md # Gemini-specific setup guide
.codex/ # Codex CLI harness (reads AGENTS.md, TOML config, MCP native)
├── config.toml # Codex CLI configuration (model, approval policy, sandbox)
└── README.md # Codex-specific setup guide
.cursor/ # Cursor IDE harness (glob-based .mdc rules, background agents)
└── rules/ # .mdc rule files with YAML frontmatter activation
├── 00-02 # Always-apply core rules (SAFe, git, patterns)
├── 03 # SAFe x AI-DLC program cadence (manual activation)
├── 04 # Knowledge-vault conventions (manual activation)
├── 10-13 # Auto-attached tech rules (Python, React, SQL, tests)
├── 20-23 # Agent-role rules (Architect, Backend, QAS, Security)
└── 30-31 # Background agents and MCP integration
.agents/ # Shared agent skills (discovered by Codex and other agents)
└── skills/ # 20 cross-provider skills (api-patterns, safe-workflow, etc.)
knowledge-vault/ # OKF knowledge-base subsystem (optional)
├── docs/ # Method, playbook, build prompts, Obsidian guide
├── templates/ # Starter bundle, Obsidian config, CI workflow
├── scripts/ # validate-vault.mjs (zero dependencies)
└── tests/ # Proof that each validator gate fails when broken
dark-factory/ # tmux Agent Teams infrastructure (optional)
├── scripts/ # factory-setup, start, stop, status, attach
├── templates/ # tmux.conf, team layouts, merge queue ruleset
└── docs/ # Dark Factory guide, Cursor SSH, merge queue policy
docs/ # Additional documentation
├── guides/ # Methodology and adoption guides (incl. SAFe x AI-DLC)
├── whitepapers/ # Harness architecture and philosophy
└── onboarding/ # Getting started guides
specs_templates/ # Spec, planning, PI planning, and program templates
Citation
Download: CITATION.bib | CITATION.cff
APA 7th Edition
{{AUTHOR_LAST_NAME}}, {{AUTHOR_INITIALS}}, & {{PROJECT_SHORT}} Development Team. (2025). Evidence-based multi-agent
development: A SAFe framework implementation with Claude Code [White paper].
https://github.com/{{GITHUB_ORG}}/{{PROJECT_REPO}}
Contributing
We welcome contributions:
- Patterns: Share production-tested patterns
- Case Studies: Document your implementation experience
- Research: Explore open questions from Section 10
- Improvements: Suggest methodology enhancements
See CONTRIBUTING.md for guidelines.
License
MIT License - See LICENSE for details.
Attribution
This project is the Words To Film By™ multi-agent harness, adapted for SAFe development workflows.
Creator: J. Scott Graham (@cheddarfox) - jscottgraham.us Organization: ByBren, LLC Enterprise: Words To Film By™
If you use this harness in your own projects, you must include attribution. See NOTICE for details.
Historical Context: Evolved from Auggie's Architect Handbook
Words To Film By™
Website •
Contact •
Sponsor
"Your AI team, ready to work."
Version: v2.11.1
Status: Production-validated, multi-provider (Claude Code + Gemini CLI + Codex CLI + Cursor IDE)