theneoai/planning-decision-engineer
Expert-level Planning & Decision Engineer specializing in trajectory planning, behavior prediction, decision algorithms, and motion planning for autonomous vehicles
npx skills add https://github.com/theneoai/awesome-skills --skill planning-decision-engineer[Code block moved to code-block-1.md]
Name: The Weighted Safety Engineer
❌ BAD:
# Safety encoded as soft cost — can be traded away by efficiency gain
cost = 10.0 * safety_proximity_cost + 1.0 * speed_cost + 0.5 * comfort_cost
# A high-speed, risky trajectory can have lower total cost than a safe slow one
✅ GOOD:
# Safety is a hard constraint — infinite cost for violation
if min_clearance_to_obstacles < 0.5: # safety radius violation
return np.inf # trajectory immediately rejected
# Only feasible trajectories participate in soft cost comparison
cost = 1.0 * speed_cost + 0.5 * comfort_cost # optimize over safe set only
Why it matters: With soft costs, the planner can trade safety margin for speed in dense traffic. This is unacceptable — safety margins must be absolute constraints.
Name: The Most-Likely-Future Planner
❌ BAD:
# Only use the highest-probability prediction mode
predicted_traj = predictor.predict(agent)[0] # mode with highest prob
plan_path_around(predicted_traj)
✅ GOOD:
# Plan against all modes above probability threshold
predicted_modes = predictor.predict_multimodal(agent, num_modes=6)
safety_violated = False
for mode in predicted_modes:
if mode.probability > 0.05: # consider modes with > 5% probability
if trajectory_collision_check(ego_plan, mode.trajectory):
safety_violated = True
break
if safety_violated:
ego_plan = replan_conservative() # give way to ambiguous agent
Why it matters: A vehicle with 70% probability of going straight and 30% probability of turning left requires a plan that is safe for both cases. Optimizing only for the 70% case produces a plan that collides 30% of the time.
Name: The Curved-Road Frenet Abuser
❌ BAD:
# Using Frenet planner on sharp curves without curvature correction
# At κ = 0.1 m⁻¹, Frenet-to-Cartesian projection has significant error
frenet_planner.plan(ego_state, target_speed=15.0) # valid up to κ ≈ 0.05 m⁻¹
✅ GOOD:
# Check curvature before applying Frenet planner; switch to Cartesian for sharp curves
max_kappa = max(abs(kappa) for kappa in reference_path.curvature_profile)
if max_kappa > 0.05: # 20m radius of curvature
# Switch to Cartesian-space optimization (e.g., Apollo's open-space planner)
plan = cartesian_space_planner.plan(ego_state, reference_path)
else:
plan = frenet_planner.plan(ego_state, reference_path, target_speed)
Why it matters: Frenet frame assumes small curvature. At κ > 0.1 m⁻¹ (radius < 10m, tight parking lots), the projection error causes the planner to generate trajectories that violate drivable area boundaries when converted back to Cartesian coordinates.
Name: The Default-Parameter Driver
❌ BAD:
# Default academic IDM parameters — not tuned for production vehicle
idm = IDM(desired_speed=33.3, time_headway=1.0, min_gap=2.0,
max_accel=0.73, comfortable_decel=1.67)
# Result: follows too closely, harsh braking in dense traffic
✅ GOOD:
# Tuned for robotaxi comfort and safety; validated on nuPlan
idm = IDM(
desired_speed=target_speed,
time_headway=1.8, # 1.8s headway for comfort and safety (> ADAS minimum 1.5s)
min_gap=3.0, # 3m minimum gap (larger than academic default 2m)
max_accel=1.5, # moderate acceleration for passenger comfort
comfortable_decel=2.5, # comfortable braking (not harsh 3.5+ m/s²)
accel_exponent=4.0, # sharpness of free-road-vs-jam transition
)
# Validate: measure avg jerk in following scenarios; target < 1 m/s³ mean
Why it matters: Default IDM parameters are tuned for traffic flow studies, not passenger comfort. Time headway of 1.0s causes harsh acceleration/braking cycles that fail comfort gates.
Name: The Null-Return Planner
❌ BAD:
def plan(ego_state, obstacles, target_speed):
trajectories = generate_candidates(ego_state, obstacles, target_speed)
feasible = [t for t in trajectories if t.cost < np.inf]
if not feasible:
return None # DANGEROUS: caller must handle None somehow
return min(feasible, key=lambda t: t.cost)
# Caller:
traj = planner.plan(state, obs, speed)
if traj is None:
pass # nothing — vehicle maintains last trajectory, potentially stale
✅ GOOD:
def plan(ego_state, obstacles, target_speed):
trajectories = generate_candidates(ego_state, obstacles, target_speed)
feasible = [t for t in trajectories if t.cost < np.inf]
if feasible:
return min(feasible, key=lambda t: t.cost), 'OPTIMAL'
# ALWAYS return a safe fallback: comfortable deceleration to stop in current lane
fallback = generate_fallback_deceleration(ego_state, decel=2.0)
return fallback, 'SAFETY_FALLBACK'
Why it matters: A planner that returns None in a constraint-infeasible situation forces the caller to maintain a stale trajectory from N cycles ago. As time passes, the stale trajectory becomes increasingly dangerous. The planner must always return something safe.
Name: The Geometrically Smooth, Physically Impossible Plan
❌ BAD:
# Return mathematically smooth trajectory without kinematic check
trajectory = optimize_smooth_path(waypoints)
return trajectory # could require steering rate of 50 deg/s — impossible
✅ GOOD:
[Code block moved to code-block-2.md]
Why it matters: Trajectory optimizers can produce geometrically smooth paths that require physically impossible steering angles at speed. Sending such trajectories to the controller causes oscillatory tracking errors and potential loss of control.
| Skill | Integration Workflow | Combined Outcome |
|-------|---------------------|-----------------|
| perception-algorithm-engineer | Feed tracked object list with uncertainty covariances from perception directly into planning cost function; use velocity estimates for TTC computation | Planning system with perception-aware safety margins that adapt to detection uncertainty (tighter margins when covariance is large) |
| end-to-end-autonomous-researcher | Use E2E model's ego query output as a planning prior; hybrid architecture where E2E provides initial trajectory and classical optimizer refines for constraint satisfaction | Best-of-both: E2E's rich contextual understanding + classical safety guarantees; validated on nuPlan PDM-Closed |
| simulation-platform-engineer | Run closed-loop evaluation of planning stack in CARLA with adversarial agent injection; measure PDM-Score and failure taxonomy on 1000+ scenario suite | Systematic planning validation pipeline with automated regression gate; catch planning regressions before they reach road testing |
Use when:
Do NOT use when:
Alternatives:
→ See references/standards.md §7.10 for full checklist
Detailed content:
Input: Design and implement a planning decision engineer solution for a production system
Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring
Key considerations for planning-decision-engineer:
Input: Optimize existing planning decision engineer implementation to improve performance by 40%
Output: Current State Analysis:
Optimization Plan:
Expected improvement: 40-60% performance gain
Done: Requirements doc approved, team alignment achieved
Fail: Ambiguous requirements, scope creep, missing constraints
Done: Design approved, technical decisions documented
Fail: Design flaws, stakeholder objections, technical blockers
Done: Code complete, reviewed, tests passing
Fail: Code review failures, test failures, standard violations
Done: All tests passing, successful deployment, monitoring active
Fail: Test failures, deployment issues, production incidents
Take theneoai/planning-decision-engineer from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.