convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/product-vision/steps/step-06-synthesize.md

@@ -0,0 +1,170 @@
+---
+step: 6
+workflow: product-vision
+title: Synthesize
+---
+
+# Step 6: Synthesize
+
+Let's bring it all together into a cohesive product vision document.
+
+## Why This Matters
+
+Your product vision document becomes:
+- The alignment tool for your team (everyone sees the same destination)
+- The decision-making framework (does this serve the vision?)
+- The communication artifact (pitches, hiring, partnerships)
+- The strategic anchor (when you drift, come back to this)
+
+## Your Task
+
+Before I generate the final artifact, a few final questions:
+
+### 1. Craft your vision statement (1-2 sentences)
+
+This is the pithy, memorable version. Should be:
+- **Aspirational** - Inspiring and ambitious
+- **Specific** - Clear about what you're creating
+- **Focused** - One clear idea, not three ideas mashed together
+
+**Formula:** For [target users] who [problem], [product] is a [category] that [key benefit]. Unlike [alternatives], our product [unique differentiation].
+
+### 2. Identify your strategic assumptions
+
+What MUST be true for this vision to succeed?
+
+Examples:
+- "Remote work will continue to dominate software teams"
+- "Engineering managers value time savings over detailed control"
+- "Teams will trust AI-generated insights"
+
+Mark each as:
+- **CRITICAL** - If this is false, vision fails
+- **IMPORTANT** - If this is false, strategy needs adjustment
+- **NICE** - Would help but not essential
+
+### 3. Define validation plan
+
+How will you know if you're making progress toward this vision?
+
+- **Metrics to track?**
+- **Milestones to hit?**
+- **Assumptions to validate first?**
+- **Timeline for first validation?**
+
+### 4. Team alignment check
+
+On a scale of 1-10:
+- How aligned is the team on this vision?
+- What concerns or disagreements remain?
+- What questions are still open?
+
+## Example
+
+**Vision Statement:**
+"For engineering managers at high-growth startups who waste hours tracking distributed team status, TeamPulse is an automated team intelligence platform that provides real-time confidence without requiring any team overhead. Unlike project management tools that demand manual updates, TeamPulse automatically aggregates workflow signals to surface insights proactively."
+
+**Strategic Assumptions:**
+
+**CRITICAL:**
+- Remote/distributed engineering teams will remain dominant (70%+ of Series A-C startups)
+- Engineering managers value accuracy + time savings > manual control
+- Modern engineering tools will maintain/improve API access
+
+**IMPORTANT:**
+- AI inference quality continues to improve (enables better pattern recognition)
+- Teams trust automated insights (education/change management needed)
+- Integration ecosystem remains accessible (not walled gardens)
+
+**NICE:**
+- Async work continues to grow (makes status even harder)
+- Economic pressure to do more with less (increases value prop)
+
+**Validation Plan:**
+
+**Metrics to Track:**
+- **Week 1-4:** 20 manager interviews - validate problem intensity
+- **Month 1-3:** 10-team pilot - validate zero-overhead approach
+- **Month 4-6:** $10K MRR - validate willingness to pay
+- **Month 7-12:** 100 teams, $100K ARR - validate product-market fit
+- **Year 2:** 1,000 teams, $1M ARR - validate scalability
+
+**Assumptions to Validate FIRST:**
+1. Managers spend 5+ hours/week on status (interview validation)
+2. Teams won't update another tool (pilot validation)
+3. AI can accurately infer status from signals (technical validation)
+
+**Timeline:**
+- **Weeks 1-4:** Problem validation (interviews)
+- **Weeks 5-8:** Technical validation (proof-of-concept)
+- **Weeks 9-16:** Solution validation (10-team pilot)
+- **Month 4+:** Business model validation (pricing experiments)
+
+**Team Alignment:**
+
+**Alignment Score:** 8/10
+
+**Remaining Concerns:**
+- **Tech lead:** "Can we actually build accurate AI models?" → Need PoC
+- **Design lead:** "Will managers trust automated insights?" → Need user research
+- **Sales lead:** "Is $20/user sustainable pricing?" → Need pricing experiments
+
+**Open Questions:**
+- Should we start with GitHub-only integrations or multi-tool from day 1?
+- Do we need manager-only insights or should individual contributors see their own data?
+- How do we handle teams that don't use integrated tools?
+
+---
+
+## Your Turn
+
+Please provide:
+1. Your vision statement (using the formula)
+2. Your strategic assumptions (marked as CRITICAL/IMPORTANT/NICE)
+3. Your validation plan with metrics and timeline
+4. Your team alignment score and open questions
+
+## Final Step
+
+When you've provided this information, I'll:
+1. Generate your complete product vision document
+2. Save it to `{output_folder}/product-vision-{product-name}-{date}.md`
+3. Create a team alignment summary
+4. Suggest next workflows:
+   - **lean-persona** to detail your target users
+   - **contextualize-scope** to define problem space boundaries
+   - **Wade's mvp** to design your minimum viable product
+
+**Remember:** This vision is your north star, not your prison. As you learn, the vision can evolve. But change it deliberately, not drift unconsciously.
+
+---
+
+## Workflow Complete
+
+After synthesis, your product vision document will include:
+- Clear vision statement
+- Problem definition
+- Target market specificity
+- Unique approach and advantages
+- Future state (3-5 years)
+- Guiding principles
+- Strategic assumptions
+- Validation plan
+- Team alignment status
+
+This becomes your strategic foundation for all product decisions.
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Vision is clear, users are not | lean-persona | Emma 🎯 | Define who you're building for |
+| Strategic assumptions need testing | lean-experiment | Wade 🧪 | Validate your biggest strategic bet |
+| User needs are assumed, not researched | user-discovery | Isla 🔍 | Ground your vision in real user evidence |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.

