FlowForge · BA/PO Pipeline Proposal
FlowForge accelerates engineering with 15 agents across 5 steps.
The BA phase has 3 agents in .require — all operating after the spec is written.
The 6–10 hours before the spec exists have no tooling. And non-technical BAs face a hidden git barrier before they can even start.
The problem
Steps 02–06 are built for developers — 15 agents, automated, structured. Step 01 has 3 agents — all post-spec-capture. The 6–10 hours before the spec gets written have nothing.
Gap Reviewer (Explore sub-agent, Phase 1) finds holes the author missed.
Self-Review (Phase 2) has the main agent switch to critical reviewer mode and challenge its own spec.
QA Author (Phase 3) generates the test skeleton.
All three are post-capture — none of them help you discover what to build.
git pull origin master must be run manually before starting any new feature. Forgetting it is silent — no error, just stale context.
(2) Branch dependency trap: /flowforge.require creates a feature branch immediately from whatever the current HEAD is. If feature A's branch hasn't been merged yet, feature B's branch is parented on A — creating an implicit dependency that isn't visible until .plan or .build fails on unrelated changes. A non-git user has no way to know this is happening.
Neither issue is in scope for the current BA pipeline proposal, but both must be resolved before non-technical BAs can run FlowForge independently.
Time audit
A standard feature before it reaches .plan. The 3 post-capture agents save ~20–30 min on spec quality; everything before the spec is written has no tool support at all.
The proposal
Seven new commands + one enhanced command extend the BA pipeline. A new pre-flight step eliminates the git barrier for non-technical users. Today's 3 agents all review the spec after you write it — the proposal adds agents for everything before and around that moment.
git pull required. Checks for unmerged branches: if a prior feature branch exists and hasn't been merged, warns the user before creating a new one — preventing silent branch dependency traps. Creates the feature branch from a clean, up-to-date HEAD.Estimated impact
Grounded in the current team size — 19 FlowForge users, 55 active tickets — observed cycle time, and where time is spent today. Baselines credit the 3 existing agents in .require.
.plan. Revised down from −65% to credit existing partial coverage./ff.ideate generates 3–4 structured options before the meeting. The session becomes a decision, not an exploration. 90+ min → ~60 min. Revised from −40% — ideation only eliminates option-generation time, not all discussion overhead..plan reviewers already apply this pattern technically — the proposal replicates it upstream at the requirements layer.Cycle time
Standard feature, business problem to merged PR. Each segment is a phase. Hover for details.
Why it compounds
The weak link is at the top. The current pipeline is only as good as the spec that enters it.
.plan. The 6 plan-review agents flag it, work bounces back to the BA. One cycle = half a dev day wasted before any code is written..verify technically correct but doesn't meet business intent. The failure that's hardest to catch.git pull origin master first. A non-technical BA will not know to do this. The failure is silent — FlowForge runs against stale code, produces a spec grounded in the wrong baseline. No error is raised. Addressed by /ff.start, but until that ships, this is a guaranteed failure mode for any BA using FlowForge without a dev standing by./flowforge.require creates the feature branch immediately from the current HEAD. If a prior feature branch is still open (not merged), the new branch is parented on it — creating an implicit dependency. When the first feature changes or is rebased, the second breaks silently. A BA starting two features in sequence will hit this every time and have no idea why. Addressed by /ff.start's branch conflict check, but the current tool has no guard at all./ff.discover depends on BAs trusting an agent-driven interview. First runs will need heavy human correction. Adoption lags the more mechanical commands.research, require enhancement, prd) validate the model before exploratory ones (discover, ideate) need to be trusted.Build sequence
Start where friction is highest and trust is easiest to build. Each phase validates the model for the next.
/ff.start is the prerequisite for all other BA commands — pull + branch safety check, zero learning curve. Research replaces hours of manual lookup. The 5 new review agents extend an existing command. PRD is a zero-cost Confluence byproduct.