apex-review

name	apex-review
description	Reviews a technical proposal from the perspective of organizational decision-makers (CTO, technical lead, QA lead, conference reviewers, etc.) and generates an HTML presentation deck. Outputs approval gate results per persona and connects to sim-conductor for improvement suggestions.
user-invocable	true
allowed-tools	["Read","Write","Bash","Agent"]
model-note	session-inherit — Sonnet base is first-class (sonnet_floor_doctrine.md); depth-critical judged steps route to dispatch (opus agent / cross-family sidecar, consent-gated), never a substrate requirement

apex-review — Decision-Maker Review Layer

Reviews proposals from the perspective of top-level organizational decision-makers, not field practitioners. Technically excellent and "this person will approve it" are different things.

Role distinction from hub-persona-auditor

• hub-persona-auditor: Validates reader comprehension of a finished asset (reading experience)
• apex-review: Evaluates decision-maker approval likelihood of a technical proposal (decision-making experience)

---

Triggers

• /apex-review
• "Will this work for the decision-maker?", "Will the CTO approve this?", "What do I need to present to the team lead?"
• "Review from an executive perspective", "Generate presentation slides" (when decision-maker audience is specified)
• When agent-composer identifies a task requiring a decision-maker approval gate
• "Check this before I report to my manager"
• "Does this look convincing?"
• "Find objections they might raise in advance"
• "Review before the executive briefing"
• "Do you think this will pass?"

---

Built-in Decision-Maker Personas

Code	Role	Core Evaluation Criteria	Auto-Reject Triggers
CTO	Chief Technology Officer	Strategic alignment · competitive advantage · tech vision	"Everyone else is already doing this" / "Feels like a personal project"
TD	Technical Lead / Team Lead	Implementation risk · team capability · operational burden · cost	Vague timelines / conflicts with existing stack
QAL	QA Lead / Quality Owner	Quality standards · testability · rollback plan · compliance	No validation plan / failure scenarios not documented
CONF	Conference Organizer / External Reviewer	Novelty · demo-readiness · audience value · reproducibility	Overloaded with internal jargon / demo not possible

If the user does not specify a target persona, it will be confirmed in Step 0.

---

Step 0. Receive Topic + Target

If no input is provided:

Please provide the apex-review target.

  Proposal summary: (What are you seeking approval for?)
  Target decision-maker: [CTO / TD (Technical Lead) / QAL (QA Lead) / CONF (Conference)] — multiple allowed
  Proposal file: (provide path or paste content if available)
  Output format: [HTML presentation deck (recommended) / Markdown report]

If no proposal file is provided, collect content through conversation.

---

Step 1. Structure the Proposal

Organize the received content into the following slide structure.

[S1] One-line thesis      — "What needs to be done and why"
[S2] Current state / problem — What is not working right now
[S3] Proposal             — What changes and how
[S4] Expected outcomes    — Quantified or verifiable change
[S5] Implementation plan  — Phases, timeline, ownership
[S6] Risks + mitigations  — Failure scenarios + rollback
[S7] Requests             — What is needed from the decision-maker

If any slide is missing during structuring, request the user to fill it in.

---

Step 2. Generate HTML Presentation Deck

Generate as apex_review_deck_YYYYMMDD.html.

HTML structure rules:

• Each slide = <section class="slide"> block
• Per slide: title + body + (if applicable) decision-maker attention note
• Navigation: keyboard ←→ or buttons
• Style: clean dark background / large headlines / emphasized key figures

<!-- Slide example -->
<section class="slide">
  <h2>Current State · Problem</h2>
  <p class="body">…</p>
  <aside class="exec-note CTO">CTO attention: …</aside>
</section>

Notify the user of the file path after saving.

---

Step 3. Persona Review

Evaluate the proposal for each target decision-maker.

Output format:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
apex-review — Decision-Maker Review Results
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[CTO Review]
  Verdict: ✅ Approved / ⚠️ Conditional / ❌ Rejected
  Rationale: …
  Conditions (if conditional): …
  Critical weaknesses: …

[TD Review]
  Verdict: …
  …

---

Step 4. Approval Gate

All ✅ Approved: Gate passed → proceed to Step 5 1+ ⚠️ Conditional: Output condition list → request user decision 1+ ❌ Rejected: Output rejection rationale + improvement directions → suggest revision and re-review

After gate verdict:

Gate result: {Passed / Conditionally passed / Rejected}

Choose your next step:
  A. Revise and re-review
  B. Proceed to sim-conductor in current state (deep validation)
     ← strongly recommended when verdict is "Conditionally passed"
  C. Use HTML deck only (as reference)
  D. Exit

"Conditionally passed" → option B is the default path: Conditions listed by personas remain unresolved until sim-conductor Area E runs challenger/beginner/main-player validation against them. Choosing C or D without sim-conductor leaves those conditions unverified — present B as the default choice and require explicit opt-out.

---

Step 5. Deep Validation (Optional)

When option B is selected:

Connect to sim-conductor Area E.
  Target: apex_review_deck_YYYYMMDD.html
  Evaluation criteria: Decision-maker perspective (CTO / TD / QAL / CONF personas)
  Output: Improvement recommendations by M/S/R tier

Incorporate sim-conductor results into the HTML deck and save the revised version.

---

Operating Notes

• Invocable without input: Content collected through conversation in Step 0
• Customizable personas: If the user specifies "our executives prioritize X", it will be reflected
• Iterative review: After revision, re-run from Step 3 (HTML decks distinguished by version date)
• Standalone or within agent-composer: In complex tasks, agent-composer will automatically include this skill

Done When

All steps 0–4 completed
+ Verdict (✅/⚠️/❌) output for all target decision-makers
+ Gate verdict (Passed / Conditionally passed / Rejected) stated
+ User next step selection (A/B/C/D) confirmed

→ Mandatory next (Conditionally passed verdict): /sim-conductor Area E — run against apex_review_deck_YYYYMMDD.html before the proposal is considered ready for submission. Skipping sim-conductor on a conditional pass means unresolved persona conditions go unverified; present option B as default and require the user to explicitly choose A/C/D to override.

Wait for sim-conductor Area E verdict before declaring the proposal submission-ready. (Conditionally passed path: proposal is not done until sim-conductor verdict folds back.)