High Intensity Flow v0.1, experimental
An augmented git workflow for multi-expertise parallel collaboration. HIF provides a single coherent branch model across the entire delegation spectrum, from human teams to fully automated pipelines.
This document describes the full model in all its complexity. In practice, HIF scales down to a single main branch for small teams or early-stage projects. Adapt the branching depth to your context: team size, project criticality, maturity stage. Start simple, add structure when coordination becomes the bottleneck.
Why HIF exists
Traditional git workflows assume either single-expertise teams or sequential review gates. AI-augmented development dramatically increases output speed, making synchronization and arbitration the real bottlenecks, not production.
In this model, the team's primary role shifts from producing code to: guiding agents, building the development environment (tests, constraints, tooling), analyzing results, and formalizing knowledge as testable, automatable artifacts.
| Evolutiondon't block anyone | Vs. | Stabilitydon't ship broken things |
| Parallelismclusters work simultaneously | Vs. | Integrationtheir work must compose |
| Iterationmessy WIP within clusters | Vs. | Clarityclean history for posterity |
Branch structure
A branch should have at most 2 concurrent contributors. Beyond that, coordination overhead negates the benefit of parallelism. This drives the branching depth described below.
Stabilization (semver)
Software projects face a permanent tension between evolving fast and keeping things stable for existing users. Semver branching resolves this by isolating concerns: cutting-edge work on main, backward-compatible improvements on vX, and production fixes on vX.Y.
Each level capitalizes on the investment made at the level above: stability branches inherit proven features, release branches inherit only safe fixes. Users choose the level of risk they accept.
feat/
From main. Breaking changes, experimental work, R&D.
comfeat/
From vX. New features, backward-compatible.
fix/
From vX.Y. Bugfixes and security patches, propagated upward.
Feature development
Feature branches are a natural extension of semver: within a single feature, multiple expertise domains work in parallel. The feature integration branch forks from main or vX, then splits into cluster branches (groups of related domains), which themselves split into expert branches.
Clusters iterate: product and implementation run in parallel, merge back into the feature branch, then start a new round. Each iteration tightens quality until convergence.
cluster/
Shared workspace for related domains (product, impl, hardening).
expert/
Individual expert branch (po, design, archi, secu, qa, ops).
Co-construction clusters
Experts organize into clusters, groups of domains with strong interdependencies. Clusters are not fixed; they form based on the nature of the work. A project declares its clusters in TEAM_WORKFLOW.md.
Product
PO, Design, UX
Value, acceptance, user experience
Implementation
DEV, QA, (OPS)
Behavior, test coverage, code quality
Infrastructure
DEV, OPS, Archi
Deployment, scaling, observability
Hardening
SECU, Archi, OPS
Auth, crypto, GDPR, threat surface
Roles
Expertise roles
What you produce: PO (value, scope), Design/UX (experience, accessibility), Architecture (patterns, contracts), Security (hardening, compliance), QA (tests, quality gates), Ops (infrastructure, CI/CD), Dev (implementation satisfying all constraints).
Meta roles
Integrator
Merges expert branches into clusters into features. Resolves conflicts with experts. Develops implementations to satisfy constraints. Rotating, per feature or per sprint. The DEV is the natural default.
Release manager
Manages vX / vX.Y branches, tags, backward-compat decisions. Stable, usually Ops or senior Dev.
Facilitator
Unblocks experts, manages sync meetings, detects bottlenecks. Rotating or PO by default.
Expert branches: knowledge over code
Expert branches are not primarily about implementation. They are workspaces where each expert formalizes their contribution -- constraints, tests, specs, rules that the implementation must satisfy. The value is the formalized knowledge, not the code state.
Formalized constraints survive merges even when code breaks. The knowledge persists independently of any particular implementation.
Agent delegation continuum
HIF supports a continuous spectrum from fully human-driven to fully automated. The same branch structure serves teams of 15 humans, a solo dev with AI agents, or any combination.
Default level: agent assists, human merges
- Agent assists any expert in their branch (write tests, draft ADRs, propose code)
- Agent runs validation suites and reports constraint satisfaction
- Agent detects stale branches, proposes integration order
- All merges are integrator-triggered
Higher delegation levels
- Agent autonomously holds an expert role (QA agent, security auditor)
- Agent performs integration merges when all automated checks pass
- Agent manages entire cluster branches with human review only at convergence
- Full delivery pipeline with human oversight reduced to strategic decisions