hackathon-risk-analyzer

hackathon-risk-analyzer

目标

识别并评估可能导致项目在开发期间或现场评审时失败的技术、集成和演示风险，并在开始实现前为每项风险制定可执行的缓解策略。

---

触发条件

在以下情况下使用此技能：

• MVP 范围已确定，技术栈已确认
• 团队即将开始实现，但尚不清楚面临哪些风险
• 涉及外部 API、数据集、GPU 资源或网络依赖项
• 团队首次使用某个部署环境
• 在第 4 阶段（项目规划）调用；此时应在 hackathon-scope-cutter 之后、首次调用 hackathon-code-implementer 之前；如果范围或技术栈发生变化，请重新调用

---

输入

输入	类型	必填	描述
project_title	string	是	项目名称
tech_stack	string[]	是	使用的技术
mvp_features	object[]	是	来自 hackathon-scope-cutter 的 MVP 功能
external_dependencies	string[]	是	所需的外部 API、服务、数据集或硬件
hackathon_duration_hours	integer	是	剩余总时长
team_skills	string[]	否	团队擅长的领域（用于标记技能差距）
demo_environment	string	否	演示运行的环境（例如：本地、Vercel、Render、浏览器）

---

输出

输出	描述
risks	已识别风险的完整列表，包含严重程度、类别和缓解策略
critical_risks	评级为 critical、必须在编码前解决的风险子集
risk_summary	综合风险评分和项目总体风险级别
pre_build_actions	开始实现前应立即采取的行动
recommended_skills	建议后续调用的技能

---

规则

1. 将每项风险归入以下类别之一：api、data、infra、skill-gap、demo、time。
2. 使用以下级别评定严重程度：critical（阻碍演示）、high（很可能导致延迟）、medium（可控）、low（可接受）。
3. 每项 critical 或 high 风险都必须有具体的缓解策略和备用方案。
4. 将任何没有免费套餐或离线备用方案的外部依赖项标记为 critical。
5. 将任何需要 GPU、专用硬件或专有数据集的功能标记为 high 或 critical。
6. pre_build_actions 必须确保在开始编码前解决所有 critical 风险。
7. 不要臆造风险；所有风险都必须基于 tech_stack、external_dependencies 和 mvp_features。

---

输出格式

risks:
  - id: "R-<number>"
    title: "<short risk title>"
    category: "<api|data|infra|skill-gap|demo|time>"
    severity: "<critical|high|medium|low>"
    description: "<what can go wrong>"
    probability: "<high|medium|low>"
    impact: "<what breaks if this occurs>"
    mitigation: "<how to prevent or reduce>"
    fallback: "<what to do if it happens anyway>"

critical_risks:
  - id: "R-<number>"
    title: "<title>"
    blocking_feature: "<which MVP feature this blocks>"

risk_summary:
  total_risks: <number>
  critical: <number>
  high: <number>
  medium: <number>
  low: <number>
  overall_level: "<red|amber|green>"
  assessment: "<one-sentence summary>"

pre_build_actions:
  - priority: <number>
    action: "<what to do>"
    risk_addressed: "R-<number>"
    estimated_minutes: <number>

recommended_skills:
  - "<skill-name>"

---

示例

输入：

project_title: "AnchorAI"
tech_stack: ["Python", "FastAPI", "React", "Groq API", "Supabase"]
mvp_features:
  - feature: "GPT-4 emotional check-in conversation"
    fake_ok: false
  - feature: "Session memory"
    fake_ok: false
  - feature: "Crisis escalation (mocked)"
    fake_ok: true
external_dependencies:
  - "Groq API (LLM inference)"
  - "Supabase (database)"
hackathon_duration_hours: 24
team_skills: ["Python", "FastAPI", "React"]
demo_environment: "local + Vercel frontend"

输出：

risks:
  - id: "R-01"
    title: "Groq API rate limit hit during live demo"
    category: "api"
    severity: "critical"
    description: "Free tier Groq API has rate limits that can be exhausted under rapid demo usage"
    probability: "medium"
    impact: "Core chat feature fails live during judging"
    mitigation: "Use a dedicated API key with higher rate limits; implement exponential backoff"
    fallback: "Pre-record the memory recall exchange; play as screen capture if API fails"

  - id: "R-02"
    title: "Supabase cold start delays first DB query"
    category: "infra"
    severity: "high"
    description: "Supabase free tier instances sleep after inactivity; first query can take 3–10 seconds"
    probability: "high"
    impact: "Demo appears broken for first 10 seconds; undermines confidence"
    mitigation: "Warm up Supabase with a ping request at demo start; add a visible loading indicator"
    fallback: "Fall back to in-memory dict for demo session if Supabase is unresponsive"

  - id: "R-03"
    title: "Team unfamiliar with Supabase client library"
    category: "skill-gap"
    severity: "medium"
    description: "Team lists Python/FastAPI skills but not Supabase; integration may take longer than estimated"
    probability: "medium"
    impact: "Session memory feature delayed by 2–4 hours"
    mitigation: "Assign Supabase integration to most experienced backend developer; use official Supabase Python SDK examples"
    fallback: "Replace Supabase with Redis for demo; migrate after hackathon"

  - id: "R-04"
    title: "Context window overflow with long session summaries"
    category: "api"
    severity: "medium"
    description: "Injecting long memory summaries into the system prompt may exceed model context limits"
    probability: "medium"
    impact: "API returns error; chat feature breaks mid-demo"
    mitigation: "Hard-cap session summary at 150 tokens before injection"
    fallback: "Truncate summary silently; log warning"

critical_risks:
  - id: "R-01"
    title: "Groq API rate limit hit during live demo"
    blocking_feature: "GPT-4 emotional check-in conversation"

risk_summary:
  total_risks: 4
  critical: 1
  high: 1
  medium: 2
  low: 0
  overall_level: "amber"
  assessment: "Project is buildable but requires API key upgrade and Supabase warm-up strategy before demo."

pre_build_actions:
  - priority: 1
    action: "Upgrade Groq API key to a plan with higher rate limits and test with 10 rapid requests"
    risk_addressed: "R-01"
    estimated_minutes: 15
  - priority: 2
    action: "Add a /health endpoint that warms Supabase on backend startup; test cold-start behavior"
    risk_addressed: "R-02"
    estimated_minutes: 20
  - priority: 3
    action: "Run Supabase Python SDK quickstart tutorial to confirm team can read/write successfully"
    risk_addressed: "R-03"
    estimated_minutes: 30

recommended_skills:
  - "hackathon-repo-bootstrap"
  - "hackathon-code-implementer"

---

上下文文件

知识库

• ../hackathon-shared-resources/knowledge/hackathon-common-failures.md
• ../hackathon-shared-resources/knowledge/hackathon-reference-architecture.md
• ../hackathon-shared-resources/knowledge/hackathon-tools.md
• ../hackathon-shared-resources/knowledge/hackathon-mvp-strategy.md

操作手册

• ../hackathon-shared-resources/playbooks/hackathon-workflow.md
• ../hackathon-shared-resources/playbooks/24h-hackathon-playbook.md
• ../hackathon-shared-resources/playbooks/36h-hackathon-playbook.md
• ../hackathon-shared-resources/playbooks/48h-hackathon-playbook.md