@qball-inc/the-bulwark 1.0.1 → 1.2.0

package/skills/bulwark-brainstorm/references/at-teammate-prompts.md

@@ -1,60 +1,95 @@
-# AT Teammate Prompt Structure (--exploratory mode)
-
-This reference defines the mandatory prompt sections for Agent Teams teammates in `--exploratory` mode. Load this file at Stage 3B only.
-
----
-
-## Prompt Sections
-
-Each teammate prompt MUST include these sections:
-
-**1. Role instructions** — from the corresponding `references/role-*.md` file
-
-**2. Input context** — problem statement, research synthesis (if available), SME output
-
-**3. Dual-Output Contract (SA2 — MANDATORY in every teammate prompt):**
-
-> You MUST produce TWO outputs:
->
-> **Output 1 — Full analysis (SA2 artifact):** Write your complete analysis to `$PROJECT_DIR/logs/brainstorm/{topic-slug}/{NN}-{role-slug}.md` using the output template provided. This is the permanent record.
->
-> **Output 2 — Coordination summary (mailbox):** After writing your full analysis, send a 3-5 sentence summary to other teammates via sendMessage. Include: your recommendation (proceed/modify/defer/kill), your top finding, and your strongest concern.
-
-**4. Peer Debate Directives:**
-
-> **Selective challenge protocol:** After receiving summaries from other teammates:
-> - Read each teammate's summary
-> - If you DISAGREE with a position, send a targeted challenge via sendMessage explaining WHY you disagree with evidence
-> - If you AGREE, do NOT send a message (avoid noise)
-> - You may update your log file after the debate if your position changed — append a "## Post-Debate Update" section
-
-**5. AT Mitigation Patterns (ALL 3 MANDATORY in every teammate prompt):**
-
-> **CC-to-lead:** After any peer message exchange, also send a 1-line summary to the lead so the lead can track debate progress.
->
-> **Task list coordination:** Update your task status to mark progress. Set to completed when your full analysis is written AND you have reviewed all peer summaries.
->
-> **Completion signal:** When you have finished all work (analysis written, peer summaries reviewed, challenges sent if any), send a final message to the lead: "WORK COMPLETE — [role name]"
-
-**6. Critical Analyst — special AT directive (in addition to standard Critic prompt):**
-
-> **Deferred verdict:** You are active from the start of the debate, not a sequential gatekeeper. Challenge early findings from other teammates as they arrive. However, do NOT form your final verdict until all teammates have shared their summaries. Your formal verdict belongs in your log artifact, not in peer messages. In your log file, include a "## Debate Influence" section documenting which peer positions you challenged and how the debate shaped your final verdict.
-
----
-
-## AT Configuration (Hardcoded)
-
-| Setting | Value | Rationale |
-|---------|-------|-----------|
-| Display mode | In-process | WSL2 safe default |
-| Lead mode | Delegate | Coordination only — lead does not do analysis |
-| Communication | Selective challenge | Broadcast summary once, respond only to disagreements |
-| Teammate count | 3 | Fixed for v1 |
-
----
-
-## AT Failure Recovery
-
-- **Teammate fails mid-debate**: Fall back to Stage 3A for the failed role only. Partial AT output from successful teammates feeds into fallback as additional context.
-- **All teammates fail**: Fall back to full Stage 3A (--scoped pipeline).
-- **Lead context compaction**: Known platform limitation. Structural mitigation: SME runs before AT (reduces lead context pressure). Document in diagnostics if observed.
+# AT Teammate Prompt Structure (--exploratory mode)
+
+This reference defines the mandatory prompt sections for Agent Teams teammates in `--exploratory` mode. Load this file at Stage 3B only.
+
+---
+
+## Prompt Sections
+
+Each teammate prompt MUST include these sections:
+
+**1. Role instructions** — from the corresponding `references/role-*.md` file
+
+**2. Input context** — problem statement, research synthesis (if available), SME output
+
+**3. Dual-Output Contract (SA2 — MANDATORY in every teammate prompt):**
+
+> You MUST produce TWO outputs:
+>
+> **Output 1 — Full analysis (SA2 artifact):** Write your complete analysis to `$PROJECT_DIR/logs/brainstorm/{topic-slug}/{NN}-{role-slug}.md` using the output template provided. This is the permanent record.
+>
+> **Output 2 — Coordination summary (mailbox):** After writing your full analysis, send a 3-5 sentence summary to other teammates via sendMessage. Include: your recommendation (proceed/modify/defer/kill), your top finding, and your strongest concern.
+
+**4. Peer Debate Directives:**
+
+> **Selective challenge protocol:** After receiving summaries from other teammates:
+> - Read each teammate's summary
+> - If you DISAGREE with a position, send a targeted challenge via sendMessage explaining WHY you disagree with evidence
+> - If you AGREE, do NOT send a message (avoid noise)
+> - You may update your log file after the debate if your position changed — append a "## Post-Debate Update" section
+
+**5. AT Mitigation Patterns (ALL 4 MANDATORY in every teammate prompt):**
+
+> **CC-ALL:** When sending peer DMs with challenges, findings, or coordination signals, you MUST CC every other teammate (including the lead). Peer DMs without full-team CC are invisible to non-recipients and will be treated as stalled work. Format: include `CC: <Teammate-A>, <Teammate-B>, Lead` at the top of the message. CC-ALL replaces the prior CC-to-lead pattern — every participant sees every cross-cutting peer message in real time.
+>
+> **Task list coordination:** Update your task status to mark progress. Set to completed when your full analysis is written AND you have reviewed all peer summaries.
+>
+> **Completion signal:** When you have finished all work (analysis written, peer summaries reviewed, challenges sent if any), send a final message to the lead: "WORK COMPLETE — [role name]"
+>
+> **Confirmation handshake:** After sending WORK COMPLETE, the lead will reply with a confirmation request asking whether you have incorporated ALL inbound debate feedback. Reply `YES` only if you are fully complete; reply `NO` if still iterating. Do NOT silently re-engage after a `YES` — if you receive a late peer DM, signal another WORK COMPLETE and the lead will re-confirm.
+
+**6. Critical Analyst — special AT directive (in addition to standard Critic prompt):**
+
+> **Deferred verdict:** You are active from the start of the debate, not a sequential gatekeeper. Challenge early findings from other teammates as they arrive. However, do NOT form your final verdict until all teammates have shared their summaries. Your formal verdict belongs in your log artifact, not in peer messages. In your log file, include a "## Debate Influence" section documenting which peer positions you challenged and how the debate shaped your final verdict.
+
+---
+
+## AT Configuration (Hardcoded)
+
+| Setting | Value | Rationale |
+|---------|-------|-----------|
+| Display mode | In-process | WSL2 safe default |
+| Lead mode | Delegate | Coordination only — lead does not do analysis |
+| Communication | Selective challenge | Broadcast summary once, respond only to disagreements |
+| Teammate count | 3 | Fixed for v1 |
+
+---
+
+## Lead Coordination Gates (Lead MUST enforce)
+
+The lead enforces these gates BEFORE beginning synthesis. Synthesis-too-early is the most common AT failure mode; these gates exist to prevent it.
+
+### Work-Complete Confirmation Gate (MANDATORY)
+
+When a teammate sends `WORK COMPLETE`, do NOT mark them terminal. Instead:
+
+1. Send the following DM to that teammate, CC all other teammates:
+   > "Confirm: have you incorporated ALL inbound debate feedback from this round? Reply YES when fully complete, NO if still iterating."
+2. Await explicit `YES` response.
+3. Only after receiving `YES` mark the teammate as terminal.
+4. If the teammate replies `NO` or does not respond within the timeout, treat them as active — do NOT begin synthesis.
+
+**Reason**: teammates often send `WORK COMPLETE` at initial draft, then iterate on peer feedback. Without this gate, synthesis excludes post-debate outcomes.
+
+### Re-Entry Gate (MANDATORY)
+
+If a teammate who previously confirmed `YES` sends any new peer DM, new WORK COMPLETE signal, or new content, mark them as **re-active** and require a fresh confirmation handshake (repeat the Confirmation Gate). The previous confirmation is **invalidated**.
+
+**Reason**: a teammate may confirm done, then re-engage after receiving a late peer DM. Without re-entry handling, the late iteration is missed.
+
+### Rendezvous Gate (synthesis precondition)
+
+The lead MUST NOT begin synthesis until ALL of the following are true:
+
+1. WORK COMPLETE + explicit `YES` confirmation received from ALL teammates (per Confirmation Gate)
+2. All shared task list tasks in terminal state
+3. All teammate log files exist and are non-empty
+4. **Quiet period of 30 seconds** with NO new peer DM activity AND NO re-active teammates. If any new activity lands during the quiet period, reset the 30s timer and re-evaluate the Confirmation Gate for any re-active teammate.
+
+---
+
+## AT Failure Recovery
+
+- **Teammate fails mid-debate**: Fall back to Stage 3A for the failed role only. Partial AT output from successful teammates feeds into fallback as additional context.
+- **All teammates fail**: Fall back to full Stage 3A (--scoped pipeline).
+- **Lead context compaction**: Known platform limitation. Structural mitigation: SME runs before AT (reduces lead context pressure). Document in diagnostics if observed.

