SAW: A SAFe-Derived Harness That Puts Hooks, Commands and Skills Around Your AI Coding Agent
SAW — SAFe Agentic Workflow AI Agent Harness for Multi-Agent Team Workflows Built on SAFe methodology (Scaled Agile Framework), adapted for AI agent teams (Now With AI-DLC!) Works for any team with repeatable processes: Software, Marketing, Research, Legal, Operations.
At a glance
- What is it?
- bybren-llc/safe-agentic-workflow is an MIT-licensed template repository that ships 11 agent profiles, 24 slash commands and 20 skills on top of Claude Code, Gemini CLI, Codex CLI or Cursor. The judgement: it is a process scaffold, not a runtime, and its value depends entirely on whether your team already has repeatable workflow steps worth encoding.
- Who is it for?
- Adopt SAW if your team already runs a ticketed process and you want the agent to inherit those steps rather than invent them, and if you are willing to maintain a sync manifest. Do not adopt it if you want a runtime that orchestrates agents for you: SAW is files copied into your repository, and the multi-agent team feature is marked experimental.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 57 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem SAW Solves Is Workflow Drift, Not Code Generation
Most teams adopt an AI coding agent and then discover that the agent has no idea how their team works. It does not know that a change needs a ticket reference, that a pull request needs a specific checklist, or that a particular directory is off limits. Each developer compensates with their own prompt, and the prompts diverge. SAW's answer is to check those conventions into the repository as files the agent reads.
The README frames this as a harness, and the framing is accurate. What you copy is a directory of agent profiles, commands and skills. The project describes 11 SAFe agent profiles as specialized roles with clear boundaries, 24 slash commands for workflow automation, and 20 skills that the model invokes on its own. The intended audience, per the README, is any team with repeatable processes, and it lists software, marketing, research, legal and operations. That list is broader than the implementation suggests: the concrete commands shown are ticket-oriented, so the fit is strongest where work arrives as numbered tickets and leaves as reviewed pull requests.
Three Layers, and Only the Top One Runs Without You
The architecture diagram in the README names three layers. Layer 1 is hooks, described as automatic guardrails covering format checks and blockers. Layer 2 is commands, described as user-invoked workflows, with /start-work and /pre-pr given as examples. Layer 3 is skills, described as model-invoked expertise, with pattern discovery as the example.
The distinction matters more than the diagram suggests. Hooks fire without a human asking. Commands fire when someone types them. Skills fire when the model decides they are relevant. So the harness has exactly one layer that enforces anything, and it is the layer the README describes in the fewest words. Everything else is a convention the agent may follow. If your team's actual problem is that agents skip steps, the hooks layer is where you should look first, and the README does not document the hook contents in the excerpt available here.
Agent Teams, the multi-agent orchestration feature with SAFe quality gates, is explicitly labelled experimental in the README. Treat it as a research direction rather than a supported capability.
Installation Is a Copy Plus a Placeholder Pass
There is no package to install. The Claude Code path in the README is two commands: copy the .claude directory into your project, then run bash scripts/setup-template.sh to customize placeholders. The README names {{TICKET_PREFIX}} and {{PROJECT_NAME}} as examples and says the script handles the rest in one pass. After that, /start-work TICKET-123 is the entry point.
The other providers differ in ways worth noting before you commit. Gemini CLI uses the same copy pattern into .gemini, requires npm install -g @google/gemini-cli and export GEMINI_API_KEY, and invokes workflows with a namespaced form: /workflow:start-work TICKET-123. Codex CLI needs two directories copied, .codex and .agents, plus npm install -g @openai/codex and export OPENAI_API_KEY, and the README states plainly that it uses natural language with no slash commands. Cursor takes .cursor only, and rules activate based on file context, with @rule-name for manual invocation.
That last difference is the one that changes your workflow. A team standardized on /start-work in Claude Code cannot carry the same habit to Codex, because the command surface does not exist there. The harness is multi-provider, but the interaction model is not portable.
The Sync Script Is the Part That Can Cost You Work
SAW ships a second script, scripts/sync-claude-harness.sh, whose job is pulling upstream changes into a repository you have already customized. The README states that this script protects your customizations via a manifest, and that the manifest has been required since v2.10.0. The initialization sequence is explicit: run sync-claude-harness.sh init, then sync-claude-harness.sh manifest init --yes, then preview with sync --version v2.11.1 --dry-run before applying. A --scope flag narrows the sync to specific domains, with .claude,.gemini given as an example.
This is a real maintenance cost, and the README is honest about it. The manual alternative is a git remote plus cherry-picking, shown as git remote add harness, git fetch harness main --tags, a diff between two version tags, and git checkout harness/main -- .codex/agents/ to pull a single directory. Both paths assume you will upgrade deliberately. The failure mode to plan for is a file you edited that the manifest does not know is protected: the README says the script will not overwrite files marked as protected, which implies the inverse for files that are not. Run the dry run first, every time.
Where the Harness Fits Badly
SAW assumes a process exists. If your team has not agreed on what a ticket contains, what a review requires, or which files an agent must not touch, the harness gives you directories to fill with your own disagreements. The 24 commands and 20 skills are scaffolding, and scaffolding around an undefined process is just more surface area.
The second mismatch is team size. A solo developer or a two-person project gains little from 11 role profiles with boundaries between them, because the boundaries exist to prevent agents from stepping on each other's responsibilities. With one person and one agent, there is nothing to separate.
The third is the experimental label on Agent Teams. If coordinated multi-agent work is the reason you are looking at SAW, the README tells you that capability is not yet settled. The parts of the project that are settled are the commands and skills, which are single-agent conveniences.
Licence-wise, the repository is MIT, which permits commercial use and modification. That is permissive, and it also means the project offers no warranty. Nothing here is legal advice; read the LICENSE file.
Against a Plain CLAUDE.md or a Rules File
The obvious alternative is what most teams already do: a single CLAUDE.md or an equivalent rules file at the repository root, listing conventions in prose. The difference in approach is structural. A prose file is read as context and competes with everything else in the window. SAW splits the same intent across three mechanisms with different trigger conditions, so a format check can run without the model choosing to run it.
That structural split is the entire argument for SAW over a rules file, and it is a real argument. It is also the reason SAW is harder to adopt: you are maintaining a directory tree, a placeholder substitution script and a sync manifest instead of one markdown file. A team whose conventions fit in a page and rarely change should keep the page. SAW earns its overhead when the conventions are numerous enough that a model reliably forgets some of them, and when someone is willing to own the sync.
What to Check Before You Copy the Directory
The README cites an origin of five months of production use, 169 issues and 2,193 commits, and points to a knowledge vault with a drift-detecting validator and a Dark Factory guide for persistent autonomous agent teams over tmux on remote servers. Those are pointers to further documentation, not evidence you can evaluate from the README alone, and the excerpt available here does not include the contents of either guide.
The practical check is narrower. Copy one provider directory into a scratch repository, run bash scripts/setup-template.sh, and read the resulting diff to see which files changed and whether any placeholder survived. Then run the sync script's init and manifest init --yes, mark one file as protected, and run a sync with --dry-run against v2.11.1 to confirm the protected file is left alone. That sequence exercises the two scripts that carry the project's real complexity. If both behave, the harness is doing what the README claims. If the placeholder pass leaves tokens behind or the protected file is touched, you have found the boundary before it found your repository.
Editorial conclusion
Adopt SAW if your team already runs a ticketed process and you want the agent to inherit those steps rather than invent them, and if you are willing to maintain a sync manifest. Do not adopt it if you want a runtime that orchestrates agents for you: SAW is files copied into your repository, and the multi-agent team feature is marked experimental. Verify first that scripts/setup-template.sh handles every placeholder in your provider directory, and that the files you intend to customize are marked protected in the manifest before the first sync, because the sync script is the one component whose failure mode damages your work rather than merely blocking it.
Community notes