Ralphthon

Busan · Codex Goal Participant Guide

Busan
Problem Statement

The goal is to show a working result built with Codex Goal and current AI models in a half-day sprint.

Track 1 — Codex Plugin

Build an extension people can plug into Codex and use immediately.

Create a Codex extension track submission: a Skill, MCP server, workflow, or tool package that other participants can install and try.

  • It reduces a real repeated workflow once connected to Codex.
  • Setup instructions, config, and README are clear enough for another builder to follow.
  • It is more than a prompt collection: it ships as a reusable tool, skill, or workflow.
  • The demo shows Codex calling the plugin and producing a useful result.

Examples: K-skill, an MCP for a SaaS tool, local file/browser/terminal tools, or a workflow package a team can reuse.

Think: any domain is fine. What matters is that it plugs into Codex and becomes usable immediately.

Track 2 — Image-native Service

Use GPT Image models as the core interface of a service.

Build a service where image generation or editing is not a side feature, but the main product experience.

  • Images are central to the input, output, editing loop, or app/game assets.
  • It goes beyond a one-shot image generator and creates a repeatable user flow.
  • Text, image, and UI connect into something people can save, share, edit, or play.
  • The use case avoids copyright, likeness, and prohibited-content traps.

Examples: generate game assets into a mini game, character/item cards, menu/poster/thumbnail tools, or image editing workflows.

Think: not a button that makes images, but an app that exists because images can be made and edited.

Track 3 — Busan Local Advantage

Use Busan as material, not homework.

Instead of forcing a local problem, use Busan/Gyeongnam assets such as ports, tourism, manufacturing, the sea, markets, and local culture.

  • The demo is more useful or more interesting because it is grounded in Busan.
  • It uses field-like inputs such as port/logistics documents, factory photos, market/tourism routes, or local language.
  • It picks a small situation a local user could try in a day.
  • Local context is connected to the product function, data, or UX, not just decoration.

Examples: multilingual port label/checklist tools, manufacturing SOP checkers, photo-based guides for Jagalchi/Nampo visitors, or games using Busan dialect and ocean imagery.

Think: not solving Busan as a problem, but using Busan as an unfair advantage.

Track 4 — AI Application

An open track for any application powered by AI.

If your build does not fit Codex Plugin, Image-native, or Busan Local Advantage, this is the open service track. Any app is welcome if AI is central to the product.

  • Text, voice, image, realtime, agents, search, automation, and multimodal AI are all allowed.
  • It needs a complete app flow where a user gives input and gets a useful result.
  • It should feel like a service with a problem, UX, and output, not just a raw model demo.
  • The strongest submissions create an experience that only became possible because of AI.

Examples: GPT Realtime voice input/output apps, meeting or call copilots, realtime tutors, multimodal search, agentic productivity tools, AI games, or social apps.

Think: if it does not fit the other tracks, that is fine. Build a useful or fun AI-powered app.

Track comparison

Codex Plugin
Image-native Service
Busan Local Advantage
AI Application
Scored on
Installability · Codex integration · reuse
Image experience · completeness · fun
Local grounding · field feel · conviction
Service quality · AI use · usability
Required proof
Codex connection demo and README
GPT Image-based generation/editing flow
Busan/Gyeongnam material is core to the product
A working app where AI is central
Why it is good
Other builders can use it immediately
The service only works because images are native
Local context makes the demo stronger
It is the most open path to a great AI app
Keywords
skill, MCP, workflow, installable
image generation, editing, game asset, visual UX
port, tourism, manufacturing, market, culture
realtime, voice, agent, multimodal, service
Reference
K-skill, automation MCPs, workflow packages
image asset games, card generators, poster tools
port/logistics, manufacturing SOPs, Jagalchi/Nampo, ocean content
GPT Realtime voice apps, copilots, AI games, productivity tools

Declare your track at submission. Prizes are awarded per track.

NOT TO DO List

Projects will be immediately disqualified if they fall into any of these categories:

  • Basic RAG Applications
  • Streamlit Applications
  • Image Analyzers
  • "AI for Education" Chatbot
  • AI Job Application Screener
  • AI Nutrition Coach
  • Personality Analyzers
Connect with the Community

Join the Ralphthon Discord for team formation, announcements, and Q&A:

  • #announcements — Official updates from organizers
  • #team-building — Find teammates (max team size: 4)
  • #live-and-updates — Live updates during the event
  • #questions — Ask organizers anything
Rules
  • Team Size: Maximum 4 members per team. Solo participants are welcome.
  • Track Lock-in: One team, one track. Declare at submission.
  • Open Source: Submitted repositories must be public.
  • New Work Only: You may not present existing projects as your own work. Judges will check.
  • Demo Requirements: Your demo must highlight only features built during the hackathon. Failure to clearly identify original contributions = disqualification.
  • Codex usage encouraged: show how Codex Goal, Skills, MCP, image models, or other AI tools helped you ship faster and demo better.
  • Banned Projects: Projects will be disqualified if they violate legal, ethical, or platform policies, or use code/data/assets you don't have rights to.

📹 Media Notice

Photos or video may be taken for event documentation. If you prefer not to appear, tell the organizers at check-in.

Judging

Casual demos: 3 minutes per team, focused on a real working screen rather than slides.

Clearly show what you built during the event. Working demos beat polished decks.

Scorecard

One card per judge per team.

Columns: Team name · Judge name · Live demo (0-4) · Creativity / Originality (0-3) · Impact potential (0-3)

Total: 10 points (Live demo 4 + Creativity 3 + Impact 3)

  • Live Demo (0-4)How well does the team implement the core idea? Does it actually work live?
  • Creativity / Originality (0-3)Has this been seen before? Does it tackle the track's problem in an original way?
  • Impact Potential (0-3)Will this survive past the hackathon? How useful is it?

Tracks

All four tracks use the same scorecard, with judges also checking how well the submission fulfills its chosen track promise.

Questions? Reach out to GB Jeong — bong@team-attention.com