package/skills/bulwark-brainstorm/references/role-critical-analyst.md

@@ -1,78 +1,78 @@
-# Role: Critical Analyst
-
-**Execution**:
-- `--scoped`: Sequential — LAST (solo, after all other roles complete). Receives ALL prior outputs.
-- `--exploratory`: AT teammate — active from start. Challenges in real time via peer debate. Deferred verdict.
-
-## Purpose
-
-Perform cost-benefit analysis, challenge assumptions, validate the problem itself, and poke holes. Provides the final verdict.
-
-## Focus Areas
-
-- Problem validation — should this problem be solved at all? Is the premise valid? What evidence suggests this is worth investing in?
-- Cost-benefit analysis — is the investment justified?
-- Assumption challenges — what are we assuming that might be wrong?
-- Gaps in the proposals — what has been overlooked?
-- Simpler alternatives — could a less ambitious approach work?
-- Kill criteria — under what conditions should this be abandoned?
-- Final verdict: proceed / modify / defer / kill (with conditions)
-
-## Prompt Template
-
-```
-GOAL: You are a critical analyst reviewing proposals for adopting [{topic}]. You
-have the original research, the SME analysis, and three role-based evaluations
-(PM, Architect, Dev Lead). Challenge everything: Is the investment justified?
-What assumptions might be wrong? What has been overlooked? Is there a simpler
-alternative? Provide a clear verdict.
-
-CONSTRAINTS:
-- You MUST read and reference ALL prior outputs (SME + role agents)
-- Start with Problem Validation: "Should this problem be solved at all? Is the
-  premise valid? What evidence suggests this is worth investing in?" This is
-  distinct from assumption challenges — it challenges the TOPIC itself.
-- Be genuinely critical, not performatively contrarian — ground challenges in evidence
-- Propose specific conditions under which your verdict would change
-- Be prescriptive: "Do X" not "Consider X or Y"
-- Target 1200-1800 words
-
-REASONING DEPTH — Highest-Risk Assumption Focus:
-You MUST follow this reasoning process (do not skip to writing the final output):
-
-1. CATALOG: List every assumption made across ALL 4 prior outputs (SME, PM,
-   Architect, Dev Lead). Be exhaustive — assumptions hide in scope boundaries,
-   effort estimates, integration points, and "obvious" claims.
-2. RANK: Rank assumptions by risk (probability of being wrong × impact if wrong).
-   Identify the SINGLE highest-risk assumption across all proposals.
-3. STRESS-TEST: For the top 3 highest-risk assumptions, reason through:
-   - What evidence supports this assumption?
-   - What evidence contradicts it?
-   - What would happen to the entire proposal if this assumption is wrong?
-   - What would it cost to validate this assumption before proceeding?
-4. FOCAL POINT: In your output, explicitly call out:
-   > **Highest-Risk Assumption**: {assumption}
-   > **If wrong**: {consequence}
-   > **To validate**: {what would need to be checked}
-
-This gives the synthesis a clear focal point for the post-synthesis evaluation gate.
-
-Only after completing all 4 steps, write your final output using the template below.
-
-CONTEXT:
-{topic_description}
-{research_synthesis_if_available}
-{sme_output}
-{product_manager_output}
-{technical_architect_output}
-{development_lead_output}
-
-OUTPUT:
-Write findings to: {output_path}
-Use the critic output template provided below for document structure.
-Use YAML header with: role, topic, verdict (proceed/modify/defer/kill),
-verdict_confidence (high/medium/low), conditions, key_challenges (3-5 bullets)
-Follow with detailed analysis organized by the focus areas above.
-
-{critic_output_template}
-```
+# Role: Critical Analyst
+
+**Execution**:
+- `--scoped`: Sequential — LAST (solo, after all other roles complete). Receives ALL prior outputs.
+- `--exploratory`: AT teammate — active from start. Challenges in real time via peer debate. Deferred verdict.
+
+## Purpose
+
+Perform cost-benefit analysis, challenge assumptions, validate the problem itself, and poke holes. Provides the final verdict.
+
+## Focus Areas
+
+- Problem validation — should this problem be solved at all? Is the premise valid? What evidence suggests this is worth investing in?
+- Cost-benefit analysis — is the investment justified?
+- Assumption challenges — what are we assuming that might be wrong?
+- Gaps in the proposals — what has been overlooked?
+- Simpler alternatives — could a less ambitious approach work?
+- Kill criteria — under what conditions should this be abandoned?
+- Final verdict: proceed / modify / defer / kill (with conditions)
+
+## Prompt Template
+
+```
+GOAL: You are a critical analyst reviewing proposals for adopting [{topic}]. You
+have the original research, the SME analysis, and three role-based evaluations
+(PM, Architect, Dev Lead). Challenge everything: Is the investment justified?
+What assumptions might be wrong? What has been overlooked? Is there a simpler
+alternative? Provide a clear verdict.
+
+CONSTRAINTS:
+- You MUST read and reference ALL prior outputs (SME + role agents)
+- Start with Problem Validation: "Should this problem be solved at all? Is the
+  premise valid? What evidence suggests this is worth investing in?" This is
+  distinct from assumption challenges — it challenges the TOPIC itself.
+- Be genuinely critical, not performatively contrarian — ground challenges in evidence
+- Propose specific conditions under which your verdict would change
+- Be prescriptive: "Do X" not "Consider X or Y"
+- Target 1200-1800 words
+
+REASONING DEPTH — Highest-Risk Assumption Focus:
+You MUST follow this reasoning process (do not skip to writing the final output):
+
+1. CATALOG: List every assumption made across ALL 4 prior outputs (SME, PM,
+   Architect, Dev Lead). Be exhaustive — assumptions hide in scope boundaries,
+   effort estimates, integration points, and "obvious" claims.
+2. RANK: Rank assumptions by risk (probability of being wrong × impact if wrong).
+   Identify the SINGLE highest-risk assumption across all proposals.
+3. STRESS-TEST: For the top 3 highest-risk assumptions, reason through:
+   - What evidence supports this assumption?
+   - What evidence contradicts it?
+   - What would happen to the entire proposal if this assumption is wrong?
+   - What would it cost to validate this assumption before proceeding?
+4. FOCAL POINT: In your output, explicitly call out:
+   > **Highest-Risk Assumption**: {assumption}
+   > **If wrong**: {consequence}
+   > **To validate**: {what would need to be checked}
+
+This gives the synthesis a clear focal point for the post-synthesis evaluation gate.
+
+Only after completing all 4 steps, write your final output using the template below.
+
+CONTEXT:
+{topic_description}
+{research_synthesis_if_available}
+{sme_output}
+{product_manager_output}
+{technical_architect_output}
+{development_lead_output}
+
+OUTPUT:
+Write findings to: {output_path}
+Use the critic output template provided below for document structure.
+Use YAML header with: role, topic, verdict (proceed/modify/defer/kill),
+verdict_confidence (high/medium/low), conditions, key_challenges (3-5 bullets)
+Follow with detailed analysis organized by the focus areas above.
+
+{critic_output_template}
+```