package/_bmad/bme/_vortex/workflows/product-vision/validate.md

@@ -0,0 +1,30 @@
+# Validate Product Vision
+
+**Status:** Coming in v1.2.0
+
+**Agent:** Emma (Contextualization Expert)
+
+**Stream:** Contextualize
+
+## Overview
+
+This validation workflow helps you review product visions to ensure they're clear, compelling, and actionable.
+
+## What Gets Validated
+
+- Is the vision inspirational yet achievable?
+- Is the problem statement specific and evidence-based?
+- Are target users clearly defined?
+- Are success metrics measurable and meaningful?
+- Are key assumptions explicitly stated?
+- Does this align team around the "why"?
+
+## Coming in v1.2.0
+
+This validation workflow will be available alongside the product-vision workflow in March 2026.
+
+## Questions?
+
+For questions or to request early access:
+- GitHub Issues: https://github.com/amalik/convoke-agents/issues
+- Tag with: `workflow:product-vision` and `v1.2.0`

package/_bmad/bme/_vortex/workflows/product-vision/workflow.md

@@ -0,0 +1,55 @@
+---
+workflow: product-vision
+type: step-file
+description: Define product vision and strategic alignment before building
+author: Emma (contextualization-expert)
+version: 1.2.0
+---
+
+# Create Product Vision Workflow
+
+This workflow guides you through defining a clear, compelling product vision that aligns your team around the "why" before you build the "what."
+
+## What is a Product Vision?
+
+A product vision is a strategic statement that articulates:
+- **Why this product should exist** - The problem it solves and impact it creates
+- **Who it's for** - The specific users/market it serves
+- **What makes it different** - The unique approach or advantage
+- **Where it's headed** - The long-term direction (3-5 years)
+
+A good product vision:
+- **Inspires** - Gets people excited to build it
+- **Focuses** - Helps say "no" to distractions
+- **Aligns** - Ensures everyone is rowing in the same direction
+- **Guides decisions** - When in doubt, does this serve the vision?
+
+## Workflow Structure
+
+**Step-file architecture:**
+- Just-in-time loading (each step loads only when needed)
+- Sequential enforcement (must complete step N before step N+1)
+- State tracking in frontmatter (progress preserved)
+
+## Steps Overview
+
+1. **Define the Problem** - What problem are we solving? Why does it matter?
+2. **Identify Target Market** - Who specifically are we serving?
+3. **Articulate Unique Approach** - What makes our solution different/better?
+4. **Envision Future State** - What does success look like in 3-5 years?
+5. **Align on Principles** - What won't we compromise on?
+6. **Synthesize** - Create the final product vision document
+
+## Output
+
+**Artifact:** Product vision document in `{output_folder}/product-vision-{product-name}-{date}.md`
+
+**Template:** Uses [product-vision.template.md](product-vision.template.md)
+
+---
+
+## INITIALIZATION
+
+Load config from {project-root}/_bmad/bme/_vortex/config.yaml
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/product-vision/steps/step-01-define-problem.md

