Pass Forward

Inspiration

This year's World Cup brought me back to soccer after years of being away from it. I had played when I was younger, then switched over to powerlifting after high school and began to develop an interest in biomechanics, something directly applicable to every movement we perform in any sport. The World Cup reminded me of that urge to pick up a ball again, but now with my new perspective on sports. It brought me to a practical question when I was trying to get back into playing. What should I change on the next pass?

That question is awkward when you practice alone. You can prop up a phone, film a pass, and notice that something looks off. Then you are left with a video and a guess. Private coaching is not always accessible, and generic tutorials cannot see the attempt in front of you. I wanted to make a modest tool for that in-between moment, one that helps a player step outside, work on a specific physical skill, and return to the ball with a concrete idea.

I narrowed the first version on purpose. Pass Forward does not try to teach all of soccer or rate the ball's flight. It stays with one stationary-ball long pass from a fixed side view. The constraint keeps the claim honest.

What it does

Private coaching may be inaccessible. Generic tutorials do not respond to an individual's movement, and ordinary video review can reveal a difference without giving the player a usable next step. Pass Forward is an interactive loop for players across experience levels who want to work on the same supported pass.

Each completed coaching pass produces one personalized next-attempt plan: one short cue and one visual target for the next attempt. A player can record with their device's camera or upload one fixed side-view clip. The browser samples five low-resolution frames and keeps the full clip local. OpenAI's gpt-5.6-terra reviews those samples and returns either one attainable correction or a retake instruction when the view is not coachable.

On a coachable result, the clip plays once, slows near the selected frame, and holds. An off-white observed trace and orange target trace show one body relationship to change. The player can replay the comparison or choose Try again for a clean attempt. The result exists only after the OpenAI request succeeds. There is no fabricated local coaching result after an API or schema failure.

How I built it

Pass Forward uses React, TypeScript, and Next.js through ChatGPT Sites and vinext. Browser media and canvas APIs open the camera, decode clips, and create the samples. The OpenAI Responses API receives five JPEG samples through a same-origin server route. Exact gpt-5.6-terra returns a Zod Structured Output that the client validates strictly before it starts the guided replay and aligned overlay. The runtime path is browser clip, five JPEG samples, same-origin route, structured response, validation, then replay. The request uses store: false, no tools, no retry, and no local result fallback. The full clip stays in the browser.

I built the project with Codex as a complete development system. A single controller thread carried architecture, priorities, context, and integration. Bounded task sessions handled implementation and review; delegated agents used parallel worktrees when the work could safely split. Using loops, goals, tests, review gates, Git reconciliation, and defining explicit definitions of done kept long horizon autonomous sessions from drifting.

I set the product direction and binding decisions, ran real-world checks, stopped sessions that looped needlessly, and made the final visual and functional calls. Codex contributed design, implementation, tests, reviews, and repository work. At runtime, GPT-5.6 Terra supplies the bounded visual coaching response. Those roles are separate by design.

Challenges I ran into

Camera recordings and uploaded clips decode on their own schedules, so sampling the intended moments required careful seeking and frame checks. The replay has a second timing problem: it must hold the decoded frame before placing the observed and target poses over the player. That drove the one-shot slowdown and held-overlay sequence.

The model output needed the same discipline. I used a strict schema and a fail-closed client because a pretty overlay is not enough if its data is incomplete. Retry and reset also had to cancel media work, timers, and pending processing without leaving an old result on screen.

The project was built around my full-time work schedule and done entirely on an older MacBook with limited disk space. Allowing things to run autonomously while still properly managing work tree clean up and constant Github usage was vital to avoiding serious issues and blockers. The length of autonomous sessions added their own maintenance cost on top of that. When an agent looped or worked the wrong seam, I had to intervene, reduce the scope, and send it back through a smaller test and review path. ChatGPT's mobile app saved my life working on this as I was able to remotely start and manage sessions through out my busy days, with my laptop sitting running and plugged in at home.

Developing a full project in its entirety while having almost no time to do work yourself means rapidly going through usage limits. Limiting GPT5.6 Sol to only be the head controller session, while delegating tasks to Terra orchestrators and having Luna or Codex Spark do all implementation significantly reduced worries of token expenditure.

Accomplishments that I'm proud of

I am proud that the camera and upload loop reaches a real, narrow coaching experience. The runtime enforces exact Terra and strict structured responses. It gives one correction, a synchronized held comparison, replay, and a clean try-again path. When the clip is not coachable or the request fails, it says so instead of inventing advice.

The privacy boundary is equally important. The full clip remains browser-local while only five low-resolution frames go to OpenAI. I also built accessible controls, reduced-motion behavior, cancellation paths, and automated privacy, accessibility, and browser checks around the loop.

The interface is responsive and camera-capable, designed to be usable on a phone at the practice field as well as at a desktop. That is a compatibility and design goal, not a claim of broad mobile or production-camera validation.

What I learned

The narrow scope made the product better. One supported movement and one correction forced clear language, clear failure states, and a visual replay that has a job to do. Multimodal output also needs a contract that is strict enough to reject a response rather than smooth over it.

I learned that autonomous agents work best with small scopes, tests, review gates, and an explicit finish line. They still need human product judgment. I had to inspect the actual experience and decide what was good enough. Meaningful model use starts with a product problem, not a model looking for one.

What's next for Pass Forward

First, I will harden clip compatibility, processing speed, overlay quality, and the depth of the one supported correction. Then I will consider additional soccer techniques, including other passes, shots, free kicks, throw-ins, headers, dribbling, and skill moves. Much later, I may explore carefully bounded movement practice for additional sports such as powerlifting, golf, tennis, or baseball.

Built With

• codex
• css
• gpt5.6
• javascript
• mediapipe
• remotion
• typescript