What you are proving
That the squad is a methodology, not just a code generator. The same Research → Plan → Implement → Review spine that drives the Azure demo also runs business discovery and delivery — owned by named specialists, persisted as decisions and history, and gated on every action that matters. The differentiator for a non-technical client: every beat ends in an artifact they can read and sign off on — a requirements document, a roadmap, a deck — never raw markdown buried in a repo.
| Capability | Squad role | Notes |
|---|---|---|
| Discovery (personas, journey map) | designer (DT Coach) | Design Thinking facilitation — empathize and define, fully non-technical. |
| Requirements (BRD / PRD) | analyst (BRD Builder) | Turns the discovery into a signable business requirements document. |
| Roadmap + backlog | product-owner (Functional Planner) | Sequences the work into a validated, goal-oriented work-item hierarchy. |
| Cheap validation | experimenter (Experiment Designer) | Designs a Minimum Viable Experiment for the riskiest assumption before anyone builds. |
| Executive deck | presenter (PowerPoint Subagent) | A board-ready summary of the whole arc. |
| Research → Plan → Implement → Review | researcher, lead, developer, tester | The methodology spine, seeded into the product profile alongside the specialists. |
Before you start
This demo touches no cloud and writes only documents, so it runs anywhere with VS Code and Copilot — ideal for a first pitch. The one optional extra worth wiring is phone approval, so a non-technical sponsor can approve the squad from their device.
| Prerequisite | Why | Check |
|---|---|---|
hve-squad installed (with the product profile) | The discovery, requirements, roadmap, experiment, and deck roles are seeded by the product profile. | apm install "Peter-N91/hve-squad" |
| VS Code + Copilot (agent mode) | The squad dispatches subagents. | — |
runSubagent or task tool enabled | The coordinator needs it to dispatch the cast. | — |
GitHub repo + gh auth (optional) | Only for the github-issue approval channel — lets a sponsor approve from a phone. | gh auth status |
No Azure, no spend, no code. Every beat in this demo produces a business document. That makes it safe to run live in front of a non-technical client — there is nothing to deploy and nothing to break. The PowerPoint and documentation roles are the translation layer that turns squad artifacts into deliverables a client actually reads.
Make it about their world
The script below uses a placeholder, {{CLIENT_PROCESS}} — a business process the
client wants to improve (onboarding, expense approval, support intake, procurement, anything).
Swap it per client, or, in a live run, let the client name their own pain point in Beat 1. The
discovery roles are general-purpose, so the squad handles whatever they bring.
Beat 0 — Initialize the squad
/squad profile=product request="Set up the squad for a business improvement project."
The coordinator discovers the repo, proposes the product profile, and on your
confirmation seeds the squad. Narrate: "One team — discovery, requirements,
roadmap, experiment, and deck specialists — and riding along with them the
methodology spine: researcher, lead, developer, tester, so research → plan →
build → review is always there, even for business work."
At Init the coordinator offers an approval channel. Pick github-issue when you
want a sponsor to approve from a phone with a /approve comment; keep the default
in-chat for a simple at-the-desk run.
Beat 1 — Discovery
/squad request="Explore the problem of {{CLIENT_PROCESS}}. Map the people involved, their journey today, and where it hurts — produce personas and a journey map."
The researcher gathers context and the designer (DT Coach) runs the
Design Thinking empathize-and-define work — personas and a journey map. This is the visibly
non-technical beat: it is about people and process, not systems.
Live tip: ask the client to supply {{CLIENT_PROCESS}} here — it
is far more compelling than a canned scenario.
Beat 2 — Requirements (BRD)
/squad request="Turn the discovery into a Business Requirements Document for {{CLIENT_PROCESS}} — goals, scope, stakeholders, business requirements, and success measures."
The analyst (BRD Builder) produces a signable requirements document.
This is where the methodology surfaces: authoring the BRD is a
confirm-tier step, so the squad researches and plans the document before drafting
it, and reviews it after — the business artifact is planned and reviewed, not improvised.
Beat 3 — Roadmap and backlog
/squad request="Sequence the requirements into a phased roadmap and a refined backlog of goal-oriented stories with acceptance criteria."
The lead plans the phases and the product-owner (Functional Planner) plans
the backlog into a validated, outcome-focused work-item hierarchy with acceptance criteria. The client leaves the beat with a roadmap and
a ready-to-work backlog — the bridge from idea to delivery.
Beat 4 — Validate cheaply
/squad request="Design a Minimum Viable Experiment to test the riskiest assumption behind {{CLIENT_PROCESS}} before we build anything."
The experimenter (Experiment Designer) frames a hypothesis and the cheapest
experiment that could prove or disprove it. Narrate: "Before we spend a
dollar building, the squad tells us the smallest test that de-risks the idea."
Beat 5 — Readiness review (go / no-go)
/squad request="Run a go/no-go readiness review of the plan and backlog before we commit — call out gaps, risks, and conditions."
The product-owner checks product fit and the tester (Plan Validator)
cross-checks the plan against the discovery and requirements, returning a clear go / conditions
/ stop call. This is governance a non-technical sponsor understands: the squad will not wave
work through past a real gap.
The council scales up automatically. When an initiative grows technical or
risk dimensions — security, cost, or architecture — and the request crosses two or more of
those domains, the coordinator convenes the full pre-implementation council and synthesizes
a single Go / Go-With-Conditions / Stop verdict. Because the product profile
does not seed the architect, security, or cost-manager
roles, the squad offers to add them or switch to the full profile rather than
guessing — it never fills an absent role itself.
Beat 6 — Executive deck
/squad request="Build an executive summary deck of the whole initiative: the problem, the journey, the requirements, the roadmap, and the experiment — for a non-technical leadership audience."
The presenter (PowerPoint Subagent) assembles a board-ready deck from the artifacts
the squad already produced. Review Follow-Through then dispatches
tester to check the deck against the source artifacts, so the closing deliverable
is validated, not just generated. The client walks away with something they can take into a
leadership meeting.
The say-it-once, run-it-once version
The same arc runs from a single autopilot request that expresses the need and names no steps. The squad derives the sequence itself:
/squad mode=autopilot profile=product request="We want to improve {{CLIENT_PROCESS}} for our team. Understand who is involved and where it hurts today, write up the business requirements, lay out a phased roadmap with a refined backlog, design a cheap experiment to test the riskiest assumption, do a readiness review, and finish with an executive summary deck for non-technical leadership. Keep me in control of anything that needs my sign-off."From that one line, autopilot sequences the pipeline and stops only where it must:
- Init — proposes the
productprofile and waits for your confirmation. - Research → Plan — discovery (researcher + designer) then the roadmap plan (lead).
- Implement — the analyst, product-owner, experimenter, and presenter author the BRD, backlog, experiment, and deck.
- Review —
testervalidates each artifact against the discovery and requirements. - Final-outcome validation — fires a notification to your registered contact and waits for your sign-off before calling the initiative done.
You only touch it at the profile confirm and the final sign-off — that is the
"tell it once, let it run" mode. With github-issue approval wired at Init, a
sponsor can give that sign-off from a phone.
Keep the experiment honest. The Minimum Viable Experiment is a design, not a result. Do not narrate it as proven outcomes — the value is that the squad surfaces the riskiest assumption and the cheapest way to test it before the client commits budget.
Failure-safe fallbacks
| If… | Then… |
|---|---|
| A role does not dispatch | Confirm the agent it maps to is installed — the product profile resolves analyst, designer, product-owner, experimenter, presenter, and technical-writer to deployed HVE Core agents. |
| The request needs security / cost / architecture review | The squad offers to add those roles or switch to the full profile — accept, and the council convenes. |
| No GitHub repo for phone approval | Keep the default in-chat channel and approve in the session — nothing blocks. |
| Live tooling hiccups | Cut to a pre-recorded run of the same script against a neutral scenario — the arc is identical, so the narrative never breaks. |
Closing talking points
- It is a methodology, not a model. Research → plan → build → review runs in every profile, so even business discovery is planned and reviewed by named specialists.
- Every beat is a deliverable. Discovery, BRD, roadmap, experiment, deck — the client signs off on artifacts, not code.
- Approve from anywhere. With
github-issueapproval, a non-technical sponsor signs off from a phone. - Safe to run live. No cloud, no spend, no code — the perfect first pitch, and it scales up to the full council the moment real risk enters.