AI Skill Report Card
Navigating Spherical Path Puzzles
Quick Start14 / 15
Given a spec like:
start: point(lat: 0°, lon: 0°), heading: north
goal: reach(point(lat: 60°, lon: 0°)) within(tol: 3°)
Since start and goal share the same meridian (lon: 0°) and heading is already north, the direct solution is a single forward move along the meridian:
forward 60 // 60° of arc along the meridian from lat 0 to lat 60
Run the path against the verifier. If every clause is satisfied ("admissible"), done. If it reports a violation (position off, heading wrong, turning ghost artifacts), adjust and rerun.
Recommendation▾
Add a concrete example showing a failed verification and the correction cycle (input path -> verifier error -> fixed path) to demonstrate the debugging loop, not just success cases.
Workflow13 / 15
Progress:
- Parse the spec: extract start point (lat/lon), start heading, all goal clauses (position, tolerance, heading requirements if any), and any intermediate waypoint constraints.
- Compute the great-circle relationship between start and goal (same meridian? same parallel? oblique?).
- Draft a minimal path using
forward <deg>andturn <deg>commands. - Mentally simulate heading changes: turning is instantaneous rotation in place (+left/−right), forward moves along the current great-circle heading by the given arc-degrees.
- Run the path through the verifier.
- Read every clause result — not just position. Check heading-at-goal, tolerance, "no ghost" / no-violation flags (e.g., "ghost compass position" meaning heading drifted without an explicit turn).
- If violated, isolate which clause failed and correct only that (e.g., add a turn, adjust forward distance, add a comment to document intent).
- Re-run until admissible.
Recommendation▾
The oblique example (Example 3) is hand-wavy ('approximate', 'nudge') — provide the actual haversine/spherical-trig formula or pseudocode for computing initial bearing and arc distance precisely, since this is the hardest case.
Core Mechanics
- Position:
point(lat: X°, lon: Y°). Lat 0° is the equator; positive lat is north. - Heading: cardinal or degree-based; "north" means following the local meridian toward increasing lat.
- forward <deg>: moves along the current great-circle heading by that many degrees of arc (arc-degrees = distance, not time).
- turn <deg>: rotates heading in place;
+is left (counterclockwise),−is right (clockwise). Zero-length turns or zero-degree forwards are no-ops but may still be flagged if the spec disallows redundant commands ("turning 0°, length 0°" ghost warning). - Comments:
// text— free, don't affect verification, use them to document reasoning for later review. - Tolerance:
within(tol: N°)— goal is satisfied if final position is within N° arc-distance of the goal point, not exact match. - Admissible path: satisfies every clause simultaneously — position, heading (if specified), tolerance, and no spurious/ghost segments.
Examples15 / 20
Example 1: Input:
start: point(lat: 0°, lon: 0°), heading: north
goal: reach(point(lat: 60°, lon: 0°)) within(tol: 3°)
Output:
forward 60 // same meridian, straight shot north
Example 2: Input:
start: point(lat: 0°, lon: 0°), heading: north
goal: reach(point(lat: 0°, lon: 90°)) within(tol: 3°)
Output:
turn -90 // face east
forward 90 // travel along equator (equator is itself a great circle)
Example 3 (oblique goal): Input:
start: point(lat: 0°, lon: 0°), heading: north
goal: reach(point(lat: 45°, lon: 45°)) within(tol: 3°)
Output:
turn -45 // rough initial bearing toward NE
forward 55 // approximate great-circle distance
// verify, then nudge turn/forward values based on reported miss distance
Note: for oblique goals, exact initial bearing and arc-length require spherical trigonometry (haversine / spherical law of cosines) — compute precisely rather than guessing when precision matters.
Recommendation▾
Clarify what the 'verifier' actually is (a tool/command Claude should invoke, or a mental simulation) — this is ambiguous and affects how the workflow should be executed in practice.
Best Practices
- Always re-check heading after any sequence of turns before issuing
forward— cumulative turns compound. - Prefer the fewest commands that satisfy the spec; extra turns/forwards risk introducing "ghost" violations (uncommanded net rotation or drift flagged by the verifier).
- Use comments liberally to record why a value was chosen — makes debugging failed verifications far faster.
- When goal and start share a meridian or the equator, the great-circle path is simply "forward" along it — no trig needed.
- For oblique goals, compute initial bearing and distance analytically (spherical trig) rather than iterating blindly; then verify and fine-tune only for tolerance.
- Consult "the reference book" (the spec's glossary) whenever a term's exact semantics (e.g., what counts as a "clause," how heading-at-goal is graded) is ambiguous — don't assume.
Common Pitfalls
- Don't confuse
turnwithforward— turning changes heading only, it does not move position. - Don't leave zero-degree turns or zero-length forwards in the final path; verifiers often flag these as ghost/no-op violations even if harmless.
- Don't assume Euclidean/flat-map shortest paths — on a sphere, straight-looking lat/lon paths are not geodesics except along meridians and the equator.
- Don't ignore heading-at-goal requirements if the spec includes them — reaching the right position with the wrong final heading is still inadmissible.
- Don't treat tolerance as license for sloppiness — aim for the exact goal and let tolerance absorb only genuine approximation error.