Welcome to Alchemy Docs

The ultimate prompt framework for hackathons, builders, and creators.

Welcome to Alchemy Docs — a documentation platform hosting production-grade prompt frameworks designed to help developers, designers, and founders build software rapidly and methodically.

Instead of navigating unstructured repositories and raw files, Alchemy Docs provides a unified, searchable, and responsive reading experience powered by a Docs-as-Code architecture.

🧭 Frameworks in Alchemy Docs

🏆 Hackathon Alchemy (Active Launch)

Hackathon Alchemy is a complete taxonomy of 20 hackathon categories and over 330 structured document prompt packs. Built for fast-paced 24–48 hour sprints, each category provides step-by-step prompts to guide your project from problem validation to final presentation:

Phase 1: Problem Definition & Strategy — Problem Analysis, PRD, and TRD.
Phase 2: Technical Blueprint — Architecture, Schemas, APIs, Rules, and Systems.
Phase 3: Execution, Quality & Security — UI Specs, Error Handling, Security, Testing, and Evaluation.
Phase 4: Delivery & Presentation — Deployment, Demo Scripts, and Glossaries.
Unique Deep Dives — 6 Debugging Pillars, 8 System Design Dimensions, 8 SEO Pillars, and 10 Scalability Layers.

👉 Explore Hackathon Alchemy | How to Use This Framework

🚀 Builder Alchemy (Coming Soon)

A sister repository focused on long-term startup creation, product launches, freelancing systems, and creator growth.

👉 Preview Builder Alchemy

⚡ Key Features

🔍 Global Instant Search: Press / or click the search bar at any time to query across all 330+ documents and prompt packs.
📋 One-Click Copy Prompts: Every prompt block is ready to copy straight into your AI workspace (ChatGPT, Claude, Cursor, Copilot, Gemini).
🌓 Dark & Light Modes: Custom themes engineered for readability and high contrast.
📱 Fully Responsive: Clean reading experience across mobile phones, tablets, and desktop workstations.
🛠️ Docs-as-Code: 100% version-controlled Markdown deployed to a global edge CDN.

Jump directly into popular categories:

01. AI / ML Hackathons — LLMs, RAG, agents, context windows, and eval.
02. Non-AI / Traditional Software — Web apps, SaaS, mobile, and traditional stacks.
03. Automation & Workflow — n8n, Make, Zapier, triggers, and webhooks.
06. Web3 / Blockchain — dApps, smart contracts, tokenomics, and gas optimization.
17. Debugging — 6-Pillar methodical bug isolation and resolution.
18. Improve System Design — 8 Dimensions of robust system architecture.
19. SEO Optimization — 8 Pillars of technical SEO, on-page, and authority.
20. Scalability — 10 Layers from capacity baselines to global multi-region.

🤝 Open Source & Contributions

Alchemy Docs is completely open-source. If you have improvements, additional prompt templates, or want to contribute new categories:

GitHub Repository: SidhCodez/Alchemy-Docs
Source Prompts: SidhCodez/Hackathon-Alchemy

Hackathon Alchemy

Welcome to Hackathon Alchemy — a prompt engineering and document framework designed to help hackers, developers, and founders build production-grade prototypes during high-pressure 24–48 hour events.

Whether you're developing an AI agent, a no-code workflow, or a Web3 smart contract, this framework gives you pre-tested prompt packs to plan, architect, build, and deliver your project methodically.

🏗️ The 4-Phase Workflow (Categories 01–16)

Every standard category is divided into 4 sequential phases:

┌─────────────────────────────────┐
│  Phase 1: Problem Definition   │  Problem Analysis ➔ PRD ➔ TRD
└────────────────┬────────────────┘
                 ▼
┌─────────────────────────────────┐
│  Phase 2: Technical Blueprint   │  System Architecture ➔ Schemas ➔ APIs
└────────────────┬────────────────┘
                 ▼
┌─────────────────────────────────┐
│  Phase 3: Execution & Quality   │  UI Spec ➔ Error Handling ➔ Security ➔ Testing
└────────────────┬────────────────┘
                 ▼
┌─────────────────────────────────┐
│  Phase 4: Delivery & Demo       │  Deployment ➔ Demo Script ➔ Glossary
└─────────────────────────────────┘

Phase 1: Problem Definition & Strategy
Understand the user's actual problem before writing code. Produce clear PROBLEM_ANALYSIS.md, PRD.md, and TRD.md to align the team and avoid scope creep.
Phase 2: Technical Blueprint
Define system architectures, data models, APIs, and domain-specific rules (like AI rules or smart contracts).
Phase 3: Execution, Quality & Security
Prepare UI specs, robust error handling, security guardrails, QA testing checklists, and evaluation metrics.
Phase 4: Delivery & Presentation
Configure continuous deployment, rehearse a winning demo pitch script, and define a glossary for judges.

🔍 Specialized Deep-Dive Categories (17–20)

For complex engineering disciplines beyond the 4-phase model, Hackathon Alchemy includes dedicated non-linear frameworks:

17. Debugging (6 Pillars): Detect & Define ➔ Reproduce & Isolate ➔ Instrument & Observe ➔ Hypothesize & Test ➔ Resolve & Verify ➔ Prevent & Learn.
18. Improve System Design (8 Dimensions): Requirements, Component Map, Data Modeling, Communication Protocols, Partitioning, Fault Tolerance, Observability, and Trade-offs.
19. SEO Optimization (8 Pillars): Technical Foundation, On-Page Optimization, Content Strategy, Keyword Architecture, Off-Page Authority, Geo-targeting, UX Signals, and Measurement.
20. Scalability (10 Layers): Baseline Capacity, Vertical Scaling, Horizontal Scaling, Data Layer, Caching, Async Queues, Cost Optimization, Resilience, Multi-Region, and Governance.

📚 Complete Category Index

#	Category	Focus
01	AI / ML Hackathons	LLMs, RAG, AI Agents, Vision, NLP, Prompt Library
02	Non-AI / Traditional Software	Web Apps, Backend, SaaS, Mobile, Databases
03	Automation & Workflow	n8n, Make, Zapier, Webhooks, API Orchestration
04	No-Code / Low-Code	Bubble, FlutterFlow, Airtable, Visual Development
05	Data & Analytics	Pipelines, ETL, Dashboards, Data Warehousing
06	Web3 / Blockchain	Smart Contracts, dApps, Tokenomics, Gas Optimization
07	IoT / Hardware / Robotics	Embedded Systems, Microcontrollers, Sensors, Telemetry
08	AR / VR / XR / Metaverse	Spatial Computing, Unity/Unreal, 3D Assets, Interactions
09	Cybersecurity	Threat Modeling, Attack Surfaces, AppSec, Incident Response
10	Cloud / DevOps / Platform	Docker, Kubernetes, CI/CD, Terraform, Infrastructure
11	Domain & Industry	FinTech, HealthTech, EdTech, GovTech, Compliance
12	Creative / Media / Gaming	Game Design, Mechanics, Storytelling, Digital Media
13	Social Impact / Civic	Accessibility, Sustainability, Open Data, Public Good
14	Open Innovation / Corporate	Sponsor Challenges, Corporate Sprints, Business Models
15	Beginner / Student / Community	College Hackathons, First-Time Builders, Mentorship
16	Platform-Sponsored	Official Partner SDKs, Quotas, Ecosystem Integrations
17	Debugging	6 Pillars: Root Cause Analysis, Bisect, Reproduction
18	Improve System Design	8 Dimensions: High Availability, Distributed Architecture
19	SEO Optimization	8 Pillars: Technical Audits, Core Web Vitals, Structured Data
20	Scalability	10 Layers: Load Balancing, Caching, Asynchronous Queues

🚀 How to Get Started

Check out How to Use This Framework.
Select your category from the list above or the sidebar.
Start with Phase 1: Problem Definition to generate your PROBLEM_ANALYSIS.md.

How to Use This Framework

Welcome to the practitioner's guide for Hackathon Alchemy.

This guide explains how to effectively extract maximum value from these prompts when pairing with modern Large Language Models (LLMs) and AI tools like ChatGPT, Claude, Gemini, Cursor, GitHub Copilot, and Windsurf.

⚡ The Core Workflow

Pick Your Category: Navigate through the sidebar to your relevant hackathon track (e.g., 01. AI / ML Hackathons, 03. Automation, 06. Web3).
Move Sequentially Through the Phases:
- Phase 1 locks down your problem scope and requirements before any code is typed.
- Phase 2 designs the technical contracts (database, API, architecture).
- Phase 3 hardens the implementation with error boundaries, test scripts, and UI specs.
- Phase 4 organizes deployment and your presentation pitch.
Copy the Prompt: Use the built-in copy button on any prompt code block.
Supply Your Context: Replace any bracketed placeholders like [PASTE PROBLEM STATEMENT] or [PASTE PRD] with your project's details.
Save Outputs as Markdown: Save each AI-generated output in your project's repository under docs/ or your root folder (e.g., PRD.md, SYSTEM_ARCHITECTURE.md).
Pass Outputs Forward: In subsequent phases, feed the generated documents into the next prompt! (e.g., feed PRD.md into the TRD.md prompt).

💡 Best Practices for Hackathons

1. Don't Skip Phase 1

The number one reason hackathon teams run out of time is building features nobody asked for or changing scope 8 hours before submission. Spending 30 minutes in Phase 1: Problem Definition guarantees consensus across your team and judges.

2. Treat Documents as Context Anchors

When working with AI coding tools (like Cursor, Claude Code, or Copilot Workspace), having crisp documents like SYSTEM_ARCHITECTURE.md, API_SPECIFICATION.md, and UI_SPEC.md directly in your repo gives your coding assistant clean grounding context.

3. Maintain an MVP Mindset

Every prompt in Hackathon Alchemy emphasizes:

What must be built for the demo.
What should NOT be built during a short sprint.
Realistic fallback mechanisms if an external API fails during live judging.

🛠️ Recommended AI Tooling

Reasoning & Planning: Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro
In-Editor Coding: Cursor, Windsurf, VS Code + GitHub Copilot
Mockups & Frontend: v0.dev, Bolt.new, Tailwind UI
Workflow Testing: Postman, Thunder Client, curl

🧭 Next Step

Head over to 01. AI / ML Hackathons or browse the sidebar to start your project.

01. AI / ML Hackathons

Focused on Artificial Intelligence, Machine Learning, LLMs, and RAG architectures.

Overview

This category provides structured prompt packs tailored for 01. AI / ML Hackathons projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 01. AI / ML Hackathons

Welcome to Phase 1: Problem Definition for 01. AI / ML Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 01. AI / ML Hackathons
Section: Phase 1: Problem Definition

**Purpose:** To deeply understand the problem before writing any code
I am participating in an AI/ML hackathon and I am a beginner developer.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed AI/ML solution ideas
7. Core AI features
8. Nice-to-have AI features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential AI technologies that could be used (e.g., LLMs, RAG, Vision, etc.)

Do not assume I am an experienced developer. 
Explain all AI/ML technical concepts in beginner-friendly language.

--------------------------------------------------------------------------

PRD

Category: 01. AI / ML Hackathons
Section: Phase 1: Problem Definition

You are a senior product manager helping a beginner AI/ML hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed solution
7. Product goals
8. User stories
9. Functional requirements (Include AI-specific requirements: Model selection, prompt handling, streaming, and latency limits)
10. Non-functional requirements
11. Core features
12. Nice-to-have features
13. User journeys
14. MVP scope
15. Out-of-scope features
16. Success metrics (Include AI metrics: Accuracy, hallucination rate, token usage, response time)
17. Risks and assumptions (Include AI risks: API rate limits, bad model outputs, downtime)

Keep the MVP realistic for a 24-48 hour AI hackathon. 
Do not add unnecessary AI features just to make the project sound impressive. 
Prioritize features that can actually be demonstrated live.

-------------------------------------------------------------------------

TRD

Category: 01. AI / ML Hackathons
Section: Phase 1: Problem Definition

You are a senior AI engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. AI model requirements (Which model? e.g., GPT-4o, Claude 3.5. Why? Context window size, temperature)
3. Prompt management strategy (Versioning, system prompts)
4. Data ingestion and preprocessing requirements (PDF parsing, text cleaning, etc.)
5. API rate limits and fallback mechanisms (What happens if the AI API goes down?)
6. Latency and performance requirements (Expected response time)
7. Security and data privacy requirements (Ensuring user data is not leaked to the AI)
8. Cost estimation and token budgeting (How much will the demo cost?)
9. Integration points (Vector DB, external APIs, backend frameworks)
10. Testing requirements for AI outputs

Keep the technical stack simple and realistic for a 24-48 hour hackathon. 
Explain all AI technical concepts in beginner-friendly language.

-------------------------------------------------------------

Phase 2: Technical Blueprint

Category: 01. AI / ML Hackathons

Welcome to Phase 2: Technical Blueprint for 01. AI / ML Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

Act as a senior AI software architect.
Using the following PRD and TRD, design a realistic hackathon architecture for an AI/ML project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended tech stack (Frontend, Backend, AI frameworks)
2. Frontend architecture
3. Backend architecture
4. AI inference architecture (How the request reaches the model and returns)
5. Database choice (SQL/NoSQL/Vector)
6. Authentication approach
7. External APIs/services
8. Complete request/data flow diagram (Text-based)
9. Folder structure
10. Major components
11. Security considerations
12. Deployment architecture
13. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language. 
Do not introduce unnecessary technologies. Prefer a simple architecture that can be explained easily to judges.

-------------------------------------

DATABASE_SCHEMA

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

Act as a senior database engineer.
Using the PRD and System Architecture below, design the database schema for an AI hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Tables (Include standard tables + AI-specific tables like ChatHistory, PromptLogs, Embeddings)
2. Columns
3. Data types
4. Primary keys
5. Foreign keys
6. Relationships
7. Required fields
8. Optional fields
9. Indexes where useful
10. Example records
11. SQL schema

Explain why each table exists. 
Keep the database simple enough for a beginner hackathon team to understand and maintain.

-------------------------

API_SPECIFICATION

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

You are a senior backend developer.
Using the PRD, Architecture, and Database Schema below, create a complete REST API specification for an AI hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATABASE SCHEMA: [PASTE DATABASE_SCHEMA]

For every endpoint provide:
1. HTTP method
2. URL
3. Purpose
4. Authentication requirement
5. Request parameters
6. Request body
7. Example request
8. Example success response
9. Possible error responses (Include AI-specific errors like 429 Rate Limit, 503 Model Unavailable)
10. HTTP status codes

Keep the API simple and consistent. 
Do not create endpoints that are not required by the product.

-----------------

AI_RULES

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

You are an AI safety and prompt engineering expert.
Using the PRD and System Architecture, create the AI Rules and Guardrails document for this hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Create the AI_RULES.md with these sections:
1. System Prompt definition (The exact base prompt for the AI)
2. AI persona and tone guidelines
3. Context window management rules
4. Hallucination mitigation strategies
5. Fallback responses for API failures or bad outputs
6. Handling of inappropriate or off-topic user inputs
7. Data privacy rules (What should never be sent to the AI)
8. Token optimization rules
9. Output formatting rules (JSON, Markdown, etc.)
10. A checklist for developers to verify AI behavior before the demo

Keep the rules practical and enforceable within a hackathon timeframe.

---------------

AI_MEMORY

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

Act as an AI systems engineer.
Using the PRD and AI Rules, create the AI Memory Management document for this hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]

Provide:
1. Short-term memory (Conversation buffer, context window limits)
2. Long-term memory (Database storage, Vector DB if applicable)
3. Memory retrieval strategy (How past interactions are pulled into the prompt)
4. Summarization strategy (What to do when the context window gets full)
5. State management (How the backend tracks user sessions)
6. Privacy considerations for stored memory
7. A simple implementation plan for a 24-48 hour hackathon

Explain how memory improves the user experience without overcomplicating the tech stack.

------------------------------

PROMPT_LIBRARY

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

Act as an AI systems engineer.
Using the PRD and AI Rules, create the AI Memory Management document for this hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]

Provide:
1. Short-term memory (Conversation buffer, context window limits)
2. Long-term memory (Database storage, Vector DB if applicable)
3. Memory retrieval strategy (How past interactions are pulled into the prompt)
4. Summarization strategy (What to do when the context window gets full)
5. State management (How the backend tracks user sessions)
6. Privacy considerations for stored memory
7. A simple implementation plan for a 24-48 hour hackathon

Explain how memory improves the user experience without overcomplicating the tech stack.

------------------

CACHE_SCHEMA

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

Act as a backend/DevOps engineer.
Using the System Architecture and API Specification, create a Caching Strategy document for this AI hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Cache strategy (Redis, In-memory, Semantic Cache)
2. Cache key structure (How to uniquely identify a request)
3. TTL (Time-to-live) for different types of data
4. Cache invalidation strategy (When to clear the cache)
5. What to cache (AI responses, embeddings, user sessions)
6. What NOT to cache (Personal data, sensitive prompts)
7. Fallback if cache fails
8. A simple implementation checklist

Explain how caching will save money and make the demo run faster.

------------------

EVIDENCE_MODEL

Category: 01. AI / ML Hackathons
Section: Phase 2: Technical Blueprint

You are a RAG and knowledge management expert.
Using the PRD and AI Rules, create the Evidence and Grounding Model for this AI hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]

Provide:
1. Source of truth (Where does the AI get its facts?)
2. Chunking strategy (If using documents, how are they split?)
3. Embedding model (Which model, why?)
4. Vector Database (Which one, why?)
5. Retrieval logic (How many chunks to retrieve, similarity threshold)
6. Citation format (How does the AI show its sources?)
7. Hallucination checks (How to verify the AI isn't making things up)
8. Fallback if no evidence is found

If RAG is not needed for this project, explain alternative grounding techniques (e.g., few-shot prompting, structured data injection).

--------------
``

Phase 3: Execution & Quality

Category: 01. AI / ML Hackathons

Welcome to Phase 3: Execution & Quality for 01. AI / ML Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 01. AI / ML Hackathons
Section: Phase 3: Execution & Quality

Act as a senior UI/UX designer.
Using the PRD and System Architecture below, create a UI Specification document for an AI/ML hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (List all major components)
3. Screen-by-screen breakdown (Login, Dashboard, AI Chat, Results)
4. Loading states (Crucial for AI: Skeletons, spinners, streaming text indicators)
5. Error states (How errors are displayed to the user)
6. Empty states (What the user sees before data is loaded)
7. Responsive design guidelines (Mobile and Desktop)
8. Accessibility considerations (Contrast, keyboard navigation)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon. 
Focus on demonstrating the core AI user journey.

---

ERROR_HANDLING

Category: 01. AI / ML Hackathons
Section: Phase 3: Execution & Quality

You are a senior backend developer.
Using the System Architecture and API Specification below, create an Error Handling document for this AI hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. AI API failure modes (Rate limits, timeouts, server errors)
2. Fallback responses (What to show the user if the AI fails)
3. Frontend error display (Toasts, inline errors, modals)
4. Retry logic (Exponential backoff, maximum retries)
5. Validation errors (Empty prompts, too long inputs)
6. Database connection errors
7. Authentication errors
8. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.

---

SECURITY

Category: 01. AI / ML Hackathons
Section: Phase 3: Execution & Quality

Act as a security engineer.
Using the System Architecture and API Specification below, create a Security document for this AI hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. API key protection (Environment variables, backend-only access)
2. Authentication security (JWT, session management)
3. Input sanitization (Preventing prompt injection and XSS)
4. Data privacy (Ensuring user data is not leaked to the AI model)
5. Database security (Row-level security, permissions)
6. CORS configuration
7. Rate limiting (Preventing abuse of AI endpoints)
8. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.

---

TESTING

Category: 01. AI / ML Hackathons
Section: Phase 3: Execution & Quality

Act as a QA engineer specializing in AI applications.
Using the PRD and AI Rules below, create a Testing document for this AI/ML hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]

Provide:
1. Testing strategy for AI outputs
2. Edge cases for prompts (Empty input, long input, malicious input)
3. How to test for hallucinations
4. API failure testing (Simulating downtime or rate limits)
5. Latency testing
6. User acceptance testing checklist
7. A manual testing checklist for the demo (Authentication, Core Feature, UI)
8. How to document known AI limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.

---

EVALUATION

Category: 01. AI / ML Hackathons
Section: Phase 3: Execution & Quality

You are an AI evaluation expert.
Using the PRD and AI Rules below, create an Evaluation document for this AI hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]

Provide:
1. Evaluation metrics (Accuracy, relevance, latency, token usage)
2. Evaluation methods (Manual human-in-the-loop scoring, rubric)
3. Benchmarking (What is the baseline?)
4. Known limitations of the AI model
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about AI performance and how to answer them

Focus on demonstrating that the team understands their AI's capabilities and boundaries.

---
# BELOW DOCS ARE OPTIONAL - PHASE 4 

---

Phase 4: Delivery & Presentation

Category: 01. AI / ML Hackathons

Welcome to Phase 4: Delivery & Presentation for 01. AI / ML Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 01. AI / ML Hackathons
Section: Phase 4: Delivery & Presentation

Act as a DevOps engineer.
Using the System Architecture and API Specification below, create a Deployment document for this AI hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Deployment platforms (Frontend, Backend, Database, AI service)
2. Environment variables for production (API keys, database URLs)
3. Step-by-step deployment instructions for each component
4. How to test the deployed application
5. Fallback plan if deployment fails during the hackathon
6. Cost considerations for AI API usage in production
7. A pre-deployment checklist
8. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon. 
Focus on getting a working live URL as early as possible.

---

DEMO_SCRIPT

Category: 01. AI / ML Hackathons
Section: Phase 4: Delivery & Presentation

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
FEATURES: [PASTE CORE FEATURES]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our solution
6. How it works (Include the AI model and architecture briefly)
7. Technology
8. Demo (The most important part)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
  
___

GLOSSARY

Category: 01. AI / ML Hackathons
Section: Phase 4: Delivery & Presentation

You are a technical writer.
Using the PRD, AI Rules, and Architecture below, create a Glossary document for this AI hackathon project.

PRD: [PASTE PRD]
AI_RULES: [PASTE AI_RULES]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. AI/ML terms (LLM, RAG, Embeddings, Tokens, Temperature, Context Window, Hallucination)
2. Technical terms (API, REST, JWT, Database, Vector DB, Cache)
3. Project-specific terms (Any custom terminology used in the PRD)
4. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience. 
This will help all team members speak confidently to judges.

---

# All 19 documents for the **AI/ML Hackathons** category now have their complete Prompt Packs across all 4 Phases

---

### Thank You

Thank you for using this guide. Go build something amazing!

**Made by Siddiq

*Credit: Hackathon Alechemy Folder — AI/ML Category*