package/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-01-setup.md

@@ -0,0 +1,84 @@
+---
+step: 1
+workflow: production-monitoring
+title: Setup & Multi-Experiment Input Validation
+---
+
+# Step 1: Setup & Multi-Experiment Input Validation
+
+Production monitoring operates at portfolio scale — multiple graduated experiments running in production simultaneously. Before we can monitor anything, we need the experiment contexts that established the baselines. Production data is the most honest user feedback — it can't lie — but monitoring multiple experiments without their baselines is watching dashboards without understanding what you're looking at.
+
+## Why This Matters
+
+A single production signal viewed in isolation is just a number. Multiple production signals viewed without experiment context is just a bigger dashboard. The signal indicates something very different for each experiment depending on what was tested, what was confirmed, and what behavior was expected. Portfolio monitoring requires all the experiment contexts loaded and validated so that every signal can be measured against the right baseline.
+
+## Your Task
+
+### 1. How Many Experiments Are You Monitoring?
+
+Production monitoring works with **multiple experiments simultaneously**. Provide the experiment contexts for all active experiments you want to monitor:
+
+| # | Experiment | Input |
+|---|-----------|-------|
+| 1 | *name or description* | HC4 file path or description |
+| 2 | *name or description* | HC4 file path or description |
+| 3 | *(if applicable)* | |
+
+Noah expects experiment context — ideally produced by Wade's experimentation workflow as HC4-compliant artifacts:
+- **HC4 Experiment Context** (from Wade's `lean-experiment` workflow)
+- **HC4 Experiment Context** (from Wade's `proof-of-concept`, `proof-of-value`, or `mvp` workflows)
+
+You can also bring **any well-formed experiment summaries** — Noah accepts input from outside the Vortex pattern. It doesn't have to be HC4-compliant, but having structured experiment results with explicit success criteria makes portfolio monitoring dramatically more precise.
+
+### 2. Provide Your Inputs
+
+Please provide file paths or describe each experiment context. For example:
+- `_bmad-output/vortex-artifacts/hc4-experiment-alpha-2026-02-20.md`
+- `_bmad-output/vortex-artifacts/hc4-experiment-beta-2026-02-22.md`
+- Or: "I have three experiments running — onboarding flow, pricing page, and search redesign"
+
+### 3. Per-Experiment Input Validation
+
+I'll check each artifact against the HC4 schema to assess readiness:
+
+**HC4 Frontmatter Check (per experiment):**
+- `contract: HC4`
+- `type: artifact`
+- `source_agent` (who produced it)
+- `source_workflow` (which workflow)
+- `target_agents: [noah]`
+- `input_artifacts` (upstream references)
+- `created` (date)
+
+**HC4 Body Section Check (per experiment):**
+- Experiment Summary (Name, Description, Type, Duration, Graduation Status)
+- Hypothesis Tested (Statement, Riskiest Assumption, Expected Outcome, Target Behavior Change)
+- Experiment Method (Method Type, Sample Size, Planned Duration)
+- Pre-Defined Success Criteria (Metric, Target Threshold, Actual Result, Met?)
+- Additional Results (optional — Quantitative Metrics, Qualitative Results)
+- Confirmed/Rejected Hypotheses (Status, Assumption Status, Core Learning)
+- Strategic Context (Vortex Stream, Assumption Tested, Decision It Informs, Implications)
+- Production Readiness (Metrics to Monitor, Expected Production Behavior, Signal Thresholds)
+
+**Portfolio Validation Summary:**
+
+| # | Experiment | HC4 Compliant | Missing Fields | Readiness |
+|---|-----------|---------------|----------------|-----------|
+| 1 | *name* | Yes / Partial / No | *list* | Ready / Needs Attention |
+| 2 | *name* | Yes / Partial / No | *list* | Ready / Needs Attention |
+
+**If any input is non-conforming:** That's fine — we don't reject experiment context. I'll guide you to identify which elements are present and which gaps we need to work around for each experiment. The more complete the experiment contexts, the sharper the portfolio monitoring. But even partial context is better than none — here's what we're seeing in context with whatever you can provide.
+
+> For the full HC4 schema reference, see `{project-root}/_bmad/bme/_vortex/contracts/hc4-experiment-context.md`
+
+---
+
+## Your Turn
+
+Please provide your experiment contexts — file paths, descriptions, or both. I'll validate each input and we'll proceed to assembling the portfolio.
+
+## Next Step
+
+When all experiment contexts are provided and validated, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-02-context.md

package/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-02-context.md

@@ -0,0 +1,66 @@
+---
+step: 2
+workflow: production-monitoring
+title: Portfolio Assembly & Baseline Mapping
+---
+
+# Step 2: Portfolio Assembly & Baseline Mapping
+
+Now that we've validated the experiment contexts, let's assemble the portfolio view. Each experiment has its own baselines — validated metrics, expected production behavior, signal thresholds. Assembling these into a single portfolio gives us the monitoring frame that tells us where to look and what to look for.
+
+## Why This Matters
+
+Individual experiment baselines tell you what "expected" looks like for that experiment. A portfolio view tells you what "expected" looks like across all active experiments simultaneously. When you monitor signals without this portfolio frame, you're watching each experiment in isolation — and missing the cross-experiment context that reveals which experiments share production surface area, which baselines might interact, and where a signal in one experiment could affect another. The portfolio is the monitoring instrument.
+
+## Your Task
+
+### 1. Extract Baselines Per Experiment
+
+For each validated experiment, extract the baselines that production signals will be compared against:
+
+**Repeat this table for each experiment in the portfolio:**
+
+| Field | Experiment: *[name]* |
+|-------|---------------------|
+| **Validated Success Metrics** | Which metrics were confirmed in the experiment? What were the actual values? |
+| **Expected Production Behavior** | What behavior did the experiment predict for production? (from HC4 Section 8) |
+| **Signal Thresholds** | What thresholds were defined for acceptable vs. concerning behavior? (from HC4 Section 8) |
+| **Metrics to Monitor** | Which specific production metrics should be tracked? (from HC4 Section 8) |
+| **Target Behavior Change** | What specific user behavior change was the experiment designed to produce? (from HC4 Section 2) |
+
+### 2. Assemble the Portfolio Summary
+
+Now let's bring all experiments into a single portfolio view:
+
+| # | Experiment | Hypothesis | Key Metrics | Expected Behavior | Monitoring Scope |
+|---|-----------|-----------|-------------|-------------------|-----------------|
+| 1 | *name* | *one-sentence hypothesis* | *primary metrics* | *expected production behavior* | *users/segments/features* |
+| 2 | *name* | *one-sentence hypothesis* | *primary metrics* | *expected production behavior* | *users/segments/features* |
+| 3 | *(if applicable)* | | | | |
+
+This portfolio summary becomes the monitoring dashboard — each row is an experiment you'll assess in Step 3.
+
+### 3. Map Vortex History Per Experiment
+
+For each experiment, connect to the broader Vortex journey where available:
+
+| Field | Your Input |
+|-------|-----------|
+| **Problem Definition** | Reference to the HC2 problem definition (if available) |
+| **Hypothesis Origin** | Reference to the HC3 hypothesis contract (if available) |
+| **Previous Signals** | References to any prior HC5 signal reports for this experiment (if any) |
+| **Related Experiments** | Other experiments in the portfolio that share production surface area |
+
+Not all of these will be available for every experiment — that's fine. Each connection adds depth to your portfolio monitoring. The "Related Experiments" field is particularly valuable at portfolio scale because it surfaces experiments that may be influencing each other's production signals.
+
+---
+
+## Your Turn
+
+Extract baselines for each experiment, assemble the portfolio summary, and map available Vortex history connections. The portfolio summary table is your monitoring instrument for the next step.
+
+## Next Step
+
+When your portfolio is assembled with baselines mapped, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-03-monitoring.md

package/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-03-monitoring.md

@@ -0,0 +1,74 @@
+---
+step: 3
+workflow: production-monitoring
+title: Signal Monitoring & Divergence Assessment
+---
+
+# Step 3: Signal Monitoring & Divergence Assessment
+
+We have the portfolio assembled with baselines mapped. Now we monitor — checking each experiment's production signals against its validated baselines and assessing how far reality has drifted from what the experiments predicted. Divergence is the signal. The degree of divergence tells you which experiments need attention.
+
+## Why This Matters
+
+Monitoring without divergence assessment is just looking at dashboards. Divergence assessment converts dashboard readings into portfolio intelligence. For each experiment, we need to know: is the production signal tracking the validated baseline, drifting slightly, or diverging significantly? The signal indicates something very different at each level of divergence. And at portfolio scale, patterns across experiments — correlated divergence, shared impacts, interaction effects — surface insights that single-experiment monitoring cannot reveal.
+
+## Your Task
+
+### 1. Per-Experiment Signal Assessment
+
+For each experiment in the portfolio, assess the current production signals against baselines:
+
+**Repeat this table for each experiment:**
+
+| Field | Experiment: *[name]* |
+|-------|---------------------|
+| **Observed Signal** | What production signal are you seeing? Describe factually with specific metrics. |
+| **Baseline Reference** | Which validated baseline is this signal being compared to? (from Step 2) |
+| **Divergence** | How far has the observed signal moved from the baseline? Quantify the gap. |
+| **Divergence Direction** | `Positive` (outperforming) / `Negative` (underperforming) / `Lateral` (different dimension) |
+| **Signal Trajectory** | `Improving` / `Degrading` / `Stable` / `Oscillating` / `Insufficient Data` |
+| **Observation Period** | When was this signal observed? (date range) |
+| **Affected Scope** | Which users, segments, or features are affected? |
+
+### 2. Per-Experiment Signal Summary
+
+Compile the signal assessments into a monitoring summary:
+
+| # | Experiment | Signal | Divergence | Direction | Trajectory | Scope |
+|---|-----------|--------|-----------|-----------|-----------|-------|
+| 1 | *name* | *one-sentence signal* | *quantified gap* | Pos / Neg / Lat | Improving / Degrading / Stable | *scope* |
+| 2 | *name* | *one-sentence signal* | *quantified gap* | Pos / Neg / Lat | Improving / Degrading / Stable | *scope* |
+| 3 | *(if applicable)* | | | | | |
+
+### 3. Cross-Experiment Pattern Analysis
+
+Now look across the portfolio for patterns that single-experiment monitoring misses:
+
+| Pattern | Your Analysis |
+|---------|-------------|
+| **Correlated Divergence** | Are multiple experiments diverging in the same direction at the same time? What might they share? |
+| **Shared Impact Areas** | Do any experiments affect the same users, segments, or features? Are their signals interacting? |
+| **Timing Patterns** | Did divergence start at the same time across experiments? Are there external events that could explain coordinated movement? |
+| **Contradictory Signals** | Are any experiments showing signals that contradict each other? (e.g., one improving while a related one degrades) |
+
+**Remember:** Noah observes and reports patterns. Whether correlated divergence means something strategic is Max's determination. The signal indicates patterns — we don't prescribe responses.
+
+---
+
+## Your Turn
+
+Assess production signals for each experiment against its baselines, compile the monitoring summary, and analyze cross-experiment patterns. The divergence assessments feed directly into prioritization in the next step.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into signal monitoring with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative signal assessment
+**[c]** Continue — Proceed to signal prioritization and anomaly flagging
+
+---
+
+## Next Step
+
+When your signal monitoring and divergence assessments are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-04-prioritization.md

package/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-04-prioritization.md

@@ -0,0 +1,97 @@
+---
+step: 4
+workflow: production-monitoring
+title: Signal Prioritization & Anomaly Flagging
+---
+
+# Step 4: Signal Prioritization & Anomaly Flagging
+
+We've assessed divergence for every experiment in the portfolio. Now we prioritize — ranking signals so Max knows which experiments need attention first — and flag anomalies that may warrant routing to Isla for discovery research. Prioritization converts portfolio monitoring into actionable intelligence.
+
+## Why This Matters
+
+Not all divergence is equal. A critical regression in a high-traffic experiment is more urgent than a slight variance in a small-scope test. Prioritization gives Max a ranked view of the portfolio — the signal indicates which experiments demand immediate attention and which can continue being monitored. And anomaly detection at portfolio scale surfaces unexpected patterns that single-experiment analysis might miss — cross-experiment anomalies often reveal systemic issues or emergent user behaviors.
+
+## Your Task
+
+### 1. Signal Prioritization
+
+For each experiment's signal from Step 3, assign a priority level based on three factors:
+
+**Prioritization Framework:**
+- **Divergence Severity** — How far the signal has moved from the validated baseline (`Critical` / `Warning` / `Informational`)
+- **Affected Scope** — How many users, segments, or features are impacted (`Wide` / `Moderate` / `Narrow`)
+- **Data Confidence** — How reliable the underlying data is (`High` / `Medium` / `Low`)
+
+**Priority Levels:**
+- **P1 (Immediate)** — Critical divergence + wide scope + high confidence. This experiment needs Max's attention now.
+- **P2 (Attention)** — Warning-level divergence OR wide scope with medium confidence. This experiment should be on Max's radar.
+- **P3 (Monitor)** — Informational divergence OR narrow scope OR low confidence. Continue monitoring, no urgent action.
+
+### 2. Prioritized Signal Summary
+
+Compile the prioritized portfolio view:
+
+| Priority | Experiment | Signal | Divergence Severity | Scope | Confidence | Trajectory |
+|----------|-----------|--------|-------------------|-------|-----------|-----------|
+| P1 | *name* | *one-sentence signal* | Critical / Warning / Info | Wide / Mod / Narrow | High / Med / Low | *direction* |
+| P2 | *name* | *one-sentence signal* | Critical / Warning / Info | Wide / Mod / Narrow | High / Med / Low | *direction* |
+| P3 | *name* | *one-sentence signal* | Critical / Warning / Info | Wide / Mod / Narrow | High / Med / Low | *direction* |
+
+### 3. Anomaly Flagging & HC10 Routing Assessment
+
+For each experiment, assess whether any signals represent anomalous behavior warranting routing to Isla for discovery research:
+
+| Experiment | Anomaly Detected? | Description | HC10 Routing? | Rationale |
+|-----------|-------------------|-------------|---------------|-----------|
+| *name* | Yes / No | *what unexpected behavior was observed* | Yes / No | *why or why not* |
+| *name* | Yes / No | | | |
+
+**Guidance on anomaly flagging:**
+- Flag when production behavior reveals user intent the experiment didn't anticipate
+- Flag when cross-experiment patterns suggest systemic behavior shifts
+- Do NOT flag if the divergence is explained by the experiment's own baseline predictions
+- Do NOT flag if the anomaly is isolated, transient, or easily explained by external factors
+
+### 4. Per-Experiment Data Quality Assessment
+
+Before packaging portfolio intelligence, assess data quality for each experiment:
+
+| Experiment | Sample Size | Data Completeness | Known Biases | Confidence |
+|-----------|------------|-------------------|-------------|-----------|
+| *name* | *volume* | Complete / Gaps | *any biases* | High / Med / Low |
+| *name* | *volume* | Complete / Gaps | *any biases* | High / Med / Low |
+
+### 5. Portfolio-Level Data Quality Summary
+
+| Field | Your Assessment |
+|-------|---------------|
+| **Overall Portfolio Confidence** | `High` / `Medium` / `Low` — aggregate confidence across all experiments |
+| **Experiments with Insufficient Data** | Which experiments (if any) have data quality too low for reliable prioritization? |
+| **Cross-Experiment Data Consistency** | Are the observation periods and measurement methods consistent across experiments? |
+| **Portfolio Coverage** | Does the portfolio include all active experiments, or are some missing? |
+
+**Guidance on portfolio confidence:**
+- **High:** All experiments have sufficient data, consistent measurement, and no significant gaps
+- **Medium:** Most experiments have adequate data but some have gaps or potential biases
+- **Low:** Multiple experiments have insufficient data or significant quality concerns
+
+---
+
+## Your Turn
+
+Prioritize signals using the P1/P2/P3 framework, flag anomalies for HC10 routing, and assess data quality per experiment and at portfolio level. The prioritized signal summary is the core input for the portfolio signal report in the next step.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into signal prioritization with guided questioning
+**[p]** Party Mode — Bring in other Vortex agents for collaborative prioritization review
+**[c]** Continue — Proceed to synthesis and HC5 portfolio artifact generation
+
+---
+
+## Next Step
+
+When your signal prioritization and anomaly flagging are complete, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/production-monitoring/steps/step-05-synthesize.md