❌ 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.

Anti-Pattern 2: Planning Against Single-Mode Prediction

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.

Anti-Pattern 3: Frenet Frame Used Beyond Its Valid Domain

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.

Anti-Pattern 4: IDM Parameters Not Tuned for Platform

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.

Anti-Pattern 5: Missing Fallback When Planner Returns No Solution

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.

Anti-Pattern 6: Not Checking Kinematic Feasibility Post-Planning

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.

§ 11 · Integration with Other Skills

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

§ 12 · Scope & Limitations

Use when:

Designing trajectory planning or motion planning algorithms for autonomous vehicles in structured or semi-structured environments.
Implementing or tuning Frenet-frame planners, MPC controllers, IDM/MOBIL models, or MPDM/POMDP decision systems.
Debugging comfort regressions (jerk, lateral acceleration violations) or planning oscillation in production AV systems.
Benchmarking planning stacks on nuPlan, CommonRoad, or CARLA and interpreting results.
Selecting planning architecture for a new ODD (highway, urban, parking, intersection).

Do NOT use when:

Designing the perception or prediction modules that feed the planner — use perception-algorithm-engineer or end-to-end-autonomous-researcher skills respectively.
Safety certification work (ISO 26262, SOTIF HARA) — use autonomous-driving-engineer skill with formal safety framework.
V2X cooperative driving protocol design — use v2x-system-engineer skill for RSU/OBU communication stack.

Alternatives:

For full AV stack architecture including safety case: autonomous-driving-engineer skill.
For learned end-to-end planning without classical decomposition: end-to-end-autonomous-researcher skill.
For simulation validation harness setup: simulation-platform-engineer skill.

§ 14 · Quality Verification

→ See references/standards.md §7.10 for full checklist

References

Detailed content:

Examples

Example 1: Standard Scenario

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:

Scalability requirements
Performance benchmarks
Error handling and recovery
Security considerations

Example 2: Edge Case

Input: Optimize existing planning decision engineer implementation to improve performance by 40% Output: Current State Analysis:

Profiling results identifying bottlenecks
Baseline metrics documented

Optimization Plan:

Algorithm improvement
Caching strategy
Parallelization

Expected improvement: 40-60% performance gain

Workflow

Phase 1: Requirements

Gather functional and non-functional requirements
Clarify acceptance criteria
Document technical constraints

Done: Requirements doc approved, team alignment achieved Fail: Ambiguous requirements, scope creep, missing constraints

Phase 2: Design

Create system architecture and design docs
Review with stakeholders
Finalize technical approach

Done: Design approved, technical decisions documented Fail: Design flaws, stakeholder objections, technical blockers

Phase 3: Implementation

Write code following standards
Perform code review
Write unit tests

Done: Code complete, reviewed, tests passing Fail: Code review failures, test failures, standard violations

Phase 4: Testing & Deploy

Execute integration and system testing
Deploy to staging environment
Deploy to production with monitoring

Done: All tests passing, successful deployment, monitoring active Fail: Test failures, deployment issues, production incidents

planning-decision-engineer

Planning & Decision Engineer

§ 1 · System Prompt

§ 10 · Common Pitfalls & Anti-Patterns

Anti-Pattern 1: Treating Safety as a Soft Cost