hackathon-judge-simulator

hackathon-judge-simulator

目標

ハッカソンの審査員団によるプロジェクト評価をシミュレートし、想定される質問や批判的な懸念、予測スコアを生成します。チームがピッチやデモを強化するために役立てます。

---

トリガー条件

次の場合にこのスキルを使用します。

• ピッチデッキを作成し、デモを録画した
• ライブ審査の前にピッチの弱点を洗い出す必要がある
• 厳しい質問や反論の戦略を準備する必要がある
• 予測スコアから、プレゼンテーション前に対処できる課題が見つかった
• フェーズ 7（評価）で呼び出されます。ピッチを改善した後、2 回目のシミュレーションとして再度呼び出してください

---

入力

入力	型	必須	説明
project_title	string	はい	プロジェクト名
problem_statement	string	はい	解決する課題
solution_summary	string	はい	プロジェクトが課題をどのように解決するか
mvp_features	string[]	はい	構築したもの
tech_stack	string[]	はい	使用した技術
evaluation_axes	object[]	はい	hackathon-track-analyzer の審査基準
pitch_content	string	いいえ	より的を絞ったシミュレーションに使用する、ピッチまたはスライドの草案
judge_personas	string[]	いいえ	想定される審査員のタイプ（例：技術、ビジネス、分野の専門家）

---

出力

出力	説明
judge_personas_used	シミュレートした審査員のタイプと、それぞれが重視しそうな点
questions	想定される審査員の質問と推奨回答
objections	審査員が提起しそうな批判的な懸念
predicted_scores	評価軸ごとのスコアとその理由
overall_verdict	シミュレーションによる全体的な印象と入賞の可能性
pitch_improvements	予測された弱点に対処するための具体的な変更点

---

ルール

1. judge_personas が指定されていない場合は、少なくとも 3 種類の異なる審査員をシミュレートしてください。
2. 各評価軸につき、少なくとも 2 つの質問を生成してください。
3. ソリューションの弱点を狙った質問を少なくとも 1 つ含めてください。
4. predicted_scores は、hackathon-idea-scoring と同じ 1～5 のスケールを使用してください。
5. objections には、それぞれ推奨する反論戦略を組み合わせてください。
6. pitch_improvements は、残りのハッカソン時間内に実行できる内容にしてください。
7. 好意的な結果だけをシミュレートしないでください。少なくとも 1 人の懐疑的な審査員の視点を含めてください。

---

出力形式

judge_personas_used:
  - persona: "<type>"
    priorities:
      - "<priority>"

questions:
  - judge_persona: "<type>"
    question: "<question text>"
    recommended_answer: "<suggested response>"
    difficulty: "<easy|medium|hard>"

objections:
  - objection: "<concern>"
    likelihood: "<high|medium|low>"
    rebuttal_strategy: "<how to address>"

predicted_scores:
  - axis: "<axis name>"
    score: <1-5>
    reasoning: "<why>"

overall_verdict:
  impression: "<string>"
  ranking_likelihood: "<top-3|mid-field|long-shot>"
  key_strengths:
    - "<strength>"
  key_weaknesses:
    - "<weakness>"

pitch_improvements:
  - issue: "<problem>"
    action: "<what to change>"
    priority: "<high|medium|low>"

---

例

入力：

project_title: "AnchorAI"
problem_statement: "College students wait 6 weeks for counseling while anxiety compounds."
solution_summary: "GPT-4 companion with Redis-backed session memory for persistent emotional context."
mvp_features: ["GPT-4 check-in conversation", "Session memory", "Crisis escalation (mocked)"]
tech_stack: ["Python", "FastAPI", "React", "Redis", "OpenAI GPT-4"]
evaluation_axes:
  - axis: "Innovation"
  - axis: "Impact"
  - axis: "Technical Execution"

出力：

judge_personas_used:
  - persona: "Technical judge"
    priorities: ["Working implementation", "Appropriate tech choices", "Scalability awareness"]
  - persona: "Impact/domain judge"
    priorities: ["Real user need", "Safety guardrails", "Clinical validity concerns"]
  - persona: "Business judge"
    priorities: ["Market size", "Differentiation", "Go-to-market path"]

questions:
  - judge_persona: "Technical judge"
    question: "How does the memory actually work — what are you storing and retrieving?"
    recommended_answer: "We store a GPT-4 generated summary of each session in Redis, keyed by user ID. On the next session, we prepend that summary to the system prompt. It's simple and it works for the demo."
    difficulty: "medium"
  - judge_persona: "Impact/domain judge"
    question: "Is this safe? What happens if someone is in genuine crisis?"
    recommended_answer: "We detect distress signals and surface hotline resources immediately. We're explicit that AnchorAI is not a therapist. In the roadmap, we escalate to human counselors."
    difficulty: "hard"
  - judge_persona: "Business judge"
    question: "How is this different from Woebot or BetterHelp?"
    recommended_answer: "Woebot has no memory and uses rigid scripts. BetterHelp is $80/week. AnchorAI is the only free, always-available companion that actually knows your history."
    difficulty: "medium"

objections:
  - objection: "This could give vulnerable users dangerous advice"
    likelihood: "high"
    rebuttal_strategy: "Acknowledge directly. Explain the safety guardrails and the explicit non-therapist framing. Offer to show the crisis card in the demo."
  - objection: "Memory feature is just system prompt injection — not novel"
    likelihood: "medium"
    rebuttal_strategy: "Agree it's a simple mechanism. Pivot to impact: the novelty is the UX, not the implementation. Show the user experience, not the code."

predicted_scores:
  - axis: "Innovation"
    score: 4
    reasoning: "Memory-based continuity in mental health context is genuinely novel for a hackathon"
  - axis: "Impact"
    score: 5
    reasoning: "Large, underserved audience with real demonstrated need"
  - axis: "Technical Execution"
    score: 4
    reasoning: "Working live demo with real API integration; Redis memory functions correctly"

overall_verdict:
  impression: "Strong emotional narrative with a memorable live demo moment. Safety question will come up — being prepared for it is the difference between winning and not."
  ranking_likelihood: "top-3"
  key_strengths:
    - "Emotionally resonant problem framing"
    - "Live working wow moment (memory recall)"
    - "Clear differentiation from existing tools"
  key_weaknesses:
    - "Safety and clinical validity will be scrutinized"
    - "Business model not addressed"

pitch_improvements:
  - issue: "No mention of how AnchorAI avoids causing harm"
    action: "Add one sentence to the solution slide: 'AnchorAI is not a therapist — it's a bridge to one.'"
    priority: "high"
  - issue: "No business or monetization framing"
    action: "Add one bullet to vision slide: 'Free tier for students; licensed model for universities'"
    priority: "medium"

---

コンテキストファイル

ナレッジベース

• ../hackathon-shared-resources/knowledge/hackathon-judging-criteria.md
• ../hackathon-shared-resources/knowledge/hackathon-pitch-strategy.md
• ../hackathon-shared-resources/knowledge/hackathon-winning-patterns.md
• ../hackathon-shared-resources/knowledge/hackathon-demo-psychology.md

プレイブック

• ../hackathon-shared-resources/playbooks/hackathon-workflow.md