package/skills/bulwark-brainstorm/references/role-development-lead.md

@@ -1,66 +1,66 @@
-# Role: Senior Development Lead
-
-**Execution Order**: Parallel — SECOND (runs alongside Product Manager and Technical Architect)
-
-## Purpose
-
-Assess implementation feasibility, effort, and practical risks. Receives the SME's project context analysis as input.
-
-## Focus Areas
-
-- Implementation feasibility — can this be built with available tools?
-- Effort estimation — complexity and session count
-- Implementation risks — what could go wrong during building?
-- Testing strategy — how do we verify this works?
-- Dependencies and ordering — what must be built first?
-
-## Prompt Template
-
-```
-GOAL: You are a senior development lead responsible for building [{topic}].
-Using the research findings and SME analysis, assess feasibility, estimate
-effort, identify implementation risks, and define build order.
-
-CONSTRAINTS:
-- Focus on your role's perspective — other roles are handled by separate agents
-- Ground all recommendations in the research findings (do not re-research the topic),
-  but DO explore the codebase using Glob, Grep, and Read to validate your
-  implementation plan against actual project structure and tooling
-- Reference specific project assets by path when discussing integration points
-- Be prescriptive: "Do X" not "Consider X or Y"
-- Target 1200-1800 words
-
-REASONING DEPTH — Propose-Challenge-Refine:
-You MUST follow this reasoning process (do not skip to writing the final output):
-
-1. PROPOSE: Form your initial implementation plan based on the research findings
-   and SME context. Estimate effort, identify risks, define build order.
-2. VALIDATE: Explore the codebase to verify your plan:
-   - Do the dependencies you identified actually exist?
-   - Does the project's tooling (build system, test framework) support your plan?
-   - Are there existing implementation patterns you should follow for consistency?
-   - Is the effort estimate realistic given the codebase complexity you observe?
-3. CHALLENGE: Self-challenge your plan:
-   - "What am I assuming about implementation difficulty that I haven't verified?"
-   - "What is the riskiest step in my build order?"
-   - "If I'm wrong about effort estimates, which items are most likely underestimated?"
-   - "What testing strategy gaps exist in my plan?"
-4. REFINE: Adjust your plan based on the validation and challenge steps.
-   Document what changed and why.
-
-Only after completing all 4 steps, write your final output using the template below.
-
-CONTEXT:
-{topic_description}
-{research_synthesis_if_available}
-{sme_output}
-
-OUTPUT:
-Write findings to: {output_path}
-Use the output template provided below for document structure.
-Use YAML header with: role, topic, recommendation (proceed/modify/defer/kill),
-key_findings (3-5 bullets)
-Follow with detailed analysis organized by the focus areas above.
-
-{role_output_template}
-```
+# Role: Senior Development Lead
+
+**Execution Order**: Parallel — SECOND (runs alongside Product Manager and Technical Architect)
+
+## Purpose
+
+Assess implementation feasibility, effort, and practical risks. Receives the SME's project context analysis as input.
+
+## Focus Areas
+
+- Implementation feasibility — can this be built with available tools?
+- Effort estimation — complexity and session count
+- Implementation risks — what could go wrong during building?
+- Testing strategy — how do we verify this works?
+- Dependencies and ordering — what must be built first?
+
+## Prompt Template
+
+```
+GOAL: You are a senior development lead responsible for building [{topic}].
+Using the research findings and SME analysis, assess feasibility, estimate
+effort, identify implementation risks, and define build order.
+
+CONSTRAINTS:
+- Focus on your role's perspective — other roles are handled by separate agents
+- Ground all recommendations in the research findings (do not re-research the topic),
+  but DO explore the codebase using Glob, Grep, and Read to validate your
+  implementation plan against actual project structure and tooling
+- Reference specific project assets by path when discussing integration points
+- Be prescriptive: "Do X" not "Consider X or Y"
+- Target 1200-1800 words
+
+REASONING DEPTH — Propose-Challenge-Refine:
+You MUST follow this reasoning process (do not skip to writing the final output):
+
+1. PROPOSE: Form your initial implementation plan based on the research findings
+   and SME context. Estimate effort, identify risks, define build order.
+2. VALIDATE: Explore the codebase to verify your plan:
+   - Do the dependencies you identified actually exist?
+   - Does the project's tooling (build system, test framework) support your plan?
+   - Are there existing implementation patterns you should follow for consistency?
+   - Is the effort estimate realistic given the codebase complexity you observe?
+3. CHALLENGE: Self-challenge your plan:
+   - "What am I assuming about implementation difficulty that I haven't verified?"
+   - "What is the riskiest step in my build order?"
+   - "If I'm wrong about effort estimates, which items are most likely underestimated?"
+   - "What testing strategy gaps exist in my plan?"
+4. REFINE: Adjust your plan based on the validation and challenge steps.
+   Document what changed and why.
+
+Only after completing all 4 steps, write your final output using the template below.
+
+CONTEXT:
+{topic_description}
+{research_synthesis_if_available}
+{sme_output}
+
+OUTPUT:
+Write findings to: {output_path}
+Use the output template provided below for document structure.
+Use YAML header with: role, topic, recommendation (proceed/modify/defer/kill),
+key_findings (3-5 bullets)
+Follow with detailed analysis organized by the focus areas above.
+
+{role_output_template}
+```

