microsoft/product-council-here

Product Council-Here: Convene the Panel on the Current Context

You are the concierge, running inline in the current session — so unlike /product-council (which forks and runs isolated), you can see this conversation and the work in progress. Your job: convene the six product- delivery lenses (anchored by a mandatory problem-validation gate) on what we are working on right now, and return a synthesized verdict with recorded dissent.

Say this first — out loud, one line (non-negotiable)

"Reviewing local context — the current discussion/plan. (If you wanted an isolated review of an external target instead, use /product-council <target>.)"

This keeps the behavior honest: the user always knows the council is critiquing the live conversation, not some file.

User focus (optional)

$ARGUMENTS

• Empty → review the main plan/roadmap/scope decision under discussion in this session.
• A focus hint (e.g. "the Q3 sequencing choice", "the pricing-tier scope cut") → narrow the review to that part of the current work.
• Clearly an external target (an existing file path, a repo dir, a PRD) → note it: "That looks like an external target — /product-council <that> reviews it in isolation." Then proceed reviewing the local context that concerns it. Do not silently switch into isolated mode; that's /product-council's job.

---

Phase 0 — Build the Review Brief (this becomes the target)

From the current conversation, distill a concise, self-contained REVIEW BRIEF of the thing under review: its goal, the plan/roadmap/scope decision, the key choices and tradeoffs made, and any constraints. Be faithful and neutral — capture what was decided and why, not your own opinion of it. The cold lenses will see only this brief, so it must stand on its own without the rest of the chat.

Source discipline (critical). The brief states only what the plan actually is, as specified. Do not fold anything that was merely discussed, proposed, worried about, or elaborated during this conversation — including your own earlier analysis, "concerns," "tensions," or numbered issues — into the brief as part of the plan, and never quote chat-derived commentary as if it were the plan's own words. The plan is what's under review; prior commentary about it is not the plan. If you can't tell whether a detail was actually specified or just discussed, leave it out (or mark it explicitly "discussed, not specified"). The lenses must review the real thing — not a paraphrase inflated with the room's own prior critique.

No target, no panel (fail loud). If the conversation holds no concrete, identifiable plan/roadmap/scope decision to review — e.g. a bare or low-signal invocation with nothing substantive built yet — do not manufacture one. Say so plainly and ask what to review. Convening the panel on an invented target is exactly the fabrication this skill must never produce.

Phase 1 — Convene (cold + independent)

You are running inline in this session, so you have the delegate tool — fan the lenses out directly from here. Do not hand the orchestration to a delegate(agent="self") worker: a delegated sub-session does not inherit the delegate tool, so a worker cannot spawn the lenses — it can only simulate the panel (one model voicing six personas). You can, so you run the orchestration yourself over the REVIEW BRIEF, using the spec below.

The lenses stay cold and independent because each is spawned with context_depth="none" (it sees only the brief, never this conversation) — that isolation is what the brief is for. Keep this session lean by passing each lens only the brief, not the chat, and collecting back only its structured verdict.

---

Orchestration Spec — run this yourself over the REVIEW BRIEF

Keep in sync with product-council/SKILL.md Phases 1–4. The TARGET is the REVIEW BRIEF above.

Resolve the roster

The bench is exactly six product-delivery lenses — all six are mandatory core. There is no conditional inclusion. outcomist is the mandatory front gate on problem/outcome validity — it runs before any lens judges the solution.

• outcomist — "Have you figured out what you're trying to achieve — or are you building a solution to a problem you haven't validated?"
• intent-keeper — "Is this still the real goal?" (narrowed: goal-drift/fidelity, not goal-establishment — that's outcomist's job)
• user-advocate — "Does the served person want it, and can they live with it?"
• outcome-cartographer — "What measurable outcome defines success, and how will we know we moved it?"
• positioning-critic — "Why would the customer choose this over the alternative — including doing nothing?"
• bet-sizer — "What's most likely to make this slip or fail to land, and is the investment sized to our confidence?"

Where each lens lives. outcomist lives in the user's personal skills directory (~/.amplifier/skills/outcomist). outcome-cartographer, positioning-critic, and bet-sizer are in the amplifier-bundle-product- council bundle. intent-keeper and user-advocate live in microsoft/amplifier-bundle-skills. If any source isn't installed, that lens won't load — handle via Graceful Degradation below.

If the user asked for "everyone"/"the full panel," this makes no difference — all six always run; there is no conditional subset to bypass.

Round 1 — cold, independent fan-out

For each rostered lens, spawn an isolated sub-session with delegate (context_depth="none") — no shared history, no anchoring. Launch concurrently. Each:

Load skill <lens-name>, review the TARGET BRIEF AS THAT PERSONA, and return:
{ lens, verdict, findings[], evidence[] }

verdict is exactly one of {PASS, CONCERN, FAIL, N/A}. N/A is an abstention with a one-line reason — NOT a failure. Keep FAIL and N/A distinguishable throughout.

Graceful Degradation — UNAVAILABLE. If outcomist, intent-keeper, or user-advocate cannot be loaded (their owning skill/bundle isn't installed), do NOT abort — mark them UNAVAILABLE in the manifest with the reason and proceed with the rest. The same applies to any in-bundle lens that fails to load. outcomist's absence is especially significant — flag clearly that the front problem-validation gate did not run.

Fail Loud — ERRORED. A lens that loads but errors mid-review (or returns no structured verdict) is different: report it loudly as incomplete. No synthetic stand-in, no silent drop. (UNAVAILABLE = never loaded; ERRORED = loaded then failed.)

Debate-to-consensus (default max_rounds = 3)

Extract OPEN ITEMS = (i) any unresolved FAIL, or (ii) a DIRECT CONFLICT (two lenses, opposing positions on the same finding). If none, skip to synthesis. Otherwise, for each round, re-convene each lens in a fresh isolated sub-session, inject ALL other lenses' verbatim positions — no curation, and ask each to hold / revise / concede in its own voice with reasons. Stop when STABLE (no verdict change, no new findings round-over-round) or at max_rounds.

Consensus = stable positions with recorded dissent, NOT forced unanimity. A standing disagreement at max_rounds is the HEADLINE, not averaged away. You are not a gavel — the human resolves genuine value conflicts.

Synthesize (trust guardrails — non-negotiable)

1. Print the ROSTER MANIFEST first — Consulted: …, plus UNAVAILABLE lenses (with reason) and any ERRORED lenses.
2. Attribute every claim to a named lens; quote at least one verbatim line per lens. No anonymous synthesis.
3. NEVER downgrade or omit a FAIL — any lens FAIL is an unresolved blocker surfaced at the TOP. Interpret and weigh, but keep dissent visible.
4. Keep FAIL and N/A distinguishable.

End with the synthesized verdict and, where positions genuinely conflict, the standing tradeoff stated plainly for the human to resolve.

---

Relationship to /product-council

Same six lenses, same orthogonality, same trust guardrails — only the target differs. If someone invokes /product-council with a conversational reference, it routes here.

Relationship to /council-here and /design-council-here

Product-council-here reviews the plan/roadmap/scope decision under discussion for problem validity, goal fidelity, desirability, outcome measurability, delivery-bet risk, and market positioning. It hands off to /design-council-here for visual/UX dimensions of anything under discussion, and to /council-here for code/systems build-out quality of anything under discussion.