Skip to content

Run 1: Avalanche Observation Network

The Challenge

Build the core of an Avalanche Observation Network — a platform where backcountry skiers submit field observations and avalanche forecasters review them. This mirrors how avalanche centers like the Utah Avalanche Center actually operate: community observations flow in, forecasters synthesize them into danger ratings that keep people safe.

Your platform needs to serve both sides of the pipeline from day one. A submission experience that makes it easy for a skier to report what they see. A feed experience that lets a forecaster move through observations efficiently. Both grounded in the real observation types and field schemas used by avalanche centers.

Use story-driven prompting — the delegation contracts from Lift 1. Write a user story with acceptance criteria for each feature, delegate it, and verify the result before moving on.

Who You're Building For

The backcountry skier (submitter). They just finished a tour in the Wasatch backcountry. They saw shooting cracks on a northwest-facing slope above treeline. They want to report it — quickly, from their phone or laptop — so the information reaches the people who need it. They're not avalanche professionals. The form needs to be clear about what to provide without requiring expertise they don't have.

The avalanche forecaster (consumer). It's early morning, still dark out. They're reviewing last night's observation submissions before writing the morning's danger rating for the Salt Lake zone. They need to scan dozens of observations efficiently, filter by type and zone, and drill into the ones that matter. Time is short. The interface needs to surface the most relevant information without making them dig.

What You're Starting With

From Lift 1, you've got:

  • The Three Pillars (Scope, Intent, Structure) — your framework for every prompt
  • User stories with acceptance criteria — your delegation contract format. You wrote your first one during the lift — use it or refine it
  • The Explore → Plan → Implement → Verify workflow — your process for building iteratively
  • A project context file — you created this during Lift 1's bootstrap activity. Your AI coding assistant already knows your project

Your repository also has sample observation data and an observation type taxonomy with field schemas. Ask your AI coding assistant to explore them — they'll inform your data model and give you seed data for the feed.

Baseline Capabilities

  • Observation submission form — a backcountry skier can submit a field observation with observation type (avalanche, snowpack, weather, red flag), location, date, and a description
  • Observation feed — an avalanche forecaster can browse submitted observations in a list or feed view, with the most recent observations first
  • Filtering — observations can be filtered by type so a forecaster can focus on what's relevant (e.g., "show me only avalanche sightings")
  • Detail view — selecting an observation shows its full information
  • Sample data is loaded — the feed is populated with the pre-seeded observations so it works immediately, not just after someone submits

Stretch Goals

  • Type-specific fields — when a skier selects "avalanche" as the observation type, the form shows additional fields like aspect, elevation band, and avalanche size; "weather" shows temperature and wind; the observation type taxonomy in your data defines what each type needs
  • Zone-based filtering — forecasters can filter by UAC forecast zone to focus on their area
  • Observation counts — show a summary of how many observations exist by type, giving forecasters a quick pulse on what's been reported
  • Red flag highlighting — surface red flag observations (shooting cracks, collapsing, recent avalanche activity) prominently, since these are the highest-signal reports for forecasters
  • Professional styling — make the platform feel like a tool a real avalanche center would use, not a prototype

Tips

  • Start with one persona, then build the other. Don't try to build the submission form and the feed in the same story. Pick one — the feed with sample data is often a good starting point because you'll see results immediately — verify it works, then build the other.
  • Use the story you wrote in Lift 1. You already have a delegation contract ready to go. Hand it to your AI coding assistant. Verify the result against your acceptance criteria. Then write the next story.
  • Let AI explore the data for you. Before you design the submission form, ask your AI coding assistant: "What observation types and fields does our data schema define? Summarize the structure." Let the data model inform your design instead of inventing one from scratch.
  • Your first feature sets the pattern. You're starting from scratch, and AI will make structural choices with your first feature that every future feature builds on. After it's working, ask AI: "Walk me through how you organized this — the file structure, the components, how data flows. Would this structure hold up well as we add more features?" If AI suggests a better organization, now is the cheapest time to reshape it. Code that works can always be reorganized — and it's easier to do it now than after five features depend on it.
  • Save and sync after each working feature. Build the habit now — every time something works, save your progress and sync it. You'll thank yourself later when you want to undo a change that breaks something. Remember: your AI assistant starts fresh every conversation. Your saved, synced code is the only thing that persists.
  • If AI breaks something, undo and retry. Your AI assistant will often catch errors and try to fix them on its own. But if the app is broken or the output is completely wrong, you can always say: "Undo everything you just changed." Then start a fresh conversation with /clear and re-delegate with a more specific story and tighter acceptance criteria. A broken result is feedback on your delegation, not a verdict on the approach.
  • Start fresh between features. After completing and verifying a feature, type /clear to reset your conversation. Your project context file loads automatically, so every fresh conversation starts productive. This prevents quality from fading as the conversation grows — remember the oxygen tank from Lift 1.