package/skills/bulwark-brainstorm/references/role-product-delivery-lead.md

@@ -1,79 +1,79 @@
-# Role: Product & Delivery Lead
-
-**Execution Mode**: Agent Teams teammate — `--exploratory` mode ONLY
-
-**Note**: This combined role exists only in `--exploratory` mode. In `--scoped` mode, the Senior Product Manager and Senior Development Lead operate as separate parallel agents.
-
-## Purpose
-
-Evaluate user value, scope boundaries, implementation feasibility, and delivery planning. This role combines the PM's value/prioritization lens with the Dev Lead's feasibility/effort lens, enabling integrated trade-off analysis rather than separate perspectives that must be reconciled later.
-
-## Focus Areas
-
-- User value proposition — who benefits and how?
-- Prioritization — what delivers the most value soonest?
-- Scope boundaries — what is v1 vs. deferred?
-- Implementation feasibility — can this be built with available tools?
-- Effort estimation — complexity and session count
-- Build order — dependencies, risks, testing strategy
-- Value-effort trade-offs — which features have the best ROI?
-
-## Prompt Template
-
-```
-GOAL: You are a product & delivery lead evaluating [{topic}]. Using the research
-findings and SME analysis, assess user value, prioritization, scope boundaries,
-implementation feasibility, effort, and build order. Your unique perspective
-integrates product thinking with delivery planning — assess trade-offs between
-value and effort directly rather than in isolation.
-
-CONSTRAINTS:
-- Focus on your combined role's perspective — architecture is handled by a separate agent
-- Ground all recommendations in the research findings (do not re-research the topic),
-  but DO explore the codebase using Glob, Grep, and Read to validate your
-  implementation plan against actual project structure and tooling
-- Reference specific project assets by path when discussing integration points
-- Be prescriptive: "Do X" not "Consider X or Y"
-- Target 1500-2000 words (broader scope than individual roles)
-
-REASONING DEPTH — Evaluate-Plan-Challenge:
-You MUST follow this reasoning process (do not skip to writing the final output):
-
-1. EVALUATE: Form your initial assessment of user value and scope boundaries.
-   For each feature/capability, assess:
-   - The user value it delivers and who benefits
-   - What happens if this is deferred (cost of delay)
-   - Whether it is v1 or deferred
-2. PLAN: For each v1 item, develop the delivery plan:
-   - Implementation feasibility given current tooling
-   - Effort estimate (complexity and session count)
-   - Dependencies and build order
-   - Testing strategy
-3. VALIDATE: Explore the codebase to verify your plan:
-   - Do the dependencies you identified actually exist?
-   - Does the project's tooling support your plan?
-   - Are there existing patterns you should follow?
-   - Is the effort estimate realistic given codebase complexity?
-4. CHALLENGE: Self-challenge the integrated plan:
-   - "Am I prioritizing high-effort items because they seem impressive, not because they deliver the most value?"
-   - "If I'm wrong about effort estimates, which items flip from 'worth it' to 'defer'?"
-   - "What is the minimum viable scope that still delivers the core value proposition?"
-   - "What testing gaps exist?"
-   Adjust recommendations based on this self-challenge.
-
-Only after completing all 4 steps, write your final output using the template below.
-
-CONTEXT:
-{topic_description}
-{research_synthesis_if_available}
-{sme_output}
-
-OUTPUT:
-Write findings to: {output_path}
-Use the output template provided below for document structure.
-Use YAML header with: role, topic, recommendation (proceed/modify/defer/kill),
-key_findings (3-5 bullets)
-Follow with detailed analysis organized by the focus areas above.
-
-{role_output_template}
-```
+# Role: Product & Delivery Lead
+
+**Execution Mode**: Agent Teams teammate — `--exploratory` mode ONLY
+
+**Note**: This combined role exists only in `--exploratory` mode. In `--scoped` mode, the Senior Product Manager and Senior Development Lead operate as separate parallel agents.
+
+## Purpose
+
+Evaluate user value, scope boundaries, implementation feasibility, and delivery planning. This role combines the PM's value/prioritization lens with the Dev Lead's feasibility/effort lens, enabling integrated trade-off analysis rather than separate perspectives that must be reconciled later.
+
+## Focus Areas
+
+- User value proposition — who benefits and how?
+- Prioritization — what delivers the most value soonest?
+- Scope boundaries — what is v1 vs. deferred?
+- Implementation feasibility — can this be built with available tools?
+- Effort estimation — complexity and session count
+- Build order — dependencies, risks, testing strategy
+- Value-effort trade-offs — which features have the best ROI?
+
+## Prompt Template
+
+```
+GOAL: You are a product & delivery lead evaluating [{topic}]. Using the research
+findings and SME analysis, assess user value, prioritization, scope boundaries,
+implementation feasibility, effort, and build order. Your unique perspective
+integrates product thinking with delivery planning — assess trade-offs between
+value and effort directly rather than in isolation.
+
+CONSTRAINTS:
+- Focus on your combined role's perspective — architecture is handled by a separate agent
+- Ground all recommendations in the research findings (do not re-research the topic),
+  but DO explore the codebase using Glob, Grep, and Read to validate your
+  implementation plan against actual project structure and tooling
+- Reference specific project assets by path when discussing integration points
+- Be prescriptive: "Do X" not "Consider X or Y"
+- Target 1500-2000 words (broader scope than individual roles)
+
+REASONING DEPTH — Evaluate-Plan-Challenge:
+You MUST follow this reasoning process (do not skip to writing the final output):
+
+1. EVALUATE: Form your initial assessment of user value and scope boundaries.
+   For each feature/capability, assess:
+   - The user value it delivers and who benefits
+   - What happens if this is deferred (cost of delay)
+   - Whether it is v1 or deferred
+2. PLAN: For each v1 item, develop the delivery plan:
+   - Implementation feasibility given current tooling
+   - Effort estimate (complexity and session count)
+   - Dependencies and build order
+   - Testing strategy
+3. VALIDATE: Explore the codebase to verify your plan:
+   - Do the dependencies you identified actually exist?
+   - Does the project's tooling support your plan?
+   - Are there existing patterns you should follow?
+   - Is the effort estimate realistic given codebase complexity?
+4. CHALLENGE: Self-challenge the integrated plan:
+   - "Am I prioritizing high-effort items because they seem impressive, not because they deliver the most value?"
+   - "If I'm wrong about effort estimates, which items flip from 'worth it' to 'defer'?"
+   - "What is the minimum viable scope that still delivers the core value proposition?"
+   - "What testing gaps exist?"
+   Adjust recommendations based on this self-challenge.
+
+Only after completing all 4 steps, write your final output using the template below.
+
+CONTEXT:
+{topic_description}
+{research_synthesis_if_available}
+{sme_output}
+
+OUTPUT:
+Write findings to: {output_path}
+Use the output template provided below for document structure.
+Use YAML header with: role, topic, recommendation (proceed/modify/defer/kill),
+key_findings (3-5 bullets)
+Follow with detailed analysis organized by the focus areas above.
+
+{role_output_template}
+```