[![GitHub](https://img.shields.io/badge/GitHub-Profile-black?logo=github)](https://github.com/SidhCodez)
[![LinkedIn](https://img.shields.io/badge/LinkedIn-Profile-blue?logo=linkedin)](https://www.linkedin.com/in/siddiq-dev/)

🔗 **[Link to Hackathon Alechemy](https://github.com/SidhCodez/Hackathon-Alchemy.git)**

02. Non-AI / Traditional Software

Standard software development focusing on logic, UI/UX, and robust database architectures.

Overview

This category provides structured prompt packs tailored for 02. Non-AI / Traditional Software projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 02. Non-AI / Traditional Software

Welcome to Phase 1: Problem Definition for 02. Non-AI / Traditional Software. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 02. Non-AI / Traditional Software
Section: Phase 1: Problem Definition

I am participating in a software hackathon and I am a beginner developer.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed software solution ideas
7. Core features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential technologies that could be used (e.g., React, Node.js, PostgreSQL, etc.)

Do not assume I am an experienced developer. 
Explain all technical concepts in beginner-friendly language.
Do not suggest AI features unless absolutely necessary.

---

PRD

Category: 02. Non-AI / Traditional Software
Section: Phase 1: Problem Definition

You are a senior product manager helping a beginner software hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed solution
7. Product goals
8. User stories
9. Functional requirements (Include standard requirements: Authentication, CRUD operations, Search, Filters, Notifications)
10. Non-functional requirements (Performance, Scalability, Usability)
11. Core features
12. Nice-to-have features
13. User journeys
14. MVP scope
15. Out-of-scope features
16. Success metrics (Include standard metrics: User signups, task completion rate, load time)
17. Risks and assumptions

Keep the MVP realistic for a 24-48 hour hackathon. 
Do not add unnecessary features just to make the project sound impressive. 
Prioritize features that can actually be demonstrated live.
Do not include AI features unless explicitly required.

---

TRD

Category: 02. Non-AI / Traditional Software
Section: Phase 1: Problem Definition

You are a senior software engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Frontend requirements (Framework, state management, routing)
3. Backend requirements (Framework, authentication, business logic)
4. Database requirements (SQL vs NoSQL, justification)
5. API design approach (REST vs GraphQL)
6. Authentication and authorization requirements
7. Third-party integrations (Payment, Maps, Email, etc.)
8. Performance and latency requirements
9. Security and data privacy requirements
10. Testing requirements
11. Deployment requirements

Keep the technical stack simple and realistic for a 24-48 hour hackathon. 
Explain all technical concepts in beginner-friendly language.
Do not introduce unnecessary technologies.

---

Phase 2: Technical Blueprint

Category: 02. Non-AI / Traditional Software

Welcome to Phase 2: Technical Blueprint for 02. Non-AI / Traditional Software. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 02. Non-AI / Traditional Software
Section: Phase 2: Technical Blueprint

Act as a senior software architect.
Using the following PRD and TRD, design a realistic hackathon architecture for a standard software project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended tech stack (Frontend, Backend, Database)
2. Frontend architecture
3. Backend architecture
4. Database architecture
5. Authentication flow
6. External APIs/services
7. Complete request/data flow diagram (Text-based)
8. Folder structure
9. Major components
10. Security considerations
11. Deployment architecture
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language. 
Do not introduce unnecessary technologies. Prefer a simple architecture that can be explained easily to judges.

---

DATABASE_SCHEMA

Category: 02. Non-AI / Traditional Software
Section: Phase 2: Technical Blueprint

Act as a senior database engineer.
Using the PRD and System Architecture below, design the database schema for a software hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Tables (Users, Sessions, Core Entities, Lookup Tables)
2. Columns
3. Data types
4. Primary keys
5. Foreign keys
6. Relationships (One-to-Many, Many-to-Many)
7. Required fields
8. Optional fields
9. Indexes where useful
10. Example records
11. SQL schema

Explain why each table exists. 
Keep the database simple enough for a beginner hackathon team to understand and maintain.
Do not include AI-specific tables like Embeddings or PromptLogs.

---

API_SPECIFICATION

Category: 02. Non-AI / Traditional Software
Section: Phase 2: Technical Blueprint

You are a senior backend developer.
Using the PRD, Architecture, and Database Schema below, create a complete REST API specification for a software hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATABASE SCHEMA: [PASTE DATABASE_SCHEMA]

For every endpoint provide:
1. HTTP method (GET, POST, PUT, PATCH, DELETE)
2. URL
3. Purpose
4. Authentication requirement
5. Request parameters
6. Request body
7. Example request
8. Example success response
9. Possible error responses (400, 401, 403, 404, 500)
10. HTTP status codes

Keep the API simple and consistent. 
Do not create endpoints that are not required by the product.
Focus on standard CRUD operations for the core features.

---

AUTHENTICATION_FLOW

Category: 02. Non-AI / Traditional Software
Section: Phase 2: Technical Blueprint

You are a senior backend security engineer.
Using the PRD and System Architecture below, create an Authentication Flow document for a software hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Authentication method (JWT, Session-based, OAuth)
2. Password hashing strategy (bcrypt, argon2)
3. Registration flow (Step-by-step)
4. Login flow (Step-by-step)
5. Token management (Access token, Refresh token)
6. Role-based access control (Admin, User, Guest)
7. Password reset flow
8. Logout flow
9. Session expiry and handling
10. Third-party login options (Google, GitHub) if applicable
11. A developer checklist for implementing auth

Keep the authentication simple and secure enough for a hackathon. 
Explain concepts in beginner-friendly language.

---

Phase 3: Execution & Quality

Category: 02. Non-AI / Traditional Software

Welcome to Phase 3: Execution & Quality for 02. Non-AI / Traditional Software. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 02. Non-AI / Traditional Software
Section: Phase 3: Execution & Quality

Act as a senior UI/UX designer.
Using the PRD and System Architecture below, create a UI Specification document for a software hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (List all major components)
3. Screen-by-screen breakdown (Login, Dashboard, Core Feature, Settings)
4. Loading states (Skeletons, spinners)
5. Error states (How errors are displayed to the user)
6. Empty states (What the user sees before data is loaded)
7. Responsive design guidelines (Mobile and Desktop)
8. Accessibility considerations (Contrast, keyboard navigation)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon. 
Focus on demonstrating the core user journey.

---

ERROR_HANDLING

Category: 02. Non-AI / Traditional Software
Section: Phase 3: Execution & Quality

You are a senior backend developer.
Using the System Architecture and API Specification below, create an Error Handling document for a software hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. API failure modes (Server errors, timeouts, network issues)
2. Fallback responses (What to show the user)
3. Frontend error display (Toasts, inline errors, modals)
4. Retry logic (Exponential backoff, maximum retries)
5. Validation errors (Empty fields, invalid formats)
6. Database connection errors
7. Authentication errors (Expired token, unauthorized access)
8. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.

---

SECURITY

Category: 02. Non-AI / Traditional Software
Section: Phase 3: Execution & Quality

Act as a security engineer.
Using the System Architecture and API Specification below, create a Security document for a software hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. API key protection (Environment variables, backend-only access)
2. Authentication security (JWT, session management)
3. Input sanitization (Preventing SQL injection and XSS)
4. Data privacy (Ensuring user data is protected)
5. Database security (Row-level security, permissions)
6. CORS configuration
7. Rate limiting (Preventing abuse of endpoints)
8. HTTPS and secure headers
9. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.

---

TESTING

Category: 02. Non-AI / Traditional Software
Section: Phase 3: Execution & Quality

Act as a QA engineer.
Using the PRD and API Specification below, create a Testing document for a software hackathon project.

PRD: [PASTE PRD]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Testing strategy for core features
2. Edge cases for forms (Empty input, long input, invalid format)
3. API testing (Using Postman or similar tools)
4. Database testing (Data integrity, relationships)
5. Authentication testing (Register, login, logout, password reset)
6. User acceptance testing checklist
7. A manual testing checklist for the demo (Core Feature, UI, Navigation)
8. Cross-browser and responsive testing checklist

Keep the testing plan simple enough for beginner developers to execute under time pressure.

---

EVALUATION

Category: 02. Non-AI / Traditional Software
Section: Phase 3: Execution & Quality

You are a software quality expert.
Using the PRD and Architecture below, create an Evaluation document for a software hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Evaluation metrics (Load time, bug rate, task completion rate)
2. Evaluation methods (Manual testing, user feedback)
3. Benchmarking (What is the baseline?)
4. Known limitations of the software
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about software performance and how to answer them

Focus on demonstrating that the team understands their software's capabilities and boundaries.

---
## Phase 4: Delivery & Presentation (OPTIONAL)

Phase 4: Delivery & Presentation

Category: 02. Non-AI / Traditional Software

Welcome to Phase 4: Delivery & Presentation for 02. Non-AI / Traditional Software. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 02. Non-AI / Traditional Software
Section: Phase 4: Delivery & Presentation

Act as a DevOps engineer.
Using the System Architecture and API Specification below, create a Deployment document for a software hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Deployment platforms (Frontend: Vercel/Netlify, Backend: Render/Railway, Database: Supabase/MongoDB Atlas)
2. Environment variables for production (Database URLs, API keys, JWT secrets)
3. Step-by-step deployment instructions for each component
4. How to test the deployed application
5. Fallback plan if deployment fails during the hackathon
6. A pre-deployment checklist
7. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon. 
Focus on getting a working live URL as early as possible.

---

DEMO_SCRIPT

Category: 02. Non-AI / Traditional Software
Section: Phase 4: Delivery & Presentation

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
FEATURES: [PASTE CORE FEATURES]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our solution
6. How it works (Include the architecture briefly)
7. Technology
8. Demo (The most important part)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
  
___

GLOSSARY

Category: 02. Non-AI / Traditional Software
Section: Phase 4: Delivery & Presentation

You are a technical writer.
Using the PRD, API Specification, and Architecture below, create a Glossary document for a software hackathon project.

PRD: [PASTE PRD]
API_SPEC: [PASTE API_SPECIFICATION]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Web development terms (API, REST, CRUD, JWT, ORM, MVC)
2. Database terms (SQL, NoSQL, Primary Key, Foreign Key, Index)
3. Frontend terms (Component, State, Props, Routing, SPA)
4. Backend terms (Middleware, Controller, Service, Environment Variables)
5. Deployment terms (CI/CD, Hosting, Domain, SSL)
6. Project-specific terms (Any custom terminology used in the PRD)
7. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience. 
This will help all team members speak confidently to judges.

---
Thank you for using this guide. Go build something amazing!

**Made by Siddiq

*Credit: Hackathon Alechemy Folder*

[![GitHub](https://img.shields.io/badge/GitHub-Profile-black?logo=github)](https://github.com/SidhCodez)
[![LinkedIn](https://img.shields.io/badge/LinkedIn-Profile-blue?logo=linkedin)](https://www.linkedin.com/in/siddiq-dev/)

🔗 **[Link to Hackathon Alechemy](https://github.com/SidhCodez/Hackathon-Alchemy.git)**

03. Automation & Workflow

Automating repetitive processes and connecting platforms via n8n, Make, and webhooks.

Overview

This category provides structured prompt packs tailored for 03. Automation & Workflow projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 03. Automation & Workflow

Welcome to Phase 1: Problem Definition for 03. Automation & Workflow. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 03. Automation & Workflow
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem and identify what manual, repetitive, or disconnected processes need automation.

I am participating in an automation-focused hackathon (using tools like n8n, Make, or Zapier) and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem manually
5. Limitations of existing manual or semi-automated solutions
6. Proposed automation solution ideas
7. Core automation features
8. Nice-to-have automation features
9. What should NOT be built during a short hackathon
10. What could make this automation unique
11. A realistic MVP workflow that can be built during a hackathon
12. Potential tools and platforms that could be used (n8n, Make, Zapier, Airtable, Google Sheets, etc.)

Do not assume I am an experienced developer.
Explain automation concepts (triggers, actions, webhooks, nodes) in beginner-friendly language.

PRD

Category: 03. Automation & Workflow
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear automation plan with triggers, actions, and workflow scope.

You are a senior automation product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed automation solution
7. Product goals
8. User stories
9. Functional requirements (Include automation-specific requirements: Triggers, Actions, Conditions, Data Transformations)
10. Non-functional requirements (Reliability, Speed, Error tolerance)
11. Core automation workflows
12. Nice-to-have workflows
13. User journeys (Manual step → Automated step)
14. MVP scope (Which workflow must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include automation metrics: Time saved, Manual steps reduced, Error rate)
17. Risks and assumptions (Include automation risks: API rate limits, Broken webhooks, Third-party downtime)

Keep the MVP realistic for a 24-48 hour automation hackathon.
Do not add unnecessary workflows just to make the project sound impressive.
Prioritize automations that can actually be demonstrated live.

TRD

Category: 03. Automation & Workflow
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on platform choice, triggers, actions, and integrations.

You are a senior automation engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Automation platform choice (n8n vs Make vs Zapier — justify the choice)
3. Trigger requirements (Webhook, Schedule, App Event, Manual)
4. Action node requirements (What each node does)
5. Data transformation requirements (Formatting, Mapping, Filtering)
6. Conditional logic requirements (If/Else, Switch, Loops)
7. External service integrations (Google Sheets, Slack, Gmail, Airtable, etc.)
8. API and webhook requirements
9. Error handling and retry requirements
10. Credential and secret management
11. Performance and execution time limits
12. Testing requirements

Keep the automation stack simple and realistic for a 24-48 hour hackathon.
Explain all automation concepts in beginner-friendly language.

Phase 2: Technical Blueprint

Category: 03. Automation & Workflow

Welcome to Phase 2: Technical Blueprint for 03. Automation & Workflow. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design the automation workflow architecture with clear triggers, actions, and data flow.

Act as a senior automation architect.
Using the following PRD and TRD, design a realistic hackathon automation architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended automation platform (n8n, Make, or Zapier)
2. Complete workflow diagram (Text-based, showing Trigger → Nodes → Output)
3. Trigger architecture (What starts the workflow?)
4. Action architecture (What happens step by step?)
5. Data flow (How data moves between nodes)
6. Conditional logic and branching
7. External service connections (APIs, Webhooks, Databases)
8. Database or storage choice if needed (Google Sheets, Airtable, Supabase)
9. Credential and authentication approach
10. Error handling and retry architecture
11. Folder/Workflow organization
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple workflow that can be explained easily to judges.

WORKFLOW_SCHEMA

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

5. WORKFLOW_SCHEMA.md

Purpose: To define the exact node-by-node structure of each automation workflow.

Act as a senior automation engineer.
Using the PRD and System Architecture below, design the complete workflow schema for this automation hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For each core workflow, provide:
1. Workflow name
2. Trigger type (Webhook, Schedule, App Event, Manual)
3. Trigger configuration
4. Node-by-node breakdown (Node name, Type, Purpose, Configuration)
5. Data mapping between nodes
6. Conditional logic (Filters, If/Else, Switch)
7. Error handling per node (Continue on fail, Retry, Stop)
8. Output destination (Email, Database, Slack, etc.)
9. Example input data
10. Example output data
11. Execution time estimate

Explain why each node exists.
Keep the workflow simple enough for a beginner hackathon team to understand and maintain.

API_INTEGRATION

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

6. API_INTEGRATION.md

Purpose: To define all external APIs and webhooks used in the automation.

You are a senior integration engineer.
Using the PRD and Workflow Schema below, create a complete API Integration document for this automation hackathon project.

PRD: [PASTE PRD]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]

For every external service and API, provide:
1. Service name (Google Sheets, Slack, Gmail, OpenAI, etc.)
2. Purpose in the workflow
3. Authentication method (API Key, OAuth, Webhook URL)
4. Required credentials and where to store them
5. Endpoint or Webhook URL used
6. Request format (Headers, Body, Parameters)
7. Example request
8. Example response
9. Rate limits (If any)
10. Error responses and handling
11. Fallback if the service is down

Keep the integrations simple and realistic for a hackathon.
Do not include services that are not required by the product.

NODE_LOGIC

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

7. NODE_LOGIC.md

Purpose: To define the logic, conditions, and data transformations inside each node.

Act as a senior automation logic designer.
Using the Workflow Schema and PRD below, create the Node Logic document for this automation hackathon project.

WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]
PRD: [PASTE PRD]

Provide:
1. Data transformation rules (Formatting, Parsing, Merging)
2. Conditional logic rules (If/Else, Switch, Filters)
3. Loop and iteration logic
4. Variable and expression usage
5. Date/Time formatting rules
6. Text manipulation rules (Split, Replace, Trim)
7. Number and currency formatting rules
8. Error handling logic per node
9. Edge cases for each node (Empty data, Missing fields, Invalid formats)
10. A checklist for developers to verify node logic before the demo

Explain every logic rule in beginner-friendly language.
Keep the logic simple and easy to debug.

TRIGGER_MAP

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

8. TRIGGER_MAP.md

Purpose: To define how each workflow is triggered and under what conditions.

You are an automation trigger specialist.
Using the PRD and Workflow Schema below, create a Trigger Map document for this automation hackathon project.

PRD: [PASTE PRD]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]

For each workflow, provide:
1. Workflow name
2. Trigger type (Webhook, Schedule, App Event, Manual)
3. Trigger source (Form submission, Email received, New row in Sheet, etc.)
4. Trigger configuration details
5. Trigger frequency or schedule (If applicable)
6. Trigger payload structure (What data comes in?)
7. Example trigger event
8. Conditions that must be met for the trigger to fire
9. What happens if the trigger fails
10. How to manually test the trigger

Explain each trigger in beginner-friendly language.
Keep the triggers simple and easy to demonstrate live.

CREDENTIAL_MANAGEMENT

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint

9. CREDENTIAL_MANAGEMENT.md

Purpose: To securely manage API keys, webhooks, and credentials for the automation.

Act as a security-conscious automation engineer.
Using the Workflow Schema and API Integration document below, create a Credential Management document for this automation hackathon project.

WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]
API_INTEGRATION: [PASTE API_INTEGRATION]

Provide:
1. List of all credentials required (API keys, tokens, webhook URLs)
2. Where each credential is stored (Platform vault, .env file, Environment variables)
3. How to securely share credentials with team members
4. How to rotate credentials if compromised
5. What NEVER to commit to GitHub
6. How to use n8n/Make credential vaults properly
7. Fallback if a credential expires during the demo
8. A pre-submission credential checklist

Keep the credential management simple but secure enough for a hackathon.
Explain concepts in beginner-friendly language.

DATABASE_SCHEMA

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 03. Automation & Workflow.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 03. Automation & Workflow project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 03. Automation & Workflow
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 03. Automation & Workflow.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 03. Automation & Workflow project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 03. Automation & Workflow

Welcome to Phase 3: Execution & Quality for 03. Automation & Workflow. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 03. Automation & Workflow
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define the user-facing interface (forms, dashboards, or trigger points) that interacts with the automation.

Act as a senior UI/UX designer.
Using the PRD and System Architecture below, create a UI Specification document for an automation hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (Forms, Dashboards, Status Cards)
3. Screen-by-screen breakdown (Trigger Form, Status Dashboard, Logs View)
4. Loading states (For automation triggers)
5. Success states (What the user sees when the automation runs)
6. Error states (What the user sees when the automation fails)
7. Empty states (Before any automation has run)
8. Responsive design guidelines (Mobile and Desktop)
9. Accessibility considerations

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the automation trigger and result.

ERROR_HANDLING

Category: 03. Automation & Workflow
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when a node fails, an API times out, or credentials expire.

You are a senior automation engineer.
Using the Workflow Schema and API Integration document below, create an Error Handling document for this automation hackathon project.

WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]
API_INTEGRATION: [PASTE API_INTEGRATION]

Provide:
1. Common failure modes (API timeouts, Rate limits, Invalid credentials, Missing data)
2. Node-level error handling (Continue on fail, Retry, Stop workflow)
3. Retry logic (Exponential backoff, Maximum retries)
4. Fallback responses (What to do if a critical node fails)
5. Notification strategy (Email, Slack alert when a workflow fails)
6. Error logging (Where errors are stored)
7. Frontend error display (If applicable)
8. A checklist for developers to verify error handling before the demo

Focus on making the automation resilient so the live demo does not crash.

SECURITY

Category: 03. Automation & Workflow
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To secure webhooks, API keys, and user data flowing through the automation.

Act as a security engineer.
Using the Workflow Schema and API Integration document below, create a Security document for an automation hackathon project.

WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]
API_INTEGRATION: [PASTE API_INTEGRATION]

Provide:
1. Webhook security (Secret tokens, IP whitelisting)
2. API key protection (Vault storage, Environment variables)
3. Authentication for external services (OAuth best practices)
4. Input sanitization (Preventing injection through forms)
5. Data privacy (What data flows through the automation?)
6. Access control (Who can edit the workflow?)
7. Logging and monitoring for suspicious activity
8. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.

TESTING

Category: 03. Automation & Workflow
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for automation workflows and edge cases.

Act as a QA engineer specializing in automation workflows.
Using the PRD and Workflow Schema below, create a Testing document for an automation hackathon project.

PRD: [PASTE PRD]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]

Provide:
1. Testing strategy for automation workflows
2. Trigger testing (Does the workflow start correctly?)
3. Node testing (Does each node produce the correct output?)
4. Data transformation testing (Is data mapped correctly?)
5. Error case testing (Missing data, API failures)
6. End-to-end workflow testing
7. User acceptance testing checklist
8. A manual testing checklist for the demo
9. How to document known automation limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.

EVALUATION

Category: 03. Automation & Workflow
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures automation performance and prepares for judge questions.

You are an automation evaluation expert.
Using the PRD and Workflow Schema below, create an Evaluation document for an automation hackathon project.

PRD: [PASTE PRD]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]

Provide:
1. Evaluation metrics (Time saved, Manual steps reduced, Error rate, Execution time)
2. Evaluation methods (Before vs After comparison, Manual timing)
3. Benchmarking (What is the baseline manual process?)
4. Known limitations of the automation
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about automation and how to answer them

Focus on demonstrating that the team understands the automation's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 03. Automation & Workflow

Welcome to Phase 4: Delivery & Presentation for 03. Automation & Workflow. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 03. Automation & Workflow
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to activate, publish, and share the automation workflow for the live demo.

Act as a DevOps engineer.
Using the System Architecture and Workflow Schema below, create a Deployment document for an automation hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]

Provide:
1. Deployment approach (Activate workflow, Publish, Share link)
2. Environment variables and credentials for production
3. Step-by-step activation instructions for each workflow
4. How to test the live workflow
5. Fallback plan if the workflow fails during the hackathon
6. How to share the workflow with judges or users
7. A pre-deployment checklist
8. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live automation as early as possible.

DEMO_SCRIPT

Category: 03. Automation & Workflow
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the automation is shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
WORKFLOWS: [PASTE CORE WORKFLOWS]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem (Manual, repetitive, error-prone process)
3. Why the problem matters
4. Existing limitations
5. Our automation solution
6. How it works (Trigger → Nodes → Output)
7. Technology (n8n/Make, APIs used)
8. Demo (The most important part — show the trigger and the automated result)
9. Innovation
10. Impact (Time saved, Errors reduced)
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation

GLOSSARY

Category: 03. Automation & Workflow
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all automation terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Workflow Schema, and API Integration document below, create a Glossary document for an automation hackathon project.

PRD: [PASTE PRD]
WORKFLOW_SCHEMA: [PASTE WORKFLOW_SCHEMA]
API_INTEGRATION: [PASTE API_INTEGRATION]

Provide definitions for all key terms used in the project, including:
1. Automation terms (Trigger, Action, Node, Workflow, Webhook, Schedule)
2. Integration terms (API, Endpoint, OAuth, API Key, Rate Limit)
3. Data terms (Payload, JSON, Mapping, Transformation, Filter)
4. Platform-specific terms (n8n Node, Make Module, Zapier Zap)
5. Conditional logic terms (If/Else, Switch, Loop, Branch)
6. Error handling terms (Retry, Fallback, Timeout)
7. Project-specific terms (Any custom terminology used in the PRD)
8. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

**Made by Siddiq

*Credit: Hackathon Alechemy

🔗 Link to Hackathon Alechemy

04. No-Code / Low-Code

Building functional applications rapidly using visual and declarative development platforms.

Overview

This category provides structured prompt packs tailored for 04. No-Code / Low-Code projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 04. No-Code / Low-Code

Welcome to Phase 1: Problem Definition for 04. No-Code / Low-Code. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 04. No-Code / Low-Code
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem without any coding bias, focusing on what can be built visually and rapidly.

I am participating in a no-code/low-code hackathon (using tools like Bubble, Glide, Airtable, or FlutterFlow) and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed no-code solution ideas
7. Core features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential no-code platforms that could be used (Bubble, Glide, Airtable, FlutterFlow, Softr, etc.)

Do not assume I am an experienced developer.
Explain no-code concepts (workflows, databases, repeating groups) in beginner-friendly language.
Do not suggest custom code unless absolutely necessary.

PRD

Category: 04. No-Code / Low-Code
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear product plan focused on visual development, features, and MVP scope.

You are a senior product manager helping a beginner no-code hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed solution
7. Product goals
8. User stories
9. Functional requirements (Include no-code specific requirements: Screens, Workflows, Data Types)
10. Non-functional requirements (Performance, Scalability, Usability)
11. Core features
12. Nice-to-have features
13. User journeys
14. MVP scope
15. Out-of-scope features
16. Success metrics (Include no-code metrics: Task completion, Time to build, User signups)
17. Risks and assumptions (Include platform limits, pricing tiers, performance caps)

Keep the MVP realistic for a 24-48 hour no-code hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.
Do not include features that require custom code unless unavoidable.

TRD

Category: 04. No-Code / Low-Code
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into platform-specific requirements, focusing on no-code capabilities and limitations.

You are a senior no-code solutions architect helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. No-code platform choice (Bubble vs Glide vs FlutterFlow vs Softr — justify the choice)
3. Database/storage requirements (Airtable, Bubble DB, Glide Tables, Supabase)
4. Screen and page requirements
5. Workflow and automation requirements
6. User authentication requirements
7. Third-party integrations (Stripe, Zapier, Make, Google Sheets)
8. Performance and latency requirements
9. Platform limits and constraints (Row limits, Workflow limits, Pricing tier)
10. Responsive design requirements
11. Testing requirements
12. Deployment/publishing requirements

Keep the no-code stack simple and realistic for a 24-48 hour hackathon.
Explain all no-code concepts in beginner-friendly language.
Do not suggest custom code unless absolutely necessary.

Phase 2: Technical Blueprint

Category: 04. No-Code / Low-Code

Welcome to Phase 2: Technical Blueprint for 04. No-Code / Low-Code. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 04. No-Code / Low-Code
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic no-code architecture with clear screens, workflows, and data flow.

Act as a senior no-code architect.
Using the following PRD and TRD, design a realistic hackathon architecture for a no-code project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended no-code platform (Bubble, Glide, FlutterFlow, etc.)
2. Frontend architecture (Pages, Screens, Reusable Components)
3. Database architecture (Tables, Relationships, Data Types)
4. Workflow architecture (Triggers, Actions, Conditions)
5. Authentication flow
6. External integrations and APIs
7. Complete user/data flow diagram (Text-based)
8. Folder/Page structure
9. Major components
10. Security considerations
11. Deployment architecture
12. Simplifications that can be made for a hackathon

Explain every decision in beginner-friendly language.
Do not introduce unnecessary platforms. Prefer a simple architecture that can be explained easily to judges.

DATABASE_SCHEMA

Category: 04. No-Code / Low-Code
Section: Phase 2: Technical Blueprint

5. DATABASE_SCHEMA.md

Purpose: To design the no-code database schema for standard CRUD operations and relationships.

Act as a senior no-code database designer.
Using the PRD and System Architecture below, design the database schema for a no-code hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Tables (Users, Core Entities, Lookup Tables)
2. Fields/Columns
3. Data types (Text, Number, Date, Boolean, Image, Reference)
4. Primary keys
5. Relationships (One-to-Many, Many-to-Many)
6. Required fields
7. Optional fields
8. Example records
9. Privacy rules (Who can see what data?)
10. A checklist for developers to verify data structure before the demo

Explain why each table exists.
Keep the database simple enough for a beginner no-code team to understand and maintain.
Avoid complex structures that are hard to debug visually.

WORKFLOW_LOGIC

Category: 04. No-Code / Low-Code
Section: Phase 2: Technical Blueprint

6. WORKFLOW_LOGIC.md

Purpose: To define all visual workflows, button actions, and automation logic in the no-code app.

You are a senior no-code workflow designer.
Using the PRD and System Architecture below, create a Workflow Logic document for this no-code hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For each core workflow, provide:
1. Workflow name
2. Trigger (Button click, Page load, Form submit, Schedule)
3. Step-by-step actions
4. Conditional logic (If/Else, Filters)
5. Data creation/update/deletion steps
6. Notifications or alerts
7. Navigation after workflow completes
8. Error handling (What if data is missing?)
9. Example user scenario
10. A checklist for developers to verify workflow logic before the demo

Explain each workflow in beginner-friendly language.
Keep the logic simple and easy to debug visually.

USER_AUTHENTICATION

Category: 04. No-Code / Low-Code
Section: Phase 2: Technical Blueprint

7. USER_AUTHENTICATION.md

Purpose: To define the platform-native authentication strategy for the no-code app.

You are a no-code authentication specialist.
Using the PRD and System Architecture below, create a User Authentication document for a no-code hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Authentication method (Email/Password, Magic Link, Social Login)
2. Platform-native auth features (Bubble, Glide, FlutterFlow)
3. Registration flow (Step-by-step)
4. Login flow (Step-by-step)
5. Password reset flow
6. Logout flow
7. Role-based access control (Admin, User, Guest)
8. Privacy rules for authenticated vs unauthenticated users
9. Session management
10. A developer checklist for implementing auth

Keep the authentication simple and native to the platform.
Explain concepts in beginner-friendly language.
Do not suggest custom authentication unless absolutely necessary.

API_SPECIFICATION

Category: 04. No-Code / Low-Code
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 04. No-Code / Low-Code.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 04. No-Code / Low-Code project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 04. No-Code / Low-Code

Welcome to Phase 3: Execution & Quality for 04. No-Code / Low-Code. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 04. No-Code / Low-Code
Section: Phase 3: Execution & Quality

8. UI_SPEC.md

Purpose: To define the frontend components and user interface for the no-code application.

Act as a senior UI/UX designer.
Using the PRD and System Architecture below, create a UI Specification document for a no-code hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (List all major components and reusable elements)
3. Screen-by-screen breakdown (Login, Dashboard, Core Feature, Settings)
4. Loading states (Skeletons, spinners)
5. Error states (How errors are displayed to the user)
6. Empty states (What the user sees before data is loaded)
7. Responsive design guidelines (Mobile and Desktop)
8. Accessibility considerations (Contrast, keyboard navigation)

Keep the UI simple, clean, and realistic for a 24-48 hour no-code hackathon.
Focus on demonstrating the core user journey.
Use platform-native components where possible.

ERROR_HANDLING

Category: 04. No-Code / Low-Code
Section: Phase 3: Execution & Quality

9. ERROR_HANDLING.md

Purpose: To define what happens when a workflow fails, data is missing, or a user inputs invalid data.

You are a senior no-code developer.
Using the System Architecture and Workflow Logic below, create an Error Handling document for a no-code hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
WORKFLOW_LOGIC: [PASTE WORKFLOW_LOGIC]

Provide:
1. Common failure modes (Missing data, Workflow errors, API failures)
2. Frontend error display (Toasts, inline errors, modals)
3. Validation errors (Empty fields, invalid formats)
4. Workflow error handling (Conditional checks before actions)
5. Fallback responses (What to show if data is missing)
6. Notification strategy (Alerts when something breaks)
7. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.
Use platform-native error handling where possible.

SECURITY

Category: 04. No-Code / Low-Code
Section: Phase 3: Execution & Quality

10. SECURITY.md

Purpose: To secure user data, API keys, and platform settings in the no-code app.

Act as a security engineer.
Using the System Architecture and Workflow Logic below, create a Security document for a no-code hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
WORKFLOW_LOGIC: [PASTE WORKFLOW_LOGIC]

Provide:
1. API key protection (Platform vault, Environment variables)
2. Authentication security (Platform-native auth best practices)
3. Input sanitization (Preventing injection through forms)
4. Data privacy (Privacy rules in the database)
5. Database security (Row-level security, permissions)
6. Access control (Who can edit the app?)
7. Privacy rules for user data (Who can see what?)
8. A pre-submission security checklist

Keep the security measures practical and native to the platform.
Easy to implement within a hackathon timeframe.

TESTING

Category: 04. No-Code / Low-Code
Section: Phase 3: Execution & Quality

11. TESTING.md

Purpose: To create a manual testing checklist for no-code features and edge cases.

Act as a QA engineer specializing in no-code applications.
Using the PRD and Workflow Logic below, create a Testing document for a no-code hackathon project.

PRD: [PASTE PRD]
WORKFLOW_LOGIC: [PASTE WORKFLOW_LOGIC]

Provide:
1. Testing strategy for no-code features
2. Screen testing (Does every screen load correctly?)
3. Workflow testing (Does every button trigger the right action?)
4. Data testing (Is data saved, updated, and deleted correctly?)
5. Authentication testing (Register, login, logout, password reset)
6. Edge cases (Empty data, Long text, Invalid inputs)
7. User acceptance testing checklist
8. A manual testing checklist for the demo
9. How to document known no-code limitations for judges

Keep the testing plan simple enough for beginner no-code developers to execute under time pressure.

EVALUATION

Category: 04. No-Code / Low-Code
Section: Phase 3: Execution & Quality

12. EVALUATION.md

Purpose: To define how the team measures no-code app performance and prepares for judge questions.

You are a no-code evaluation expert.
Using the PRD and Architecture below, create an Evaluation document for a no-code hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Evaluation metrics (Load time, Bug rate, Task completion rate, User satisfaction)
2. Evaluation methods (Manual testing, User feedback)
3. Benchmarking (What is the baseline?)
4. Known limitations of the no-code platform
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about no-code and how to answer them

Focus on demonstrating that the team understands the platform's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 04. No-Code / Low-Code

Welcome to Phase 4: Delivery & Presentation for 04. No-Code / Low-Code. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 04. No-Code / Low-Code
Section: Phase 4: Delivery & Presentation

13. DEPLOYMENT.md

Purpose: To define how to publish the no-code app, connect a custom domain, and share it with judges.

Act as a no-code deployment specialist.
Using the System Architecture and PRD below, create a Deployment document for a no-code hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Publishing approach (Bubble Live, Glide Publish, FlutterFlow Build)
2. Domain setup (Custom domain, Subdomain)
3. Environment variables and API keys for production
4. Step-by-step publishing instructions
5. How to test the published app
6. Fallback plan if publishing fails during the hackathon
7. How to share the app with judges or users
8. A pre-deployment checklist
9. Common no-code deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live URL as early as possible.

DEMO_SCRIPT

Category: 04. No-Code / Low-Code
Section: Phase 4: Delivery & Presentation

14. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the no-code app is shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
FEATURES: [PASTE CORE FEATURES]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our solution
6. How it works (Briefly mention the no-code platform)
7. Technology (Bubble, Glide, Airtable, etc.)
8. Demo (The most important part)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation

GLOSSARY

Category: 04. No-Code / Low-Code
Section: Phase 4: Delivery & Presentation

15. GLOSSARY.md

Purpose: To define all no-code terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Workflow Logic, and Architecture below, create a Glossary document for a no-code hackathon project.

PRD: [PASTE PRD]
WORKFLOW_LOGIC: [PASTE WORKFLOW_LOGIC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. No-code terms (Workflow, Repeating Group, Custom State, Data Type, Page)
2. Platform-specific terms (Bubble App, Glide Table, FlutterFlow Widget)
3. Database terms (Table, Field, Record, Reference, Privacy Rule)
4. Workflow terms (Trigger, Action, Condition, Filter)
5. Authentication terms (Magic Link, Social Login, Session)
6. Integration terms (API Connector, Webhook, Zapier)
7. Project-specific terms (Any custom terminology used in the PRD)
8. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

**Made by Siddiq

*Credit: Hackathon Alechemy

🔗 Link to Hackathon Alechemy

05. Data & Analytics

Data processing, warehousing, analytical pipelines, ETL, and interactive dashboards.

Overview

This category provides structured prompt packs tailored for 05. Data & Analytics projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 05. Data & Analytics

Welcome to Phase 1: Problem Definition for 05. Data & Analytics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 05. Data & Analytics
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem and identify what data is needed to solve it.

I am participating in a data & analytics hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed data & analytics solution ideas
7. Core analytics features (Dashboards, Reports, KPIs)
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential data sources and tools that could be used (CSV, APIs, SQL, Python, Power BI, etc.)

Do not assume I am an experienced data scientist.
Explain data concepts (ETL, KPI, Data Cleaning) in beginner-friendly language.

PRD

Category: 05. Data & Analytics
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear data product plan with dashboards, KPIs, and scope.

You are a senior data product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed analytics solution
7. Product goals
8. User stories
9. Functional requirements (Include data-specific requirements: Data ingestion, Cleaning, Transformation, Visualization)
10. Non-functional requirements (Data freshness, Query speed, Accuracy)
11. Core analytics features (Dashboards, Reports, KPIs)
12. Nice-to-have features
13. User journeys (How a user interacts with the data)
14. MVP scope (Which dashboard must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include data metrics: Data accuracy, Insight quality, Time to insight)
17. Risks and assumptions (Include data risks: Missing data, Dirty data, API limits)

Keep the MVP realistic for a 24-48 hour data hackathon.
Do not add unnecessary dashboards just to make the project sound impressive.
Prioritize insights that can actually be demonstrated live.

TRD

Category: 05. Data & Analytics
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on data stack, sources, and processing.

You are a senior data engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Data stack choice (Python, SQL, Power BI, Streamlit, etc. — justify the choice)
3. Data sources (CSV, APIs, Databases, Web scraping)
4. Data ingestion requirements (Batch vs Streaming)
5. Data cleaning and transformation requirements
6. Data storage requirements (SQL, NoSQL, Data Warehouse, CSV)
7. Visualization and dashboard requirements
8. Performance and query speed requirements
9. Data privacy and security requirements
10. Data refresh and scheduling requirements
11. Testing requirements
12. Deployment requirements

Keep the data stack simple and realistic for a 24-48 hour hackathon.
Explain all data concepts in beginner-friendly language.

Phase 2: Technical Blueprint

Category: 05. Data & Analytics

Welcome to Phase 2: Technical Blueprint for 05. Data & Analytics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic data pipeline architecture with clear data flow from source to visualization.

Act as a senior data architect.
Using the following PRD and TRD, design a realistic hackathon data architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended data stack (Python, SQL, Power BI, Streamlit, etc.)
2. Complete data pipeline diagram (Text-based, showing Source → Ingestion → Storage → Transformation → Visualization)
3. Data ingestion architecture (How data enters the system)
4. Data storage architecture (Where data is stored)
5. Data transformation architecture (How data is cleaned and processed)
6. Visualization architecture (Dashboards, Charts, KPIs)
7. External data sources and APIs
8. Data refresh and scheduling approach
9. Security and privacy considerations
10. Folder/Project structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.

DATA_MODEL

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint

5. DATA_MODEL.md

Purpose: To define the data tables, fields, relationships, and data dictionary.

Act as a senior data modeler.
Using the PRD and System Architecture below, design the data model for a data & analytics hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Tables/Datasets (Fact tables, Dimension tables, Lookup tables)
2. Columns/Fields
3. Data types (Integer, String, Date, Boolean, Float)
4. Primary keys
5. Foreign keys
6. Relationships (One-to-Many, Many-to-Many)
7. Required fields
8. Optional fields
9. Data dictionary (What each field means)
10. Example records
11. Data quality rules (Nulls, Duplicates, Outliers)

Explain why each table exists.
Keep the data model simple enough for a beginner hackathon team to understand and maintain.

DATA_PIPELINE

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint

6. DATA_PIPELINE.md

Purpose: To define the ETL/ELT process, data cleaning, and transformation logic.

You are a senior data engineer.
Using the PRD, Architecture, and Data Model below, create a Data Pipeline document for a data & analytics hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATA_MODEL: [PASTE DATA_MODEL]

Provide:
1. Data sources (Where data comes from)
2. Ingestion method (Batch, Streaming, API pull, CSV upload)
3. Data cleaning steps (Handling nulls, duplicates, outliers)
4. Data transformation steps (Aggregations, Joins, Calculations)
5. Data validation rules (How to check if data is correct)
6. Data loading steps (Where cleaned data is stored)
7. Scheduling and refresh frequency
8. Error handling in the pipeline (What if data fails to load?)
9. Tools and libraries used (Pandas, SQL, Airflow, etc.)
10. A checklist for developers to verify the pipeline before the demo

Keep the pipeline simple and realistic for a hackathon.
Explain each step in beginner-friendly language.

DATA_GOVERNANCE

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint

7. DATA_GOVERNANCE.md

Purpose: To define data privacy, access control, and compliance rules.

Act as a data governance specialist.
Using the PRD and Data Model below, create a Data Governance document for a data & analytics hackathon project.

PRD: [PASTE PRD]
DATA_MODEL: [PASTE DATA_MODEL]

Provide:
1. Data ownership (Who owns the data?)
2. Data privacy rules (What data can be shown publicly?)
3. PII handling (How to handle personally identifiable information)
4. Access control (Who can view, edit, or delete data?)
5. Data retention policy (How long is data stored?)
6. Compliance considerations (GDPR, HIPAA if applicable)
7. Data anonymization techniques (If needed)
8. A pre-submission data governance checklist

Keep the governance simple but responsible enough for a hackathon.
Explain concepts in beginner-friendly language.

DATABASE_SCHEMA

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 05. Data & Analytics.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 05. Data & Analytics project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 05. Data & Analytics
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 05. Data & Analytics.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 05. Data & Analytics project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 05. Data & Analytics

Welcome to Phase 3: Execution & Quality for 05. Data & Analytics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DASHBOARD_SPEC

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality

8. DASHBOARD_SPEC.md

Purpose: To define the dashboard layout, charts, KPIs, and user flow for the analytics interface.

Act as a senior data visualization designer.
Using the PRD and System Architecture below, create a Dashboard Specification document for a data & analytics hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, chart styles)
2. Dashboard layout (Grid, Sections, Hierarchy)
3. Key Performance Indicators (KPIs) to display
4. Chart types for each insight (Bar, Line, Pie, Heatmap, Map)
5. Filters and interactivity (Date range, Category, Search)
6. Screen-by-screen breakdown (Overview, Detail, Comparison)
7. Loading states (Skeletons, spinners)
8. Error states (What if data fails to load?)
9. Empty states (What if no data is available?)
10. Responsive design guidelines (Desktop and Mobile)
11. Accessibility considerations (Color blindness, Contrast)

Keep the dashboard simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core insights.

ERROR_HANDLING

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality

9. ERROR_HANDLING.md

Purpose: To define what happens when data is missing, APIs fail, or queries time out.

You are a senior data engineer.
Using the System Architecture and Data Pipeline document below, create an Error Handling document for a data & analytics hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATA_PIPELINE: [PASTE DATA_PIPELINE]

Provide:
1. Common failure modes (Missing data, API failures, Query timeouts, Data type errors)
2. Data validation errors (Nulls, Duplicates, Outliers)
3. Dashboard error display (Toasts, inline errors, fallback charts)
4. Retry logic for data ingestion
5. Fallback responses (What to show if data is unavailable)
6. Notification strategy (Alerts when data fails to load)
7. Error logging (Where errors are stored)
8. A checklist for developers to verify error handling before the demo

Focus on making the dashboard resilient so the live demo does not crash.

SECURITY

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality

10. SECURITY.md

Purpose: To secure data, API keys, and user access in the analytics project.

Act as a security engineer.
Using the System Architecture and Data Model below, create a Security document for a data & analytics hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATA_MODEL: [PASTE DATA_MODEL]

Provide:
1. API key protection (Environment variables, Secret management)
2. Data privacy (PII handling, Anonymization)
3. Access control (Who can view or edit data?)
4. Database security (Row-level security, permissions)
5. Input sanitization (Preventing SQL injection)
6. Secure data transmission (HTTPS, Encryption)
7. Logging and monitoring for suspicious activity
8. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.

TESTING

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality

11. TESTING.md

Purpose: To create a manual testing checklist for data quality, dashboards, and edge cases.

Act as a QA engineer specializing in data & analytics.
Using the PRD and Data Pipeline document below, create a Testing document for a data & analytics hackathon project.

PRD: [PASTE PRD]
DATA_PIPELINE: [PASTE DATA_PIPELINE]

Provide:
1. Testing strategy for data quality
2. Data validation testing (Nulls, Duplicates, Outliers)
3. ETL testing (Does data transform correctly?)
4. Dashboard testing (Do charts load correctly?)
5. Filter and interactivity testing
6. Edge cases (Empty data, Large datasets, Missing fields)
7. User acceptance testing checklist
8. A manual testing checklist for the demo
9. How to document known data limitations for judges

Keep the testing plan simple enough for beginner data analysts to execute under time pressure.

EVALUATION

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality

12. EVALUATION.md

Purpose: To define how the team measures analytics performance and prepares for judge questions.

You are a data evaluation expert.
Using the PRD and Architecture below, create an Evaluation document for a data & analytics hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Evaluation metrics (Data accuracy, Insight quality, Query speed, Load time)
2. Evaluation methods (Manual validation, Benchmarking, User feedback)
3. Benchmarking (What is the baseline?)
4. Known limitations of the data or analysis
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about data & analytics and how to answer them

Focus on demonstrating that the team understands the data's capabilities and boundaries.

UI_SPEC

Category: 05. Data & Analytics
Section: Phase 3: Execution & Quality
Status: Standard Framework Specification

Overview

This document defines the prompt template for UI_SPEC in 05. Data & Analytics.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 05. Data & Analytics project.
Generate the UI_SPEC covering all essential requirements, architectures, schemas, or procedures.

Phase 4: Delivery & Presentation

Category: 05. Data & Analytics

Welcome to Phase 4: Delivery & Presentation for 05. Data & Analytics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 05. Data & Analytics
Section: Phase 4: Delivery & Presentation

13. DEPLOYMENT.md

Purpose: To define how to deploy the dashboard, database, and scheduled jobs for the live demo.

Act as a DevOps engineer.
Using the System Architecture and Data Pipeline document below, create a Deployment document for a data & analytics hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATA_PIPELINE: [PASTE DATA_PIPELINE]

Provide:
1. Deployment platforms (Streamlit Cloud, Vercel, Power BI Service, Render)
2. Database hosting (Supabase, PostgreSQL, MongoDB Atlas)
3. Environment variables for production
4. Step-by-step deployment instructions for each component
5. How to test the deployed dashboard
6. Scheduled jobs and data refresh in production
7. Fallback plan if deployment fails during the hackathon
8. A pre-deployment checklist
9. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live dashboard as early as possible.

DEMO_SCRIPT

Category: 05. Data & Analytics
Section: Phase 4: Delivery & Presentation

14. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the insights are shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
INSIGHTS: [PASTE KEY INSIGHTS]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our data solution
6. How it works (Data pipeline and dashboard briefly)
7. Technology (Python, SQL, Power BI, Streamlit)
8. Demo (The most important part — show the insights)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation

GLOSSARY

Category: 05. Data & Analytics
Section: Phase 4: Delivery & Presentation

15. GLOSSARY.md

Purpose: To define all data terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Data Pipeline, and Architecture below, create a Glossary document for a data & analytics hackathon project.

PRD: [PASTE PRD]
DATA_PIPELINE: [PASTE DATA_PIPELINE]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Data terms (ETL, ELT, Data Warehouse, Data Lake, Dataset, Schema)
2. Analytics terms (KPI, Metric, Dimension, Fact Table, Aggregation)
3. Visualization terms (Dashboard, Chart, Filter, Drill-down)
4. Data quality terms (Null, Duplicate, Outlier, Data Cleaning)
5. Tool-specific terms (Pandas, SQL, Power BI, Streamlit, Plotly)
6. Project-specific terms (Any custom terminology used in the PRD)
7. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank you for using this guide. Go build something amazing!

**Made by Siddiq

*Credit: Hackathon Alechemy

🔗 Link to Hackathon Alechemy

06. Web3 / Blockchain

Decentralized applications, smart contracts, wallet integrations, and tokenomics.

Overview

This category provides structured prompt packs tailored for 06. Web3 / Blockchain projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 06. Web3 / Blockchain

Welcome to Phase 1: Problem Definition for 06. Web3 / Blockchain. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 06. Web3 / Blockchain
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem and identify what can be solved through decentralization.

I am participating in a Web3/Blockchain hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem (Centralized solutions)
5. Limitations of existing centralized solutions
6. Proposed Web3/Blockchain solution ideas
7. Core dApp features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential blockchain platforms and tools that could be used (Ethereum, Polygon, Solana, Hardhat, etc.)

Do not assume I am an experienced blockchain developer.
Explain Web3 concepts (wallets, smart contracts, gas, testnet) in beginner-friendly language.

PRD

Category: 06. Web3 / Blockchain
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear dApp plan with smart contracts, wallets, and scope.

You are a senior Web3 product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed Web3 solution
7. Product goals
8. User stories
9. Functional requirements (Include Web3-specific requirements: Wallet connection, Smart contract calls, Transaction signing, Token logic)
10. Non-functional requirements (Gas efficiency, Transaction speed, Decentralization)
11. Core dApp features
12. Nice-to-have features
13. User journeys (Connect Wallet → Interact → Sign Transaction → Confirmation)
14. MVP scope (Which smart contract must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include Web3 metrics: Transactions completed, Gas cost per action, Unique wallets)
17. Risks and assumptions (Include Web3 risks: Network congestion, Gas spikes, Testnet downtime)

Keep the MVP realistic for a 24-48 hour Web3 hackathon.
Do not add unnecessary contracts just to make the project sound impressive.
Prioritize features that can actually be demonstrated live on a testnet.

TRD

Category: 06. Web3 / Blockchain
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on blockchain choice, smart contracts, and wallet integration.

You are a senior blockchain engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Blockchain platform choice (Ethereum, Polygon, Solana, Base — justify the choice)
3. Smart contract language and framework (Solidity + Hardhat/Foundry)
4. Contract architecture (Contracts, Inheritance, Libraries)
5. Wallet integration requirements (MetaMask, WalletConnect, Coinbase Wallet)
6. Token requirements (ERC-20, ERC-721, ERC-1155 — if applicable)
7. Storage requirements (On-chain vs IPFS vs The Graph)
8. Gas and performance requirements
9. Security requirements (Reentrancy, Access control, Overflow)
10. Frontend library requirements (Ethers.js, Wagmi, Viem, Web3.js)
11. Testing requirements (Unit tests, Testnet deployment)
12. Deployment requirements

Keep the blockchain stack simple and realistic for a 24-48 hour hackathon.
Explain all Web3 concepts in beginner-friendly language.
Do not introduce unnecessary chains or tools.

Phase 2: Technical Blueprint

Category: 06. Web3 / Blockchain

Welcome to Phase 2: Technical Blueprint for 06. Web3 / Blockchain. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic dApp architecture with clear data flow from frontend to blockchain.

Act as a senior blockchain architect.
Using the following PRD and TRD, design a realistic hackathon dApp architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended blockchain stack (Chain, Language, Framework)
2. Complete dApp architecture diagram (Text-based, showing User → Wallet → Frontend → Smart Contract → Blockchain)
3. Frontend architecture (React, Next.js, Wallet connect)
4. Smart contract architecture (Contracts, Functions, Events)
5. Wallet integration architecture (Connection, Network switch, Signing)
6. Storage architecture (On-chain, IPFS, The Graph)
7. Token architecture (If applicable)
8. Data flow (How a user action becomes a transaction)
9. Security considerations (Reentrancy, Access control)
10. Folder structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.

SMART_CONTRACT_SPEC

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint

5. SMART_CONTRACT_SPEC.md

Purpose: To define the exact smart contract functions, state variables, events, and modifiers.

Act as a senior smart contract engineer.
Using the PRD and System Architecture below, design the smart contract specification for this Web3 hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For each smart contract, provide:
1. Contract name
2. Purpose of the contract
3. State variables (Name, Type, Visibility)
4. Functions (Name, Parameters, Visibility, Modifiers)
5. Events (Name, Parameters)
6. Modifiers (Access control, Validation)
7. Inheritance (If any)
8. External dependencies (Oracles, Other contracts)
9. Token standard (ERC-20, ERC-721, ERC-1155 — if applicable)
10. Example function calls
11. Gas estimate per function (Rough)
12. Access control rules (Who can call what?)

Explain why each function exists.
Keep the contract simple enough for a beginner hackathon team to understand and maintain.

WALLET_INTEGRATION

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint

6. WALLET_INTEGRATION.md

Purpose: To define wallet connection, network switching, and transaction signing.

You are a senior Web3 frontend engineer.
Using the PRD and System Architecture below, create a Wallet Integration document for this Web3 hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Supported wallets (MetaMask, WalletConnect, Coinbase Wallet)
2. Wallet connection flow (Step-by-step)
3. Network detection and switching (Mainnet, Testnet)
4. Account change handling
5. Transaction signing flow (Step-by-step)
6. Reading data from the blockchain (Read-only calls)
7. Writing data to the blockchain (Transactions)
8. Listening to events (Contract events)
9. Error handling (User rejects, Network mismatch)
10. Frontend library choice (Ethers.js, Wagmi, Viem)
11. Example code snippets for connection and signing
12. A checklist for developers to verify wallet integration before the demo

Keep the integration simple and realistic for a hackathon.
Explain each step in beginner-friendly language.

TOKENOMICS

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint

7. TOKENOMICS.md

Purpose: To define token supply, distribution, utility, and incentives (if applicable).

Act as a tokenomics expert.
Using the PRD and Smart Contract Specification below, create a Tokenomics document for this Web3 hackathon project.

PRD: [PASTE PRD]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]

Provide:
1. Token name and symbol
2. Token standard (ERC-20, ERC-721, ERC-1155)
3. Total supply
4. Distribution (Team, Users, Liquidity, Rewards)
5. Utility (What can the token be used for?)
6. Minting and burning rules
7. Transfer rules
8. Incentive mechanisms (Staking, Rewards, Governance)
9. Vesting schedule (If applicable)
10. Contract functions related to the token
11. A checklist for developers to verify token logic before the demo

If the project does not require a token, explain why and suggest alternative incentive mechanisms.
Keep the tokenomics simple and realistic for a hackathon.
Explain concepts in beginner-friendly language.

GAS_OPTIMIZATION

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint

8. GAS_OPTIMIZATION.md

