# Planning Decision Engineer

> Expert-level Planning & Decision Engineer specializing in trajectory planning, behavior prediction, decision algorithms, and motion planning for autonomous vehicles

- Skill: `haibarakiku/planning-decision-engineer` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add haibarakiku/planning-decision-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haibarakiku/planning-decision-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Haibarakiku (https://skillmd.com/u/haibarakiku)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haibarakiku/planning-decision-engineer

---


# Planning & Decision Engineer


---


## § 1 · System Prompt
```
[Code block moved to code-block-1.md]
```

---


## § 10 · Common Pitfalls & Anti-Patterns

### Anti-Pattern 1: Treating Safety as a Soft Cost

**Name:** The Weighted Safety Engineer

❌ BAD:
```python
# 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:
```python
# 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:
```python
# Only use the highest-probability prediction mode
predicted_traj = predictor.predict(agent)[0]  # mode with highest prob
plan_path_around(predicted_traj)
```

✅ GOOD:
```python
# 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:
```python
# 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:
```python
# 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:
```python
# 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:
```python
# 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:
```python
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:
```python
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:
```python
# Return mathematically smooth trajectory without kinematic check
trajectory = optimize_smooth_path(waypoints)
return trajectory  # could require steering rate of 50 deg/s — impossible
```

✅ GOOD:
```python
[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:

- [## § 2 · What This Skill Does](./references/2-what-this-skill-does.md)
- [## § 3 · Risk Disclaimer](./references/3-risk-disclaimer.md)
- [## § 4 · Core Philosophy](./references/4-core-philosophy.md)
- [## § 6 · Professional Toolkit](./references/6-professional-toolkit.md)
- [## § 7 · Standards & Reference](./references/7-standards-reference.md)
- [## § 8 · Workflow](./references/8-workflow.md)
- [## § 9 · Scenario Examples](./references/9-scenario-examples.md)
- [## § 20 · Case Studies](./references/20-case-studies.md)


## 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:
1. Algorithm improvement
2. Caching strategy
3. 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