RFC: Optional Client-Delivery Workflow with Research Sprints and Multi-Round Review #328

Discovery interviews, research sprints, work plans, and multi-round review

Summary

I’d like to discuss an optional workflow for Squad that improves how it handles ambiguous or evolving work before implementation begins.

This is strongly inspired by the behavioral strengths of Flow-Next, especially its interview-first refinement, research-backed planning, and repeated review gates, but the proposal here is to express those behaviors natively within Squad.

The workflow I’m proposing would let Squad:

• clarify rough requests like a client-facing delivery lead,
• research multiple plausible directions when the answer is not obvious,
• compare and score those directions from different perspectives,
• present a visible solution plan and work plan,
• refine that plan through multiple review rounds,
• and require evidence-backed implementation review before calling work done.

Scenario

My real workflow often looks like this:

• I start with rough ideas, not finished tickets.
• Parts of the idea sometimes supersede or reorder other parts.
• Sometimes I know the outcome I want but not the stack or implementation details, and I want the system to research and recommend.
• Before implementation starts, I want to see:
  • the proposed solution,
  • the work plan,
  • milestones,
  • task order,
  • priorities,
  • dependencies,
  • and what can be parallelized.
• I want multiple rounds of plan review and implementation review, with concrete required changes and evidence, not just one-pass approval.

In practice, I want Squad to behave more like a strong client-facing delivery team before it behaves like a coding swarm.

Why Squad already feels close

Current Squad already has many of the right building blocks:

• real multi-agent spawning instead of role-play
• durable .squad/ state
• directives / decisions
• custom ceremonies
• skills as a reusable orchestration primitive
• reviewer gating
• SDK-first support
• role specialization already present in many teams

That makes this feel like an extension of Squad’s existing direction, not a different product.

What feels missing

The main thing that feels missing is a first-class local planning and review workflow for ambiguous work.

1. Client-facing discovery is not first-class

The Lead is not explicitly optimized for a structured clarification / refinement pass when the request is still fuzzy.

2. Research sprints are not first-class

When a request is vague or there are multiple viable approaches, I want Squad to run a bounded research sprint before committing to a solution plan.

That research sprint should:

• produce multiple plausible proposals,
• score them from different goals,
• and recommend the best option or best blend.

3. The local workflow artifact set is not standardized

I want an explicit repo-local artifact set for:

• research briefs
• proposal sets
• scoring matrices
• judge decisions
• context packs
• solution plans
• work plans
• task graphs
• plan reviews
• implementation reviews
• evidence bundles

4. Plan review is not first-class

I want a dedicated plan review loop with clear verdicts such as:

• SHIP
• NEEDS_WORK
• BLOCKED

5. Implementation review wants richer evidence

I want “done” to mean:

• code exists,
• evidence exists,
• required reviewers approved,
• and the Lead approved the result.

6. Local iterative refinement wants a bounded revise/resubmit loop

For local workflow artifacts, I often want:

• author writes plan or task
• reviewers say NEEDS_WORK
• same author revises
• re-review
• continue until approved or escalated

A bounded local revise/resubmit loop feels like a better fit for plan/task refinement than immediate global lockout.

Proposed workflow

For non-trivial work:

1. Discovery Interview
2. Research Sprint when the direction is still open
3. Context Pack
4. Solution Plan
5. Work Plan
6. Task Graph
7. Plan Review until SHIP
8. Implementation
9. Evidence Bundle
10. Implementation Review until SHIP
11. Lead approval

Research Sprint proposal

This is the biggest addition I think would improve outcomes.

Research Sprint purpose

A Research Sprint is a bounded discovery pass that turns vague work into a decision-ready direction.

Research Sprint outputs

• research brief
• multiple proposals
• scoring matrix
• judge decision
• selected option or blended option
• carry-forward notes for the solution plan

Research Sprint perspectives

I think this works best when proposals are intentionally scored from different goals:

• Original / Proposer

  • argues for the strongest candidate approach
  • explains why it is attractive
  • presents the upside clearly

• Adversarial / Challenger

  • looks for weaknesses, blind spots, hidden cost, edge cases, and long-term risk
  • pushes against shallow optimism

• Judge / Synthesizer

  • scores the options explicitly
  • explains tradeoffs
  • recommends the best option or best blend

Suggested scoring dimensions

• user fit
• technical fit
• delivery risk
• reversibility
• maintainability
• UX clarity
• testing complexity
• operational complexity
• time to first value
• long-term extensibility

Why this matters

This would help Squad handle requests like:

• “I have an idea, but I’m not sure how it should work.”
• “Research it and tell me the best options.”
• “Some of these ideas conflict. Figure out the right order.”
• “Bring me the strongest approach, not just the first one.”

Proposed implementation shape

1. Add an optional built-in workflow skill

Something like:

• client-delivery-loop

It would teach the team this flow:

1. Discovery Interview
2. Research Sprint when needed
3. Context Pack
4. Solution Plan
5. Work Plan
6. Task Graph
7. Plan Review until SHIP
8. Implementation
9. Evidence Bundle
10. Implementation Review until SHIP
11. Lead approval

2. Add optional ceremonies

New ceremonies such as:

• Discovery Interview
• Research Sprint
• Plan Review
• Implementation Review

3. Standardize a local workflow artifact namespace

Something like:

.squad/workflow/
  research/
  context-packs/
  plans/
  work-plans/
  tasks/
  plan-reviews/
  impl-reviews/
  evidence/

4. Reuse existing roles where possible

I am not asking for a second mandatory cast of reviewer agents.

In many teams, the current roster already has enough specialization for:

• lead / architecture
• QA
• UX
• security
• prompt/procedure ownership
• SDK/build ownership

So this feels like a role/capability convention, not a fixed required roster.

5. Add a workflow-scoped iterative review policy

For artifacts under the local workflow namespace only, allow a bounded same-author revise/resubmit loop, for example:

• up to 2 consecutive NEEDS_WORK rounds go back to the same author
• immediate reassignment if a reviewer requests fresh eyes
• forced reassignment on the 3rd rejection

6. Make this work in both markdown-mode and SDK-first repos

This feels especially important now that Squad supports both repo-local markdown state and SDK-first configuration/build flows.

Why this feels aligned with Squad’s direction

This seems compatible with the current direction toward:

• skill-based orchestration,
• SDK-first configurability,
• smaller coordinator surfaces,
• and more modular workflow behavior.

The proposal is meant to lean into that direction.

Questions for maintainers

1. Should this live in core as an optional built-in workflow, or as an extension/plugin pattern?
2. Should the local artifact namespace be under .squad/workflow/, or should it align with another proposal/spec convention?
3. Should research sprints be modeled primarily as:
   • a skill,
   • a ceremony,
   • a standard artifact schema,
   • or a combination of the three?
4. Should the iterative local revise/resubmit rule be:
   • workflow-scoped,
   • ceremony-scoped,
   • or globally configurable?
5. Should the review verdict schema be standardized across ceremonies?
6. In SDK-first mode, what is the right authoring surface for this feature so source and generated output stay aligned?

What I’d be happy to PR after discussion

If this direction sounds reasonable, I’d be happy to follow up with a minimal PR that starts with:

1. an optional workflow skill,
2. optional ceremonies,
3. docs for the local workflow artifact layout,
4. research sprint support and scored proposal comparison,
5. and the smallest possible implementation for iterative local review.

I’m intentionally aiming for the smallest version that matches how planning and refinement often work in practice.