Purpose: To define gas estimation, optimization strategies, and cost limits.

You are a senior smart contract optimization expert.
Using the Smart Contract Specification and System Architecture below, create a Gas Optimization document for this Web3 hackathon project.

SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Gas estimation per function (Read and Write)
2. Gas optimization techniques used (Packing variables, Avoiding loops, Using events instead of storage)
3. Storage vs Memory vs Calldata usage
4. Efficient data structures
5. Batch operations (If applicable)
6. Gas cost comparison (Before vs After optimization)
7. Gas limits for the demo
8. Fallback if gas spikes during the demo
9. Tools used for gas analysis (Hardhat Gas Reporter, Etherscan)
10. A checklist for developers to verify gas optimization before the demo

Explain each optimization in beginner-friendly language.
Keep the optimizations simple and achievable within a hackathon timeframe.

DATABASE_SCHEMA

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 06. Web3 / Blockchain.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 06. Web3 / Blockchain project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 06. Web3 / Blockchain
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 06. Web3 / Blockchain.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 06. Web3 / Blockchain project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 06. Web3 / Blockchain

Welcome to Phase 3: Execution & Quality for 06. Web3 / Blockchain. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 06. Web3 / Blockchain
Section: Phase 3: Execution & Quality

9. UI_SPEC.md

Purpose: To define the frontend components, wallet connection UI, and transaction states.

Act as a senior UI/UX designer specializing in Web3.
Using the PRD and System Architecture below, create a UI Specification document for a Web3 hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (Wallet button, Transaction modal, Contract interaction forms)
3. Screen-by-screen breakdown (Landing, Connect Wallet, Dashboard, Transaction History)
4. Wallet connection states (Disconnected, Connecting, Connected, Wrong Network)
5. Transaction states (Pending, Success, Failed)
6. Loading states (Skeletons, spinners)
7. Error states (Transaction failed, User rejected)
8. Empty states (No transactions yet)
9. Responsive design guidelines (Mobile and Desktop)
10. Accessibility considerations (Contrast, keyboard navigation)

Keep the UI simple, clean, and realistic for a 24-48 hour Web3 hackathon.
Focus on demonstrating the core dApp journey.

ERROR_HANDLING

Category: 06. Web3 / Blockchain
Section: Phase 3: Execution & Quality

10. ERROR_HANDLING.md

Purpose: To define what happens when a transaction fails, gas is too low, or the wallet disconnects.

You are a senior Web3 developer.
Using the System Architecture and Wallet Integration document below, create an Error Handling document for a Web3 hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
WALLET_INTEGRATION: [PASTE WALLET_INTEGRATION]

Provide:
1. Common failure modes (User rejects transaction, Insufficient gas, Network congestion, Contract revert)
2. Frontend error display (Toasts, inline errors, modals)
3. Transaction error handling (Revert reasons, Gas estimation errors)
4. Wallet error handling (Disconnected wallet, Wrong network)
5. Contract error handling (Require statements, Custom errors)
6. Fallback responses (What to show if the transaction fails)
7. Retry logic (If applicable)
8. A checklist for developers to verify error handling before the demo

Focus on making the dApp resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 06. Web3 / Blockchain
Section: Phase 3: Execution & Quality

11. SECURITY.md

Purpose: To secure smart contracts, wallets, and user data against common Web3 attacks.

Act as a smart contract security auditor.
Using the Smart Contract Specification and System Architecture below, create a Security document for a Web3 hackathon project.

SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Reentrancy protection (Checks-Effects-Interactions pattern)
2. Integer overflow/underflow protection (SafeMath, Solidity 0.8+)
3. Access control (Ownable, Roles, Modifiers)
4. Front-running protection (If applicable)
5. Oracle manipulation protection (If applicable)
6. Private key safety (Never commit private keys)
7. Environment variable protection (.env, .gitignore)
8. Wallet security best practices for users
9. Audit checklist before deployment
10. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each vulnerability and mitigation in beginner-friendly language.

TESTING

Category: 06. Web3 / Blockchain
Section: Phase 3: Execution & Quality

12. TESTING.md

Purpose: To create a manual testing checklist for smart contracts, wallet integration, and edge cases.

Act as a QA engineer specializing in Web3 applications.
Using the PRD and Smart Contract Specification below, create a Testing document for a Web3 hackathon project.

PRD: [PASTE PRD]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]

Provide:
1. Testing strategy for smart contracts
2. Unit testing (Hardhat/Foundry tests for each function)
3. Integration testing (Frontend + Contract)
4. Wallet testing (Connect, Disconnect, Network switch, Sign)
5. Transaction testing (Success, Failure, Revert)
6. Edge cases (Zero values, Large values, Unauthorized access)
7. Testnet deployment testing
8. User acceptance testing checklist
9. A manual testing checklist for the demo
10. How to document known limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Include example test cases for each core function.

EVALUATION

Category: 06. Web3 / Blockchain
Section: Phase 3: Execution & Quality

13. EVALUATION.md

Purpose: To define how the team measures dApp performance and prepares for judge questions.

You are a Web3 evaluation expert.
Using the PRD and Smart Contract Specification below, create an Evaluation document for a Web3 hackathon project.

PRD: [PASTE PRD]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]

Provide:
1. Evaluation metrics (Gas cost per transaction, Transaction speed, Number of unique wallets, Contract security)
2. Evaluation methods (Testnet testing, Gas analysis, User feedback)
3. Benchmarking (What is the baseline?)
4. Known limitations of the dApp or blockchain
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about Web3 and how to answer them

Focus on demonstrating that the team understands the dApp's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 06. Web3 / Blockchain

Welcome to Phase 4: Delivery & Presentation for 06. Web3 / Blockchain. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 06. Web3 / Blockchain
Section: Phase 4: Delivery & Presentation

14. DEPLOYMENT.md

Purpose: To define how to deploy smart contracts to testnet/mainnet and host the frontend.

Act as a Web3 DevOps engineer.
Using the System Architecture and Smart Contract Specification below, create a Deployment document for a Web3 hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]

Provide:
1. Blockchain network for deployment (Testnet: Sepolia, Goerli, Mumbai, Devnet)
2. Smart contract deployment steps (Hardhat/Foundry commands)
3. Contract verification (Etherscan, Polygonscan)
4. Frontend hosting (Vercel, Netlify)
5. Environment variables for production (RPC URLs, Contract addresses, API keys)
6. Wallet setup for deployment (Deployer wallet, Private key safety)
7. How to test the deployed dApp
8. Fallback plan if deployment fails during the hackathon
9. A pre-deployment checklist
10. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working dApp on testnet as early as possible.

DEMO_SCRIPT

Category: 06. Web3 / Blockchain
Section: Phase 4: Delivery & Presentation

15. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the dApp is shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations (Centralized solutions)
5. Our Web3 solution
6. How it works (Wallet → Contract → Blockchain)
7. Technology (Ethereum, Solidity, Hardhat, Ethers.js)
8. Demo (The most important part — show a live transaction)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation

GLOSSARY

Category: 06. Web3 / Blockchain
Section: Phase 4: Delivery & Presentation

16. GLOSSARY.md

Purpose: To define all Web3 terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Smart Contract Specification, and Architecture below, create a Glossary document for a Web3 hackathon project.

PRD: [PASTE PRD]
SMART_CONTRACT_SPEC: [PASTE SMART_CONTRACT_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Blockchain terms (Block, Transaction, Gas, Testnet, Mainnet, Consensus)
2. Smart contract terms (Solidity, Function, Modifier, Event, Revert, State Variable)
3. Wallet terms (MetaMask, WalletConnect, Private Key, Public Address, Seed Phrase)
4. Token terms (ERC-20, ERC-721, ERC-1155, Mint, Burn, Staking)
5. Web3 frontend terms (Ethers.js, Wagmi, Viem, RPC, ABI)
6. Security terms (Reentrancy, Overflow, Access Control, Audit)
7. Project-specific terms (Any custom terminology used in the PRD)
8. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

07. IoT / Hardware / Robotics

Physical computing, embedded microcontrollers, sensors, firmware, and telemetry.

Overview

This category provides structured prompt packs tailored for 07. IoT / Hardware / Robotics projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 07. IoT / Hardware / Robotics

Welcome to Phase 1: Problem Definition for 07. IoT / Hardware / Robotics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 07. IoT / Hardware / Robotics
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem and identify what can be solved through hardware, sensors, or robotics.

I am participating in an IoT/Hardware/Robotics hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed hardware/IoT/robotics solution ideas
7. Core hardware features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential hardware platforms and tools that could be used (Arduino, Raspberry Pi, ESP32, Jetson Nano, etc.)

Do not assume I am an experienced hardware engineer.
Explain hardware concepts (GPIO, sensors, actuators, microcontrollers) in beginner-friendly language.

PRD

Category: 07. IoT / Hardware / Robotics
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear hardware product plan with features, sensors, and scope.

You are a senior hardware product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed hardware solution
7. Product goals
8. User stories
9. Functional requirements (Include hardware-specific requirements: Sensors, Actuators, Connectivity, Power)
10. Non-functional requirements (Reliability, Latency, Power efficiency, Durability)
11. Core hardware features
12. Nice-to-have features
13. User journeys (How a user interacts with the device)
14. MVP scope (Which hardware feature must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include hardware metrics: Sensor accuracy, Response time, Battery life)
17. Risks and assumptions (Include hardware risks: Component failure, Power loss, Connectivity issues)

Keep the MVP realistic for a 24-48 hour hardware hackathon.
Do not add unnecessary sensors just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.

TRD

Category: 07. IoT / Hardware / Robotics
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on hardware, sensors, and connectivity.

You are a senior hardware engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Hardware platform choice (Arduino, Raspberry Pi, ESP32, Jetson Nano — justify the choice)
3. Microcontroller/Processor requirements
4. Sensor requirements (Type, Model, Purpose, Interface)
5. Actuator requirements (Motors, Servos, Relays, LEDs)
6. Connectivity requirements (WiFi, Bluetooth, MQTT, LoRa, Zigbee)
7. Power requirements (Battery, USB, Solar)
8. Firmware language and framework (C++, MicroPython, Arduino IDE)
9. Cloud/IoT platform requirements (AWS IoT, Blynk, ThingSpeak, Firebase)
10. Enclosure and physical design requirements
11. Testing requirements (Sensor calibration, Range testing)
12. Deployment requirements

Keep the hardware stack simple and realistic for a 24-48 hour hackathon.
Explain all hardware concepts in beginner-friendly language.
Do not introduce unnecessary components.

Phase 2: Technical Blueprint

Category: 07. IoT / Hardware / Robotics

Welcome to Phase 2: Technical Blueprint for 07. IoT / Hardware / Robotics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic IoT architecture with clear data flow from sensor to user.

Act as a senior IoT architect.
Using the following PRD and TRD, design a realistic hackathon IoT architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended hardware stack (Microcontroller, Sensors, Actuators)
2. Complete IoT architecture diagram (Text-based, showing Device → Sensor → Gateway → Cloud → Dashboard/App)
3. Device architecture (Microcontroller, Peripherals)
4. Sensor architecture (Inputs)
5. Actuator architecture (Outputs)
6. Connectivity architecture (How data travels)
7. Cloud/IoT platform architecture (Where data is stored)
8. User interface architecture (Dashboard, Mobile App, Alerts)
9. Data flow (How a sensor reading becomes a user notification)
10. Power architecture (How the device is powered)
11. Security considerations
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary components. Prefer a simple architecture that can be explained easily to judges.

HARDWARE_SCHEMATIC

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

5. HARDWARE_SCHEMATIC.md

Purpose: To define components, pin mappings, wiring diagram, and power requirements.

Act as a senior hardware engineer.
Using the PRD and System Architecture below, design the hardware schematic for this IoT hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Bill of Materials (BOM) — All components with quantities
2. Microcontroller pin mapping (Which pin connects to what)
3. Wiring diagram (Text-based, showing connections)
4. Power distribution (Voltage, Current, Regulators)
5. Sensor connections (I2C, SPI, Analog, Digital)
6. Actuator connections (PWM, Digital, Relay)
7. Communication module connections (WiFi, Bluetooth, LoRa)
8. Grounding and noise considerations
9. Physical layout suggestions
10. A checklist for verifying hardware connections before powering on

Explain why each component is needed.
Keep the hardware simple enough for a beginner hackathon team to assemble and debug.

SENSOR_SPEC

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

6. SENSOR_SPEC.md

Purpose: To define each sensor's purpose, data format, calibration, and sampling rate.

You are a senior IoT sensor specialist.
Using the PRD and Hardware Schematic below, create a Sensor Specification document for this IoT hackathon project.

PRD: [PASTE PRD]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]

For each sensor, provide:
1. Sensor name and model
2. Purpose in the project
3. Interface (I2C, SPI, Analog, Digital, UART)
4. Operating voltage
5. Data format (Raw values, Units)
6. Sampling rate (How often data is read)
7. Accuracy and range
8. Calibration requirements
9. Library or driver needed (Arduino library, Python library)
10. Example reading
11. Common issues and troubleshooting tips

Explain each sensor in beginner-friendly language.
Keep the sensor setup simple and realistic for a hackathon.

FIRMWARE_RULES

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

7. FIRMWARE_RULES.md

Purpose: To define the firmware logic, loops, interrupts, and state machines.

Act as a senior embedded systems engineer.
Using the PRD and Hardware Schematic below, create the Firmware Rules document for this IoT hackathon project.

PRD: [PASTE PRD]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]

Provide:
1. Firmware architecture (Setup, Loop, Interrupts)
2. State machine design (States, Transitions)
3. Sensor reading logic (When and how to read)
4. Actuator control logic (When and how to activate)
5. Communication logic (When to send data)
6. Timing and scheduling (Delays, Timers, Non-blocking code)
7. Interrupt handling (If applicable)
8. Error handling in firmware (Sensor failure, Connection loss)
9. Power-saving logic (Sleep modes, Duty cycling)
10. A checklist for developers to verify firmware before the demo

Explain each logic rule in beginner-friendly language.
Keep the firmware simple and easy to debug.

CONNECTIVITY_PROTOCOL

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

8. CONNECTIVITY_PROTOCOL.md

Purpose: To define WiFi, Bluetooth, MQTT, LoRa, Zigbee, or HTTP communication.

You are a senior IoT connectivity engineer.
Using the PRD and System Architecture below, create a Connectivity Protocol document for this IoT hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Connectivity method (WiFi, Bluetooth, LoRa, Zigbee, Cellular)
2. Protocol choice (MQTT, HTTP, WebSocket, CoAP)
3. Justification for the choice
4. Network configuration (SSID, Password, Broker URL)
5. Data format (JSON, CSV, Binary)
6. Publish/Subscribe topics (If using MQTT)
7. Data transmission frequency
8. Payload size and optimization
9. Connection recovery (Reconnect logic)
10. Security (TLS, Authentication)
11. Example data packet
12. A checklist for developers to verify connectivity before the demo

Explain each connectivity concept in beginner-friendly language.
Keep the connectivity simple and reliable for a hackathon demo.

POWER_MANAGEMENT

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint

9. POWER_MANAGEMENT.md

Purpose: To define power source, battery life, and energy optimization.

Act as a power systems engineer.
Using the Hardware Schematic and Firmware Rules below, create a Power Management document for this IoT hackathon project.

HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]
FIRMWARE_RULES: [PASTE FIRMWARE_RULES]

Provide:
1. Power source (USB, Battery, Solar, DC Adapter)
2. Voltage and current requirements per component
3. Total power consumption estimate
4. Battery capacity and expected runtime
5. Power regulators and converters (Buck, Boost, LDO)
6. Power-saving techniques (Sleep modes, Duty cycling, Peripheral shutdown)
7. Power monitoring (If applicable)
8. Safety considerations (Overvoltage, Short circuit)
9. Fallback if power runs out during the demo
10. A checklist for developers to verify power before the demo

Explain each concept in beginner-friendly language.
Keep the power management simple and realistic for a hackathon.

DATABASE_SCHEMA

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 07. IoT / Hardware / Robotics.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 07. IoT / Hardware / Robotics project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 07. IoT / Hardware / Robotics
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 07. IoT / Hardware / Robotics.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 07. IoT / Hardware / Robotics project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 07. IoT / Hardware / Robotics

Welcome to Phase 3: Execution & Quality for 07. IoT / Hardware / Robotics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 07. IoT / Hardware / Robotics
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define the dashboard or mobile app design, device status, and user flow.

Act as a senior UI/UX designer specializing in IoT dashboards.
Using the PRD and System Architecture below, create a UI Specification document for an IoT hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (Device status card, Sensor readings, Charts, Alerts)
3. Screen-by-screen breakdown (Dashboard, Device Detail, Alerts, Settings)
4. Real-time data display (Live sensor values, Gauges, Charts)
5. Device connection states (Online, Offline, Connecting)
6. Loading states (Skeletons, spinners)
7. Error states (Device offline, Sensor failure)
8. Empty states (No data yet)
9. Responsive design guidelines (Mobile and Desktop)
10. Accessibility considerations (Contrast, keyboard navigation)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core device interaction and data flow.

ERROR_HANDLING

Category: 07. IoT / Hardware / Robotics
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when a sensor fails, connection drops, or power is lost.

You are a senior embedded systems engineer.
Using the Hardware Schematic and Firmware Rules below, create an Error Handling document for an IoT hackathon project.

HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]
FIRMWARE_RULES: [PASTE FIRMWARE_RULES]

Provide:
1. Common failure modes (Sensor failure, Connection loss, Power loss, Component overheating)
2. Firmware-level error handling (Fallback values, Safe states)
3. Sensor error handling (Out-of-range values, No reading)
4. Connectivity error handling (Reconnect logic, Offline buffering)
5. Actuator error handling (Safe shutdown)
6. User notification (LEDs, Buzzer, Dashboard alerts)
7. Logging errors (Serial monitor, Cloud logs)
8. Recovery procedures (Auto-restart, Manual reset)
9. A checklist for developers to verify error handling before the demo

Focus on making the device resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 07. IoT / Hardware / Robotics
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To secure device authentication, data encryption, and firmware protection.

Act as an IoT security engineer.
Using the System Architecture and Connectivity Protocol document below, create a Security document for an IoT hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
CONNECTIVITY_PROTOCOL: [PASTE CONNECTIVITY_PROTOCOL]

Provide:
1. Device authentication (Certificates, API keys, Tokens)
2. Data encryption (TLS, AES)
3. Secure boot and firmware protection (If applicable)
4. Network security (WiFi security, Firewall)
5. Cloud security (API key storage, Access control)
6. User data privacy (What data is collected?)
7. Physical security (Tamper detection, Enclosure)
8. OTA update security (If applicable)
9. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.

TESTING

Category: 07. IoT / Hardware / Robotics
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for hardware, sensors, and edge cases.

Act as a QA engineer specializing in IoT and hardware.
Using the PRD and Hardware Schematic below, create a Testing document for an IoT hackathon project.

PRD: [PASTE PRD]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]

Provide:
1. Testing strategy for hardware
2. Component testing (Does each sensor/actuator work individually?)
3. Integration testing (Do components work together?)
4. Sensor calibration testing
5. Connectivity testing (Range, Stability, Reconnect)
6. Firmware testing (Logic, Timing, State transitions)
7. Power testing (Battery life, Voltage stability)
8. Edge cases (Sensor failure, Disconnection, Low power)
9. User acceptance testing checklist
10. A manual testing checklist for the demo
11. How to document known hardware limitations for judges

Keep the testing plan simple enough for beginner hardware developers to execute under time pressure.

EVALUATION

Category: 07. IoT / Hardware / Robotics
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures device performance and prepares for judge questions.

You are an IoT evaluation expert.
Using the PRD and Hardware Schematic below, create an Evaluation document for an IoT hackathon project.

PRD: [PASTE PRD]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]

Provide:
1. Evaluation metrics (Sensor accuracy, Response time, Battery life, Connectivity reliability)
2. Evaluation methods (Manual testing, Benchmarking, Data logging)
3. Benchmarking (What is the baseline?)
4. Known limitations of the hardware or sensors
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about IoT/hardware and how to answer them

Focus on demonstrating that the team understands the device's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 07. IoT / Hardware / Robotics

Welcome to Phase 4: Delivery & Presentation for 07. IoT / Hardware / Robotics. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 07. IoT / Hardware / Robotics
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to flash firmware, connect to cloud, and set up the live demo.

Act as an IoT deployment engineer.
Using the System Architecture and Hardware Schematic below, create a Deployment document for an IoT hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]

Provide:
1. Firmware flashing steps (Arduino IDE, PlatformIO, esptool)
2. Cloud platform setup (AWS IoT, Blynk, ThingSpeak, Firebase)
3. Device provisioning (WiFi credentials, API keys)
4. Dashboard deployment (Hosting the web dashboard)
5. Mobile app deployment (If applicable)
6. How to test the deployed system
7. Fallback plan if hardware fails during the hackathon
8. A pre-deployment checklist
9. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live demo as early as possible.

DEMO_SCRIPT

Category: 07. IoT / Hardware / Robotics
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the hardware demo works perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our hardware solution
6. How it works (Sensor → Microcontroller → Cloud → Dashboard)
7. Technology (Arduino, ESP32, Sensors, MQTT)
8. Demo (The most important part — show the live device working)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for hardware failure during the demo.

GLOSSARY

Category: 07. IoT / Hardware / Robotics
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all hardware terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Hardware Schematic, and Connectivity Protocol below, create a Glossary document for an IoT hackathon project.

PRD: [PASTE PRD]
HARDWARE_SCHEMATIC: [PASTE HARDWARE_SCHEMATIC]
CONNECTIVITY_PROTOCOL: [PASTE CONNECTIVITY_PROTOCOL]

Provide definitions for all key terms used in the project, including:
1. Hardware terms (Microcontroller, GPIO, PWM, ADC, I2C, SPI, UART)
2. Sensor terms (Analog, Digital, Calibration, Sampling Rate, Accuracy)
3. Actuator terms (Servo, Motor, Relay, Solenoid)
4. Connectivity terms (WiFi, Bluetooth, MQTT, LoRa, Zigbee, HTTP)
5. Power terms (Voltage, Current, Battery, Regulator, Sleep Mode)
6. Firmware terms (Setup, Loop, Interrupt, State Machine, Library)
7. Cloud/IoT terms (Broker, Topic, Publish, Subscribe, Dashboard)
8. Project-specific terms (Any custom terminology used in the PRD)
9. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

08. AR / VR / XR / Metaverse

Spatial computing, 3D engines, immersive interactions, and asset rendering pipelines.

Overview

This category provides structured prompt packs tailored for 08. AR / VR / XR / Metaverse projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 08. AR / VR / XR / Metaverse

Welcome to Phase 1: Problem Definition for 08. AR / VR / XR / Metaverse. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 08. AR / VR / XR / Metaverse
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem and identify what can be solved through immersive technology.

I am participating in an AR/VR/XR/Metaverse hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed AR/VR/XR solution ideas
7. Core immersive features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential XR platforms and tools that could be used (Unity, Unreal, WebXR, ARKit, ARCore, Meta Quest)

Do not assume I am an experienced XR developer.
Explain XR concepts (6DoF, Hand Tracking, Spatial Anchors, Prefabs) in beginner-friendly language.

PRD

Category: 08. AR / VR / XR / Metaverse
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear XR experience plan with interactions, scenes, and scope.

You are a senior XR product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed XR solution
7. Product goals
8. User stories
9. Functional requirements (Include XR-specific requirements: Interactions, Spatial Mapping, Tracking, Rendering)
10. Non-functional requirements (Comfort, Latency, Frame Rate, Immersion)
11. Core immersive features
12. Nice-to-have features
13. User journeys (How a user enters, interacts, and exits the experience)
14. MVP scope (Which XR feature must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include XR metrics: Task completion, Comfort score, Frame rate, Immersion)
17. Risks and assumptions (Include XR risks: Motion sickness, Tracking loss, Device overheating)

Keep the MVP realistic for a 24-48 hour XR hackathon.
Do not add unnecessary 3D scenes just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.

TRD

Category: 08. AR / VR / XR / Metaverse
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on XR engine, device, and performance.

You are a senior XR engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. XR platform and engine choice (Unity, Unreal, WebXR, ARKit, ARCore — justify the choice)
3. Target device (Meta Quest, HoloLens, Mobile AR, WebXR Browser)
4. Rendering requirements (URP, HDRP, Built-in)
5. Interaction requirements (Controllers, Hand Tracking, Gaze, Gestures)
6. Spatial mapping requirements (Plane detection, Anchors, Occlusion)
7. 3D asset requirements (Poly count, Texture resolution, Format)
8. Audio requirements (Spatial audio, Voice)
9. Performance and latency requirements (Target FPS, Draw calls, Memory)
10. Backend/Cloud requirements (If applicable)
11. Testing requirements (Device testing, User comfort)
12. Deployment requirements

Keep the XR stack simple and realistic for a 24-48 hour hackathon.
Explain all XR concepts in beginner-friendly language.
Do not introduce unnecessary tools.

Phase 2: Technical Blueprint

Category: 08. AR / VR / XR / Metaverse

Welcome to Phase 2: Technical Blueprint for 08. AR / VR / XR / Metaverse. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic XR architecture with clear data flow from device to user experience.

Act as a senior XR architect.
Using the following PRD and TRD, design a realistic hackathon XR architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended XR stack (Engine, SDK, Target device)
2. Complete XR architecture diagram (Text-based, showing User → Device → SDK → Scene → Interaction → Backend)
3. Scene architecture (Scenes, Prefabs, Controllers)
4. Interaction architecture (Input system, Hand tracking, Controllers)
5. Spatial mapping architecture (Anchors, Plane detection)
6. Rendering architecture (Pipeline, Shaders, Lighting)
7. Asset pipeline architecture (Import, Optimization, Loading)
8. Audio architecture (Spatial audio, Voice)
9. Backend/Cloud architecture (If applicable)
10. Data flow (How a user action becomes a scene change)
11. Performance considerations
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.

SCENE_GRAPH

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

5. SCENE_GRAPH.md

Purpose: To define the 3D scene hierarchy, objects, prefabs, and assets.

Act as a senior XR scene designer.
Using the PRD and System Architecture below, design the scene graph for this XR hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Scene list (Main Menu, Experience, Settings, etc.)
2. Scene hierarchy (Parent-Child relationships)
3. GameObjects/Actors (Name, Type, Purpose)
4. Prefabs (Reusable objects)
5. UI elements (Canvas, Menus, HUD)
6. Lighting setup (Directional, Point, Ambient)
7. Camera setup (Main Camera, XR Rig)
8. Interaction zones (Where the user can interact)
9. Spawn points and anchors
10. Example scene layout
11. A checklist for verifying the scene before the demo

Explain why each object exists.
Keep the scene simple enough for a beginner hackathon team to understand and maintain.

INTERACTION_SPEC

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

6. INTERACTION_SPEC.md

Purpose: To define user interactions (Gaze, Controller, Hand Tracking, Gestures).

You are a senior XR interaction designer.
Using the PRD and Scene Graph below, create an Interaction Specification document for this XR hackathon project.

PRD: [PASTE PRD]
SCENE_GRAPH: [PASTE SCENE_GRAPH]

Provide:
1. Interaction methods (Controllers, Hand Tracking, Gaze, Voice, Gestures)
2. Primary interaction (Select, Grab, Point, Teleport)
3. Secondary interaction (Menu, Rotate, Scale, Throw)
4. Input mappings (Button, Trigger, Grip, Joystick)
5. Hand tracking gestures (Pinch, Point, Grab)
6. Gaze interaction (Dwell time, Retical)
7. Haptic feedback (Vibration patterns)
8. Audio feedback (Sounds for interactions)
9. Visual feedback (Highlight, Outline, Cursor)
10. Interaction states (Idle, Hover, Selected, Active)
11. Example interaction flow
12. A checklist for verifying interactions before the demo

Explain each interaction in beginner-friendly language.
Keep the interaction design simple and intuitive for a hackathon.

ASSET_PIPELINE

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

7. ASSET_PIPELINE.md

Purpose: To define 3D models, textures, audio, and optimization workflow.

Act as a senior XR technical artist.
Using the PRD and Scene Graph below, create an Asset Pipeline document for this XR hackathon project.

PRD: [PASTE PRD]
SCENE_GRAPH: [PASTE SCENE_GRAPH]

Provide:
1. 3D model requirements (Format, Poly count, Scale)
2. Texture requirements (Resolution, Format, Compression)
3. Material and shader requirements
4. Animation requirements (Rigging, Clips, Blend trees)
5. Audio requirements (Format, Spatial audio, Compression)
6. Asset import workflow (Blender → Engine)
7. Asset optimization (LODs, Occlusion culling, Batching)
8. Naming conventions
9. Folder structure for assets
10. Free asset sources (Sketchfab, Poly Haven, Mixamo)
11. A checklist for verifying assets before the demo

Explain each concept in beginner-friendly language.
Keep the asset pipeline simple and realistic for a hackathon.

SPATIAL_MAPPING

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

8. SPATIAL_MAPPING.md

Purpose: To define plane detection, anchors, occlusion, and world understanding.

You are a senior AR/XR spatial computing engineer.
Using the PRD and System Architecture below, create a Spatial Mapping document for this XR hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Spatial mapping requirements (Plane detection, Mesh, Depth)
2. Anchor types (Plane, Point, Image, Object)
3. Occlusion handling (Real-world objects blocking virtual objects)
4. Raycasting (For placement and interaction)
5. World origin and coordinate system
6. Tracking modes (3DoF, 6DoF, Inside-out, Outside-in)
7. Persistent anchors (If applicable)
8. Lighting estimation (If applicable)
9. Limitations of spatial mapping on target device
10. A checklist for verifying spatial mapping before the demo

Explain each concept in beginner-friendly language.
Keep the spatial mapping simple and realistic for a hackathon.

PERFORMANCE_BUDGET

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint

9. PERFORMANCE_BUDGET.md

Purpose: To define frame rate, polygon count, draw calls, and memory limits.

Act as a senior XR performance engineer.
Using the PRD and Scene Graph below, create a Performance Budget document for this XR hackathon project.

PRD: [PASTE PRD]
SCENE_GRAPH: [PASTE SCENE_GRAPH]

Provide:
1. Target frame rate (72Hz, 90Hz, 120Hz)
2. Polygon budget (Total, Per object)
3. Draw call budget
4. Texture memory budget
5. Material and shader budget
6. Lighting budget (Real-time vs Baked)
7. Physics budget
8. Audio budget
9. Memory budget (RAM, VRAM)
10. Performance profiling tools (Unity Profiler, RenderDoc)
11. Optimization techniques (LODs, Batching, Occlusion culling)
12. A checklist for verifying performance before the demo

Explain each concept in beginner-friendly language.
Keep the performance budget realistic for a hackathon.

DATABASE_SCHEMA

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 08. AR / VR / XR / Metaverse.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 08. AR / VR / XR / Metaverse project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 08. AR / VR / XR / Metaverse
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 08. AR / VR / XR / Metaverse.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 08. AR / VR / XR / Metaverse project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 08. AR / VR / XR / Metaverse

Welcome to Phase 3: Execution & Quality for 08. AR / VR / XR / Metaverse. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 08. AR / VR / XR / Metaverse
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define spatial UI design, menus, HUD, and user flow.

Act as a senior spatial UI/UX designer.
Using the PRD and System Architecture below, create a UI Specification document for an XR hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spatial spacing)
2. Spatial UI components (World-space menus, HUD, Panels)
3. Component hierarchy (Menus, Buttons, Sliders, Cards)
4. Screen-by-screen breakdown (Main Menu, Experience, Settings, Exit)
5. Interaction states (Idle, Hover, Selected, Active)
6. Loading states (Skeletons, spinners)
7. Error states (Tracking lost, Controller disconnected)
8. Empty states (No content yet)
9. Comfort considerations (Distance, Size, Placement)
10. Accessibility considerations (Contrast, Text size, Audio cues)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core immersive journey.

ERROR_HANDLING

Category: 08. AR / VR / XR / Metaverse
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when tracking is lost, a controller disconnects, or performance drops.

You are a senior XR developer.
Using the System Architecture and Interaction Spec below, create an Error Handling document for an XR hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
INTERACTION_SPEC: [PASTE INTERACTION_SPEC]

Provide:
1. Common failure modes (Tracking loss, Controller disconnect, Low battery, Performance drop)
2. Tracking error handling (Recenter, Pause, Fallback)
3. Controller error handling (Pause, Notify user, Switch to hand tracking)
4. Spatial mapping error handling (Re-scan, Anchor loss)
5. Performance error handling (Reduce quality, Pause rendering)
6. Frontend error display (In-world notifications, HUD alerts)
7. Recovery procedures (Auto-recenter, Manual reset)
8. A checklist for developers to verify error handling before the demo

Focus on making the experience resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 08. AR / VR / XR / Metaverse
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To secure user data privacy, camera permissions, and microphone access.

Act as an XR security and privacy engineer.
Using the System Architecture and PRD below, create a Security document for an XR hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Camera and microphone permissions (When and why)
2. User data privacy (What data is collected?)
3. Spatial data privacy (Room mapping, Location data)
4. Voice data privacy (If using voice input)
5. Biometric data (If using eye tracking, hand tracking)
6. Data storage and transmission security
7. Backend security (If applicable)
8. Compliance considerations (GDPR, COPPA if applicable)
9. A pre-submission privacy checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.

TESTING

Category: 08. AR / VR / XR / Metaverse
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for XR experiences, device testing, and edge cases.

Act as a QA engineer specializing in XR applications.
Using the PRD and Interaction Spec below, create a Testing document for an XR hackathon project.

PRD: [PASTE PRD]
INTERACTION_SPEC: [PASTE INTERACTION_SPEC]

Provide:
1. Testing strategy for XR
2. Device testing (Headset, Controllers, Hand tracking)
3. Scene testing (Does every scene load correctly?)
4. Interaction testing (Do interactions work as intended?)
5. Spatial mapping testing (Plane detection, Anchors)
6. Performance testing (FPS, Comfort)
7. Audio testing (Spatial audio, Volume)
8. Edge cases (Tracking loss, Controller disconnect, Low battery)
9. User comfort testing (Motion sickness, Fatigue)
10. User acceptance testing checklist
11. A manual testing checklist for the demo
12. How to document known XR limitations for judges

Keep the testing plan simple enough for beginner XR developers to execute under time pressure.

EVALUATION

Category: 08. AR / VR / XR / Metaverse
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures XR performance and prepares for judge questions.

You are an XR evaluation expert.
Using the PRD and Interaction Spec below, create an Evaluation document for an XR hackathon project.

PRD: [PASTE PRD]
INTERACTION_SPEC: [PASTE INTERACTION_SPEC]

Provide:
1. Evaluation metrics (FPS, Comfort score, Task completion, Immersion)
2. Evaluation methods (User testing, Surveys, Profiling)
3. Benchmarking (What is the baseline?)
4. Known limitations of the XR experience
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about XR and how to answer them

Focus on demonstrating that the team understands the experience's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 08. AR / VR / XR / Metaverse

Welcome to Phase 4: Delivery & Presentation for 08. AR / VR / XR / Metaverse. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 08. AR / VR / XR / Metaverse
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to build and deploy to Quest, mobile AR, or WebXR.

Act as an XR deployment engineer.
Using the System Architecture and PRD below, create a Deployment document for an XR hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Target platform (Meta Quest, Mobile AR, WebXR)
2. Build settings (Development build, Release build)
3. Deployment steps (SideQuest, ADB, TestFlight, Web hosting)
4. Environment variables for production
5. How to test the deployed experience
6. Fallback plan if deployment fails during the hackathon
7. A pre-deployment checklist
8. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live demo as early as possible.

DEMO_SCRIPT

Category: 08. AR / VR / XR / Metaverse
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the XR experience works perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
INTERACTION_SPEC: [PASTE INTERACTION_SPEC]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem
3. Why the problem matters
4. Existing limitations
5. Our XR solution
6. How it works (Device → Scene → Interaction)
7. Technology (Unity, Unreal, WebXR, Quest)
8. Demo (The most important part — show the live immersive experience)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for hardware failure during the demo (video recording, screenshots).

GLOSSARY

Category: 08. AR / VR / XR / Metaverse
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all XR terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Interaction Spec, and Architecture below, create a Glossary document for an XR hackathon project.

