agentleFS
chendanielychendaniely/skills/creating-ultra-crew-guides/SKILL.md

creating-ultra-crew-guides

Skill1 starsChanged 29 days agoMITView on GitHub

Use when crewing, pacing, or captaining for a runner in an ultramarathon (50K–200mi) and building a crew guide, aid-station plan, driving/logistics doc, or race-day reference — including races with crew-accessible aid stations, cutoffs, drop bags, pacer rules, and no cell service.

The file

Files
SKILL.md

Creating Ultra Crew Guides

Overview

A crew guide is a field document read at 3 a.m., on no sleep, with no internet — not a research report. Optimize for flip to the aid station you're driving to and know exactly what to do.

Core principle: the crew chief is the team's information hub. Every section must answer: what do I set up, what do I tell the runner and pacer, and what's next?

When to Use

  • Building crew/pacer materials for any ultra with crew-accessible aid stations
  • Ingesting race sources (official site, race guide PDF/Doc, third-party profiles, podcasts, YouTube) into a usable plan
  • Race logistics: leapfrog driving, drop bags, pacer legs, cutoffs, offline navigation

Not for: the runner's own training/pacing plan (that's a different artifact — consume it, don't write it).

Deliverables

FilePurpose
During-race guideThe core. Master table + one ## section per crew-accessible aid station
Pre-race guideSchedule, drop bags, gear, route/comms, team briefing, fill-in-before-signal sheet
Post-race guideFinish, recovery, DNF contingency, debrief captured while fresh
Dash cardOne page for the car: stops, ETAs, cutoffs, drives, GPS, emergency numbers
Driving instructionsLeg-by-leg, in crew order (≠ course order), with gas + road warnings
Context/working notesCanonical data, decisions, conventions, open questions — so a new session resumes cold

Per-Station Section Template

## <Station> — Mile X (Y km)
📊 Leg ahead — stations up to the NEXT CREW stop (mi/km + cutoff + ETA)
📍 Quick facts — ETA · cutoff · crew/pacer/drop-bag · drive · parking
🅿️ Setup — turn-by-turn, where to park, what to stage before arrival
🏃 When runner arrives — start break timer · log cal/fluid/pee · give/tell/check
📣 Direct the team — brief the pacer, assign jobs, say the numbers out loud
🧭 Course ahead — terrain, water, dark/cold/heat, what to warn them about

Data Rules

RuleWhy
Cutoffs: official chart ONLYThird-party sites and pace planners drift. Never mix sources.
ETAs: ask for the runner's pace plan firstUse its arrival column (accounts for elevation). Label as goal, not fact.
No pace plan? Derive ETAs, label every one an estimateIf the runner only has a goal finish time, derive ETAs (e.g. from prior-year splits of similar finishers) and put "get the runner's pace plan" on the pre-race checklist. Derived ETAs are crew estimates, not a pace plan — the crew still doesn't write the runner's plan.
Convert units with a tool callNever hand-convert. Report mi and km.
Report 3 distances per stationto next AS, to next crew AS, and total. The middle one drives decisions.
Flag every conflict inlineShow both values, say which to plan against, add to a verify list.
Tag by source (🎧 podcast, etc.)The user must see where a claim came from.

Extraction Techniques

  • Google Doc race guide: curl -sL ".../export?format=txt" (WebFetch dies on the redirect).
  • Charts that are images (aid-station tables often are): export the same Doc as format=pdf, then read those pages — this is usually the only way to get authoritative cutoffs.
  • Podcast/video: ffmpeg -vn -ac 1 -ar 16000 → whisper (seed the initial prompt with aid-station and place names so proper nouns transcribe correctly). Produce transcript + distilled notes as separate files.
  • Google Maps links: /maps/dir/ URLs contain lat/lon — extract them. Short maps.app.goo.gl links usually don't resolve to coordinates.

Offline-First

Assume no cell service. Therefore:

  • Everything must be printable; nothing critical lives only in an app.
  • Include GPS coordinates (aid stations often have no street address).
  • Include a fill-in sheet for what only the team knows: bib #, allergies/meds, emergency contact, nutrition targets, drop-bag contents, teammate phones/inReach, RD emergency number.
  • Warn where routing apps suggest non-roads; give the correct route explicitly.
  • Note gas towns and dead stretches; compute sunrise/sunset for headlamp timing.

Common Mistakes

MistakeFix
Assuming which stations the crew will staffAsk. "Crew-allowed" ≠ "crew plans to be there." Rebuild distances when it changes.
Treating a source's crew as the user's crewPodcast hosts have their own base, pacers, and stops. Mark as reference-only.
Course order = driving orderCrews leapfrog and backtrack; document the driving sequence separately.
Burying decisions in proseLead with the 1–2 forks that shape the day (which station, tight turnarounds).
Leaving cutoffs unverifiedChart may update race week — say so, and put verification on the pre-race checklist.
Skipping the debriefCapture results/corrections immediately after the finish; that's next year's guide.

Plans Change — Rebuild Cleanly

Crew stops, pacer legs, and routes will change mid-build. When they do: recompute every derived number (to-next-crew-AS distances especially), then grep the whole doc set for the old assumption — stale mentions in a briefing script or drop-bag table are the failure mode. Verify with a search, not memory.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.