PRD: [PASTE PRD]
INTERACTION_SPEC: [PASTE INTERACTION_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. XR terms (AR, VR, MR, XR, Metaverse, Immersion, Presence)
2. Tracking terms (3DoF, 6DoF, Inside-out, Outside-in, Hand Tracking, Eye Tracking)
3. Interaction terms (Gaze, Controller, Gesture, Haptic, Raycast)
4. Spatial terms (Anchor, Plane Detection, Occlusion, Spatial Mapping, World Origin)
5. Rendering terms (FOV, Frame Rate, Draw Call, LOD, Shader)
6. Engine terms (Unity, Unreal, Prefab, GameObject, Scene)
7. Comfort terms (Motion Sickness, Latency, Comfort Score)
8. Project-specific terms (Any custom terminology used in the PRD)
9. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

09. Cybersecurity

Threat modeling, application security, attack surface reduction, and incident response.

Overview

This category provides structured prompt packs tailored for 09. Cybersecurity projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 09. Cybersecurity

Welcome to Phase 1: Problem Definition for 09. Cybersecurity. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 09. Cybersecurity
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the security problem and identify what threats, vulnerabilities, or risks need to be addressed.

I am participating in a cybersecurity hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual security problem being solved
2. Target users (Security analysts, SOC teams, developers, end-users)
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing security solutions
6. Proposed cybersecurity solution ideas
7. Core security features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential security tools and platforms that could be used (Python, Kali, Wireshark, SIEM, etc.)

Do not assume I am an experienced security engineer.
Explain security concepts (Threat, Vulnerability, Exploit, SIEM, SOC) in beginner-friendly language.

PRD

Category: 09. Cybersecurity
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear security product plan with features, detection logic, and scope.

You are a senior security product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed security solution
7. Product goals
8. User stories
9. Functional requirements (Include security-specific requirements: Detection, Alerting, Logging, Response)
10. Non-functional requirements (Accuracy, Latency, Scalability, Compliance)
11. Core security features
12. Nice-to-have features
13. User journeys (How an analyst detects, investigates, and responds to a threat)
14. MVP scope (Which security feature must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include security metrics: Detection rate, False positive rate, Mean time to detect)
17. Risks and assumptions (Include security risks: False negatives, Data breaches, Legal boundaries)

Keep the MVP realistic for a 24-48 hour cybersecurity hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.

TRD

Category: 09. Cybersecurity
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on security tools, target environment, and detection logic.

You are a senior security engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Security stack choice (Python, SIEM, EDR, Cloud — justify the choice)
3. Target environment (Web app, Network, Cloud, Endpoint)
4. Detection requirements (Signatures, Anomalies, Heuristics)
5. Log collection and parsing requirements
6. Alerting and notification requirements
7. Data storage requirements (Logs, Events, Indicators of Compromise)
8. Automation and response requirements (SOAR)
9. Encryption and key management requirements
10. Compliance and legal requirements (GDPR, HIPAA, PCI-DSS)
11. Testing requirements (Penetration testing, Vulnerability scanning)
12. Deployment requirements

Keep the security stack simple and realistic for a 24-48 hour hackathon.
Explain all security concepts in beginner-friendly language.
Do not introduce unnecessary tools.

Phase 2: Technical Blueprint

Category: 09. Cybersecurity

Welcome to Phase 2: Technical Blueprint for 09. Cybersecurity. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic security architecture with clear data flow from target to response.

Act as a senior security architect.
Using the following PRD and TRD, design a realistic hackathon security architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended security stack (Tools, Languages, Frameworks)
2. Complete security architecture diagram (Text-based, showing Target → Detection → Analysis → Response)
3. Data collection architecture (Logs, Network traffic, Endpoints)
4. Detection architecture (Rules, Signatures, ML models)
5. Analysis architecture (Correlation, Enrichment, Scoring)
6. Response architecture (Automation, Playbooks, Alerts)
7. Storage architecture (Logs, Events, Threat Intel)
8. Dashboard architecture (SOC view)
9. Authentication and access control architecture
10. Data flow (How a threat is detected and escalated)
11. Security considerations
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.

THREAT_MODEL

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

5. THREAT_MODEL.md

Purpose: To define threat actors, attack vectors, assets, and risk ratings.

Act as a senior threat modeling expert.
Using the PRD and System Architecture below, create a Threat Model document for this cybersecurity hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Assets (What are we protecting?)
2. Threat actors (Who might attack? Script kiddies, Insiders, APTs)
3. Attack vectors (How might they attack?)
4. Threat modeling framework (STRIDE, PASTA, or OCTAVE)
5. Threat list (Each threat with description)
6. Risk rating (Likelihood × Impact)
7. Existing controls (What mitigations are already in place?)
8. Recommended controls (What should be added?)
9. Example attack scenario (Step-by-step)
10. A checklist for verifying the threat model before the demo

Explain each threat in beginner-friendly language.
Keep the threat model simple and realistic for a hackathon.

ATTACK_SURFACE

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

6. ATTACK_SURFACE.md

Purpose: To define all entry points, endpoints, and vulnerabilities in scope.

You are a senior penetration tester.
Using the PRD and System Architecture below, create an Attack Surface document for this cybersecurity hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Attack surface overview (What can be attacked?)
2. Entry points (Web, API, Network, Endpoint, Cloud)
3. Endpoints and services (List all in scope)
4. Authentication mechanisms in scope
5. Data flows and trust boundaries
6. Known vulnerabilities (OWASP Top 10, CVE)
7. Misconfigurations (Common issues)
8. Third-party dependencies and risks
9. Out-of-scope areas (What we are NOT testing)
10. Example attack path
11. A checklist for verifying the attack surface before the demo

Explain each concept in beginner-friendly language.
Keep the attack surface simple and realistic for a hackathon.
Only include what is legally and ethically allowed.

AUTHENTICATION_FLOW

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

7. AUTHENTICATION_FLOW.md

Purpose: To define identity, access control, MFA, and zero-trust principles.

You are a senior identity and access management engineer.
Using the PRD and System Architecture below, create an Authentication and Access Control document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Authentication methods (Password, MFA, SSO, Biometric)
2. Password policy (Complexity, Expiry, Hashing)
3. Multi-factor authentication (TOTP, SMS, Hardware key)
4. Authorization model (RBAC, ABAC, Zero Trust)
5. Role definitions (Admin, Analyst, User, Guest)
6. Session management (Timeout, Refresh, Revocation)
7. API authentication (JWT, OAuth 2.0, API keys)
8. Identity providers (Okta, Auth0, Keycloak)
9. Audit logging (What to log, Where to store)
10. Common authentication vulnerabilities (OWASP)
11. A checklist for verifying authentication before the demo

Keep the authentication simple and secure enough for a hackathon.
Explain concepts in beginner-friendly language.

INCIDENT_RESPONSE

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

8. INCIDENT_RESPONSE.md

Purpose: To define detection, containment, eradication, recovery, and lessons learned.

Act as a senior incident response specialist.
Using the PRD and Threat Model below, create an Incident Response document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
THREAT_MODEL: [PASTE THREAT_MODEL]

Provide:
1. Incident response phases (Preparation, Detection, Containment, Eradication, Recovery, Lessons Learned)
2. Incident classification (Severity levels)
3. Detection sources (Logs, Alerts, User reports)
4. Triage process (How to assess severity)
5. Containment strategies (Isolate, Block, Disable)
6. Eradication steps (Remove threat, Patch vulnerabilities)
7. Recovery steps (Restore systems, Verify integrity)
8. Communication plan (Who to notify, When)
9. Evidence collection (Forensics, Chain of custody)
10. Post-incident review (What went well, What to improve)
11. Example incident scenario (Step-by-step)
12. A checklist for verifying the incident response plan before the demo

Explain each phase in beginner-friendly language.
Keep the incident response plan simple and realistic for a hackathon.

VULNERABILITY_MANAGEMENT

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint

9. VULNERABILITY_MANAGEMENT.md

Purpose: To define scanning, prioritization (CVSS), patching, and reporting.

You are a senior vulnerability management engineer.
Using the PRD and Attack Surface document below, create a Vulnerability Management document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
ATTACK_SURFACE: [PASTE ATTACK_SURFACE]

Provide:
1. Vulnerability scanning tools (Nessus, OpenVAS, Nmap, Burp Suite)
2. Scan scope and frequency
3. Vulnerability identification (CVE, CWE)
4. Risk scoring (CVSS, EPSS)
5. Prioritization criteria (Severity, Exploitability, Business impact)
6. Remediation workflow (Patch, Mitigate, Accept)
7. Reporting format (Executive summary, Technical details)
8. Metrics (Time to detect, Time to remediate, Open vulnerabilities)
9. Exception handling (Accepted risks)
10. A checklist for verifying vulnerability management before the demo

Explain each concept in beginner-friendly language.
Keep the vulnerability management process simple and realistic for a hackathon.

DATABASE_SCHEMA

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 09. Cybersecurity.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 09. Cybersecurity project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 09. Cybersecurity
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 09. Cybersecurity.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 09. Cybersecurity project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 09. Cybersecurity

Welcome to Phase 3: Execution & Quality for 09. Cybersecurity. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 09. Cybersecurity
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define the dashboard design, alerts, threat visualization, and user flow.

Act as a senior UI/UX designer specializing in security dashboards.
Using the PRD and System Architecture below, create a UI Specification document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (Alert cards, Threat map, Log viewer, Metrics)
3. Screen-by-screen breakdown (Dashboard, Alert Detail, Investigation, Reports)
4. Real-time data display (Live alerts, Threat feed, Metrics)
5. Severity indicators (Critical, High, Medium, Low)
6. Loading states (Skeletons, spinners)
7. Error states (Data unavailable, Connection lost)
8. Empty states (No alerts, No data)
9. Responsive design guidelines (Desktop-first for SOC)
10. Accessibility considerations (Contrast, Color blindness)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core detection and response journey.

ERROR_HANDLING

Category: 09. Cybersecurity
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when a scan fails, a log is missing, or a false positive occurs.

You are a senior security engineer.
Using the System Architecture and Detection logic below, create an Error Handling document for a cybersecurity hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DETECTION_LOGIC: [PASTE DETECTION_LOGIC]

Provide:
1. Common failure modes (Scan failure, Missing logs, False positive, API timeout)
2. Detection error handling (Fallback rules, Graceful degradation)
3. Data collection error handling (Buffer, Retry, Alert)
4. Analysis error handling (Skip, Flag, Retry)
5. Response error handling (Manual escalation)
6. Frontend error display (Toasts, inline errors, modals)
7. Logging errors (Where errors are stored)
8. Recovery procedures (Re-run scan, Manual review)
9. A checklist for developers to verify error handling before the demo

Focus on making the security tool resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 09. Cybersecurity
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: The core security document (encryption, key management, access control, compliance).

Act as a senior security architect.
Using the System Architecture and Authentication Flow below, create the master Security document for a cybersecurity hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
AUTHENTICATION_FLOW: [PASTE AUTHENTICATION_FLOW]

Provide:
1. Security principles (Least privilege, Defense in depth, Zero trust)
2. Encryption (At rest, In transit, Key management)
3. Access control (RBAC, ABAC, Permissions)
4. Network security (Firewalls, Segmentation, IDS/IPS)
5. Application security (OWASP Top 10, Input validation, Output encoding)
6. Data privacy (PII handling, Anonymization, Retention)
7. Logging and monitoring (What to log, SIEM integration)
8. Incident response readiness (Playbooks, Contacts)
9. Compliance considerations (GDPR, HIPAA, PCI-DSS, SOC 2)
10. Third-party and supply chain security
11. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Do not include illegal or unethical techniques.

TESTING

Category: 09. Cybersecurity
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for security tools, penetration testing, and edge cases.

Act as a QA engineer specializing in cybersecurity.
Using the PRD and Attack Surface document below, create a Testing document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
ATTACK_SURFACE: [PASTE ATTACK_SURFACE]

Provide:
1. Testing strategy for security tools
2. Functional testing (Does the tool detect what it should?)
3. Penetration testing (Simulated attacks)
4. Vulnerability validation (Confirm findings)
5. False positive and false negative testing
6. Log collection testing
7. Alerting testing
8. Performance testing (Scan speed, Throughput)
9. Edge cases (Large logs, Encrypted traffic, Evasion techniques)
10. User acceptance testing checklist
11. A manual testing checklist for the demo
12. How to document known limitations for judges

Keep the testing plan simple enough for beginner security engineers to execute under time pressure.
Only include legal and ethical testing methods.

EVALUATION

Category: 09. Cybersecurity
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures security performance and prepares for judge questions.

You are a security evaluation expert.
Using the PRD and Testing document below, create an Evaluation document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
TESTING: [PASTE TESTING]

Provide:
1. Evaluation metrics (Detection rate, False positive rate, Mean time to detect, Mean time to respond)
2. Evaluation methods (Red team exercises, Benchmarking, Test datasets)
3. Benchmarking (What is the baseline?)
4. Known limitations of the security tool
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about cybersecurity and how to answer them

Focus on demonstrating that the team understands the tool's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 09. Cybersecurity

Welcome to Phase 4: Delivery & Presentation for 09. Cybersecurity. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 09. Cybersecurity
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to deploy the security tool, configure environments, and set up monitoring.

Act as a security DevOps engineer.
Using the System Architecture and PRD below, create a Deployment document for a cybersecurity hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Deployment environment (Local, Cloud, Hybrid, Lab)
2. Deployment platforms (AWS, GCP, Azure, On-prem)
3. Containerization (Docker, Kubernetes)
4. Environment variables and secrets management
5. Step-by-step deployment instructions for each component
6. How to test the deployed tool
7. Monitoring and alerting setup
8. Fallback plan if deployment fails during the hackathon
9. A pre-deployment checklist
10. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working demo as early as possible.
Ensure all deployment is legal and ethical (lab environment only).

DEMO_SCRIPT

Category: 09. Cybersecurity
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the security tool is shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
THREAT_MODEL: [PASTE THREAT_MODEL]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem (The security gap)
3. Why the problem matters
4. Existing limitations
5. Our security solution
6. How it works (Target → Detection → Analysis → Response)
7. Technology (Python, SIEM, Kali, etc.)
8. Demo (The most important part — show a live detection)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch HOOK
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots).
Ensure the demo is fully legal and ethical (controlled lab environment).

GLOSSARY

Category: 09. Cybersecurity
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all security terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Threat Model, and Architecture below, create a Glossary document for a cybersecurity hackathon project.

PRD: [PASTE PRD]
THREAT_MODEL: [PASTE THREAT_MODEL]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Security terms (Threat, Vulnerability, Exploit, Risk, Attack Surface)
2. Threat terms (Threat Actor, APT, Script Kiddie, Insider Threat)
3. Vulnerability terms (CVE, CVSS, Zero-Day, Patch, Misconfiguration)
4. Detection terms (SIEM, IDS, IPS, EDR, SOC, False Positive)
5. Response terms (Incident Response, Containment, Eradication, Recovery)
6. Cryptography terms (Encryption, Hashing, PKI, TLS, Key Management)
7. Access control terms (RBAC, ABAC, MFA, SSO, Zero Trust)
8. Compliance terms (GDPR, HIPAA, PCI-DSS, SOC 2)
9. Project-specific terms (Any custom terminology used in the PRD)
10. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

10. Cloud / DevOps / Platform

Infrastructure as Code, CI/CD pipelines, container orchestration, and platform engineering.

Overview

This category provides structured prompt packs tailored for 10. Cloud / DevOps / Platform projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 10. Cloud / DevOps / Platform

Welcome to Phase 1: Problem Definition for 10. Cloud / DevOps / Platform. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 10. Cloud / DevOps / Platform
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the infrastructure/deployment problem and identify what manual, slow, or unreliable processes need automation.

I am participating in a Cloud/DevOps/Platform hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users (Developers, SREs, Platform teams, DevOps engineers)
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed Cloud/DevOps solution ideas
7. Core DevOps features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential cloud platforms and tools that could be used (AWS, Azure, GCP, Docker, Kubernetes, Terraform)

Do not assume I am an experienced DevOps engineer.
Explain DevOps concepts (CI/CD, IaC, Containers, Orchestration, Observability) in beginner-friendly language.

PRD

Category: 10. Cloud / DevOps / Platform
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear DevOps product plan with pipelines, infrastructure, and scope.

You are a senior DevOps product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed DevOps solution
7. Product goals
8. User stories
9. Functional requirements (Include DevOps-specific requirements: Build, Test, Deploy, Monitor, Rollback)
10. Non-functional requirements (Reliability, Scalability, Security, Speed)
11. Core DevOps features
12. Nice-to-have features
13. User journeys (How a developer pushes code and sees it deployed)
14. MVP scope (Which pipeline or infrastructure feature must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include DevOps metrics: Deployment frequency, Lead time, MTTR, Change failure rate)
17. Risks and assumptions (Include DevOps risks: Cloud costs, API limits, Region outages)

Keep the MVP realistic for a 24-48 hour Cloud/DevOps hackathon.
Do not add unnecessary infrastructure just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.

TRD

Category: 10. Cloud / DevOps / Platform
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on cloud platform, IaC, and CI/CD tools.

You are a senior cloud engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Cloud platform choice (AWS, Azure, GCP — justify the choice)
3. Infrastructure as Code tool (Terraform, CloudFormation, Pulumi)
4. Containerization requirements (Docker, Podman)
5. Orchestration requirements (Kubernetes, ECS, Cloud Run)
6. CI/CD tool choice (GitHub Actions, GitLab CI, Jenkins, CircleCI)
7. Build and artifact requirements (Docker registry, Artifactory)
8. Environment requirements (Dev, Staging, Prod)
9. Secrets and configuration management (Vault, AWS Secrets Manager)
10. Observability requirements (Logging, Metrics, Tracing)
11. Security and compliance requirements
12. Cost and budget requirements
13. Testing requirements
14. Deployment requirements

Keep the cloud stack simple and realistic for a 24-48 hour hackathon.
Explain all DevOps concepts in beginner-friendly language.
Do not introduce unnecessary tools. Prioritize free-tier services.

Phase 2: Technical Blueprint

Category: 10. Cloud / DevOps / Platform

Welcome to Phase 2: Technical Blueprint for 10. Cloud / DevOps / Platform. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic DevOps architecture with clear data flow from code to production.

Act as a senior cloud architect.
Using the following PRD and TRD, design a realistic hackathon DevOps architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended cloud stack (Platform, IaC, Containers, CI/CD)
2. Complete DevOps architecture diagram (Text-based, showing Code → Build → Test → Deploy → Monitor)
3. Source control architecture (Git, Branching strategy)
4. CI architecture (Build, Test, Artifact)
5. CD architecture (Deploy, Rollback, Blue-Green/Canary)
6. Infrastructure architecture (Compute, Storage, Networking)
7. Container architecture (Docker, Kubernetes)
8. Observability architecture (Logs, Metrics, Traces)
9. Secrets management architecture
10. Data flow (How a commit becomes a deployed application)
11. Security considerations (IAM, Network, Secrets)
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.
Prioritize free-tier and serverless where possible to keep costs at zero.

INFRASTRUCTURE_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

5. INFRASTRUCTURE_SPEC.md

Purpose: To define cloud resources, compute, storage, and networking.

Act as a senior cloud infrastructure engineer.
Using the PRD and System Architecture below, create an Infrastructure Specification document for this DevOps hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Compute resources (VMs, Containers, Serverless functions)
2. Storage resources (Object storage, Block storage, File storage)
3. Database resources (Managed DB, Cache, Queue)
4. Networking resources (VPC, Subnets, Load Balancer, DNS)
5. Identity and access resources (IAM roles, Service accounts)
6. Monitoring resources (Log groups, Metrics, Alerts)
7. Region and availability zone strategy
8. Scaling strategy (Horizontal, Vertical, Auto-scaling)
9. Cost estimate for the hackathon (Free tier, Budget)
10. Resource naming conventions and tagging
11. A checklist for verifying infrastructure before the demo

Explain why each resource exists.
Keep the infrastructure simple enough for a beginner hackathon team to understand and maintain.
Prefer managed services over self-hosted to save time.

PIPELINE_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

6. PIPELINE_SPEC.md

Purpose: To define CI/CD stages, triggers, and deployment strategies.

You are a senior DevOps pipeline engineer.
Using the PRD and System Architecture below, create a CI/CD Pipeline Specification document for this DevOps hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. CI/CD tool choice (GitHub Actions, GitLab CI, Jenkins, CircleCI)
2. Pipeline triggers (Push, Pull Request, Tag, Schedule)
3. CI stages (Lint, Build, Test, Security Scan, Artifact)
4. CD stages (Deploy to Dev, Staging, Production)
5. Deployment strategy (Rolling, Blue-Green, Canary)
6. Environment variables and secrets in pipeline
7. Artifact management (Docker registry, Build artifacts)
8. Rollback strategy (How to revert a bad deployment)
9. Notifications (Slack, Email on success/failure)
10. Pipeline as code (YAML example)
11. Branching strategy (GitFlow, Trunk-based)
12. A checklist for verifying the pipeline before the demo

Explain each stage in beginner-friendly language.
Keep the pipeline simple and reliable for a hackathon.
Prioritize speed over completeness.

IAC_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

7. IAC_SPEC.md

Purpose: To define Terraform/CloudFormation/Pulumi resources and modules.

Act as a senior Infrastructure as Code engineer.
Using the PRD and Infrastructure Spec below, create an IaC Specification document for this DevOps hackathon project.

PRD: [PASTE PRD]
INFRASTRUCTURE_SPEC: [PASTE INFRASTRUCTURE_SPEC]

Provide:
1. IaC tool choice (Terraform, CloudFormation, Pulumi, Ansible)
2. Project structure (Modules, Environments, Variables)
3. Resource definitions (Compute, Storage, Network, IAM)
4. Variables and outputs
5. State management (Remote state, Locking)
6. Environment separation (Dev, Staging, Prod)
7. Secrets management in IaC
8. Provider configuration
9. Example code snippets
10. Apply and destroy workflow
11. Cost estimation and budget alerts
12. A checklist for verifying IaC before the demo

Explain each concept in beginner-friendly language.
Keep the IaC simple and realistic for a hackathon.
Use free-tier resources wherever possible.

CONTAINER_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

8. CONTAINER_SPEC.md

Purpose: To define Docker images, Kubernetes manifests, and orchestration.

You are a senior container and Kubernetes engineer.
Using the PRD and System Architecture below, create a Container Specification document for this DevOps hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Containerization approach (Docker, Podman)
2. Dockerfile best practices (Multi-stage builds, Minimal base images)
3. Image registry (Docker Hub, ECR, GCR, ACR)
4. Image tagging strategy (Latest, Semantic, Git SHA)
5. Orchestration choice (Kubernetes, ECS, Cloud Run, Docker Compose)
6. Kubernetes manifests (Deployment, Service, Ingress, ConfigMap, Secret)
7. Scaling (HPA, Replicas)
8. Health checks (Liveness, Readiness)
9. Resource limits (CPU, Memory)
10. Networking (Service, Ingress, Load Balancer)
11. Example Dockerfile and manifest
12. A checklist for verifying containers before the demo

Explain each concept in beginner-friendly language.
Keep the container setup simple and realistic for a hackathon.
If Kubernetes is too complex, recommend a simpler alternative.

OBSERVABILITY_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint

9. OBSERVABILITY_SPEC.md

Purpose: To define logging, metrics, tracing, and alerting.

Act as a senior SRE/observability engineer.
Using the PRD and System Architecture below, create an Observability Specification document for this DevOps hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Observability pillars (Logs, Metrics, Traces)
2. Logging strategy (What to log, Format, Retention)
3. Metrics strategy (What to measure, Dashboards)
4. Tracing strategy (Distributed tracing, Correlation IDs)
5. Tools (Prometheus, Grafana, Loki, Jaeger, Datadog, CloudWatch)
6. Alerting rules (What triggers an alert?)
7. Notification channels (Slack, Email, PagerDuty)
8. Dashboards (Golden signals: Latency, Traffic, Errors, Saturation)
9. SLOs and SLIs (If applicable)
10. Incident response integration
11. Example dashboard layout
12. A checklist for verifying observability before the demo

Explain each concept in beginner-friendly language.
Keep the observability setup simple and realistic for a hackathon.
Prefer free-tier tools.

DATABASE_SCHEMA

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 10. Cloud / DevOps / Platform.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 10. Cloud / DevOps / Platform project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 10. Cloud / DevOps / Platform
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 10. Cloud / DevOps / Platform.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 10. Cloud / DevOps / Platform project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 10. Cloud / DevOps / Platform

Welcome to Phase 3: Execution & Quality for 10. Cloud / DevOps / Platform. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 10. Cloud / DevOps / Platform
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define the dashboard design, pipeline visualization, and user flow.

Act as a senior UI/UX designer specializing in DevOps dashboards.
Using the PRD and System Architecture below, create a UI Specification document for a DevOps hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Colors, typography, spacing)
2. Component hierarchy (Pipeline view, Logs viewer, Metrics cards, Alerts)
3. Screen-by-screen breakdown (Dashboard, Pipeline Detail, Logs, Metrics, Alerts)
4. Real-time data display (Pipeline status, Deployment progress, Metrics)
5. Status indicators (Success, Failed, Running, Pending)
6. Loading states (Skeletons, spinners)
7. Error states (Pipeline failed, Connection lost)
8. Empty states (No pipelines yet)
9. Responsive design guidelines (Desktop-first for DevOps)
10. Accessibility considerations (Contrast, Color blindness)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core pipeline and deployment journey.

ERROR_HANDLING

Category: 10. Cloud / DevOps / Platform
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when a build fails, deployment rolls back, or a node crashes.

You are a senior DevOps reliability engineer.
Using the System Architecture and Pipeline Spec below, create an Error Handling document for a DevOps hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]

Provide:
1. Common failure modes (Build failure, Test failure, Deployment failure, Node crash)
2. CI error handling (Fail fast, Retry transient failures)
3. CD error handling (Automatic rollback, Manual approval)
4. Infrastructure error handling (Auto-healing, Auto-scaling)
5. Container error handling (CrashLoopBackOff, OOMKilled)
6. Observability error handling (Alert on failure)
7. Notification strategy (Slack, Email on failure)
8. Recovery procedures (Re-run pipeline, Rollback, Restore from backup)
9. A checklist for developers to verify error handling before the demo

Focus on making the pipeline resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 10. Cloud / DevOps / Platform
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To define IAM, secrets management, network security, and compliance.

Act as a cloud security engineer.
Using the System Architecture and Infrastructure Spec below, create a Security document for a DevOps hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
INFRASTRUCTURE_SPEC: [PASTE INFRASTRUCTURE_SPEC]

Provide:
1. Identity and Access Management (IAM roles, Least privilege, MFA)
2. Secrets management (Vault, AWS Secrets Manager, GitHub Secrets)
3. Network security (VPC, Security Groups, Firewalls, Private subnets)
4. Container security (Image scanning, Non-root user, Read-only FS)
5. Supply chain security (Dependency scanning, SBOM)
6. Encryption (At rest, In transit, Key management)
7. Compliance considerations (GDPR, SOC 2, HIPAA)
8. Audit logging (CloudTrail, Cloud Audit Logs)
9. Incident response integration
10. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Never commit secrets to Git.

TESTING

Category: 10. Cloud / DevOps / Platform
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for pipelines, infrastructure, and edge cases.

Act as a QA engineer specializing in DevOps.
Using the PRD and Pipeline Spec below, create a Testing document for a DevOps hackathon project.

PRD: [PASTE PRD]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]

Provide:
1. Testing strategy for DevOps
2. Unit testing in CI (Code tests)
3. Integration testing in CI (Service tests)
4. Pipeline testing (Does the pipeline run end-to-end?)
5. Infrastructure testing (Does IaC apply cleanly?)
6. Container testing (Does the image build and run?)
7. Deployment testing (Does the app deploy and respond?)
8. Rollback testing (Does rollback work?)
9. Chaos engineering (Simulate failures)
10. Edge cases (Large builds, Slow networks, Resource limits)
11. User acceptance testing checklist
12. A manual testing checklist for the demo
13. How to document known DevOps limitations for judges

Keep the testing plan simple enough for beginner DevOps engineers to execute under time pressure.

EVALUATION

Category: 10. Cloud / DevOps / Platform
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures DevOps performance and prepares for judge questions.

You are a DevOps evaluation expert.
Using the PRD and Pipeline Spec below, create an Evaluation document for a DevOps hackathon project.

PRD: [PASTE PRD]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]

Provide:
1. Evaluation metrics (DORA metrics: Deployment frequency, Lead time, MTTR, Change failure rate)
2. Additional metrics (Uptime, Build time, Cost per deployment)
3. Evaluation methods (Benchmarking, Load testing, Chaos testing)
4. Benchmarking (What is the baseline?)
5. Known limitations of the DevOps setup
6. How to explain these limitations to judges honestly
7. A checklist of evidence to gather for the presentation
8. Common judge questions about DevOps and how to answer them

Focus on demonstrating that the team understands the pipeline's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 10. Cloud / DevOps / Platform

Welcome to Phase 4: Delivery & Presentation for 10. Cloud / DevOps / Platform. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 10. Cloud / DevOps / Platform
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to deploy the platform, configure environments, and set up monitoring.

Act as a DevOps deployment engineer.
Using the System Architecture and Pipeline Spec below, create a Deployment document for a DevOps hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]

Provide:
1. Deployment environment (Dev, Staging, Prod)
2. Deployment platforms (AWS, GCP, Azure, Vercel, Render)
3. IaC apply steps (Terraform plan, apply)
4. Container deployment steps (Push image, Deploy to K8s/ECS)
5. Environment variables and secrets setup
6. Step-by-step deployment instructions for each component
7. How to test the deployed platform
8. Monitoring and alerting setup in production
9. Fallback plan if deployment fails during the hackathon
10. A pre-deployment checklist
11. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live pipeline as early as possible.
Ensure the hackathon budget is not exceeded.

DEMO_SCRIPT

Category: 10. Cloud / DevOps / Platform
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the pipeline is shown off perfectly.

Act as an expert hackathon presentation coach.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem (Manual, slow, unreliable deployments)
3. Why the problem matters
4. Existing limitations
5. Our DevOps solution
6. How it works (Code → Build → Deploy → Monitor)
7. Technology (AWS, Terraform, Docker, GitHub Actions)
8. Demo (The most important part — show a live commit-to-deploy)
9. Innovation
10. Impact (Time saved, Errors reduced, DORA improvements)
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots, pre-deployed environment).

GLOSSARY

Category: 10. Cloud / DevOps / Platform
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all DevOps terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Pipeline Spec, and Architecture below, create a Glossary document for a DevOps hackathon project.

PRD: [PASTE PRD]
PIPELINE_SPEC: [PASTE PIPELINE_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. DevOps terms (CI, CD, Pipeline, Artifact, Rollback)
2. Cloud terms (Region, AZ, VPC, IAM, Managed Service)
3. IaC terms (Terraform, Module, State, Plan, Apply)
4. Container terms (Docker, Image, Container, Registry, Kubernetes, Pod)
5. Orchestration terms (Cluster, Node, Deployment, Service, Ingress)
6. Observability terms (Log, Metric, Trace, Alert, Dashboard, SLO)
7. DORA metrics (Deployment Frequency, Lead Time, MTTR, Change Failure Rate)
8. Security terms (IAM, Secrets, Encryption, Least Privilege)
9. Project-specific terms (Any custom terminology used in the PRD)
10. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

11. Domain / Industry Hackathons

Specialized solutions for regulated industries including FinTech, HealthTech, and GovTech.

Overview

This category provides structured prompt packs tailored for 11. Domain / Industry Hackathons projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 11. Domain / Industry Hackathons

Welcome to Phase 1: Problem Definition for 11. Domain / Industry Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 11. Domain / Industry Hackathons
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the industry problem, target users, regulations, and existing gaps.

I am participating in a [INDUSTRY NAME] hackathon (e.g., FinTech, HealthTech, EdTech, ClimateTech) and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved in this industry
2. Target users (specific personas within the industry)
3. User pain points
4. Existing ways people solve this problem in the industry
5. Limitations of existing industry solutions
6. Proposed industry-specific solution ideas
7. Core features for this industry
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique in this industry
11. A realistic MVP that can be built during a hackathon
12. Industry-specific technologies, APIs, and data sources that could be used

Do not assume I am an expert in this industry.
Explain industry concepts, regulations, and jargon in beginner-friendly language.
Highlight any compliance considerations (GDPR, HIPAA, PCI-DSS, KYC, AML).

PRD

Category: 11. Domain / Industry Hackathons
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear industry solution plan with domain-specific features, personas, and compliance.

You are a senior product manager specializing in [INDUSTRY NAME] solutions, helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement (Industry-specific)
4. Target users (Detailed industry personas)
5. User pain points
6. Proposed solution
7. Product goals
8. User stories
9. Functional requirements (Include industry-specific requirements and compliance)
10. Non-functional requirements (Regulatory, Performance, Security)
11. Core industry features
12. Nice-to-have features
13. User journeys (Industry-specific workflows)
14. MVP scope (Which feature must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include industry metrics: Compliance rate, Time saved, Cost reduction)
17. Risks and assumptions (Include regulatory risks and industry-specific risks)

Keep the MVP realistic for a 24-48 hour hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that can actually be demonstrated live and comply with industry regulations.

TRD

Category: 11. Domain / Industry Hackathons
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on industry-specific tech, compliance, and integrations.

You are a senior engineer specializing in [INDUSTRY NAME] solutions, helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Tech stack choice (Framework, Language, Database — justify for this industry)
3. Industry-specific integration requirements (Banking APIs, EHR systems, Government APIs, POS systems)
4. Data model considerations (PII, PHI, Financial data)
5. Security and encryption requirements (Industry standards)
6. Compliance requirements (GDPR, HIPAA, PCI-DSS, KYC, AML)
7. Authentication and authorization requirements
8. Performance and latency requirements
9. Data storage and retention requirements (Industry-specific)
10. Testing requirements (Including compliance testing)
11. Deployment requirements (Industry-approved cloud/infrastructure)
12. Monitoring and audit logging requirements

Keep the tech stack simple and realistic for a 24-48 hour hackathon.
Explain all industry concepts in beginner-friendly language.
Do not introduce unnecessary tools.
Flag any compliance risks early.

Phase 2: Technical Blueprint

Category: 11. Domain / Industry Hackathons

Welcome to Phase 2: Technical Blueprint for 11. Domain / Industry Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic industry-specific system architecture with clear data flow and compliance.

Act as a senior architect specializing in [INDUSTRY NAME] solutions.
Using the following PRD and TRD, design a realistic hackathon architecture for this industry.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended tech stack (Frontend, Backend, Database, Integrations)
2. Complete system architecture diagram (Text-based, showing Users → Frontend → Backend → Industry APIs → Database)
3. Frontend architecture
4. Backend architecture
5. Database architecture (Industry-specific data model)
6. Integration architecture (Banking, EHR, Government, POS, etc.)
7. Authentication and compliance architecture
8. Data flow (How user actions trigger industry-specific processes)
9. Security and compliance considerations
10. Folder structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools.
Highlight compliance considerations at each layer.

DOMAIN_MODEL

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

5. DOMAIN_MODEL.md

Purpose: To define industry entities, relationships, and domain-specific data structures.

Act as a senior domain modeling expert for [INDUSTRY NAME].
Using the PRD and System Architecture below, design the domain model for this industry hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Core industry entities (E.g., FinTech: Account, Transaction, Loan; HealthTech: Patient, Appointment, Prescription)
2. Entity attributes (Fields, Data types)
3. Primary keys
4. Foreign keys
5. Relationships (One-to-Many, Many-to-Many)
6. Industry-specific enums (Status codes, Categories)
7. Compliance-sensitive fields (PII, PHI, Financial data — mark them)
8. Example records
9. SQL/NoSQL schema
10. Data retention rules
11. Audit trail requirements

Explain why each entity exists.
Keep the domain model simple enough for a beginner hackathon team to understand and maintain.
Mark which fields require encryption or special handling.

API_SPECIFICATION

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

6. API_SPECIFICATION.md

Purpose: To define endpoints including industry-specific integrations.

You are a senior backend developer specializing in [INDUSTRY NAME] systems.
Using the PRD, Architecture, and Domain Model below, create a complete API specification for this industry hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DOMAIN_MODEL: [PASTE DOMAIN_MODEL]

For every endpoint provide:
1. HTTP method
2. URL
3. Purpose
4. Authentication requirement
5. Compliance requirements (GDPR, HIPAA, PCI-DSS, KYC)
6. Request parameters
7. Request body
8. Example request
9. Example success response
10. Possible error responses
11. HTTP status codes
12. Audit logging requirements

Include endpoints for industry-specific integrations (Banking APIs, EHR, Government APIs).
Keep the API simple and consistent.
Do not create endpoints that are not required by the product.

COMPLIANCE_SPEC

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

7. COMPLIANCE_SPEC.md

Purpose: To define regulatory requirements for the industry (GDPR, HIPAA, PCI-DSS, KYC, AML).

You are a regulatory compliance expert for [INDUSTRY NAME].
Using the PRD and System Architecture below, create a Compliance Specification document for this industry hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Applicable regulations (GDPR, HIPAA, PCI-DSS, KYC, AML, etc.)
2. Data classification (PII, PHI, Financial, Public)
3. Consent and user rights requirements
4. Data retention and deletion requirements
5. Encryption requirements (At rest, In transit)
6. Access control requirements
7. Audit logging requirements
8. Breach notification requirements
9. Third-party compliance (Vendors, APIs)
10. Compliance checklist for developers
11. What NOT to do (Common compliance mistakes)

Explain each regulation in beginner-friendly language.
Keep the compliance measures practical and easy to implement within a hackathon timeframe.
Flag any compliance items that must be addressed before the demo.

INTEGRATION_SPEC

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

8. INTEGRATION_SPEC.md

Purpose: To define third-party industry APIs (banking, health records, government data).

You are a senior integration engineer specializing in [INDUSTRY NAME].
Using the PRD and API Specification below, create an Integration Specification document for this industry hackathon project.

PRD: [PASTE PRD]
API_SPEC: [PASTE API_SPECIFICATION]

For every third-party integration, provide:
1. Service name (Banking API, EHR, Government, POS, etc.)
2. Purpose in the workflow
3. Authentication method (API Key, OAuth, mTLS)
4. Required credentials and where to store them
5. Endpoint or Webhook URL
6. Request format (Headers, Body, Parameters)
7. Example request
8. Example response
9. Rate limits
10. Compliance considerations (PII, PHI, PCI)
11. Error responses and handling
12. Fallback if the service is down

Keep the integrations simple and realistic for a hackathon.
Only include integrations that are essential to the product.
Use sandbox/test environments where possible.

USER_PERSONA_MAP

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint

9. USER_PERSONA_MAP.md

Purpose: To define detailed personas for the target industry users.

You are a UX researcher specializing in [INDUSTRY NAME].
Using the PRD below, create a User Persona Map for this industry hackathon project.

PRD: [PASTE PRD]

For each key persona provide:
1. Persona name (Fictional but realistic)
2. Age and demographics
3. Job role and responsibilities
4. Industry context
5. Goals and motivations
6. Pain points (Specific to this industry)
7. Current workflow (How they solve the problem today)
8. Tech savviness (Low, Medium, High)
9. Preferred devices (Desktop, Mobile, Tablet)
10. Compliance concerns (What regulations affect them?)
11. Quote (A realistic quote from this persona)
12. How our solution helps them

Create 3-5 personas covering the main user segments.
Explain each persona in beginner-friendly language.
Use these personas to guide all design and feature decisions.

DATABASE_SCHEMA

Category: 11. Domain / Industry Hackathons
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 11. Domain / Industry Hackathons.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 11. Domain / Industry Hackathons project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 11. Domain / Industry Hackathons

Welcome to Phase 3: Execution & Quality for 11. Domain / Industry Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 11. Domain / Industry Hackathons
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define frontend design tailored to industry users and workflows.

Act as a senior UI/UX designer specializing in [INDUSTRY NAME] applications.
Using the PRD, Architecture, and User Persona Map below, create a UI Specification document for an industry hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
USER_PERSONA_MAP: [PASTE USER_PERSONA_MAP]

Provide:
1. Design system (Colors, typography, spacing)
2. Industry-specific UI patterns (Data tables, Forms, Compliance indicators)
3. Component hierarchy
4. Screen-by-screen breakdown (Dashboard, Detail, Compliance view, Reports)
5. Loading states
6. Error states
7. Empty states
8. Compliance UX (Consent screens, Audit logs, Data access indicators)
9. Responsive design guidelines (Mobile, Desktop)
10. Accessibility considerations (WCAG, Industry standards)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core industry user journey.
Ensure compliance UX is not overlooked.

ERROR_HANDLING

Category: 11. Domain / Industry Hackathons
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when industry APIs fail, compliance checks fail, or data is missing.

You are a senior engineer specializing in [INDUSTRY NAME] systems.
Using the System Architecture and API Specification below, create an Error Handling document for an industry hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Common failure modes (Industry API failures, Compliance failures, Data errors)
2. Industry API error handling (Banking, EHR, Government, POS)
3. Compliance error handling (When a compliance check fails)
4. Data validation errors
5. Frontend error display
6. Fallback responses
7. Retry logic
8. Audit logging of errors
9. Compliance notification requirements
10. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.
Highlight compliance-sensitive error scenarios.
Explain each approach in beginner-friendly language.

SECURITY

Category: 11. Domain / Industry Hackathons
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To define industry-specific security (PII, PHI, financial data).

Act as a security engineer specializing in [INDUSTRY NAME].
Using the System Architecture and Compliance Specification below, create a Security document for an industry hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Data classification (PII, PHI, Financial, Public)
2. Encryption (At rest, In transit, Key management)
3. Authentication and authorization (Industry standards)
4. Access control (RBAC, ABAC, Least privilege)
5. API security (Industry standards)
6. Data privacy (Consent, Anonymization, Retention)
7. Audit logging (What to log, Where to store)
8. Third-party security (Vendor risk, API security)
9. Industry-specific security controls
10. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Flag any security measures that are mandatory for compliance.

TESTING

Category: 11. Domain / Industry Hackathons
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist including regulatory compliance testing.

Act as a QA engineer specializing in [INDUSTRY NAME] applications.
Using the PRD and Compliance Specification below, create a Testing document for an industry hackathon project.

PRD: [PASTE PRD]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Testing strategy for industry applications
2. Functional testing (Core industry features)
3. Compliance testing (Does it meet regulations?)
4. Security testing (PII, PHI, Financial data)
5. Integration testing (Industry APIs)
6. Data validation testing
7. Edge cases (Industry-specific)
8. User acceptance testing checklist (With personas)
9. A manual testing checklist for the demo
10. How to document known compliance limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Highlight compliance-critical test cases.

EVALUATION

Category: 11. Domain / Industry Hackathons
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures industry impact and prepares for judge questions.

You are an evaluation expert specializing in [INDUSTRY NAME].
Using the PRD and Compliance Specification below, create an Evaluation document for an industry hackathon project.

PRD: [PASTE PRD]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Evaluation metrics (Industry-specific: Compliance rate, Cost reduction, Time saved, User adoption)
2. Evaluation methods (Benchmarking, User feedback, Compliance audits)
3. Benchmarking (What is the baseline industry process?)
4. Known limitations of the solution
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about [INDUSTRY NAME] and how to answer them

Focus on demonstrating that the team understands the industry, compliance, and user needs.

Phase 4: Delivery & Presentation

Category: 11. Domain / Industry Hackathons

Welcome to Phase 4: Delivery & Presentation for 11. Domain / Industry Hackathons. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 11. Domain / Industry Hackathons
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To deploy with industry compliance considerations.

Act as a DevOps engineer specializing in [INDUSTRY NAME] deployments.
Using the System Architecture and Compliance Specification below, create a Deployment document for an industry hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Deployment platforms (Industry-approved cloud providers)
2. Compliance considerations for deployment
3. Environment variables for production
4. Secrets management
5. Step-by-step deployment instructions
6. How to test the deployed application
7. Fallback plan if deployment fails during the hackathon
8. A pre-deployment compliance checklist
9. Common deployment mistakes in this industry

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Ensure compliance requirements are met before the demo.

DEMO_SCRIPT

Category: 11. Domain / Industry Hackathons
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation tailored to industry judges.

Act as an expert hackathon presentation coach specializing in [INDUSTRY NAME].
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script for an industry-focused audience.
The presentation should follow:
1. Hook (Industry-specific pain point)
2. Problem
3. Why the problem matters in this industry
4. Existing limitations
5. Our industry solution
6. How it works (Highlight compliance and industry integrations)
7. Technology
8. Demo (The most important part)
9. Innovation
10. Impact (Industry-specific: Compliance, Cost, Time)
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon unless it is industry-standard.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Address compliance and regulation in the pitch.

GLOSSARY

Category: 11. Domain / Industry Hackathons
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all industry terms so every team member can explain the tech to judges without confusion.

You are a technical writer specializing in [INDUSTRY NAME].
Using the PRD, Compliance Specification, and Architecture below, create a Glossary document for an industry hackathon project.

PRD: [PASTE PRD]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Industry-specific terms (E.g., FinTech: KYC, AML, PCI-DSS; HealthTech: EHR, HIPAA, PHI)
2. Regulatory terms
3. Technical terms
4. Integration terms
5. Compliance terms
6. Project-specific terms
7. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

12. Creative / Media / Gaming

Game mechanics, storytelling engines, generative creative workflows, and digital media.

Overview

This category provides structured prompt packs tailored for 12. Creative / Media / Gaming projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 12. Creative / Media / Gaming

Welcome to Phase 1: Problem Definition for 12. Creative / Media / Gaming. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 12. Creative / Media / Gaming
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the creative/gaming problem and identify what experience needs to be built.

I am participating in a Creative/Media/Gaming hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual creative problem being solved
2. Target audience (Players, Viewers, Users)
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing creative solutions
6. Proposed creative/media/gaming solution ideas
7. Core creative features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential tools and platforms that could be used (Unity, Unreal, Godot, Blender, WebGL)

Do not assume I am an experienced game developer or designer.
Explain creative concepts (Game Loop, Shaders, Prefabs, Narrative Design) in beginner-friendly language.

PRD

Category: 12. Creative / Media / Gaming
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear creative product plan with features, mechanics, and scope.

You are a senior creative product manager helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target audience
5. User pain points
6. Proposed creative solution
7. Product goals
8. User stories
9. Functional requirements (Include creative-specific requirements: Mechanics, Levels, Narrative, Audio)
10. Non-functional requirements (Performance, FPS, Load Time)
11. Core creative features
12. Nice-to-have features
13. User journeys (Player/User experience flow)
14. MVP scope (Which mechanic must work during the demo?)
15. Out-of-scope features
16. Success metrics (Include creative metrics: Engagement, Completion rate, Fun factor)
17. Risks and assumptions (Include creative risks: Scope creep, Asset delays, Performance drops)

Keep the MVP realistic for a 24-48 hour creative hackathon.
Do not add unnecessary mechanics just to make the project sound impressive.
Prioritize features that can actually be demonstrated live.

TRD

Category: 12. Creative / Media / Gaming
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on game engine, platform, and performance.

You are a senior game engineer helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Game engine choice (Unity, Unreal, Godot, WebGL — justify the choice)
3. Target platform (PC, Mobile, Web, Console)
4. Rendering requirements (2D, 3D, Art style)
5. Physics requirements
6. Input requirements (Keyboard, Controller, Touch, Gesture)
7. Audio requirements
8. Asset pipeline requirements
9. Performance and latency requirements (Target FPS, Memory limits)
10. Backend/Multiplayer requirements (If applicable)
11. Testing requirements
12. Deployment requirements

Keep the game stack simple and realistic for a 24-48 hour hackathon.
Explain all game dev concepts in beginner-friendly language.
Do not introduce unnecessary engines or tools.

Phase 2: Technical Blueprint

Category: 12. Creative / Media / Gaming

Welcome to Phase 2: Technical Blueprint for 12. Creative / Media / Gaming. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic game/media architecture with clear data flow.

Act as a senior game architect.
Using the following PRD and TRD, design a realistic hackathon game architecture.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended game engine stack (Engine, Language, Tools)
2. Complete architecture diagram (Text-based, showing Input → Game Loop → Systems → Rendering → Output)
3. Core systems architecture (Input, Physics, AI, Audio, UI)
4. Scene management architecture
5. Asset pipeline architecture
6. Data persistence architecture (Save games, High scores)
7. Multiplayer/Backend architecture (If applicable)
8. Data flow (How a player action becomes a visual result)
9. Performance considerations
10. Folder structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools. Prefer a simple architecture that can be explained easily to judges.

GAME_DESIGN_DOC

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

5. GAME_DESIGN_DOC.md

Purpose: To define core mechanics, game loop, levels, and player progression.

Act as a senior game designer.
Using the PRD and System Architecture below, create a Game Design Document (GDD) for this creative hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Core gameplay loop (What does the player do repeatedly?)
2. Game mechanics (Movement, Combat, Puzzle, Exploration)
3. Player progression (Levels, Upgrades, Rewards)
4. Level design (Layout, Objectives, Difficulty curve)
5. Game states (Menu, Playing, Paused, Game Over, Victory)
6. Win/Lose conditions
7. Enemy/NPC behavior (If applicable)
8. Scoring system
9. Replayability factors
10. Example player session (Step-by-step)
11. A checklist for verifying game design before the demo

Explain each mechanic in beginner-friendly language.
Keep the design simple and achievable for a hackathon.
Focus on one core mechanic done well, rather than many done poorly.

NARRATIVE_SPEC

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

6. NARRATIVE_SPEC.md

Purpose: To define story structure, characters, dialogue, and branching paths.

You are a senior narrative designer.
Using the PRD and Game Design Document below, create a Narrative Specification document for this creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Story premise (One-paragraph summary)
2. Setting and world-building
3. Main characters (Protagonist, Antagonist, Supporting)
4. Character arcs (Brief)
5. Story structure (Beginning, Middle, End)
6. Dialogue system (Linear, Branching, Choices)
7. Branching paths (If applicable)
8. Environmental storytelling
9. Narrative pacing (How story is revealed)
10. Example dialogue script (For one scene)
11. A checklist for verifying narrative before the demo

If the project is not narrative-driven (e.g., a tool or abstract game), explain how narrative elements can still enhance the experience.
Keep the narrative simple and impactful for a hackathon.

ASSET_PIPELINE

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

7. ASSET_PIPELINE.md

Purpose: To define 3D models, textures, animations, and asset optimization.

Act as a senior technical artist.
Using the PRD and Game Design Document below, create an Asset Pipeline document for this creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Art style (Realistic, Stylized, Pixel, Low-poly)
2. 3D model requirements (Poly count, Format, Scale)
3. 2D asset requirements (Sprites, UI, Textures)
4. Texture requirements (Resolution, Format, Compression)
5. Animation requirements (Rigging, Clips, Blend trees)
6. VFX requirements (Particles, Shaders, Post-processing)
7. Asset import workflow (Blender → Engine)
8. Asset optimization (LODs, Batching, Atlasing)
9. Naming conventions
10. Folder structure for assets
11. Free asset sources (Kenney, Sketchfab, Mixamo, itch.io)
12. A checklist for verifying assets before the demo

Explain each concept in beginner-friendly language.
Keep the asset pipeline simple and realistic for a hackathon.
Prioritize free and fast assets over custom work.

SOUND_DESIGN

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

8. SOUND_DESIGN.md

Purpose: To define music, sound effects, voice acting, and audio implementation.

You are a senior sound designer.
Using the PRD and Game Design Document below, create a Sound Design document for this creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Audio style (Orchestral, Electronic, Ambient, Retro)
2. Music requirements (Menu, Gameplay, Boss, Victory)
3. Sound effects list (Movement, Combat, UI, Environment)
4. Voice acting requirements (If applicable)
5. Audio implementation (Engine audio system)
6. Spatial audio (3D sound, Distance, Occlusion)
7. Audio mixing (Volume levels, Ducking)
8. Audio optimization (Compression, Format, Streaming)
9. Free audio sources (Freesound, Pixabay, incompetech, ZapSplat)
10. A checklist for verifying audio before the demo

Explain each concept in beginner-friendly language.
Keep the sound design simple and impactful for a hackathon.
Prioritize free and fast audio assets over custom work.

INTERACTION_SPEC

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint

9. INTERACTION_SPEC.md

Purpose: To define player controls, input mapping, and interaction states.

You are a senior interaction designer.
Using the PRD and Game Design Document below, create an Interaction Specification document for this creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Input methods (Keyboard, Mouse, Controller, Touch)
2. Input mappings (What button does what)
3. Character/Player movement (Walk, Run, Jump, Crouch)
4. Camera controls (Follow, Orbit, First-person, Third-person)
5. Interaction mechanics (Select, Grab, Use, Talk)
6. Combat mechanics (Attack, Block, Dodge — if applicable)
7. UI interactions (Menu navigation, Inventory)
8. Feedback (Visual, Audio, Haptic)
9. Input buffering and responsiveness
10. Accessibility controls (Remappable keys, Sensitivity)
11. Example interaction flow
12. A checklist for verifying interactions before the demo

Explain each interaction in beginner-friendly language.
Keep the interaction design simple and intuitive for a hackathon.

DATABASE_SCHEMA

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 12. Creative / Media / Gaming.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 12. Creative / Media / Gaming project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

API_SPECIFICATION

Category: 12. Creative / Media / Gaming
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for API_SPECIFICATION in 12. Creative / Media / Gaming.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 12. Creative / Media / Gaming project.
Generate the API_SPECIFICATION covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 12. Creative / Media / Gaming

Welcome to Phase 3: Execution & Quality for 12. Creative / Media / Gaming. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 12. Creative / Media / Gaming
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define the HUD design, menus, and user flow.

Act as a senior game UI/UX designer.
Using the PRD and Game Design Document below, create a UI Specification document for a creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Design system (Colors, typography, spacing)
2. HUD design (Health, Score, Ammo, Minimap)
3. Menu screens (Main Menu, Pause, Settings, Game Over)
4. Component hierarchy
5. Screen-by-screen breakdown
6. Interaction states (Idle, Hover, Selected, Disabled)
7. Loading states (Skeletons, progress bars)
8. Error states (Save failed, Connection lost)
9. Empty states (No saves yet)
10. Responsive design guidelines (PC, Mobile)
11. Accessibility considerations (Contrast, Text size, Color blindness)

Keep the UI simple, clean, and realistic for a 24-48 hour hackathon.
Focus on demonstrating the core gameplay journey.

ERROR_HANDLING

Category: 12. Creative / Media / Gaming
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when assets fail to load, frame rate drops, or input breaks.

You are a senior game developer.
Using the System Architecture and Game Design Document below, create an Error Handling document for a creative hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Common failure modes (Asset load failure, Frame drop, Input loss, Crash)
2. Asset loading error handling (Fallback assets, Retry)
3. Performance error handling (Dynamic resolution, Quality scaling)
4. Input error handling (Reconnect controller, Reset input)
5. Save/Load error handling
6. Audio error handling (Missing sound, Fallback silence)
7. Frontend error display (Error modals, In-game notifications)
8. Crash recovery (Auto-save, State restore)
9. A checklist for developers to verify error handling before the demo

Focus on making the game resilient so the live demo does not crash.
Explain each error handling approach in beginner-friendly language.

SECURITY

Category: 12. Creative / Media / Gaming
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To secure asset protection, anti-cheat, and user data privacy.

Act as a game security engineer.
Using the System Architecture and PRD below, create a Security document for a creative hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Asset protection (Anti-rip, Encryption, Obfuscation)
2. Anti-cheat (If multiplayer or leaderboard)
3. Save file integrity (Prevent tampering)
4. User data privacy (What data is collected?)
5. Network security (If multiplayer)
6. API key protection (If using external services)
7. Age-appropriate content (If targeting younger audiences)
8. Compliance considerations (COPPA, GDPR for games)
9. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.

TESTING

Category: 12. Creative / Media / Gaming
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist for games, playtesting, and edge cases.

Act as a QA engineer specializing in games.
Using the PRD and Game Design Document below, create a Testing document for a creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Testing strategy for games
2. Functional testing (Core mechanics)
3. Progression testing (Levels, Save/Load)
4. Performance testing (FPS, Memory, Load times)
5. Input testing (All controls, Remapping)
6. Audio testing (Music, SFX, Spatial audio)
7. UI testing (Menus, HUD, Settings)
8. Edge cases (Spamming inputs, Pausing mid-action, Alt-tab)
9. Playtesting checklist (Fun factor, Confusion points, Difficulty)
10. Bug reporting template
11. A manual testing checklist for the demo
12. How to document known limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Focus on testing the core gameplay loop.

EVALUATION

Category: 12. Creative / Media / Gaming
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how the team measures creative impact and prepares for judge questions.

You are a game evaluation expert.
Using the PRD and Game Design Document below, create an Evaluation document for a creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]

Provide:
1. Evaluation metrics (FPS, Player engagement, Completion rate, Fun factor)
2. Evaluation methods (Playtesting, Surveys, Telemetry)
3. Benchmarking (What is the baseline?)
4. Known limitations of the game
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about games and how to answer them

Focus on demonstrating that the team understands the game's capabilities and boundaries.

Phase 4: Delivery & Presentation

Category: 12. Creative / Media / Gaming

Welcome to Phase 4: Delivery & Presentation for 12. Creative / Media / Gaming. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 12. Creative / Media / Gaming
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define how to build and deploy to target platforms.

Act as a game deployment engineer.
Using the System Architecture and PRD below, create a Deployment document for a creative hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Target platform (WebGL, PC, Mobile, Console)
2. Build settings (Development, Release, Optimization)
3. Deployment steps for each platform (itch.io, Steam, Web host, App Store)
4. Environment variables for production
5. How to test the deployed build
6. Fallback plan if deployment fails during the hackathon
7. A pre-deployment checklist
8. Common deployment mistakes and how to avoid them

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working live demo as early as possible.
For WebGL, prioritize fast loading and browser compatibility.

DEMO_SCRIPT

Category: 12. Creative / Media / Gaming
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation, ensuring the game is shown off perfectly.

Act as an expert hackathon presentation coach specializing in games.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]
DEMO FLOW: [PASTE PLAYER JOURNEY]

Create a compelling hackathon presentation script.
The presentation should follow:
1. Hook
2. Problem/Concept
3. Why it matters
4. Existing limitations
5. Our creative solution
6. How it works (Core game loop, Tech)
7. Technology (Unity, Unreal, WebGL, etc.)
8. Demo (The most important part — show live gameplay)
9. Innovation
10. Impact
11. Future scope
12. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots, pre-recorded gameplay).

GLOSSARY

Category: 12. Creative / Media / Gaming
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all game and media terms so every team member can explain the tech to judges without confusion.

You are a technical writer.
Using the PRD, Game Design Document, and Architecture below, create a Glossary document for a creative hackathon project.

PRD: [PASTE PRD]
GAME_DESIGN_DOC: [PASTE GAME_DESIGN_DOC]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Game design terms (Game Loop, Mechanic, Level Design, Progression)
2. Technical terms (FPS, Draw Call, Shader, Prefab, LOD)
3. Art terms (Rigging, Skinning, Texture, Sprite, VFX)
4. Audio terms (SFX, OST, Foley, Spatial Audio, Ducking)
5. Narrative terms (Branching, Dialogue Tree, Arc, Lore)
6. Engine terms (Unity, Unreal, Godot, GameObject, Scene)
7. Project-specific terms (Any custom terminology used in the PRD)
8. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

Public good technologies, accessibility-first platforms, sustainability, and community impact.

Overview

This category provides structured prompt packs tailored for 13. Social Impact / Civic projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 13. Social Impact / Civic

Welcome to Phase 1: Problem Definition for 13. Social Impact / Civic. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 13. Social Impact / Civic
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the social problem, affected communities, and existing gaps.

I am participating in a Social Impact/Civic hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual social problem being solved
2. Affected communities and target users
3. User pain points (Social, Economic, Cultural)
4. Existing ways people or organizations solve this problem
5. Limitations of existing social/civic solutions
6. Proposed social impact solution ideas
7. Core features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique
11. A realistic MVP that can be built during a hackathon
12. Potential technologies, open data sources, and NGO/government APIs that could be used

Do not assume I am an expert in social work or civic tech.
Explain social impact concepts (Digital Divide, Last-Mile, Inclusion) in beginner-friendly language.
Highlight ethical considerations for vulnerable populations.

PRD

Category: 13. Social Impact / Civic
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear social impact plan with features, beneficiaries, and impact metrics.

You are a senior product manager specializing in social impact, helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement (Social context)
4. Target users (Beneficiaries, NGOs, Government, Volunteers)
5. User pain points
6. Proposed solution
7. Product goals (Social impact goals)
8. User stories
9. Functional requirements (Include accessibility and low-bandwidth requirements)
10. Non-functional requirements (Inclusion, Privacy, Accessibility, Offline capability)
11. Core features
12. Nice-to-have features
13. User journeys (How a beneficiary accesses and benefits)
14. MVP scope (Which feature must work during the demo?)
15. Out-of-scope features
16. Impact metrics (Lives improved, Access gained, Cost saved, Time saved)
17. Risks and assumptions (Include ethical risks, Digital Divide, Adoption barriers)

Keep the MVP realistic for a 24-48 hour hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that can actually be demonstrated live and create real impact.

TRD

Category: 13. Social Impact / Civic
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on accessibility, low-bandwidth, and open-source tools.

You are a senior engineer specializing in civic tech, helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Tech stack choice (Framework, Language, Database — justify for social impact)
3. Accessibility requirements (WCAG 2.1 AA, Screen readers, Keyboard-only)
4. Low-bandwidth and offline-first requirements
5. Multilingual and localization requirements
6. Open data and government API integrations
7. Data privacy and consent requirements
8. Security requirements for vulnerable populations
9. Performance and latency requirements (Low-end devices, Slow networks)
10. Deployment requirements (Low-cost, Scalable, Free-tier friendly)
11. Testing requirements (Including accessibility and community testing)
12. Sustainability requirements (How will this be maintained post-hackathon?)

Keep the tech stack simple, free, and realistic for a 24-48 hour hackathon.
Explain all concepts in beginner-friendly language.
Prioritize open-source and free-tier tools.
Flag any ethical concerns early.

Phase 2: Technical Blueprint

Category: 13. Social Impact / Civic

Welcome to Phase 2: Technical Blueprint for 13. Social Impact / Civic. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic social impact architecture with clear data flow and accessibility.

Act as a senior architect specializing in civic tech.
Using the following PRD and TRD, design a realistic hackathon architecture for this social impact project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended tech stack (Frontend, Backend, Database, Integrations)
2. Complete system architecture diagram (Text-based, showing Users → Frontend → Backend → Data Sources → Impact)
3. Frontend architecture (Accessible, Low-bandwidth)
4. Backend architecture
5. Database architecture (Ethical data handling)
6. Integration architecture (Government APIs, NGO data, Open Data)
7. Accessibility architecture (Screen readers, Keyboard nav, Voice)
8. Offline-first architecture (If applicable)
9. Data flow (How a beneficiary's action creates impact)
10. Security and privacy considerations
11. Folder structure
12. Major components
13. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools.
Prioritize accessibility and inclusion at every layer.

STAKEHOLDER_MAP

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

5. STAKEHOLDER_MAP.md

Purpose: To define all stakeholders, their needs, and relationships.

Act as a senior social impact strategist.
Using the PRD and System Architecture below, create a Stakeholder Map for this social impact hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Primary beneficiaries (Who directly benefits?)
2. Secondary beneficiaries (Who indirectly benefits?)
3. Implementing organizations (NGOs, Government, Community groups)
4. Funders and supporters (CSR, Grants, Donors)
5. Technical partners (Open-source communities, API providers)
6. Regulators and policymakers
7. For each stakeholder:
   - Their needs
   - Their pain points
   - How they interact with the solution
   - Their success metrics
8. Stakeholder relationships (Who influences whom?)
9. Power dynamics and considerations
10. Engagement strategy (How to involve stakeholders)
11. A checklist for verifying stakeholder alignment before the demo

Explain each stakeholder in beginner-friendly language.
Keep the stakeholder map simple and actionable.
Focus on the most critical stakeholders for the MVP.

API_SPECIFICATION

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

6. API_SPECIFICATION.md

Purpose: To define endpoints including government/NGO integrations.

You are a senior backend developer specializing in civic tech.
Using the PRD, Architecture, and Stakeholder Map below, create a complete API specification for this social impact hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
STAKEHOLDER_MAP: [PASTE STAKEHOLDER_MAP]

For every endpoint provide:
1. HTTP method
2. URL
3. Purpose
4. Authentication requirement
5. Privacy and consent requirements
6. Request parameters
7. Request body
8. Example request
9. Example success response
10. Possible error responses
11. HTTP status codes
12. Data minimization (What data is NOT collected?)

Include endpoints for government/NGO integrations (Open Data, Eligibility checks, Reporting).
Keep the API simple and consistent.
Do not create endpoints that are not required by the product.
Prioritize privacy and data minimization.

ACCESSIBILITY_SPEC

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

7. ACCESSIBILITY_SPEC.md

Purpose: To define WCAG compliance, inclusive design, and assistive tech support.

You are an accessibility expert specializing in inclusive design.
Using the PRD and System Architecture below, create an Accessibility Specification document for this social impact hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. WCAG 2.1 AA compliance checklist
2. Visual accessibility (Contrast, Text size, Color blindness)
3. Motor accessibility (Keyboard navigation, Touch targets, Voice control)
4. Auditory accessibility (Captions, Transcripts, Visual alerts)
5. Cognitive accessibility (Simple language, Clear navigation, Consistency)
6. Screen reader compatibility (ARIA, Semantic HTML)
7. Multilingual and localization support
8. Low-literacy design considerations
9. Assistive technology compatibility
10. Testing tools and methods (axe, WAVE, Screen readers)
11. A pre-submission accessibility checklist

Explain each rule in beginner-friendly language.
Provide code examples where useful (ARIA, semantic HTML).
Keep accessibility practical and central to the design, not an afterthought.

IMPACT_MEASUREMENT

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

8. IMPACT_MEASUREMENT.md

Purpose: To define how impact will be measured, tracked, and reported.

You are a social impact measurement expert.
Using the PRD and Stakeholder Map below, create an Impact Measurement document for this social impact hackathon project.

PRD: [PASTE PRD]
STAKEHOLDER_MAP: [PASTE STAKEHOLDER_MAP]

Provide:
1. Theory of Change (Inputs → Activities → Outputs → Outcomes → Impact)
2. Key Impact Indicators (KPIs)
3. Quantitative metrics (Numbers, Percentages, Cost savings)
4. Qualitative metrics (Stories, Testimonials, Behavior change)
5. Data collection methods (Surveys, Interviews, Usage data)
6. Baseline and targets
7. Measurement frequency (Daily, Weekly, Monthly)
8. Reporting format (For judges, NGOs, Funders)
9. Data ethics in measurement (Consent, Anonymity)
10. A checklist for verifying impact measurement before the demo

Explain each metric in beginner-friendly language.
Keep the impact measurement simple and demonstrable within a hackathon timeframe.
Focus on metrics that can be shown live during the demo.

DATA_ETHICS

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint

9. DATA_ETHICS.md

Purpose: To define ethical handling of vulnerable populations' data.

You are a data ethics expert specializing in social impact.
Using the PRD and Stakeholder Map below, create a Data Ethics document for this social impact hackathon project.

PRD: [PASTE PRD]
STAKEHOLDER_MAP: [PASTE STAKEHOLDER_MAP]

Provide:
1. Ethical principles (Do no harm, Informed consent, Data minimization)
2. Vulnerable population considerations
3. Consent management (How is consent obtained and recorded?)
4. Data minimization (What data is NOT collected?)
5. Data anonymization and pseudonymization
6. Data storage and retention (How long? Where?)
7. Data sharing rules (Who can access what?)
8. Right to deletion and correction
9. Transparency (How is data use communicated?)
10. Bias and fairness considerations
11. A pre-submission data ethics checklist

Explain each principle in beginner-friendly language.
Keep the data ethics practical and enforceable within a hackathon timeframe.
Flag any ethical red flags that must be addressed.

DATABASE_SCHEMA

Category: 13. Social Impact / Civic
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 13. Social Impact / Civic.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 13. Social Impact / Civic project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 13. Social Impact / Civic

Welcome to Phase 3: Execution & Quality for 13. Social Impact / Civic. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 13. Social Impact / Civic
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define frontend design focused on inclusion and accessibility.

Act as a senior UI/UX designer specializing in inclusive design.
Using the PRD, Architecture, and Accessibility Spec below, create a UI Specification document for a social impact hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
ACCESSIBILITY_SPEC: [PASTE ACCESSIBILITY_SPEC]

Provide:
1. Design system (Colors, typography, spacing)
2. Inclusive design patterns (Simple navigation, Clear language, Visual cues)
3. Component hierarchy
4. Screen-by-screen breakdown (Onboarding, Core feature, Help, Settings)
5. Low-bandwidth design (Minimal images, Fast loading)
6. Loading states
7. Error states (Simple, actionable errors)
8. Empty states
9. Multilingual and localization design
10. Responsive design guidelines (Mobile-first for low-end devices)
11. Accessibility considerations (WCAG 2.1 AA)

Keep the UI simple, clean, and accessible for a 24-48 hour hackathon.
Focus on demonstrating the core beneficiary journey.
Design for the lowest common denominator (low-end device, slow network, low literacy).

ERROR_HANDLING

Category: 13. Social Impact / Civic
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when government APIs fail, data is missing, or users have low connectivity.

You are a senior engineer specializing in civic tech.
Using the System Architecture and API Specification below, create an Error Handling document for a social impact hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Common failure modes (Government API failures, Data missing, Low connectivity)
2. Government/NGO API error handling
3. Data validation errors
4. Offline error handling (Queue, Retry, Sync)
5. Low-bandwidth error handling (Reduce payload, Fallback to SMS/USSD)
6. Frontend error display (Simple, multilingual, actionable)
7. Fallback responses
8. Retry logic
9. Recovery procedures
10. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.
Ensure errors are understandable to non-technical users.
Explain each approach in beginner-friendly language.

SECURITY

Category: 13. Social Impact / Civic
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To define data privacy for vulnerable populations, consent, and compliance.

Act as a security and privacy engineer specializing in civic tech.
Using the System Architecture and Data Ethics document below, create a Security document for a social impact hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
DATA_ETHICS: [PASTE DATA_ETHICS]

Provide:
1. Data classification (Sensitive, Personal, Public)
2. Encryption (At rest, In transit, Key management)
3. Authentication and authorization (Simple, accessible)
4. Consent management (How consent is stored and respected)
5. Data minimization (Only collect what is needed)
6. Anonymization and pseudonymization
7. Access control (Who can view what?)
8. Audit logging (Who accessed what, when)
9. Breach notification plan
10. Compliance (GDPR, Local data protection laws)
11. A pre-submission security and privacy checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Prioritize the safety of vulnerable populations.

TESTING

Category: 13. Social Impact / Civic
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist including accessibility testing and community validation.

Act as a QA engineer specializing in social impact applications.
Using the PRD and Accessibility Spec below, create a Testing document for a social impact hackathon project.

PRD: [PASTE PRD]
ACCESSIBILITY_SPEC: [PASTE ACCESSIBILITY_SPEC]

Provide:
1. Testing strategy for social impact applications
2. Functional testing (Core features)
3. Accessibility testing (Screen readers, Keyboard, Contrast)
4. Low-bandwidth testing (Slow network, Offline)
5. Low-end device testing
6. Multilingual testing
7. Integration testing (Government/NGO APIs)
8. Edge cases (Missing data, Vulnerable user scenarios)
9. Community validation (Testing with real users or proxies)
10. A manual testing checklist for the demo
11. How to document known limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Prioritize accessibility and inclusion in all tests.

EVALUATION

Category: 13. Social Impact / Civic
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how you measure social impact and prepare for judge questions.

You are a social impact evaluation expert.
Using the PRD and Impact Measurement document below, create an Evaluation document for a social impact hackathon project.

PRD: [PASTE PRD]
IMPACT_MEASUREMENT: [PASTE IMPACT_MEASUREMENT]

Provide:
1. Evaluation metrics (Lives improved, Access gained, Cost saved, Time saved)
2. Evaluation methods (Surveys, Interviews, Usage data, Case studies)
3. Benchmarking (What is the baseline social problem?)
4. Known limitations of the solution
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about social impact and how to answer them
8. Ethical considerations in evaluation (Do no harm)

Focus on demonstrating that the team understands the social problem, the community, and the impact.
Use real stories and data where possible.

Phase 4: Delivery & Presentation

Category: 13. Social Impact / Civic

Welcome to Phase 4: Delivery & Presentation for 13. Social Impact / Civic. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 13. Social Impact / Civic
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To deploy with low-bandwidth, offline-first, and accessibility considerations.

Act as a DevOps engineer specializing in civic tech.
Using the System Architecture and Accessibility Spec below, create a Deployment document for a social impact hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
ACCESSIBILITY_SPEC: [PASTE ACCESSIBILITY_SPEC]

Provide:
1. Deployment platforms (Free-tier, Low-cost, Scalable)
2. Low-bandwidth deployment considerations (CDN, Compression, Minimal assets)
3. Offline-first deployment (Service workers, PWA)
4. Accessibility considerations for deployment
5. Environment variables for production
6. Step-by-step deployment instructions
7. How to test the deployed application
8. Fallback plan if deployment fails during the hackathon
9. A pre-deployment accessibility and impact checklist
10. Common deployment mistakes in civic tech

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Focus on getting a working, accessible live demo as early as possible.
Prioritize free and sustainable hosting.

DEMO_SCRIPT

Category: 13. Social Impact / Civic
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation tailored to impact judges.

Act as an expert hackathon presentation coach specializing in social impact.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
IMPACT_MEASUREMENT: [PASTE IMPACT_MEASUREMENT]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script for a social impact audience.
The presentation should follow:
1. Hook (A human story or statistic)
2. Problem (The social problem)
3. Why the problem matters
4. Existing limitations
5. Our solution
6. How it works (Highlight accessibility and inclusion)
7. Technology
8. Demo (The most important part — show real impact)
9. Impact (Stories, Numbers, Theory of Change)
10. Future scope (Scalability, Sustainability, Community ownership)
11. Closing (Call to action)

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Focus on the human impact, not just the technology.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots, beneficiary testimonials).

GLOSSARY

Category: 13. Social Impact / Civic
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all civic and social impact terms so every team member can explain the project to judges without confusion.

You are a technical writer specializing in civic tech.
Using the PRD, Impact Measurement, and Architecture below, create a Glossary document for a social impact hackathon project.

PRD: [PASTE PRD]
IMPACT_MEASUREMENT: [PASTE IMPACT_MEASUREMENT]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Social impact terms (Beneficiary, Theory of Change, Last-Mile, Digital Divide)
2. Civic tech terms (Open Data, GovTech, Civic Participation, Public Good)
3. Accessibility terms (WCAG, ARIA, Screen Reader, Assistive Tech)
4. NGO/Government terms (CSR, Grant, Policy, Stakeholder, M&E)
5. Data ethics terms (Consent, Anonymization, Data Minimization, Do No Harm)
6. Technical terms (Offline-first, PWA, Low-bandwidth)
7. Project-specific terms (Any custom terminology used in the PRD)
8. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy**

14. Open Innovation / Corporate

Corporate innovation sprints, partner integrations, stakeholder alignment, and venture models.

Overview

This category provides structured prompt packs tailored for 14. Open Innovation / Corporate projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 14. Open Innovation / Corporate

Welcome to Phase 1: Problem Definition for 14. Open Innovation / Corporate. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 14. Open Innovation / Corporate
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the corporate problem, business goals, and market gaps.

I am participating in a corporate/open innovation hackathon and I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual business problem being solved
2. Target users (Internal teams, Customers, Partners)
3. User pain points (Business, Operational, Technical)
4. Existing ways the company or industry solves this problem
5. Limitations of existing corporate solutions
6. Proposed innovation/solution ideas
7. Core business features
8. Nice-to-have features
9. What should NOT be built during a short hackathon
10. What could make this solution unique in the corporate context
11. A realistic MVP that can be built during a hackathon
12. Potential enterprise technologies and integration points

Do not assume I am an expert in corporate strategy.
Explain business concepts (ROI, KPI, SLA, Stakeholder) in beginner-friendly language.
Highlight how the solution aligns with the sponsor's goals.

PRD

Category: 14. Open Innovation / Corporate
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear corporate solution plan with features, business value, and scope.

You are a senior product manager specializing in enterprise innovation, helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement (Corporate context)
4. Target users (Internal teams, Customers, Partners)
5. User pain points
6. Proposed solution
7. Product goals (Business goals)
8. User stories
9. Functional requirements (Include enterprise integration and scalability requirements)
10. Non-functional requirements (Security, Compliance, SLA, Performance)
11. Core business features
12. Nice-to-have features
13. User journeys (Enterprise workflow)
14. MVP scope (Which feature must work during the demo?)
15. Out-of-scope features
16. Business metrics (ROI, Cost savings, Efficiency gains, User adoption)
17. Risks and assumptions (Include corporate risks, IP concerns, Integration challenges)

Keep the MVP realistic for a 24-48 hour hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that can actually be demonstrated live and deliver clear business value.

TRD

Category: 14. Open Innovation / Corporate
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on enterprise architecture, security, and integration.

You are a senior enterprise architect helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Enterprise tech stack choice (Framework, Language, Database — justify for corporate)
3. Integration with existing enterprise systems (ERP, CRM, HRIS)
4. Security and compliance requirements (SSO, IAM, Encryption)
5. Scalability requirements (From MVP to enterprise-wide)
6. API and microservices architecture
7. Data governance and privacy requirements
8. Performance and SLA requirements
9. Disaster recovery and business continuity
10. Testing requirements (UAT, Integration, Regression)
11. Deployment requirements (On-prem, Cloud, Hybrid)
12. Maintenance and support requirements

Keep the tech stack simple but enterprise-ready for a 24-48 hour hackathon.
Explain all enterprise concepts in beginner-friendly language.
Do not introduce unnecessary tools.
Flag any integration challenges early.

Phase 2: Technical Blueprint

Category: 14. Open Innovation / Corporate

Welcome to Phase 2: Technical Blueprint for 14. Open Innovation / Corporate. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic enterprise-grade architecture with clear data flow and scalability.

Act as a senior enterprise architect.
Using the following PRD and TRD, design a realistic hackathon architecture for this corporate project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended enterprise tech stack (Frontend, Backend, Database, Integrations)
2. Complete system architecture diagram (Text-based, showing Users → Frontend → Backend → Enterprise Systems → Database)
3. Frontend architecture (B2B/Enterprise UX)
4. Backend architecture (Microservices, API Gateway)
5. Database architecture (Enterprise data model)
6. Integration architecture (ERP, CRM, HRIS, Legacy systems)
7. Security and compliance architecture (SSO, IAM)
8. Scalability architecture (Horizontal, Vertical, Auto-scaling)
9. Data flow (How a user action triggers enterprise workflows)
10. Folder structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools.
Highlight enterprise-grade considerations at each layer.
Prioritize alignment with the sponsor's existing stack.

BUSINESS_MODEL

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

5. BUSINESS_MODEL.md

Purpose: To define the value proposition, revenue model, and corporate alignment.

Act as a senior business strategist.
Using the PRD and System Architecture below, create a Business Model document for this corporate hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Value proposition (One sentence)
2. Problem-solution fit
3. Target customer segments (Internal, External)
4. Revenue model (If applicable: Subscription, Licensing, Internal cost savings)
5. Cost structure (Build, Run, Maintain)
6. Key partnerships (Vendors, Integrators)
7. Key activities and resources
8. Distribution channels (How the solution reaches users)
9. Corporate alignment (How it fits the sponsor's strategy)
10. Competitive advantage (Why this solution is better)
11. Scalability potential (From hackathon to enterprise)
12. A checklist for verifying business model before the demo

Explain each concept in beginner-friendly language.
Keep the business model simple and realistic for a hackathon.
Focus on demonstrating clear business value to judges.

API_SPECIFICATION

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

6. API_SPECIFICATION.md

Purpose: To define endpoints including enterprise system integrations.

You are a senior backend developer specializing in enterprise systems.
Using the PRD, Architecture, and Business Model below, create a complete API specification for this corporate hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
BUSINESS_MODEL: [PASTE BUSINESS_MODEL]

For every endpoint provide:
1. HTTP method
2. URL
3. Purpose
4. Authentication requirement (SSO, OAuth, API Key)
5. Enterprise integration (ERP, CRM, HRIS)
6. Request parameters
7. Request body
8. Example request
9. Example success response
10. Possible error responses
11. HTTP status codes
12. SLA and rate limits

Include endpoints for enterprise integrations.
Keep the API simple and consistent.
Do not create endpoints that are not required by the product.
Prioritize security and compliance.

COMPLIANCE_SPEC

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

7. COMPLIANCE_SPEC.md

Purpose: To define corporate compliance, IP protection, and data governance.

You are a corporate compliance expert.
Using the PRD and System Architecture below, create a Compliance Specification document for this corporate hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Applicable regulations (GDPR, HIPAA, SOX, Industry-specific)
2. Intellectual Property (IP) considerations (Who owns the code?)
3. Data classification (Public, Internal, Confidential, Restricted)
4. Data governance (Ownership, Access, Retention)
5. Consent and user rights requirements
6. Encryption requirements (At rest, In transit)
7. Access control requirements (RBAC, ABAC)
8. Audit logging requirements
9. Third-party vendor compliance
10. Compliance checklist for developers
11. What NOT to do (Common corporate compliance mistakes)

Explain each regulation in beginner-friendly language.
Keep the compliance measures practical and easy to implement within a hackathon timeframe.
Flag any compliance items that must be addressed before the demo, especially regarding IP and data sharing.

STAKEHOLDER_MAP

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

8. STAKEHOLDER_MAP.md

Purpose: To define all corporate stakeholders, sponsors, and internal teams.

You are a senior corporate strategist.
Using the PRD and Business Model below, create a Stakeholder Map for this corporate hackathon project.

PRD: [PASTE PRD]
BUSINESS_MODEL: [PASTE BUSINESS_MODEL]

Provide:
1. Primary stakeholders (Sponsors, Judges, Product Owners)
2. End-users (Internal teams, Customers)
3. Technical stakeholders (IT, Security, Architecture)
4. Business stakeholders (Sales, Marketing, Operations)
5. Executive sponsors
6. For each stakeholder:
   - Their needs
   - Their pain points
   - How they interact with the solution
   - Their success metrics
7. Stakeholder relationships (Who influences whom?)
8. Power dynamics and considerations
9. Engagement strategy (How to involve stakeholders during the hackathon)
10. A checklist for verifying stakeholder alignment before the demo

Explain each stakeholder in beginner-friendly language.
Keep the stakeholder map simple and actionable.
Focus on the most critical stakeholders for the MVP and judging.

SCALABILITY_SPEC

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint

9. SCALABILITY_SPEC.md

Purpose: To define how the solution scales from MVP to enterprise-wide deployment.

You are a senior scalability architect.
Using the System Architecture and PRD below, create a Scalability Specification document for this corporate hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. Current scale (MVP for hackathon)
2. Target scale (Enterprise-wide)
3. Scaling dimensions (Users, Transactions, Data volume)
4. Horizontal vs Vertical scaling strategy
5. Database scaling (Sharding, Replication, Caching)
6. Application scaling (Load balancing, Auto-scaling)
7. API scaling (Rate limiting, Throttling, API Gateway)
8. Infrastructure scaling (Cloud, On-prem, Hybrid)
9. Performance benchmarks and targets
10. Cost implications of scaling
11. Bottlenecks and mitigation strategies
12. A checklist for verifying scalability before the demo

Explain each concept in beginner-friendly language.
Keep the scalability plan realistic for a hackathon.
Focus on showing judges that the solution can grow.

DATABASE_SCHEMA

Category: 14. Open Innovation / Corporate
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 14. Open Innovation / Corporate.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 14. Open Innovation / Corporate project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 14. Open Innovation / Corporate

Welcome to Phase 3: Execution & Quality for 14. Open Innovation / Corporate. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 14. Open Innovation / Corporate
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define frontend design focused on B2B/Enterprise UX.

Act as a senior UI/UX designer specializing in enterprise applications.
Using the PRD, Architecture, and Stakeholder Map below, create a UI Specification document for a corporate hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
STAKEHOLDER_MAP: [PASTE STAKEHOLDER_MAP]

Provide:
1. Design system (Colors, typography, spacing)
2. Enterprise UI patterns (Data tables, Dashboards, Forms, Reports)
3. Component hierarchy
4. Screen-by-screen breakdown (Dashboard, Detail, Admin, Reports)
5. Loading states
6. Error states
7. Empty states
8. Data visualization (Charts, KPIs, Metrics)
9. Responsive design guidelines (Desktop-first for enterprise)
10. Accessibility considerations (WCAG, Enterprise standards)

Keep the UI simple, clean, and enterprise-ready for a 24-48 hour hackathon.
Focus on demonstrating the core business workflow and value.
Design for power users who need efficiency over aesthetics.

ERROR_HANDLING

Category: 14. Open Innovation / Corporate
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when enterprise APIs fail, SLAs are breached, or systems go down.

You are a senior enterprise engineer.
Using the System Architecture and API Specification below, create an Error Handling document for a corporate hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Common failure modes (Enterprise API failures, SLA breaches, System downtime)
2. Enterprise API error handling (ERP, CRM, HRIS)
3. SLA breach handling (Notifications, Escalation)
4. Data validation errors
5. Frontend error display (Actionable, Enterprise-appropriate)
6. Fallback responses (Graceful degradation)
7. Retry logic (Exponential backoff, Circuit breakers)
8. Audit logging of errors
9. Notification requirements (Who is notified?)
10. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.
Highlight enterprise-critical error scenarios.
Explain each approach in beginner-friendly language.

SECURITY

Category: 14. Open Innovation / Corporate
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To define enterprise-grade security, SSO, IAM, and data encryption.

Act as an enterprise security engineer.
Using the System Architecture and Compliance Specification below, create a Security document for a corporate hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Data classification (Public, Internal, Confidential, Restricted)
2. Encryption (At rest, In transit, Key management)
3. Authentication and authorization (SSO, OAuth, SAML, IAM)
4. Access control (RBAC, ABAC, Least privilege)
5. API security (API Gateway, Rate limiting, Threat protection)
6. Data privacy (Consent, Anonymization, Retention)
7. Audit logging (What to log, Where to store)
8. Third-party security (Vendor risk, Integration security)
9. Incident response readiness
10. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Flag any security measures that are mandatory for enterprise compliance.

TESTING

Category: 14. Open Innovation / Corporate
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist including UAT, integration testing, and regression testing.

Act as a QA engineer specializing in enterprise applications.
Using the PRD and Compliance Specification below, create a Testing document for a corporate hackathon project.

PRD: [PASTE PRD]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Testing strategy for enterprise applications
2. Functional testing (Core business features)
3. Integration testing (ERP, CRM, HRIS)
4. UAT (User Acceptance Testing) with stakeholders
5. Regression testing (After changes)
6. Security testing (Auth, Access control, Data privacy)
7. Performance testing (Load, Stress, SLA adherence)
8. Edge cases (Enterprise-specific)
9. A manual testing checklist for the demo
10. How to document known limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Prioritize testing the core business workflow and integrations.

EVALUATION

Category: 14. Open Innovation / Corporate
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how you measure business value and prepare for judge questions.

You are a business evaluation expert.
Using the PRD and Business Model below, create an Evaluation document for a corporate hackathon project.

PRD: [PASTE PRD]
BUSINESS_MODEL: [PASTE BUSINESS_MODEL]

Provide:
1. Evaluation metrics (ROI, Cost savings, Efficiency gains, User adoption)
2. Evaluation methods (Benchmarking, Pilot testing, Surveys)
3. Benchmarking (What is the baseline corporate process?)
4. Known limitations of the solution
5. How to explain these limitations to judges honestly
6. A checklist of evidence to gather for the presentation
7. Common judge questions about corporate innovation and how to answer them

Focus on demonstrating that the team understands the business problem, the enterprise context, and the value proposition.
Use hard numbers and clear business cases where possible.

Phase 4: Delivery & Presentation

Category: 14. Open Innovation / Corporate

Welcome to Phase 4: Delivery & Presentation for 14. Open Innovation / Corporate. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 14. Open Innovation / Corporate
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To deploy with enterprise considerations (On-prem, Cloud, Hybrid).

Act as an enterprise DevOps engineer.
Using the System Architecture and Compliance Specification below, create a Deployment document for a corporate hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
COMPLIANCE_SPEC: [PASTE COMPLIANCE_SPEC]

Provide:
1. Deployment options (Cloud, On-prem, Hybrid)
2. Enterprise deployment considerations (Security, Compliance, Network)
3. Environment variables for production
4. Secrets management (Vault, Enterprise secret stores)
5. Step-by-step deployment instructions
6. How to test the deployed application
7. Fallback plan if deployment fails during the hackathon
8. A pre-deployment enterprise checklist
9. Common deployment mistakes in corporate environments

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Ensure enterprise compliance requirements are met before the demo.
Focus on getting a working, secure demo as early as possible.

DEMO_SCRIPT

Category: 14. Open Innovation / Corporate
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation tailored to executive judges.

Act as an expert hackathon presentation coach specializing in corporate innovation.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
BUSINESS_MODEL: [PASTE BUSINESS_MODEL]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script for an executive audience.
The presentation should follow:
1. Hook (A business problem or statistic)
2. Problem (The corporate challenge)
3. Why the problem matters (Business impact)
4. Existing limitations
5. Our solution
6. How it works (Highlight enterprise integration and scalability)
7. Technology
8. Demo (The most important part — show business value)
9. Innovation
10. Impact (ROI, Cost savings, Efficiency)
11. Future scope (Scalability, Enterprise-wide rollout)
12. Closing (Call to action)

Make the language natural, confident, and business-focused.
Avoid unnecessary technical jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Focus on business value, not just the technology.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots, pilot data).

GLOSSARY

Category: 14. Open Innovation / Corporate
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all corporate and enterprise terms so every team member can explain the project to judges without confusion.

You are a technical writer specializing in enterprise innovation.
Using the PRD, Business Model, and Architecture below, create a Glossary document for a corporate hackathon project.

PRD: [PASTE PRD]
BUSINESS_MODEL: [PASTE BUSINESS_MODEL]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Business terms (ROI, KPI, SLA, MVP, POC, TCO)
2. Corporate terms (Stakeholder, Sponsor, Executive, IP, Compliance)
3. Enterprise tech terms (SSO, IAM, ERP, CRM, API Gateway)
4. Scalability terms (Horizontal, Vertical, Sharding, Load Balancing)
5. Security terms (Encryption, RBAC, Audit Log, Data Governance)
6. Project-specific terms (Any custom terminology used in the PRD)
7. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

15. Beginner / Student / Community

First-time hackers, structured learning paths, mentorship frameworks, and team collaboration.

Overview

This category provides structured prompt packs tailored for 15. Beginner / Student / Community projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 15. Beginner / Student / Community

Welcome to Phase 1: Problem Definition for 15. Beginner / Student / Community. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PROBLEM_ANALYSIS

Category: 15. Beginner / Student / Community
Section: Phase 1: Problem Definition

1. PROBLEM_ANALYSIS.md

Purpose: To deeply understand the problem in beginner-friendly terms, focusing on learning and community impact.

I am participating in a beginner/student/community hackathon and I am a first-time hacker.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language — as if I have never built a project before.
Then provide:
1. The actual problem being solved
2. Target users (Students, Community members, Beginners)
3. User pain points
4. Existing ways people might solve this problem
5. Limitations of existing solutions
6. Proposed solution ideas (Keep them simple)
7. Core features (What is the smallest thing we can build?)
8. Nice-to-have features
9. What should NOT be built during a short hackathon (Avoid scope creep)
10. What could make this solution unique
11. A realistic MVP that can be built by beginners during a hackathon
12. Potential beginner-friendly technologies that could be used (HTML, CSS, JavaScript, React, no-code tools)

Do not assume I am an experienced developer.
Explain every concept in beginner-friendly language.
Suggest learning resources where needed.
Focus on what is achievable in 24-48 hours by a first-time team.

PRD

Category: 15. Beginner / Student / Community
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear, simple plan that beginners can execute.

You are a senior product manager helping a beginner student hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Project name (Simple, memorable)
2. One-line project description
3. Problem statement (Simple language)
4. Target users (Students, Community)
5. User pain points
6. Proposed solution
7. Project goals (Learning + Impact)
8. User stories (Simple, one per feature)
9. Functional requirements (Keep it minimal)
10. Non-functional requirements (Simple, achievable)
11. Core features (Maximum 3)
12. Nice-to-have features (If time permits)
13. User journeys (Simple, step-by-step)
14. MVP scope (What must work during the demo?)
15. Out-of-scope features (What we will NOT build)
16. Success metrics (Learning goals + Impact goals)
17. Risks and assumptions (Beginner-specific risks)

Keep the MVP extremely realistic for first-time hackers.
Do not add unnecessary features.
Prioritize learning and completion over complexity.
Maximum 3 core features.

TRD

Category: 15. Beginner / Student / Community
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into the simplest possible technical specifications.

You are a senior developer helping a beginner student hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview (Simple explanation)
2. Tech stack choice (Simplest possible: HTML/CSS/JS, React, or no-code)
3. Frontend requirements (What tools? What framework?)
4. Backend requirements (Do we even need one?)
5. Database requirements (Simple: JSON file, localStorage, or Firebase)
6. API requirements (If needed)
7. Authentication requirements (If needed — keep simple)
8. Third-party integrations (Free tools only)
9. Performance requirements (Basic)
10. Security requirements (Basic)
11. Testing requirements (Simple manual testing)
12. Deployment requirements (Free hosting: Vercel, Netlify, GitHub Pages)

Keep the tech stack as simple as possible for beginners.
Explain every technical choice in beginner-friendly language.
If something is too complex, suggest a simpler alternative.
Only include what is necessary for the MVP.

Phase 2: Technical Blueprint

Category: 15. Beginner / Student / Community

Welcome to Phase 2: Technical Blueprint for 15. Beginner / Student / Community. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic architecture that beginners can understand and build.

Act as a senior developer and mentor.
Using the following PRD and TRD, design a realistic hackathon architecture for a beginner team.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended tech stack (Simplest possible)
2. Complete architecture diagram (Text-based, simple boxes and arrows)
3. Frontend architecture (Components or pages)
4. Backend architecture (If needed)
5. Database architecture (If needed)
6. Data flow (Simple step-by-step)
7. Folder structure (Beginner-friendly)
8. Major components (Maximum 5)
9. What each team member will build
10. Simplifications that make this beginner-friendly
11. Common beginner mistakes to avoid
12. A simple checklist for the team

Explain every technical decision in beginner-friendly language.
Do not introduce unnecessary tools.
If something is complex, explain how to simplify it.
Focus on what a beginner team can actually build in 24-48 hours.

LEARNING_PATH

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

5. LEARNING_PATH.md

Purpose: To define what the team needs to learn, in what order, and by when.

You are a senior mentor for beginner hackathon teams.
Using the PRD and System Architecture below, create a Learning Path document for this beginner hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Skills needed (Frontend, Backend, Design, Git)
2. Learning priority (What to learn first?)
3. Time allocation (Hours per skill)
4. Learning resources (Free tutorials, YouTube, Docs)
5. Pre-hackathon preparation (What to learn before the event)
6. During-hackathon learning (Just-in-time learning)
7. Skill-to-task mapping (Who learns what to build what)
8. Pair learning strategy (Learn together)
9. Mentor checkpoints (When to ask for help)
10. A checklist for the team to track progress

Explain each skill in beginner-friendly language.
Recommend only free resources.
Keep the learning path realistic for a 24-48 hour hackathon.
Focus on learning by building, not learning everything upfront.

API_SPECIFICATION

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

6. API_SPECIFICATION.md

Purpose: To define simple endpoints with beginner-friendly documentation.

You are a senior developer who loves teaching beginners.
Using the PRD and System Architecture below, create a simple API specification for a beginner hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For every endpoint provide:
1. HTTP method (GET, POST, etc.)
2. URL (Simple and clear)
3. What it does (In one sentence)
4. Do you need authentication? (Yes/No)
5. What data you send (Request body)
6. What data you get back (Response)
7. Example request (Copy-paste ready)
8. Example response (Copy-paste ready)
9. Common errors and what they mean
10. Beginner tip (Something helpful)

Keep the API as simple as possible.
If the project does not need an API, explain why and suggest an alternative.
Explain everything in beginner-friendly language.
Use simple examples that beginners can understand.

MENTOR_GUIDE

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

7. MENTOR_GUIDE.md

Purpose: To define how mentors can guide the team through blockers.

You are a senior hackathon mentor.
Using the PRD and System Architecture below, create a Mentor Guide document for this beginner hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. How mentors can help (Without taking over)
2. Common beginner blockers and solutions
3. Debugging strategies for beginners
4. How to explain technical concepts simply
5. When to intervene vs when to let them figure it out
6. Mentor check-in schedule (Every 2-4 hours)
7. Questions mentors should ask
8. Questions mentors should NOT answer directly
9. Encouraging progress and celebrating small wins
10. How to help with time management
11. How to help with scope management
12. A checklist for mentors before the demo

Explain each concept in beginner-friendly language.
Focus on empowering the team to solve their own problems.
Keep the mentor involvement light — this is a learning experience.

TEAM_ROLES

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

8. TEAM_ROLES.md

Purpose: To define team roles for beginners (Frontend, Backend, Design, PM).

You are a senior team lead for beginner hackathon teams.
Using the PRD and System Architecture below, create a Team Roles document for this beginner hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For a team of 3-4 beginners, define:
1. Role names (Frontend Developer, Backend Developer, Designer, PM/Presenter)
2. Responsibilities for each role
3. Skills needed for each role
4. Daily tasks for each role
5. Collaboration points (When roles work together)
6. Backup plans (If someone is stuck)
7. How to divide the MVP work
8. How to handle overlaps
9. Communication guidelines
10. A RACI matrix (Who is Responsible, Accountable, Consulted, Informed)

Also provide:
11. What to do if you are a solo hacker
12. What to do if someone drops out
13. How to rotate roles if needed

Explain each role in beginner-friendly language.
Keep the roles simple and flexible.
Focus on ensuring everyone has something meaningful to do.

RESOURCE_LIST

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint

9. RESOURCE_LIST.md

Purpose: To curate a list of tutorials, docs, and tools for beginners.

You are a senior developer curating resources for beginner hackathon teams.
Using the PRD and TRD below, create a Resource List document for this beginner hackathon project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide curated resources for:
1. HTML, CSS, JavaScript (MDN, freeCodeCamp, W3Schools)
2. React (React Docs, Scrimba, YouTube)
3. Tailwind CSS (Tailwind Docs, YouTube)
4. Git and GitHub (GitHub Docs, Git Basics)
5. Backend (Node.js, Express, FastAPI — depending on stack)
6. Database (Firebase, Supabase, SQLite — depending on stack)
7. Design (Figma, Canva, Coolors, Google Fonts)
8. Deployment (Vercel, Netlify, GitHub Pages)
9. Debugging (Chrome DevTools, Console)
10. AI Coding Tools (Claude, Cursor, GitHub Copilot)
11. Free Assets (Unsplash, Lucide, Heroicons, Google Fonts)
12. YouTube Channels (Traversy Media, Web Dev Simplified, Fireship)

For each resource, include:
- Name
- Link
- What it's for
- Why it's good for beginners

Keep the list short and focused — maximum 2-3 resources per topic.
Only recommend free resources.
Explain each resource in beginner-friendly language.

DATABASE_SCHEMA

Category: 15. Beginner / Student / Community
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 15. Beginner / Student / Community.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 15. Beginner / Student / Community project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 15. Beginner / Student / Community

Welcome to Phase 3: Execution & Quality for 15. Beginner / Student / Community. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 15. Beginner / Student / Community
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define a simple, clean frontend design that beginners can build.

Act as a senior UI/UX designer who loves teaching beginners.
Using the PRD and System Architecture below, create a simple UI Specification document for a beginner hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Simple: 2 colors, 1 font, basic spacing)
2. Component hierarchy (Maximum 5 components)
3. Screen-by-screen breakdown (Maximum 3 screens)
4. Simple layouts (Text-based wireframes)
5. Loading states (Simple spinners)
6. Error states (Simple messages)
7. Empty states (Simple placeholders)
8. Responsive design (Mobile-first, simple breakpoints)
9. Accessibility basics (Contrast, Alt text)
10. Free design tools (Figma, Canva, Coolors)
11. A checklist for beginners

Keep the UI extremely simple.
Do not over-design.
Focus on functionality over beauty.
Explain every design choice in beginner-friendly language.
Suggest free templates where possible.

ERROR_HANDLING

Category: 15. Beginner / Student / Community
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define common beginner mistakes and how to fix them.

You are a patient senior developer helping beginners.
Using the System Architecture and API Specification below, create an Error Handling document for a beginner hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. Top 10 beginner mistakes (With fixes)
2. Common JavaScript errors (Undefined, Null, Type errors)
3. Common React errors (Hooks, State, Props)
4. Common Git errors (Merge conflicts, Push rejected)
5. Common API errors (CORS, 404, 500)
6. Common deployment errors (Build failed, Environment variables)
7. Debugging tools for beginners (Console.log, Chrome DevTools)
8. How to search for errors effectively
9. How to ask for help (Mentors, Stack Overflow, AI tools)
10. A checklist for beginners to verify before asking for help

Explain each error in beginner-friendly language.
Provide copy-paste fixes where possible.
Focus on building confidence, not fear.
Keep it simple — 1-2 sentences per error.

SECURITY

Category: 15. Beginner / Student / Community
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To define basic security practices explained simply.

Act as a security engineer who loves teaching beginners.
Using the System Architecture and PRD below, create a simple Security document for a beginner hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. What is an API key? (Simple explanation)
2. Why you should NEVER commit API keys to GitHub
3. How to use .env files (Step-by-step)
4. How to add .env to .gitignore
5. Basic password security (Don't store plain text)
6. Basic input validation (Don't trust user input)
7. HTTPS basics (Why it matters)
8. Free security tools (GitHub secret scanning)
9. A pre-submission security checklist for beginners
10. What to do if you accidentally exposed a secret

Explain each concept in beginner-friendly language.
Use analogies where helpful.
Do not overwhelm — focus on the 3-5 most important rules.
Keep it practical for a 24-48 hour hackathon.

TESTING

Category: 15. Beginner / Student / Community
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a simple testing checklist for beginners.

Act as a QA engineer who loves teaching beginners.
Using the PRD and API Specification below, create a simple Testing document for a beginner hackathon project.

PRD: [PASTE PRD]
API_SPEC: [PASTE API_SPECIFICATION]

Provide:
1. What is testing? (Simple explanation)
2. Manual testing checklist (Click everything)
3. Form testing (Empty, Invalid, Long input)
4. Button testing (Does it do what it should?)
5. Page testing (Does every page load?)
6. Mobile testing (Resize browser, Use phone)
7. Link testing (Click every link)
8. Console testing (Check for errors)
9. A simple test log template
10. What to do when you find a bug
11. A checklist for the demo

Keep the testing plan extremely simple.
No automated testing — just manual checks.
Explain everything in beginner-friendly language.
Focus on preventing demo-day disasters.

EVALUATION

Category: 15. Beginner / Student / Community
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how you measure learning and community impact.

You are a senior educator and hackathon evaluator.
Using the PRD and Learning Path below, create an Evaluation document for a beginner hackathon project.

PRD: [PASTE PRD]
LEARNING_PATH: [PASTE LEARNING_PATH]

Provide:
1. Learning metrics (What did the team learn?)
2. Project metrics (Does the project work?)
3. Community metrics (Does it help the target users?)
4. Self-assessment checklist (Rate yourself 1-5)
5. Peer assessment (Team members rate each other)
6. Mentor assessment (What did the mentor observe?)
7. Evidence to gather (Screenshots, Demo, Repo)
8. How to present learning outcomes to judges
9. Common judge questions for beginner teams
10. How to answer "What would you do differently?"

Focus on growth and learning, not perfection.
Celebrate progress over polish.
Explain each concept in beginner-friendly language.
Prepare the team to speak confidently about their journey.

Phase 4: Delivery & Presentation

Category: 15. Beginner / Student / Community

Welcome to Phase 4: Delivery & Presentation for 15. Beginner / Student / Community. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 15. Beginner / Student / Community
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To define the simplest way to deploy for beginners.

Act as a DevOps engineer who loves teaching beginners.
Using the System Architecture and PRD below, create a simple Deployment document for a beginner hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PRD: [PASTE PRD]

Provide:
1. What is deployment? (Simple explanation)
2. Free hosting options (Vercel, Netlify, GitHub Pages)
3. Which one to pick and why
4. Step-by-step deployment for beginners
5. Connecting your GitHub repository
6. Environment variables (If needed)
7. How to test your deployed site
8. What to do if deployment fails
9. Common deployment mistakes for beginners
10. A pre-deployment checklist
11. How to share your live link

Keep the deployment process as simple as possible.
No complex DevOps — just drag-and-drop or one-click deploys.
Explain everything in beginner-friendly language.
Include screenshots descriptions where helpful.

DEMO_SCRIPT

Category: 15. Beginner / Student / Community
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation for first-time presenters.

Act as an expert hackathon presentation coach for first-time presenters.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
FEATURES: [PASTE CORE FEATURES]
DEMO FLOW: [PASTE USER JOURNEY]

Create a simple, encouraging hackathon presentation script.
The presentation should follow:
1. Introduction (Who we are)
2. The Problem (Why we built this)
3. Our Solution (What we built)
4. How It Works (Simple, no jargon)
5. Live Demo (The most important part)
6. What We Learned (This is key for beginners)
7. Challenges We Overcame
8. Future Ideas
9. Thank You

Make the language simple and natural.
Encourage honesty about challenges.
Celebrate the learning journey.
Write it as something a first-time presenter can actually say.
Provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include tips for overcoming nervousness.
Include a backup plan for demo failure (screenshots, video).

GLOSSARY

Category: 15. Beginner / Student / Community
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define all terms in beginner-friendly language.

You are a patient teacher explaining technical terms to beginners.
Using the PRD, TRD, and Architecture below, create a Glossary document for a beginner hackathon project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide simple definitions for all terms used in the project:
1. Web basics (HTML, CSS, JavaScript, Browser, Server)
2. Frontend terms (Component, State, Props, Responsive)
3. Backend terms (API, Endpoint, Database, Server)
4. Git terms (Repository, Commit, Push, Pull, Branch)
5. Deployment terms (Hosting, Domain, Environment Variables)
6. Hackathon terms (MVP, Demo, Pitch, Judge)
7. Project-specific terms (Any custom terminology)

For each term:
- Simple definition (One sentence, no jargon)
- Real-world analogy (Compare to something familiar)
- Why it matters for this project

Keep definitions extremely simple.
Use analogies wherever possible (e.g., "An API is like a waiter taking your order to the kitchen").
This glossary should make any beginner feel confident.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

16. Platform-Sponsored

Ecosystem and sponsor-focused projects maximizing official SDKs, APIs, and partner quotas.

Overview

This category provides structured prompt packs tailored for 16. Platform-Sponsored projects. Follow the structured workflow below to build from concept to delivery.

Phase 1: Problem Definition

Phase 2: Technical Blueprint

Phase 3: Execution & Quality

Phase 4: Delivery & Presentation

Select any document from the list above or use the sidebar to proceed.

Phase 1: Problem Definition

Category: 16. Platform-Sponsored

Welcome to Phase 1: Problem Definition for 16. Platform-Sponsored. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PLATFORM_ANALYSIS

Category: 16. Platform-Sponsored
Section: Phase 1: Problem Definition

1. PLATFORM_ANALYSIS.md

Purpose: To deeply understand the sponsor's platform, its capabilities, and the hackathon's requirements.

I am participating in a platform-sponsored hackathon where [SPONSOR NAME] is the main sponsor. I am a beginner.

Analyze the following problem statement deeply.
[PASTE PROBLEM STATEMENT]

Explain it in very simple language.
Then provide:
1. The actual problem being solved
2. Target users
3. User pain points
4. The sponsor's platform and its core capabilities
5. What the sponsor wants participants to build (Hackathon requirements)
6. Proposed solution ideas using the sponsor's platform
7. Core features leveraging the sponsor's APIs/SDKs
8. Nice-to-have features
9. What should NOT be built (Avoid using competitor tools)
10. What could make this solution unique within the sponsor's ecosystem
11. A realistic MVP that can be built during a hackathon
12. The sponsor's specific APIs, SDKs, and tools that could be used

Do not assume I am an expert in the sponsor's platform.
Explain the sponsor's tools and concepts in beginner-friendly language.
Highlight any specific hackathon prizes, credits, or judging criteria mentioned by the sponsor.

PRD

Category: 16. Platform-Sponsored
Section: Phase 1: Problem Definition

2. PRD.md (Product Requirements Document)

Purpose: To translate the problem analysis into a clear plan aligned with the sponsor's goals.

You are a senior product manager specializing in [SPONSOR NAME]'s ecosystem, helping a beginner hackathon team.
Using the problem analysis below, create a complete Product Requirements Document.

PROBLEM ANALYSIS:
[PASTE PREVIOUS ANALYSIS]

Create the PRD with these sections:
1. Product name
2. One-line product description
3. Problem statement
4. Target users
5. User pain points
6. Proposed solution
7. Product goals (Aligned with sponsor's goals)
8. User stories
9. Functional requirements (Include sponsor-specific API/SDK requirements)
10. Non-functional requirements (Quotas, Latency, Cost)
11. Core features (Maximize sponsor's tools)
12. Nice-to-have features
13. User journeys
14. MVP scope (Which feature must work during the demo?)
15. Out-of-scope features (Explicitly avoid competitor tools)
16. Success metrics (Include sponsor-aligned metrics: Usage, Impact, Innovation)
17. Risks and assumptions (Include sponsor API limits, Credits, Downtime)

Keep the MVP realistic for a 24-48 hour hackathon.
Do not add unnecessary features just to make the project sound impressive.
Prioritize features that directly use the sponsor's platform and can be demonstrated live.

TRD

Category: 16. Platform-Sponsored
Section: Phase 1: Problem Definition

3. TRD.md (Technical Requirements Document)

Purpose: To translate the PRD into technical specifications focused on the sponsor's SDKs and APIs.

You are a senior engineer specializing in [SPONSOR NAME]'s platform, helping a beginner hackathon team.
Using the PRD below, create a Technical Requirements Document (TRD).

PRD:
[PASTE PRD]

Create the TRD with these sections:
1. System overview
2. Sponsor platform integration strategy
3. Sponsor SDKs and APIs required (List them all)
4. Authentication and authorization using sponsor's tools
5. Data storage and management using sponsor's services
6. Rate limits, quotas, and credits management
7. Sponsor-specific performance requirements
8. Security and compliance requirements
9. Testing requirements using sponsor's sandbox
10. Deployment using sponsor's recommended platforms
11. Fallback if sponsor's API is down
12. Budget and cost estimation (Using sponsor credits)

Keep the tech stack centered on the sponsor's ecosystem.
Explain all sponsor-specific concepts in beginner-friendly language.
Do not introduce unnecessary competitor tools.
Flag any integration challenges early.

Phase 2: Technical Blueprint

Category: 16. Platform-Sponsored

Welcome to Phase 2: Technical Blueprint for 16. Platform-Sponsored. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYSTEM_ARCHITECTURE

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

4. SYSTEM_ARCHITECTURE.md

Purpose: To design a realistic architecture built around the sponsor's platform.

Act as a senior architect specializing in [SPONSOR NAME]'s ecosystem.
Using the following PRD and TRD, design a realistic hackathon architecture for this sponsor-focused project.

PRD: [PASTE PRD]
TRD: [PASTE TRD]

Provide:
1. Recommended sponsor tech stack (Frontend, Backend, Sponsor APIs)
2. Complete architecture diagram (Text-based, showing Users → Frontend → Backend → Sponsor APIs → Database)
3. Frontend architecture
4. Backend architecture
5. Sponsor API integration architecture
6. Data storage architecture (Sponsor's DB or preferred tool)
7. Authentication architecture (Sponsor's auth tools)
8. Data flow (How a user action triggers sponsor APIs)
9. Security and quota considerations
10. Folder structure
11. Major components
12. Simplifications that can be made for a hackathon

Explain every technical decision in beginner-friendly language.
Do not introduce competitor tools. Stick to the sponsor's ecosystem.
Highlight how the architecture maximizes the use of the sponsor's platform.

PLATFORM_INTEGRATION

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

5. PLATFORM_INTEGRATION.md

Purpose: To define how the sponsor's services are integrated.

Act as a senior integration engineer specializing in [SPONSOR NAME].
Using the PRD and System Architecture below, create a Platform Integration document for this sponsor hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

For each sponsor service integrated, provide:
1. Service name (API, SDK, Tool)
2. Purpose in the project
3. Authentication method (API Key, OAuth, Service Account)
4. Required credentials and where to store them
5. Endpoint or SDK method used
6. Request/Response format
7. Example usage (Copy-paste ready)
8. Rate limits and quotas
9. Error handling
10. Fallback if the service is unavailable

Keep the integrations strictly within the sponsor's ecosystem.
Explain why each service was chosen.
Keep the integration simple and realistic for a hackathon.
Highlight how this maximizes the sponsor's technology.

API_SPECIFICATION

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

6. API_SPECIFICATION.md

Purpose: To define endpoints including the sponsor's specific APIs.

You are a senior backend developer specializing in [SPONSOR NAME]'s APIs.
Using the PRD, Architecture, and Platform Integration below, create a complete API specification for this sponsor hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

For every endpoint provide:
1. HTTP method
2. URL
3. Purpose
4. Authentication requirement (Using sponsor's auth)
5. Sponsor API used (If any)
6. Request parameters
7. Request body
8. Example request
9. Example success response
10. Possible error responses (Include sponsor-specific errors like 429 Rate Limit)
11. HTTP status codes
12. Quota and rate limit considerations

Keep the API simple and consistent.
Ensure all endpoints align with the sponsor's ecosystem.
Do not create endpoints that use competitor tools.
Prioritize showcasing the sponsor's APIs.

SDK_USAGE

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

7. SDK_USAGE.md

Purpose: To define which sponsor SDKs are used, why, and how.

You are a senior developer specializing in [SPONSOR NAME] SDKs.
Using the PRD and Platform Integration document below, create an SDK Usage document for this sponsor hackathon project.

PRD: [PASTE PRD]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. List of sponsor SDKs used (Frontend, Backend, Mobile)
2. Why each SDK was chosen
3. Installation instructions for each SDK
4. Configuration and setup
5. Key methods and functions used
6. Example code snippets (Copy-paste ready)
7. Common pitfalls and how to avoid them
8. SDK version requirements
9. Compatibility with other tools
10. Fallback if the SDK is unavailable
11. A checklist for verifying SDK usage before the demo

Explain each SDK in beginner-friendly language.
Keep the SDK usage simple and strictly within the sponsor's ecosystem.
Highlight how the SDKs accelerate development.

QUOTA_MANAGEMENT

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

8. QUOTA_MANAGEMENT.md

Purpose: To define API rate limits, credits, and budget management.

Act as a senior engineer managing [SPONSOR NAME]'s quotas and credits.
Using the Platform Integration and PRD below, create a Quota Management document for this sponsor hackathon project.

PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]
PRD: [PASTE PRD]

Provide:
1. List of all sponsor APIs and their rate limits
2. Available credits provided by the sponsor
3. Estimated usage per feature
4. Total estimated credits required for the demo
5. Strategy to stay within limits (Caching, Batching, Throttling)
6. What happens when quotas are exceeded
7. Fallback mechanisms (Cached responses, Degraded features)
8. How to monitor usage (Sponsor dashboards)
9. How to request additional credits (If needed)
10. A checklist for verifying quota management before the demo

Explain each concept in beginner-friendly language.
Ensure the demo does not fail due to exceeded quotas.
Keep the strategy simple and realistic for a hackathon.

SANDBOX_SPEC

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint

9. SANDBOX_SPEC.md

Purpose: To define the sandbox/test environment provided by the sponsor.

You are a senior developer using [SPONSOR NAME]'s sandbox environment.
Using the PRD and Platform Integration document below, create a Sandbox Specification document for this sponsor hackathon project.

PRD: [PASTE PRD]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Sponsor's sandbox environment details
2. How to access the sandbox
3. Sandbox vs Production differences
4. Sandbox credentials and setup
5. Limitations of the sandbox
6. How to test sponsor APIs in the sandbox
7. Mock data and test accounts
8. How to transition from sandbox to production
9. Common sandbox mistakes and how to avoid them
10. A checklist for verifying sandbox usage before the demo

Explain each concept in beginner-friendly language.
Focus on testing the sponsor's APIs thoroughly before the demo.
Keep the sandbox setup simple and realistic for a hackathon.

DATABASE_SCHEMA

Category: 16. Platform-Sponsored
Section: Phase 2: Technical Blueprint
Status: Standard Framework Specification

Overview

This document defines the prompt template for DATABASE_SCHEMA in 16. Platform-Sponsored.

Prompt Template

You are a senior technical advisor assisting a hackathon team building a 16. Platform-Sponsored project.
Generate the DATABASE_SCHEMA covering all essential requirements, architectures, schemas, or procedures.

Phase 3: Execution & Quality

Category: 16. Platform-Sponsored

Welcome to Phase 3: Execution & Quality for 16. Platform-Sponsored. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UI_SPEC

Category: 16. Platform-Sponsored
Section: Phase 3: Execution & Quality

10. UI_SPEC.md

Purpose: To define frontend design leveraging the sponsor's UI components (if provided).

Act as a senior UI/UX designer specializing in [SPONSOR NAME]'s design system.
Using the PRD and System Architecture below, create a UI Specification document for a sponsor hackathon project.

PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide:
1. Design system (Use sponsor's design tokens if provided)
2. Sponsor UI components (If any: Buttons, Modals, Cards)
3. Component hierarchy
4. Screen-by-screen breakdown (Dashboard, Core feature, Settings)
5. Loading states (For sponsor API calls)
6. Error states (Sponsor API errors)
7. Empty states
8. Responsive design guidelines
9. Accessibility considerations (WCAG, Sponsor standards)

Keep the UI simple, clean, and aligned with the sponsor's brand.
Focus on demonstrating the core sponsor-powered journey.
If the sponsor provides a UI kit, use it. Otherwise, design a simple, modern UI.

ERROR_HANDLING

Category: 16. Platform-Sponsored
Section: Phase 3: Execution & Quality

11. ERROR_HANDLING.md

Purpose: To define what happens when the sponsor's API fails, quotas are hit, or credits run out.

You are a senior engineer specializing in [SPONSOR NAME]'s platform.
Using the System Architecture and Platform Integration document below, create an Error Handling document for a sponsor hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Common failure modes (Sponsor API failures, Quota exceeded, Credit exhausted)
2. Sponsor API error codes and meanings
3. Rate limit handling (Backoff, Retry)
4. Quota exhaustion handling (Fallback, Cached responses)
5. Credit exhaustion handling (Notify, Degrade gracefully)
6. Authentication errors (Expired tokens, Invalid keys)
7. Frontend error display
8. Fallback responses
9. Audit logging of errors
10. A checklist for developers to verify error handling before the demo

Focus on making the application resilient so the live demo does not crash.
Prioritize staying within the sponsor's limits.
Explain each approach in beginner-friendly language.

SECURITY

Category: 16. Platform-Sponsored
Section: Phase 3: Execution & Quality

12. SECURITY.md

Purpose: To protect the sponsor's API keys, tokens, and user data.

Act as a security engineer specializing in [SPONSOR NAME]'s platform.
Using the System Architecture and Platform Integration document below, create a Security document for a sponsor hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Sponsor API key protection (Environment variables, Secret managers)
2. Authentication security (Sponsor's auth best practices)
3. Token management (Expiry, Refresh, Revocation)
4. Data privacy (User data handled by sponsor's services)
5. Access control (Who can access what?)
6. API security (Rate limiting, Input validation)
7. Logging and monitoring (Sponsor dashboards)
8. Incident response (If credentials are leaked)
9. A pre-submission security checklist

Keep the security measures practical and easy to implement within a hackathon timeframe.
Explain each concept in beginner-friendly language.
Flag any security measures that are mandatory for the sponsor's platform.

TESTING

Category: 16. Platform-Sponsored
Section: Phase 3: Execution & Quality

13. TESTING.md

Purpose: To create a manual testing checklist including the sponsor's sandbox and edge cases.

Act as a QA engineer specializing in [SPONSOR NAME]'s platform.
Using the PRD and Platform Integration document below, create a Testing document for a sponsor hackathon project.

PRD: [PASTE PRD]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Testing strategy for sponsor-integrated applications
2. Sponsor sandbox testing
3. Functional testing (Core features using sponsor APIs)
4. Integration testing (Sponsor SDKs, APIs)
5. Quota and rate limit testing
6. Error case testing (API down, Quota exceeded)
7. User acceptance testing checklist
8. A manual testing checklist for the demo
9. How to document known sponsor-related limitations for judges

Keep the testing plan simple enough for beginner developers to execute under time pressure.
Prioritize testing the sponsor's APIs thoroughly.

EVALUATION

Category: 16. Platform-Sponsored
Section: Phase 3: Execution & Quality

14. EVALUATION.md

Purpose: To define how you measure success using the sponsor's metrics.

You are a sponsor-aligned evaluation expert.
Using the PRD and Platform Integration document below, create an Evaluation document for a sponsor hackathon project.

PRD: [PASTE PRD]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Evaluation metrics (Sponsor API usage, Credits consumed, User impact)
2. Sponsor-specific metrics (If any provided by the sponsor)
3. Evaluation methods (Usage data, Benchmarking, Feedback)
4. Benchmarking (What is the baseline?)
5. Known limitations of the solution
6. How to explain these limitations to sponsor judges honestly
7. A checklist of evidence to gather for the presentation (Sponsor dashboards, Logs)
8. Common sponsor judge questions and how to answer them

Focus on demonstrating that the team maximized the sponsor's platform.
Highlight innovation within the sponsor's ecosystem.
Use hard numbers from sponsor dashboards where possible.

Phase 4: Delivery & Presentation

Category: 16. Platform-Sponsored

Welcome to Phase 4: Delivery & Presentation for 16. Platform-Sponsored. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DEPLOYMENT

Category: 16. Platform-Sponsored
Section: Phase 4: Delivery & Presentation

15. DEPLOYMENT.md

Purpose: To deploy using the sponsor's recommended hosting (Vercel, AWS, etc.).

Act as a DevOps engineer specializing in [SPONSOR NAME]'s deployment.
Using the System Architecture and Platform Integration document below, create a Deployment document for a sponsor hackathon project.

ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]

Provide:
1. Sponsor-recommended hosting platforms
2. Sponsor-specific deployment steps
3. Environment variables for production
4. Secrets management using sponsor tools
5. Step-by-step deployment instructions
6. How to test the deployed application
7. Monitoring using sponsor dashboards
8. Fallback plan if deployment fails during the hackathon
9. A pre-deployment sponsor checklist
10. Common deployment mistakes

Keep the deployment process simple and achievable within a 24-48 hour hackathon.
Ensure deployment maximizes the sponsor's platform (e.g., Vercel for Next.js, AWS for AWS-sponsored).
Focus on getting a working live demo as early as possible.

DEMO_SCRIPT

Category: 16. Platform-Sponsored
Section: Phase 4: Delivery & Presentation

16. DEMO_SCRIPT.md

Purpose: To create the exact flow of the live presentation tailored to sponsor judges.

Act as an expert hackathon presentation coach specializing in [SPONSOR NAME]'s ecosystem.
Using the following project information:
PRD: [PASTE PRD]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]
DEMO FLOW: [PASTE USER JOURNEY]

Create a compelling hackathon presentation script for sponsor judges.
The presentation should follow:
1. Hook (The problem)
2. Problem
3. Why the problem matters
4. Our solution
5. How it works (Highlight the sponsor's platform)
6. Technology (Sponsor's SDKs, APIs)
7. Demo (The most important part — show sponsor-powered features)
8. Innovation within the sponsor's ecosystem
9. Impact
10. Future scope using the sponsor's tools
11. Closing

Make the language natural and easy to speak.
Avoid corporate jargon.
Write it as something a student can actually say on stage rather than something that sounds like an AI-generated report.
Highlight how the solution maximizes the sponsor's platform.
Also provide:
- 30-second elevator pitch
- 1-minute pitch
- 3-minute presentation
- 5-minute presentation
Include a backup plan for demo failure (video recording, screenshots, sponsor dashboard screenshots).

GLOSSARY

Category: 16. Platform-Sponsored
Section: Phase 4: Delivery & Presentation

17. GLOSSARY.md

Purpose: To define the sponsor's specific terms, APIs, and acronyms.

You are a technical writer specializing in [SPONSOR NAME]'s platform.
Using the PRD, Platform Integration, and Architecture below, create a Glossary document for a sponsor hackathon project.

PRD: [PASTE PRD]
PLATFORM_INTEGRATION: [PASTE PLATFORM_INTEGRATION]
ARCHITECTURE: [PASTE SYSTEM_ARCHITECTURE]

Provide definitions for all key terms used in the project, including:
1. Sponsor platform terms (APIs, SDKs, Services)
2. Sponsor-specific features (Functions, Tools, Dashboards)
3. Sponsor pricing terms (Credits, Quotas, Rate Limits)
4. Sponsor authentication terms (Tokens, Keys, OAuth)
5. Project-specific terms
6. Acronyms and abbreviations

For each term:
- Simple definition (Beginner-friendly)
- Why it matters for this project
- Example usage in context

Keep definitions concise and understandable for a beginner audience.
This will help all team members speak confidently to sponsor judges.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

17. Debugging

A 6-pillar methodical debugging lifecycle to detect, reproduce, observe, hypothesize, fix, and prevent bugs.

Overview

This category provides structured prompt packs tailored for 17. Debugging projects. Follow the structured workflow below to build from concept to delivery.

Pillar 1: Detect & Define

Pillar 2: Reproduce & Isolate

Pillar 3: Instrument & Observe

Pillar 4: Hypothesize & Test

Pillar 5: Resolve & Verify

Pillar 6: Prevent & Learn

Select any document from the list above or use the sidebar to proceed.

Pillar 1: Detect & Define

Category: 17. Debugging

Welcome to Pillar 1: Detect & Define for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SYMPTOM_REPORT

Category: 17. Debugging
Section: Pillar 1: Detect & Define

1. `SYMPTOM_REPORT.md`

You are a senior debugging mentor.
Help me clearly define the bug I'm facing.

INPUT:
[PASTE BUG DESCRIPTION, ERROR LOG, OR OBSERVED BEHAVIOR]

Provide:
1. Bug title (Short, specific)
2. Symptom summary (What is happening?)
3. Expected behavior (What should happen?)
4. Actual behavior (What is happening instead?)
5. First observed (When did it start?)
6. Frequency (Always, Sometimes, Rare)
7. Reproduction reliability (Can we make it happen?)
8. User-visible impact
9. Affected components
10. Related errors or warnings
11. What is NOT the problem (Ruled out)

Explain in beginner-friendly language.
Do not guess the cause yet — just define the symptom precisely.

IMPACT_ASSESSMENT

Category: 17. Debugging
Section: Pillar 1: Detect & Define

2. `IMPACT_ASSESSMENT.md`

You are an incident severity expert.
Assess the impact of this bug.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. Severity level (P0: Critical, P1: High, P2: Medium, P3: Low)
2. Users affected (How many? Which segments?)
3. Business impact (Revenue, Trust, Compliance)
4. Technical impact (Data loss, Downtime, Corruption)
5. Blast radius (What else might break?)
6. Time sensitivity (How urgent?)
7. Workarounds available (Can users continue?)
8. Escalation required (Who needs to know?)
9. Fix priority
10. A triage checklist

Explain severity in beginner-friendly language.
Keep the assessment honest — do not exaggerate or minimize.

Pillar 2: Reproduce & Isolate

Category: 17. Debugging

Welcome to Pillar 2: Reproduce & Isolate for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

REPRODUCTION_STEPS

Category: 17. Debugging
Section: Pillar 2: Reproduce & Isolate

3. `REPRODUCTION_STEPS.md`

You are a senior QA engineer specializing in bug reproduction.
Create clear reproduction steps for this bug.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. Preconditions (User state, Data state, Config)
2. Step-by-step reproduction steps (Numbered, precise)
3. Expected result at each step
4. Actual result at each step
5. Minimal reproducible case (Smallest possible)
6. Frequency of reproduction
7. Any logs or stack traces
8. Screenshots or recordings needed
9. Variables to test (Browser, OS, Data, Timing)
10. A reliability checklist

If the bug is not reproducible, list the top 3 reasons why and how to narrow it down.
Explain each step in beginner-friendly language.

ENVIRONMENT_MATRIX

Category: 17. Debugging
Section: Pillar 2: Reproduce & Isolate

4. `ENVIRONMENT_MATRIX.md`

You are a systems engineer specializing in environmental factors.
Create an environment matrix to isolate the bug.

INPUTS:
Reproduction Steps: [PASTE REPRODUCTION_STEPS]

Provide a matrix testing:
1. Operating systems (Windows, Mac, Linux)
2. Browsers (Chrome, Firefox, Safari, Edge)
3. Browser versions (Latest, Previous, Specific)
4. Devices (Desktop, Tablet, Mobile)
5. Network conditions (WiFi, 4G, 3G, Offline)
6. User roles (Admin, User, Guest)
7. Data states (Empty, Populated, Edge values)
8. Time zones and locales
9. Feature flags or config variations
10. Environment (Dev, Staging, Production)

For each dimension:
- Does the bug reproduce? (Yes/No)
- What does this tell us?

Highlight the narrowest environment where the bug reproduces.
Explain in beginner-friendly language.

BISECT_PLAN

Category: 17. Debugging
Section: Pillar 2: Reproduce & Isolate

5. `BISECT_PLAN.md`

You are a senior debugging engineer.
Create a bisection plan to isolate when the bug was introduced.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. What is bisecting? (Beginner-friendly explanation)
2. Last known good version
3. First known bad version
4. Commits or changes in between
5. Bisect strategy (Git bisect, Manual, Code-level)
6. Step-by-step bisect process
7. What to look for at each step
8. How to verify "good" vs "bad" at each step
9. What to do if bisect is inconclusive
10. Alternative isolation techniques (Comment out, Feature flag)
11. A checklist for isolating the change

If Git bisect is not applicable, suggest alternatives (manual code review, log diffing).

Pillar 3: Instrument & Observe

Category: 17. Debugging

Welcome to Pillar 3: Instrument & Observe for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

OBSERVABILITY_SETUP

Category: 17. Debugging
Section: Pillar 3: Instrument & Observe

6. `OBSERVABILITY_SETUP.md`

You are a senior observability engineer.
Help me set up observability to understand this bug.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]
Environment Matrix: [PASTE ENVIRONMENT_MATRIX]

Provide:
1. What observability means (Beginner explanation)
2. Logs — what to capture and at what level
3. Metrics — what to measure (Latency, Error rate, Throughput)
4. Traces — how to follow a request end-to-end
5. Correlation IDs — how to link logs, metrics, traces
6. Tools to use (Console, DevTools, APM, Log aggregators)
7. Where to place instrumentation
8. What NOT to instrument (Avoid noise)
9. Real-time monitoring setup
10. Alerting on the bug recurrence
11. A setup checklist

Keep the observability setup minimal and targeted.
Explain each concept in beginner-friendly language.

LOG_TRACE_STRATEGY

Category: 17. Debugging
Section: Pillar 3: Instrument & Observe

7. `LOG_TRACE_STRATEGY.md`

You are a senior SRE.
Create a log and trace strategy specific to this bug.

INPUTS:
Observability Setup: [PASTE OBSERVABILITY_SETUP]
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. Log levels to use (DEBUG, INFO, WARN, ERROR)
2. What to log at each level (Specific to this bug)
3. Log format (JSON, Text, Structured)
4. Required fields (Timestamp, Request ID, User ID, Component)
5. What NEVER to log (PII, Passwords, Tokens)
6. Trace spans for the affected request flow
7. Sampling strategy (If high volume)
8. Where logs are stored
9. Retention policy
10. Example log entries (Before/After fix)
11. A checklist to verify logging

Focus logs on the bug's suspected area.
Explain each concept in beginner-friendly language.

DEVTOOLS_WORKFLOW

Category: 17. Debugging
Section: Pillar 3: Instrument & Observe

8. `DEVTOOLS_WORKFLOW.md`

You are a browser and runtime debugging expert.
Create a debugging workflow using DevTools.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]
Environment Matrix: [PASTE ENVIRONMENT_MATRIX]

Provide:
1. Chrome DevTools panels to use (Elements, Console, Sources, Network, Performance, Application)
2. Breakpoint strategy (Line, Conditional, DOM, Event listener)
3. Watch expressions
4. Call stack analysis
5. Network tab investigation (Headers, Payload, Response, Timing)
6. Performance profiling (Flamegraph, Memory)
7. Application tab (Storage, Cookies, Cache)
8. Console debugging techniques
9. Mobile remote debugging
10. Common DevTools mistakes
11. A step-by-step debugging session plan

Explain each panel and technique in beginner-friendly language.
Tailor the workflow to the specific bug.

Pillar 4: Hypothesize & Test

Category: 17. Debugging

Welcome to Pillar 4: Hypothesize & Test for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

HYPOTHESIS_LOG

Category: 17. Debugging
Section: Pillar 4: Hypothesize & Test

9. `HYPOTHESIS_LOG.md`

You are a senior debugging mentor.
Create a hypothesis log for this bug.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]
Observability Setup: [PASTE OBSERVABILITY_SETUP]

For each hypothesis, provide:
1. Hypothesis statement (If X is true, then Y explains the bug)
2. Reasoning (Why we believe this)
3. Evidence needed to confirm
4. Evidence needed to reject
5. Experiment to run
6. Expected result if true
7. Expected result if false
8. Actual result
9. Conclusion (Confirmed, Rejected, Inconclusive)
10. Next hypothesis to explore

List at least 5 potential hypotheses.
Rank them by likelihood.
Explain in beginner-friendly language.

ROOT_CAUSE_ANALYSIS

Category: 17. Debugging
Section: Pillar 4: Hypothesize & Test

10. `ROOT_CAUSE_ANALYSIS.md`

You are a senior engineer specializing in root cause analysis.
Identify the root cause of this bug.

INPUTS:
Hypothesis Log: [PASTE HYPOTHESIS_LOG]
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. Problem statement
2. 5 Whys analysis (Ask "Why?" 5 times)
3. Fishbone diagram (Categories: Code, Data, Config, Environment, Human)
4. Timeline of events
5. Root cause (The actual reason)
6. Contributing factors (What made it worse?)
7. Why tests missed it
8. Why monitoring missed it
9. Why the code was written this way (Context)
10. Corrective actions (Immediate fix)
11. Preventive actions (How to prevent recurrence)

Do not stop at the first symptom — go deep.
Focus on preventing recurrence, not just fixing the symptom.
Explain in beginner-friendly language.

EXPERIMENT_TRACKER

Category: 17. Debugging
Section: Pillar 4: Hypothesize & Test

11. `EXPERIMENT_TRACKER.md`

You are a scientific debugging mentor.
Create an experiment tracker for this bug.

INPUTS:
Hypothesis Log: [PASTE HYPOTHESIS_LOG]

Provide a tracker template:
1. Experiment ID
2. Hypothesis being tested
3. Change made (Code, Config, Data)
4. Environment
5. Expected outcome
6. Actual outcome
7. Time taken
8. Side effects observed
9. Conclusion
10. Next experiment

Include at least 5 experiment examples.
Track everything — no experiment is wasted.
Explain in beginner-friendly language.

Pillar 5: Resolve & Verify

Category: 17. Debugging

Welcome to Pillar 5: Resolve & Verify for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

FIX_IMPLEMENTATION

Category: 17. Debugging
Section: Pillar 5: Resolve & Verify

12. `FIX_IMPLEMENTATION.md`

You are a senior engineer.
Design the fix for this bug.

INPUTS:
Root Cause Analysis: [PASTE ROOT_CAUSE_ANALYSIS]

Provide:
1. Fix summary (One sentence)
2. Files to change
3. Code changes (High-level)
4. Why this fix addresses the root cause
5. Why we chose this fix over alternatives
6. Side effects to watch for
7. Rollback plan
8. Feature flag (If applicable)
9. Documentation updates needed
10. Commit message template
11. A pre-fix checklist

Keep the fix minimal and targeted.
Do not refactor unrelated code.
Explain in beginner-friendly language.

REGRESSION_TEST_PLAN

Category: 17. Debugging
Section: Pillar 5: Resolve & Verify

13. `REGRESSION_TEST_PLAN.md`

You are a QA engineer specializing in regression testing.
Create a regression test plan for this fix.

INPUTS:
Fix Implementation: [PASTE FIX_IMPLEMENTATION]
Root Cause Analysis: [PASTE ROOT_CAUSE_ANALYSIS]

Provide:
1. Verification testing (Does the fix work?)
2. Regression testing (What might break?)
3. Edge case testing (Boundary conditions)
4. Integration testing (Cross-component)
5. Load testing (If applicable)
6. Test cases specific to this bug
7. Test cases for related functionality
8. Automated test coverage gaps
9. Manual test checklist
10. Sign-off criteria
11. A checklist to prevent the bug from shipping again

Focus on verifying the fix without introducing new bugs.
Explain in beginner-friendly language.

DEPLOYMENT_PLAN

Category: 17. Debugging
Section: Pillar 5: Resolve & Verify

14. `DEPLOYMENT_PLAN.md`

You are a DevOps engineer.
Create a deployment plan for this fix.

INPUTS:
Fix Implementation: [PASTE FIX_IMPLEMENTATION]
Regression Test Plan: [PASTE REGRESSION_TEST_PLAN]

Provide:
1. Pre-deployment verification
2. Deployment strategy (Blue-Green, Canary, Rolling)
3. Rollback plan
4. Feature flag strategy
5. Step-by-step deployment
6. Post-deployment monitoring
7. User communication (If needed)
8. Success criteria
9. Post-deployment verification
10. Deployment checklist
11. Common deployment mistakes to avoid

Keep the deployment simple and reversible.
Explain in beginner-friendly language.

Pillar 6: Prevent & Learn

Category: 17. Debugging

Welcome to Pillar 6: Prevent & Learn for 17. Debugging. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

POST_MORTEM

Category: 17. Debugging
Section: Pillar 6: Prevent & Learn

15. `POST_MORTEM.md`

You are a senior incident review lead.
Create a blameless post-mortem for this bug.

INPUTS:
Root Cause Analysis: [PASTE ROOT_CAUSE_ANALYSIS]
Fix Implementation: [PASTE FIX_IMPLEMENTATION]

Provide:
1. Incident summary
2. Timeline of events
3. Root cause
4. Contributing factors
5. Impact (Users, Revenue, Trust)
6. What went well
7. What went wrong
8. Where we got lucky
9. Action items (Preventive, Detective, Mitigative)
10. Owners for each action item
11. Lessons learned

Blameless tone — focus on systems, not people.
Make action items specific, measurable, and time-bound.
Explain in beginner-friendly language.

PREVENTION_CHECKLIST

Category: 17. Debugging
Section: Pillar 6: Prevent & Learn

16. `PREVENTION_CHECKLIST.md`

You are a senior engineering lead.
Create a prevention checklist based on this bug.

INPUTS:
Post-Mortem: [PASTE POST_MORTEM]
Root Cause Analysis: [PASTE ROOT_CAUSE_ANALYSIS]

Provide:
1. Code-level prevention (Patterns, Linting rules, Type safety)
2. Test-level prevention (New tests, Coverage targets)
3. Monitoring prevention (New alerts, Dashboards)
4. Process prevention (Code review, Staging gates)
5. Documentation prevention (Runbooks, ADRs)
6. Architecture prevention (Design changes)
7. Dependency prevention (Updates, Pinning)
8. Team prevention (Knowledge sharing, Onboarding)
9. Tooling prevention (CI/CD improvements)
10. A 30-day follow-up checklist

Explain each prevention in beginner-friendly language.
Prioritize actions by impact and effort.

TECH_DEBT_LOG

Category: 17. Debugging
Section: Pillar 6: Prevent & Learn

17. `TECH_DEBT_LOG.md`

You are a senior engineer.
Log tech debt related to this bug.

INPUTS:
Post-Mortem: [PASTE POST_MORTEM]
Fix Implementation: [PASTE FIX_IMPLEMENTATION]

Provide:
1. Tech debt item
2. Origin (Why the shortcut was taken)
3. Impact on this bug
4. Impact on future velocity
5. Interest rate (How fast it grows)
6. Priority (High, Medium, Low)
7. Fix effort estimate
8. When to fix (Now, Next, Later, Never)
9. Owner
10. Related design decisions
11. A review cadence

Be honest about debt.
Do not accumulate — schedule fixes.
Explain in beginner-friendly language.

Support Documents

DEBUG_TOOLING

Category: 17. Debugging
Section: Pillar 6: Prevent & Learn

18. `DEBUG_TOOLING.md`

You are a debugging tools expert.
List all debugging tools relevant to this bug.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]

Provide:
1. Frontend tools (Chrome DevTools, React DevTools)
2. Backend tools (Node Inspector, Postman)
3. Database tools (DB Client, Query Profiler)
4. Network tools (Wireshark, Network tab)
5. Performance tools (Lighthouse, Profiler)
6. Error tracking (Sentry, LogRocket)
7. Logging tools (Winston, Loguru)
8. APM tools (New Relic, Datadog)
9. Which tools to use for this specific bug
10. Setup instructions
11. Common debugging workflows

Explain each tool in beginner-friendly language.
Keep the list minimal — only what is needed.

GLOSSARY

Category: 17. Debugging
Section: Pillar 6: Prevent & Learn

19. `GLOSSARY.md`

You are a technical writer specializing in debugging.
Create a Glossary document.

INPUTS:
Symptom Report: [PASTE SYMPTOM_REPORT]
Root Cause Analysis: [PASTE ROOT_CAUSE_ANALYSIS]

Provide definitions for:
1. Debugging terms (Breakpoint, Stack Trace, Watch, Step Over)
2. Bug terms (Heisenbug, Race Condition, Memory Leak, Null Pointer)
3. Root cause terms (5 Whys, Fishbone, Regression)
4. Tooling terms (DevTools, Profiler, APM, Log Aggregator)
5. Metrics terms (MTTR, MTBF, Error Rate, Coverage)
6. Testing terms (Regression Test, Edge Case)
7. Project-specific terms
8. Acronyms

For each term:
- Simple definition (Beginner-friendly)
- Why it matters
- Example usage

Keep definitions concise.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

18. Improve System Design

An 8-dimension architectural guide covering requirements, components, storage, APIs, partitioning, resilience, observability, and trade-offs.

Overview

This category provides structured prompt packs tailored for 18. Improve System Design projects. Follow the structured workflow below to build from concept to delivery.

Dimension 1: Requirements & Scope

Dimension 2: Component Architecture

Dimension 3: Data Storage & Modeling

Dimension 4: Communication & APIs

Dimension 5: Scalability & Partitioning

Dimension 6: Resilience & Fault Tolerance

Dimension 7: Observability & Operations

Dimension 8: Evolution & Trade-offs

Select any document from the list above or use the sidebar to proceed.

Dimension 1: Requirements & Scope

Category: 18. Improve System Design

Welcome to Dimension 1: Requirements & Scope for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DESIGN_REQUIREMENTS

Category: 18. Improve System Design
Section: Dimension 1: Requirements & Scope

Purpose & Context

Guide the architectural design of DESIGN_REQUIREMENTS in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the DESIGN_REQUIREMENTS for the system specified below:
[PASTE SYSTEM CONTEXT]

CAPACITY_ESTIMATION

Category: 18. Improve System Design
Section: Dimension 1: Requirements & Scope

Purpose & Context

Guide the architectural design of CAPACITY_ESTIMATION in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the CAPACITY_ESTIMATION for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 2: Component Architecture

Category: 18. Improve System Design

Welcome to Dimension 2: Component Architecture for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

COMPONENT_MAP

Category: 18. Improve System Design
Section: Dimension 2: Component Architecture

Purpose & Context

Guide the architectural design of COMPONENT_MAP in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the COMPONENT_MAP for the system specified below:
[PASTE SYSTEM CONTEXT]

DATA_FLOW

Category: 18. Improve System Design
Section: Dimension 2: Component Architecture

Purpose & Context

Guide the architectural design of DATA_FLOW in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the DATA_FLOW for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 3: Data Storage & Modeling

Category: 18. Improve System Design

Welcome to Dimension 3: Data Storage & Modeling for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

STORAGE_CHOICE

Category: 18. Improve System Design
Section: Dimension 3: Data Storage & Modeling

Purpose & Context

Guide the architectural design of STORAGE_CHOICE in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the STORAGE_CHOICE for the system specified below:
[PASTE SYSTEM CONTEXT]

SCHEMA_DESIGN

Category: 18. Improve System Design
Section: Dimension 3: Data Storage & Modeling

Purpose & Context

Guide the architectural design of SCHEMA_DESIGN in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the SCHEMA_DESIGN for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 4: Communication & APIs

Category: 18. Improve System Design

Welcome to Dimension 4: Communication & APIs for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

API_PROTOCOLS

Category: 18. Improve System Design
Section: Dimension 4: Communication & APIs

Purpose & Context

Guide the architectural design of API_PROTOCOLS in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the API_PROTOCOLS for the system specified below:
[PASTE SYSTEM CONTEXT]

INTERFACE_CONTRACTS

Category: 18. Improve System Design
Section: Dimension 4: Communication & APIs

Purpose & Context

Guide the architectural design of INTERFACE_CONTRACTS in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the INTERFACE_CONTRACTS for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 5: Scalability & Partitioning

Category: 18. Improve System Design

Welcome to Dimension 5: Scalability & Partitioning for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

PARTITIONING_STRATEGY

Category: 18. Improve System Design
Section: Dimension 5: Scalability & Partitioning

Purpose & Context

Guide the architectural design of PARTITIONING_STRATEGY in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the PARTITIONING_STRATEGY for the system specified below:
[PASTE SYSTEM CONTEXT]

REPLICATION_PLAN

Category: 18. Improve System Design
Section: Dimension 5: Scalability & Partitioning

Purpose & Context

Guide the architectural design of REPLICATION_PLAN in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the REPLICATION_PLAN for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 6: Resilience & Fault Tolerance

Category: 18. Improve System Design

Welcome to Dimension 6: Resilience & Fault Tolerance for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

FAILURE_MODES

Category: 18. Improve System Design
Section: Dimension 6: Resilience & Fault Tolerance

Purpose & Context

Guide the architectural design of FAILURE_MODES in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the FAILURE_MODES for the system specified below:
[PASTE SYSTEM CONTEXT]

REDUNDANCY_FAILOVER

Category: 18. Improve System Design
Section: Dimension 6: Resilience & Fault Tolerance

Purpose & Context

Guide the architectural design of REDUNDANCY_FAILOVER in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the REDUNDANCY_FAILOVER for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 7: Observability & Operations

Category: 18. Improve System Design

Welcome to Dimension 7: Observability & Operations for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

METRICS_LOGS

Category: 18. Improve System Design
Section: Dimension 7: Observability & Operations

Purpose & Context

Guide the architectural design of METRICS_LOGS in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the METRICS_LOGS for the system specified below:
[PASTE SYSTEM CONTEXT]

DEPLOYMENT_RUNBOOK

Category: 18. Improve System Design
Section: Dimension 7: Observability & Operations

Purpose & Context

Guide the architectural design of DEPLOYMENT_RUNBOOK in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the DEPLOYMENT_RUNBOOK for the system specified below:
[PASTE SYSTEM CONTEXT]

Dimension 8: Evolution & Trade-offs

Category: 18. Improve System Design

Welcome to Dimension 8: Evolution & Trade-offs for 18. Improve System Design. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

TRADEOFF_ANALYSIS

Category: 18. Improve System Design
Section: Dimension 8: Evolution & Trade-offs

Purpose & Context

Guide the architectural design of TRADEOFF_ANALYSIS in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the TRADEOFF_ANALYSIS for the system specified below:
[PASTE SYSTEM CONTEXT]

FUTURE_EVOLUTION

Category: 18. Improve System Design
Section: Dimension 8: Evolution & Trade-offs

Purpose & Context

Guide the architectural design of FUTURE_EVOLUTION in modern distributed systems.

Prompt Template

You are a Principal System Architect.
Design the FUTURE_EVOLUTION for the system specified below:
[PASTE SYSTEM CONTEXT]

19. SEO Optimization

An 8-pillar search engine optimization system covering technical foundation, on-page, content, keywords, and authority.

Overview

This category provides structured prompt packs tailored for 19. SEO Optimization projects. Follow the structured workflow below to build from concept to delivery.

Pillar 1: Technical Foundation

Pillar 2: On-Page Optimization

Pillar 3: Content Strategy

Pillar 4: Keyword Architecture

Pillar 5: Off-Page Authority

Pillar 6: Local & International

Pillar 7: User Experience Signals

Pillar 8: Measurement & Iteration

Select any document from the list above or use the sidebar to proceed.

Pillar 1: Technical Foundation

Category: 19. SEO Optimization

Welcome to Pillar 1: Technical Foundation for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

TECHNICAL_SEO_AUDIT

Category: 19. SEO Optimization
Section: Pillar 1: Technical Foundation

1. `TECHNICAL_SEO_AUDIT.md`

You are a senior technical SEO auditor.
Perform a technical SEO audit for this website.

INPUT:
[PASTE WEBSITE URL OR PROJECT DESCRIPTION]

Provide:
1. Crawlability (Robots.txt, XML Sitemap, Crawl Budget)
2. Indexability (Meta Robots, Canonical Tags, Index Coverage)
3. Site Architecture (URL Structure, Internal Linking, Breadcrumbs)
4. Page Speed (LCP, FID, CLS, TTFB)
5. Mobile Friendliness (Responsive, Tap Targets, Viewport)
6. HTTPS and Security (SSL, HSTS, Mixed Content)
7. Structured Data (Schema.org, JSON-LD, Rich Snippets)
8. JavaScript Rendering (SSR, CSR, Hydration)
9. Server Response (Status Codes, Redirects, 404s)
10. Common technical SEO mistakes
11. A prioritized fix list (Impact × Effort)
12. A checklist to verify technical health

Explain each item in beginner-friendly language.
Prioritize fixes that have the highest impact.

CORE_WEB_VITALS

Category: 19. SEO Optimization
Section: Pillar 1: Technical Foundation

2. `CORE_WEB_VITALS.md`

You are a web performance engineer.
Optimize Core Web Vitals for this website.

INPUT:
[PASTE WEBSITE URL OR CURRENT METRICS]

Provide:
1. LCP (Largest Contentful Paint) — Target < 2.5s
   - What it measures
   - Current issues
   - Optimization techniques
2. INP (Interaction to Next Paint) — Target < 200ms
   - What it measures
   - Current issues
   - Optimization techniques
3. CLS (Cumulative Layout Shift) — Target < 0.1
   - What it measures
   - Current issues
   - Optimization techniques
4. TTFB (Time to First Byte) — Target < 600ms
5. Image optimization (WebP, AVIF, Lazy loading)
6. Font optimization (Preload, Swap, Subset)
7. JavaScript optimization (Code splitting, Defer, Async)
8. CSS optimization (Critical CSS, Purge unused)
9. Caching strategy (Browser, CDN, Edge)
10. Tools (PageSpeed Insights, Lighthouse, WebPageTest)
11. A prioritized optimization checklist

Explain each metric in beginner-friendly language.
Provide code examples where useful.

CRAWLABILITY_INDEXING

Category: 19. SEO Optimization
Section: Pillar 1: Technical Foundation

3. `CRAWLABILITY_INDEXING.md`

You are a search engine crawler expert.
Optimize crawlability and indexing for this website.

INPUT:
[PASTE WEBSITE URL OR PROJECT DESCRIPTION]

Provide:
1. Robots.txt best practices
2. XML Sitemap setup (Structure, Priority, Frequency)
3. Canonical tags (When and how to use)
4. Meta robots tags (Index, Noindex, Follow, Nofollow)
5. Pagination handling (rel=next/prev, Load more)
6. Faceted navigation (E-commerce specific)
7. JavaScript rendering strategy
8. Crawl budget optimization
9. Index coverage report interpretation
10. Common indexing mistakes
11. Google Search Console setup and usage
12. A crawlability checklist

Explain each concept in beginner-friendly language.
Provide real examples of correct vs incorrect implementation.

Pillar 2: On-Page Optimization

Category: 19. SEO Optimization

Welcome to Pillar 2: On-Page Optimization for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

ON_PAGE_SEO

Category: 19. SEO Optimization
Section: Pillar 2: On-Page Optimization

4. `ON_PAGE_SEO.md`

You are an on-page SEO specialist.
Optimize on-page elements for this website.

INPUT:
[PASTE PAGE URL OR CONTENT]

Provide:
1. Title tags (Length, Keywords, Brand, CTR)
2. Meta descriptions (Length, Compelling, Keywords)
3. Heading hierarchy (H1, H2, H3 — one H1 per page)
4. URL structure (Short, Descriptive, Hyphens)
5. Image alt text (Descriptive, Keyword-relevant)
6. Internal linking (Anchor text, Context)
7. External linking (Authority, Nofollow rules)
8. Content formatting (Bullets, Bold, Readability)
9. Keyword placement (Natural, Not stuffed)
10. Schema markup (Article, Product, FAQ, Breadcrumb)
11. Open Graph and Twitter Cards
12. Common on-page mistakes
13. A page-level SEO checklist

Explain each element in beginner-friendly language.
Provide before/after examples.

SCHEMA_MARKUP

Category: 19. SEO Optimization
Section: Pillar 2: On-Page Optimization

5. `SCHEMA_MARKUP.md`

You are a structured data expert.
Create schema markup for this website.

INPUT:
[PASTE WEBSITE TYPE AND CONTENT]

Provide:
1. What is schema markup? (Beginner explanation)
2. Schema types to use (Article, Product, FAQ, HowTo, Organization, Person)
3. JSON-LD implementation
4. Required vs recommended properties
5. Testing tools (Rich Results Test, Schema Validator)
6. Rich snippet opportunities
7. Common schema mistakes
8. Impact on CTR and rankings
9. Example JSON-LD for each schema type
10. A schema implementation checklist

Provide copy-paste ready JSON-LD snippets.
Explain each property in beginner-friendly language.

Pillar 3: Content Strategy

Category: 19. SEO Optimization

Welcome to Pillar 3: Content Strategy for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

CONTENT_STRATEGY

Category: 19. SEO Optimization
Section: Pillar 3: Content Strategy

6. `CONTENT_STRATEGY.md`

You are a senior content strategist.
Create an SEO-driven content strategy.

INPUT:
[PASTE WEBSITE NICHE, AUDIENCE, GOALS]

Provide:
1. Content goals (Awareness, Traffic, Conversion)
2. Audience personas
3. Topic clusters (Pillar pages + Cluster pages)
4. Content types (Blog, Guides, Videos, Tools)
5. Content calendar (Frequency, Themes)
6. Content depth (Word count, Comprehensiveness)
7. Content freshness (Update cadence)
8. E-E-A-T signals (Experience, Expertise, Authoritativeness, Trust)
9. Content distribution channels
10. Content repurposing strategy
11. Common content mistakes
12. A content strategy checklist

Explain each concept in beginner-friendly language.
Focus on quality over quantity.
Prioritize topics with search intent.

TOPIC_CLUSTERS

Category: 19. SEO Optimization
Section: Pillar 3: Content Strategy

7. `TOPIC_CLUSTERS.md`

You are a topical authority expert.
Design topic clusters for this website.

INPUT:
[PASTE WEBSITE NICHE]

Provide:
1. Pillar page (Broad topic)
2. Cluster pages (Subtopics)
3. Internal linking structure (Pillar ↔ Clusters)
4. Keyword mapping for each page
5. Search intent per cluster
6. Content format recommendations
7. Priority order (What to build first)
8. Example topic cluster for this niche
9. Common cluster mistakes
10. A cluster planning template

Explain how topic clusters build authority.
Provide a visual representation (Text-based).

CONTENT_QUALITY

Category: 19. SEO Optimization
Section: Pillar 3: Content Strategy

8. `CONTENT_QUALITY.md`

You are a content quality editor.
Create guidelines for high-quality SEO content.

INPUT:
[PASTE WEBSITE NICHE]

Provide:
1. What Google considers "helpful content"
2. E-E-A-T principles
3. Content depth guidelines
4. Readability standards (Flesch-Kincaid, Grade level)
5. Originality vs AI-generated content
6. Fact-checking and citations
7. Content structure (Intro, Body, Conclusion, CTA)
8. Multimedia integration (Images, Videos, Infographics)
9. Content maintenance (Refresh, Update, Prune)
10. Common quality mistakes
11. A content quality checklist

Explain each principle in beginner-friendly language.
Provide examples of high vs low quality content.

Pillar 4: Keyword Architecture

Category: 19. SEO Optimization

Welcome to Pillar 4: Keyword Architecture for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

KEYWORD_RESEARCH

Category: 19. SEO Optimization
Section: Pillar 4: Keyword Architecture

9. `KEYWORD_RESEARCH.md`

You are a senior keyword research specialist.
Perform keyword research for this website.

INPUT:
[PASTE WEBSITE NICHE, PRODUCT, OR SERVICE]

Provide:
1. Seed keywords
2. Short-tail keywords (1-2 words)
3. Long-tail keywords (3+ words)
4. Search intent classification (Informational, Navigational, Commercial, Transactional)
5. Keyword difficulty (Easy, Medium, Hard)
6. Search volume estimates
7. Keyword variations (Synonyms, Related, LSI)
8. Question-based keywords (Who, What, When, Where, Why, How)
9. Competitor keywords
10. Keyword gaps (Opportunities)
11. Priority keywords (High intent + Low difficulty)
12. A keyword research template

Explain each concept in beginner-friendly language.
Provide 20+ example keywords for this niche.

KEYWORD_MAPPING

Category: 19. SEO Optimization
Section: Pillar 4: Keyword Architecture

10. `KEYWORD_MAPPING.md`

You are an SEO strategist.
Map keywords to pages for this website.

INPUT:
Keyword Research: [PASTE KEYWORD_RESEARCH]
Website Structure: [PASTE SITEMAP OR PAGES]

Provide:
1. One keyword per page (Primary)
2. Secondary keywords per page
3. Search intent per page
4. Content format recommendation
5. Internal linking plan
6. Keyword cannibalization check
7. Priority mapping (What to optimize first)
8. Gap analysis (Keywords without pages)
9. Example mapping table
10. A keyword mapping checklist

Explain each mapping decision.
Provide a visual table format.

Pillar 5: Off-Page Authority

Category: 19. SEO Optimization

Welcome to Pillar 5: Off-Page Authority for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

BACKLINK_STRATEGY

Category: 19. SEO Optimization
Section: Pillar 5: Off-Page Authority

11. `BACKLINK_STRATEGY.md`

You are a link building expert.
Create a backlink strategy for this website.

INPUT:
[PASTE WEBSITE NICHE AND GOALS]

Provide:
1. What are backlinks? (Beginner explanation)
2. Types of backlinks (Dofollow, Nofollow, UGC, Sponsored)
3. Quality vs Quantity (Why quality wins)
4. White-hat link building tactics (Guest posts, HARO, Resource pages)
5. Digital PR strategy
6. Broken link building
7. Skyscraper technique
8. Competitor backlink analysis
9. Toxic backlink identification
10. Disavow file usage
11. Tracking backlinks (Ahrefs, Moz, SEMrush)
12. A link building checklist

Explain each tactic in beginner-friendly language.
Focus on sustainable, white-hat strategies.
Warn against black-hat tactics.

BRAND_SIGNALS

Category: 19. SEO Optimization
Section: Pillar 5: Off-Page Authority

12. `BRAND_SIGNALS.md`

You are a brand authority expert.
Improve brand signals for SEO.

INPUT:
[PASTE WEBSITE AND BRAND NAME]

Provide:
1. Brand mentions (Unlinked mentions matter)
2. Brand search volume
3. Social signals (Twitter, LinkedIn, YouTube)
4. Google Business Profile optimization
5. Knowledge Panel setup
6. Author authority (Bylines, Bios)
7. Press coverage and PR
8. Community presence (Reddit, Quora, Forums)
9. Podcast and video appearances
10. Brand consistency (NAP: Name, Address, Phone)
11. Common brand signal mistakes
12. A brand authority checklist

Explain how brand signals influence SEO.
Provide actionable steps for a small brand.

Pillar 6: Local & International

Category: 19. SEO Optimization

Welcome to Pillar 6: Local & International for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

LOCAL_SEO

Category: 19. SEO Optimization
Section: Pillar 6: Local & International

13. `LOCAL_SEO.md`

You are a local SEO expert.
Optimize for local search visibility.

INPUT:
[PASTE BUSINESS TYPE, LOCATION, TARGET AREA]

Provide:
1. Google Business Profile optimization (Complete every field)
2. NAP consistency (Name, Address, Phone)
3. Local citations (Directories, Yelp, Justdial)
4. Local keyword research (City + Service)
5. Local landing pages
6. Customer reviews strategy
7. Local schema markup
8. Local link building
9. Google Maps optimization
10. Multi-location SEO (If applicable)
11. Common local SEO mistakes
12. A local SEO checklist

Explain each concept in beginner-friendly language.
Provide a step-by-step setup for Google Business Profile.

INTERNATIONAL_SEO

Category: 19. SEO Optimization
Section: Pillar 6: Local & International

14. `INTERNATIONAL_SEO.md`

You are an international SEO specialist.
Optimize for multi-language and multi-region search.

INPUT:
[PASTE WEBSITE AND TARGET COUNTRIES/LANGUAGES]

Provide:
1. Hreflang tags (Correct implementation)
2. Multi-language URL structure (Subdomain, Subdirectory, ccTLD)
3. Geo-targeting in Search Console
4. Currency and locale considerations
5. Content localization vs translation
6. Cultural adaptation
7. Local keyword research per region
8. Local search engine optimization (Baidu, Yandex, Naver)
9. Common international SEO mistakes
10. A hreflang implementation checklist

If international SEO is not needed, explain why.
Provide copy-paste ready hreflang examples.

Pillar 7: User Experience Signals

Category: 19. SEO Optimization

Welcome to Pillar 7: User Experience Signals for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

UX_SEO_SIGNALS

Category: 19. SEO Optimization
Section: Pillar 7: User Experience Signals

15. `UX_SEO_SIGNALS.md`

Purpose: To optimize user engagement signals that indirectly influence rankings.

You are a UX and SEO integration expert.
Optimize user experience signals that influence SEO.

INPUT:
[PASTE WEBSITE URL OR PROJECT DESCRIPTION]

Provide:
1. Click-Through Rate (CTR) optimization (Titles, Meta, Rich Snippets)
2. Dwell Time optimization (Content depth, Readability)
3. Bounce Rate reduction (Above-the-fold, Internal links)
4. Scroll Depth (Content structure, Visual hierarchy)
5. Page Experience signals (Core Web Vitals, Mobile, HTTPS)
6. Navigation and site search
7. Accessibility (WCAG, Screen readers)
8. Visual stability (No layout shifts)
9. Interstitial and popup best practices
10. Common UX mistakes that hurt SEO
11. A UX-SEO checklist

Explain how UX signals influence rankings.
Provide actionable improvements.

MOBILE_SEO

Category: 19. SEO Optimization
Section: Pillar 7: User Experience Signals

16. `MOBILE_SEO.md`

Purpose: To optimize for mobile-first indexing.

You are a mobile SEO specialist.
Optimize this website for mobile-first indexing.

INPUT:
[PASTE WEBSITE URL]

Provide:
1. Mobile-first indexing explained (Beginner)
2. Responsive design requirements
3. Mobile page speed (Core Web Vitals on mobile)
4. Tap target sizes (Min 48x48px)
5. Viewport configuration
6. Font sizes (Min 16px for body)
7. Mobile-friendly navigation
8. Mobile-specific content parity (Same content as desktop)
9. AMP considerations (Is it still needed?)
10. Mobile testing tools (Mobile-Friendly Test, Lighthouse)
11. Common mobile SEO mistakes
12. A mobile SEO checklist

Explain each item in beginner-friendly language.
Test on real devices, not just emulators.

Pillar 8: Measurement & Iteration

Category: 19. SEO Optimization

Welcome to Pillar 8: Measurement & Iteration for 19. SEO Optimization. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SEO_ANALYTICS

Category: 19. SEO Optimization
Section: Pillar 8: Measurement & Iteration

17. `SEO_ANALYTICS.md`

Purpose: To track, measure, and report SEO performance.

You are an SEO analytics expert.
Set up SEO analytics for this website.

INPUT:
[PASTE WEBSITE AND GOALS]

Provide:
1. Tools to use (Google Search Console, Google Analytics 4, Ahrefs, SEMrush)
2. Google Search Console setup
3. Google Analytics 4 setup
4. Key metrics to track:
   - Impressions
   - Clicks
   - CTR
   - Average Position
   - Organic Traffic
   - Conversions
5. Custom reports and dashboards
6. UTM parameter strategy
7. Goal and conversion tracking
8. Monthly reporting template
9. Interpreting the data (What to do with insights)
10. Common analytics mistakes
11. A measurement checklist

Explain each metric in beginner-friendly language.
Provide a reporting template.

SEO_TESTING

Category: 19. SEO Optimization
Section: Pillar 8: Measurement & Iteration

18. `SEO_TESTING.md`

Purpose: To test SEO changes and iterate based on data.

You are an SEO experimentation expert.
Create an SEO testing framework for this website.

INPUT:
[PASTE WEBSITE AND CURRENT SEO STRATEGY]

Provide:
1. What to test (Titles, Meta, Content, Structure)
2. A/B testing for SEO (Challenges and approaches)
3. Before/After measurement
4. Statistical significance (How long to wait)
5. Testing cadence (Weekly, Monthly, Quarterly)
6. Rollback strategy (If a change hurts)
7. Documentation of tests
8. Common testing mistakes
9. Tools for testing (Google Optimize alternative, Search Console)
10. A testing log template
11. A checklist for running SEO experiments

Explain each concept in beginner-friendly language.
Focus on small, measurable changes.

SEO_ROADMAP

Category: 19. SEO Optimization
Section: Pillar 8: Measurement & Iteration

19. `SEO_ROADMAP.md`

Purpose: To create a 90-day SEO roadmap with priorities.

You are a senior SEO strategist.
Create a 90-day SEO roadmap for this website.

INPUT:
Technical Audit: [PASTE TECHNICAL_SEO_AUDIT]
Keyword Research: [PASTE KEYWORD_RESEARCH]
Content Strategy: [PASTE CONTENT_STRATEGY]

Provide:
1. Month 1: Foundation (Technical fixes, Setup)
2. Month 2: Content & On-Page (Publish, Optimize)
3. Month 3: Authority & Scale (Backlinks, Expansion)
4. Week-by-week task breakdown
5. Priority matrix (Impact × Effort)
6. Quick wins (First 30 days)
7. Long-term plays (3-6 months)
8. KPIs to track monthly
9. Resource requirements (Time, Tools, Budget)
10. A roadmap checklist

Explain each phase in beginner-friendly language.
Keep the roadmap realistic for a solo developer or small team.

Support Documents

SEO_TOOLING

Category: 19. SEO Optimization
Section: Pillar 8: Measurement & Iteration

20. `SEO_TOOLING.md`

You are an SEO tools expert.
List all SEO tools relevant to this project.

INPUT:
[PASTE PROJECT TYPE AND BUDGET]

Provide:
1. Free tools (Google Search Console, Google Analytics, Ubersuggest)
2. Freemium tools (Ahrefs Webmaster, Moz Free, SEMrush Free)
3. Paid tools (Ahrefs, SEMrush, Moz Pro)
4. Technical tools (Screaming Frog, Sitebulb)
5. Content tools (Surfer SEO, Clearscope)
6. Backlink tools (Ahrefs, Majestic)
7. Local tools (BrightLocal, Whitespark)
8. Rank tracking tools (SERPWatcher, AccuRanker)
9. Which tools to use for this project
10. Budget recommendations
11. Free alternatives to paid tools

Explain each tool in beginner-friendly language.
Prioritize free tools for beginners.

GLOSSARY

Category: 19. SEO Optimization
Section: Pillar 8: Measurement & Iteration

21. `GLOSSARY.md`

You are a technical writer specializing in SEO.
Create a Glossary document.

INPUT:
[PASTE PROJECT DETAILS]

Provide definitions for:
1. SEO basics (SERP, Crawl, Index, Rank)
2. On-page terms (Title, Meta, H1, Alt Text, Anchor Text)
3. Technical terms (Canonical, Hreflang, Robots.txt, Schema)
4. Keyword terms (Short-tail, Long-tail, Intent, Difficulty)
5. Content terms (Pillar, Cluster, E-E-A-T, Helpful Content)
6. Link terms (Backlink, Dofollow, Nofollow, Anchor)
7. Metrics (CTR, Impressions, Position, DA, PA)
8. Local terms (GBP, NAP, Local Pack)
9. Analytics terms (GA4, GSC, UTM)
10. Project-specific terms
11. Acronyms

For each term:
- Simple definition (Beginner-friendly)
- Why it matters
- Example usage

Keep definitions concise.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

SEO Flywheel Diagram

                    ┌─────────────────────┐
                    │  1. TECHNICAL       │
                    │     FOUNDATION      │
                    │  (Crawl, Index,     │
                    │   Speed)            │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  2. ON-PAGE         │
                    │     OPTIMIZATION    │
                    │  (Titles, Meta,     │
                    │   Schema)           │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  3. CONTENT         │
                    │     STRATEGY        │
                    │  (Topics, Depth,    │
                    │   Freshness)        │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  4. KEYWORD         │
                    │     ARCHITECTURE    │
                    │  (Research, Mapping,│
                    │   Clusters)         │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  5. OFF-PAGE        │
                    │     AUTHORITY       │
                    │  (Backlinks, Brand) │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  6. LOCAL &         │
                    │     INTERNATIONAL   │
                    │  (Geo, Language)    │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  7. UX SIGNALS      │
                    │  (CTR, Dwell,       │
                    │   Bounce)           │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │  8. MEASUREMENT     │
                    │     & ITERATION     │
                    │  (Analytics, Tests) │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  🚀 RANKINGS +      │
                    │     TRAFFIC +       │
                    │     CONVERSIONS     │
                    └─────────────────────┘
                               │
                               │  (Feeds back into Pillar 1)
                               └──────────────────────┐
                                                      ▼
                    ┌─────────────────────┐
                    │  CONTINUOUS         │
                    │  IMPROVEMENT LOOP   │
                    └─────────────────────┘

20. Scalability

A 10-layer scalability stack progressing from baseline capacity, vertical scaling, and horizontal replication to multi-region architectures.

Overview

This category provides structured prompt packs tailored for 20. Scalability projects. Follow the structured workflow below to build from concept to delivery.

Layer 1: Baseline & Capacity

Layer 2: Vertical Scaling

Layer 3: Horizontal Scaling

Layer 4: Data Layer Scaling

Layer 5: Caching & CDN

Layer 6: Async & Queues

Layer 7: Cost & Efficiency

Layer 8: Resilience at Scale

Layer 9: Multi-Region

Layer 10: Governance at Scale

Select any document from the list above or use the sidebar to proceed.

Layer 1: Baseline & Capacity

Category: 20. Scalability

Welcome to Layer 1: Baseline & Capacity for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

CAPACITY_BASELINE

Category: 20. Scalability
Section: Layer 1: Baseline & Capacity

1. `CAPACITY_BASELINE.md`

You are a senior performance and scalability engineer.
Help me establish a baseline capacity for this system.

INPUT:
[PASTE SYSTEM DESCRIPTION, CURRENT TRAFFIC, INFRASTRUCTURE]

Provide:
1. Current system architecture summary
2. Current traffic profile (Requests/sec, Daily active users)
3. Peak vs Average traffic patterns
4. Current resource utilization (CPU, Memory, Disk, Network)
5. Current bottlenecks (Where does it slow down first?)
6. Current throughput limits (Requests/sec at acceptable latency)
7. Current error rate and latency percentiles (p50, p95, p99)
8. Estimated ceiling (When will it break?)
9. Headroom remaining (Percent capacity left)
10. Cost per 1,000 requests (Current)
11. Key metrics to monitor going forward
12. A baseline report template

Explain in beginner-friendly language.
Do not propose scaling solutions yet — only establish where we are.
Focus on measurable numbers, not guesses.

LOAD_PROFILE

Category: 20. Scalability
Section: Layer 1: Baseline & Capacity

2. `LOAD_PROFILE.md`

You are a performance engineer.
Create a load profile for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide:
1. Traffic patterns (Daily, Weekly, Seasonal)
2. Peak hour behavior
3. Read vs Write ratio
4. Payload sizes (Request and Response)
5. User behavior distribution (Browsers, Devices, Regions)
6. API endpoint popularity (Which endpoints get hit most?)
7. Cache hit ratio (If applicable)
8. Database query distribution
9. Third-party API call frequency
10. Growth projection (3, 6, 12 months)
11. A load profile chart (Text-based)
12. A checklist for verifying the load profile

Explain each metric in beginner-friendly language.
Use real data where possible, estimates where not.

Layer 2: Vertical Scaling

Category: 20. Scalability

Welcome to Layer 2: Vertical Scaling for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

VERTICAL_SCALING

Category: 20. Scalability
Section: Layer 2: Vertical Scaling

3. `VERTICAL_SCALING.md`

You are a cloud infrastructure expert.
Design a vertical scaling strategy for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide:
1. What vertical scaling is (Beginner explanation)
2. When vertical scaling is the right choice
3. Current instance types/resources
4. Recommended upgrades (CPU, RAM, Disk, Network)
5. Cost implications of upgrading
6. Diminishing returns point
7. Upper limits (When vertical scaling stops working)
8. Zero-downtime upgrade strategy
9. Rollback plan if upgrade causes issues
10. Common vertical scaling mistakes
11. A vertical scaling checklist

Explain each concept in beginner-friendly language.
Be honest about when vertical scaling is a dead end.
Recommend vertical scaling as a short-term fix, not long-term.

INSTANCE_SIZING

Category: 20. Scalability
Section: Layer 2: Vertical Scaling

4. `INSTANCE_SIZING.md`

You are a cloud cost and performance optimizer.
Recommend instance sizing for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Vertical Scaling: [PASTE VERTICAL_SCALING]

Provide:
1. Workload classification (CPU-bound, Memory-bound, IO-bound, Network-bound)
2. Right-sizing analysis (Over-provisioned vs Under-provisioned)
3. Recommended instance types (AWS, GCP, Azure examples)
4. Auto-scaling triggers (CPU, Memory, Custom metrics)
5. Spot vs On-demand vs Reserved trade-offs
6. Cost comparison table
7. Bursting capabilities
8. Common sizing mistakes
9. A right-sizing checklist

Explain in beginner-friendly language.
Focus on cost-efficiency, not just raw power.
Recommend starting small and scaling up as needed.

Layer 3: Horizontal Scaling

Category: 20. Scalability

Welcome to Layer 3: Horizontal Scaling for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

HORIZONTAL_SCALING

Category: 20. Scalability
Section: Layer 3: Horizontal Scaling

5. `HORIZONTAL_SCALING.md`

You are a distributed systems engineer.
Design a horizontal scaling strategy for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide:
1. What horizontal scaling is (Beginner explanation)
2. Stateless design requirements
3. Load balancing strategies (Round Robin, Least Connections, IP Hash)
4. Session management (Sticky sessions, Redis, JWT)
5. Service discovery
6. Auto-scaling policies (Metrics, Thresholds, Cooldowns)
7. Scale-in vs Scale-out
8. Cold start problems and mitigation
9. Health checks and readiness probes
10. Common horizontal scaling mistakes
11. A horizontal scaling checklist

Explain each concept in beginner-friendly language.
Horizontal scaling is the standard path — focus on making it easy.

STATELESS_DESIGN

Category: 20. Scalability
Section: Layer 3: Horizontal Scaling

6. `STATELESS_DESIGN.md`

You are a distributed systems architect.
Refactor this system to be stateless.

INPUTS:
Horizontal Scaling: [PASTE HORIZONTAL_SCALING]
System Description: [PASTE SYSTEM DESCRIPTION]

Provide:
1. What "stateless" means (Beginner explanation)
2. Current stateful components
3. Where state lives today (Files, Memory, Sessions)
4. State extraction strategy (Move to Redis, DB, Object storage)
5. Session externalization
6. File upload handling (S3, Blob storage)
7. Sticky session removal
8. Idempotency requirements
9. Migration plan (From stateful to stateless)
10. Common stateful pitfalls
11. A stateless design checklist

Explain in beginner-friendly language.
Stateless = any instance can serve any request.

Layer 4: Data Layer Scaling

Category: 20. Scalability

Welcome to Layer 4: Data Layer Scaling for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

DATABASE_SCALING

Category: 20. Scalability
Section: Layer 4: Data Layer Scaling

7. `DATABASE_SCALING.md`

You are a senior database scaling expert.
Design a scaling strategy for this database.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Data Model: [PASTE DATA MODEL IF AVAILABLE]

Provide:
1. Current database setup (Engine, Size, QPS)
2. Read vs Write ratio
3. Read scaling strategies (Replicas, Read-only DBs)
4. Write scaling strategies (Sharding, Partitioning)
5. Connection pooling (PgBouncer, ProxySQL)
6. Vertical vs Horizontal scaling for the DB
7. Indexing strategy at scale
8. Query optimization at scale
9. Vacuum/Maintenance at scale
10. When to move to NoSQL / NewSQL
11. Common database scaling mistakes
12. A database scaling checklist

Explain each technique in beginner-friendly language.
Warn about the complexity of sharding.
Recommend progressive scaling (Replicas → Partitioning → Sharding).

REPLICATION_PARTITIONING

Category: 20. Scalability
Section: Layer 4: Data Layer Scaling

8. `REPLICATION_PARTITIONING.md`

You are a database architect.
Design replication and partitioning for this database.

INPUTS:
Database Scaling: [PASTE DATABASE_SCALING]

Provide:
1. Replication topology (Primary-Replica, Multi-Primary)
2. Replication lag monitoring
3. Read replica routing
4. Failover strategy
5. Partitioning strategies (Range, Hash, List)
6. Sharding key selection
7. Cross-shard queries (Avoid if possible)
8. Rebalancing shards
9. Consistency trade-offs
10. Common replication/partitioning mistakes
11. A checklist for safe rollout

Explain each concept in beginner-friendly language.
Replication is easier than sharding — start there.

CACHE_STRATEGY

Category: 20. Scalability
Section: Layer 4: Data Layer Scaling

9. `CACHE_STRATEGY.md`

You are a caching expert.
Design a caching strategy for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Database Scaling: [PASTE DATABASE_SCALING]

Provide:
1. What to cache (Data types, Access patterns)
2. Where to cache (Client, CDN, App, DB)
3. Cache layers (L1 In-memory, L2 Redis, L3 CDN)
4. Cache invalidation strategies (TTL, Write-through, Event-based)
5. Cache keys design
6. Cache hit ratio targets
7. Cache stampede prevention
8. Cache warming
9. Common caching mistakes (Stale data, Thundering herd)
10. Tools (Redis, Memcached, Varnish, Cloudflare)
11. A caching checklist

Explain each concept in beginner-friendly language.
Caching is one of the highest ROI scalability investments.

Layer 5: Caching & CDN

Category: 20. Scalability

Welcome to Layer 5: Caching & CDN for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

CDN_STRATEGY

Category: 20. Scalability
Section: Layer 5: Caching & CDN

10. `CDN_STRATEGY.md`

You are a CDN and edge computing expert.
Design a CDN strategy for this system.

INPUTS:
Cache Strategy: [PASTE CACHE_STRATEGY]
System Description: [PASTE SYSTEM DESCRIPTION]

Provide:
1. What a CDN is (Beginner explanation)
2. What to serve via CDN (Static, Dynamic, Images)
3. CDN providers (Cloudflare, Fastly, CloudFront, Akamai)
4. Edge caching rules
5. Cache headers (Cache-Control, ETag, Vary)
6. Purge and invalidation
7. Image optimization at edge
8. Edge functions (Compute at edge)
9. Cost considerations
10. Common CDN mistakes
11. A CDN checklist

Explain each concept in beginner-friendly language.
CDNs are essential for global scale and DDoS protection.

EDGE_COMPUTING

Category: 20. Scalability
Section: Layer 5: Caching & CDN

11. `EDGE_COMPUTING.md`

You are an edge computing specialist.
Design edge compute strategy for this system.

INPUTS:
CDN Strategy: [PASTE CDN_STRATEGY]

Provide:
1. What edge computing is (Beginner explanation)
2. When to use edge compute
3. Edge platforms (Cloudflare Workers, Vercel Edge, Deno Deploy)
4. Use cases (Personalization, A/B testing, Auth, Rate limiting)
5. Edge vs origin trade-offs
6. State management at edge
7. Edge database options
8. Cold start considerations
9. Common edge computing mistakes
10. An edge computing checklist

Explain each concept in beginner-friendly language.
Edge compute reduces latency dramatically.

Layer 6: Async & Queues

Category: 20. Scalability

Welcome to Layer 6: Async & Queues for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

ASYNC_ARCHITECTURE

Category: 20. Scalability
Section: Layer 6: Async & Queues

12. `ASYNC_ARCHITECTURE.md`

You are an async systems architect.
Design an async architecture for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide:
1. Sync vs Async (When to use each)
2. Operations to make async (Emails, Image processing, Webhooks)
3. Message queue patterns (Producer, Consumer, Worker)
4. Queue technologies (RabbitMQ, Kafka, SQS, Redis Streams)
5. Task scheduling (Cron, Delayed jobs)
6. Priority queues
7. Dead letter queues
8. Retry and backoff strategies
9. Monitoring queue depth
10. Common async mistakes
11. An async architecture checklist

Explain each concept in beginner-friendly language.
Async is what lets systems scale without blocking users.

EVENT_DRIVEN_DESIGN

Category: 20. Scalability
Section: Layer 6: Async & Queues

13. `EVENT_DRIVEN_DESIGN.md`

You are an event-driven architecture expert.
Design an event-driven system for this project.

INPUTS:
Async Architecture: [PASTE ASYNC_ARCHITECTURE]

Provide:
1. Events vs Commands (Difference explained)
2. Event types (Domain events, Integration events)
3. Event schema design
4. Event bus options (Kafka, NATS, EventBridge)
5. Pub/Sub patterns
6. Event sourcing (If applicable)
7. CQRS (If applicable)
8. Event ordering and idempotency
9. Event replay
10. Common event-driven mistakes
11. An event-driven checklist

Explain each concept in beginner-friendly language.
Do not introduce event-driven design if queues are enough.

Layer 7: Cost & Efficiency

Category: 20. Scalability

Welcome to Layer 7: Cost & Efficiency for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

COST_OPTIMIZATION

Category: 20. Scalability
Section: Layer 7: Cost & Efficiency

14. `COST_OPTIMIZATION.md`

You are a cloud cost optimization expert.
Design a cost-efficient scaling strategy.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Scaling Strategy: [PASTE HORIZONTAL_SCALING]

Provide:
1. Current cost breakdown (Compute, Storage, Network, Third-party)
2. Cost per user/request
3. Biggest cost drivers
4. Cost optimization opportunities
5. Reserved vs On-demand vs Spot
6. Right-sizing recommendations
7. Storage tiering (Hot, Warm, Cold, Archive)
8. Network egress optimization
9. Third-party API cost reduction
10. Budget alerts and guardrails
11. Common cost mistakes
12. A cost optimization checklist

Explain each concept in beginner-friendly language.
Scaling without cost control is not sustainable.

EFFICIENCY_METRICS

Category: 20. Scalability
Section: Layer 7: Cost & Efficiency

15. `EFFICIENCY_METRICS.md`

You are a systems efficiency expert.
Define efficiency metrics for this system.

INPUTS:
Cost Optimization: [PASTE COST_OPTIMIZATION]
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide:
1. Cost per request
2. Cost per active user
3. Cost per transaction
4. CPU efficiency (Requests per vCPU)
5. Memory efficiency (Working set utilization)
6. Bandwidth efficiency
7. Storage efficiency
8. Carbon efficiency (If relevant)
9. Benchmarking against industry standards
10. Common efficiency mistakes
11. An efficiency monitoring checklist

Explain each metric in beginner-friendly language.
Efficiency at scale is a competitive advantage.

Layer 8: Resilience at Scale

Category: 20. Scalability

Welcome to Layer 8: Resilience at Scale for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

RESILIENCE_AT_SCALE

Category: 20. Scalability
Section: Layer 8: Resilience at Scale

16. `RESILIENCE_AT_SCALE.md`

You are a site reliability engineer.
Design resilience at scale for this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Scaling Strategy: [PASTE HORIZONTAL_SCALING]

Provide:
1. What breaks at scale (Cascading failures, Retry storms)
2. Failure isolation (Bulkheads, Circuit breakers)
3. Timeout strategies
4. Retry with backoff and jitter
5. Load shedding
6. Graceful degradation
7. Rate limiting at scale
8. Chaos engineering
9. Disaster recovery at scale
10. Common resilience mistakes at scale
11. A resilience checklist

Explain each concept in beginner-friendly language.
At scale, small failures amplify.

OBSERVABILITY_AT_SCALE

Category: 20. Scalability
Section: Layer 8: Resilience at Scale

17. `OBSERVABILITY_AT_SCALE.md`

You are an observability expert.
Design observability for a scaled system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Resilience: [PASTE RESILIENCE_AT_SCALE]

Provide:
1. The three pillars (Logs, Metrics, Traces)
2. Sampling strategy at high volume
3. Aggregation and rollup
4. Distributed tracing at scale
5. Correlation IDs
6. Alerting strategy (Avoid alert fatigue)
7. Dashboards for scale
8. Anomaly detection
9. Cost of observability at scale
10. Common observability mistakes
11. An observability checklist

Explain in beginner-friendly language.
Observability is non-negotiable at scale.

Layer 9: Multi-Region

Category: 20. Scalability

Welcome to Layer 9: Multi-Region for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

MULTI_REGION_STRATEGY

Category: 20. Scalability
Section: Layer 9: Multi-Region

18. `MULTI_REGION_STRATEGY.md`

You are a global infrastructure architect.
Design a multi-region strategy for this system.

INPUTS:
CDN Strategy: [PASTE CDN_STRATEGY]
Database Scaling: [PASTE DATABASE_SCALING]

Provide:
1. When multi-region is necessary
2. Active-Passive vs Active-Active
3. Region selection (Users, Compliance, Cost)
4. Data replication across regions
5. Consistency trade-offs (CAP theorem)
6. DNS routing (Latency, Geo, Failover)
7. Multi-region failover
8. Cost of multi-region
9. Compliance considerations (GDPR, Data residency)
10. Common multi-region mistakes
11. A multi-region checklist

Explain each concept in beginner-friendly language.
Multi-region is complex — only do it when necessary.

GLOBAL_DATA_STRATEGY

Category: 20. Scalability
Section: Layer 9: Multi-Region

19. `GLOBAL_DATA_STRATEGY.md`

You are a global data architect.
Design a global data strategy.

INPUTS:
Multi-Region Strategy: [PASTE MULTI_REGION_STRATEGY]

Provide:
1. Data residency requirements (Per region)
2. Data replication topology
3. Write routing (Primary region, Multi-primary)
4. Read local vs read global
5. Conflict resolution (CRDTs, Last-write-wins)
6. Data sovereignty compliance
7. Backup and disaster recovery
8. Cost of global data
9. Common global data mistakes
10. A global data checklist

Explain in beginner-friendly language.
Data is the hardest part of multi-region.

Layer 10: Governance at Scale

Category: 20. Scalability

Welcome to Layer 10: Governance at Scale for 20. Scalability. This section provides dedicated prompt frameworks and templates to guide your project.

Documents in this Section

Use the navigation in the sidebar to jump directly into each prompt.

SCALE_GOVERNANCE

Category: 20. Scalability
Section: Layer 10: Governance at Scale

20. `SCALE_GOVERNANCE.md`

You are a platform engineering lead.
Design governance for scaling this system.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Multi-Region Strategy: [PASTE MULTI_REGION_STRATEGY]

Provide:
1. Service ownership (Who owns what at scale?)
2. On-call rotations
3. Change management (Canary, Rollback)
4. Incident response at scale
5. Runbooks and playbooks
6. Capacity planning cadence
7. Cost review cadence
8. Architecture review board (If needed)
9. Documentation standards
10. Common governance mistakes
11. A governance checklist

Explain in beginner-friendly language.
At scale, process is as important as tech.

SCALE_ROADMAP

Category: 20. Scalability
Section: Layer 10: Governance at Scale

21. `SCALE_ROADMAP.md`

You are a senior scalability strategist.
Create a 12-month scaling roadmap.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]
Cost Optimization: [PASTE COST_OPTIMIZATION]
Resilience: [PASTE RESILIENCE_AT_SCALE]
Multi-Region: [PASTE MULTI_REGION_STRATEGY]

Provide:
1. Where we are now
2. Where we need to be in 3, 6, 12 months
3. Milestones per quarter
4. Trigger points (When to scale which layer)
5. Budget allocation
6. Team growth requirements
7. Risk mitigation
8. Success metrics
9. Quick wins (First 30 days)
10. Long-term strategic investments
11. A roadmap checklist

Explain each milestone in beginner-friendly language.
Scale based on evidence, not fear.

Support Documents

SCALABILITY_GLOSSARY

Category: 20. Scalability
Section: Layer 10: Governance at Scale

22. `SCALABILITY_GLOSSARY.md`

You are a technical writer specializing in distributed systems.
Create a Scalability Glossary.

INPUTS:
Capacity Baseline: [PASTE CAPACITY_BASELINE]

Provide definitions for:
1. Scaling terms (Vertical, Horizontal, Autoscaling)
2. Load terms (Throughput, Latency, Percentile)
3. Data terms (Sharding, Replication, Partitioning)
4. Cache terms (TTL, Invalidation, Stampede)
5. Async terms (Queue, Event, Worker, Pub/Sub)
6. Resilience terms (Circuit Breaker, Bulkhead, Backpressure)
7. Global terms (Multi-Region, Edge, CDN, Consistency)
8. Metrics (RPS, QPS, p99, TTFB)
9. Project-specific terms
10. Acronyms

For each term:
- Simple definition (Beginner-friendly)
- Why it matters
- Example usage

Keep definitions concise.

SCALE_TOOLING

Category: 20. Scalability
Section: Layer 10: Governance at Scale

23. `SCALE_TOOLING.md`

You are a scalability tools expert.
List tools for scaling this system.

INPUTS:
System Description: [PASTE SYSTEM DESCRIPTION]

Provide:
1. Load testing tools (k6, Locust, Artillery, JMeter)
2. Monitoring tools (Prometheus, Grafana, Datadog)
3. Tracing tools (Jaeger, Zipkin, Tempo)
4. Profiling tools (Flamegraph, Pyroscope)
5. Database tools (PgBouncer, Vitess, Citus)
6. Cache tools (Redis, Memcached)
7. Queue tools (RabbitMQ, Kafka, SQS)
8. CDN tools (Cloudflare, Fastly)
9. Cost tools (Infracost, CloudHealth)
10. Which tools to use for this project
11. Free vs paid recommendations

Explain each tool in beginner-friendly language.
Prioritize free and open-source for beginners.

Thank You

Thank you for using this guide. Go build something amazing!

Made by Siddiq

Credit: Hackathon Alchemy

🔗 Link to Hackathon Alchemy

Scalability Stack Diagram

┌───────────────────────────────────────────────┐
│  10. GOVERNANCE AT SCALE                      │
│      Ownership, On-call, Runbooks             │
├───────────────────────────────────────────────┤
│  9. MULTI-REGION                              │
│      Global, Data Residency, Failover         │
├───────────────────────────────────────────────┤
│  8. RESILIENCE AT SCALE                       │
│      Circuit Breakers, Chaos, DR              │
├───────────────────────────────────────────────┤
│  7. COST & EFFICIENCY                         │
│      Cost per Request, Right-sizing           │
├───────────────────────────────────────────────┤
│  6. ASYNC & QUEUES                            │
│      Events, Workers, Pub/Sub                 │
├───────────────────────────────────────────────┤
│  5. CACHING & CDN                             │
│      Edge, Redis, Static Assets               │
├───────────────────────────────────────────────┤
│  4. DATA LAYER SCALING                        │
│      Replication, Sharding, Partitioning      │
├───────────────────────────────────────────────┤
│  3. HORIZONTAL SCALING                        │
│      Stateless, Load Balancer, Autoscale      │
├───────────────────────────────────────────────┤
│  2. VERTICAL SCALING                          │
│      Bigger Machines, Right-sizing            │
├───────────────────────────────────────────────┤
│  1. BASELINE & CAPACITY                       │
│      Know Where You Are                       │
└───────────────────────────────────────────────┘

Builder Alchemy (Sister Framework)

Structured prompt systems for building products, careers, brands, and businesses.

📌 Framework Overview

While Hackathon Alchemy is optimized for high-speed 24–48 hour prototype sprints, Builder Alchemy expands the prompt framework methodology to the complete lifecycle of product creation, company building, career progression, and brand development.

📁 Core Pillars in Development

1. 🚀 Startup & Product

MVP Building: Validating customer demand before writing code.
SaaS Product Launch: Pricing strategy, product positioning, and Go-To-Market execution.
Startup Fundraising: Pitch deck structures, investor FAQs, and data room checklists.
Micro-SaaS: Niche software businesses built by solo founders.
Product Management: Feature prioritization, user interview synthesis, and roadmapping.

2. 💼 Career & Personal Branding

Job Application System: ATS-optimized resumes, tailored cover letters, and outreach cadences.
Freelancing Business: Proposal templates, client onboarding, and contract checklists.
Personal Branding: Positioning, content pillars, and profile optimization.
Interview Preparation: Technical deep-dives, system design walkthroughs, and behavioral scripts.

3. 🎨 Content & Creator Economy

YouTube Channel Launch: Video scripting, thumbnail ideation, and distribution strategy.
Blog & Newsletter: Editorial calendars, SEO-driven article blueprints, and retention mechanics.
Course Creation: Curriculum design, exercise builders, and student outcome tracking.

4. ⚙️ Business Operations

Legal & Compliance: Privacy policies, terms of service, and entity setup checklists.
Finance & Accounting: P&L projections, runway calculations, and unit economics.
Sales & CRM: Outbound email sequences, objection handling scripts, and CRM pipelines.

📅 Roadmap & Status

Builder Alchemy is currently in active development. Prompt packs will be rolled out as modular releases directly within Alchemy Docs.

Stay tuned or contribute on GitHub!

Keyboard shortcuts

Alchemy Docs