# Project Planning Task Ordering

> Project milestone task ordering and implementation patterns. Use when structuring task dependencies, ordering milestone work, or planning implementation sequences.

- Skill: `krmorehead/project-planning-task-ordering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add krmorehead/project-planning-task-ordering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/krmorehead/project-planning-task-ordering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: krmorehead (https://skillmd.com/u/krmorehead)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/krmorehead/project-planning-task-ordering

---


# Task Ordering & Implementation Rules

## Configure Milestone Ordering

1. Every milestone's task list MUST follow dependency order. Walk through each task and ask: "What must already exist for this to succeed?"

2. Canonical ordering for a configure milestone:
   1. Fix system baseline state (broken packages, missing modules)
   2. Install packages
   3. Generate keys/credentials (requires package tools like `wg genkey`)
   4. Template configuration files (requires generated keys)
   5. Start/enable services (requires config files)
   6. Configure runtime state (firewall rules, sysctl, NAT — requires services)
   7. Persist runtime state (save iptables rules, write generated env file)

## Provisioning Milestone Ordering

3. For a provisioning milestone:
   1. Load host-side kernel modules (LXC shares host kernel)
   2. Upload images/templates
   3. Create VM/container
   4. Configure auto-start
   5. Start VM/container
   6. Clean template baseline (fix broken packages in LXC)
   7. Register in dynamic inventory

## Dependency Constraint Rules

4. NEVER put key generation before package installation. NEVER put service start before configuration. NEVER install packages before fixing broken system state.

## Implementation Pattern Specification

5. Every feature milestone MUST include an **implementation pattern** note specifying:
   - Which task file to create
   - Which plays to add to `site.yml`
   - Which tags to use
   - Which molecule scenario to create

6. Never leave "how it integrates" as an open question. Implementation ambiguity causes inconsistent implementations.

## Architectural Decision Documentation

7. The project plan MUST reference the architectural decisions that were made and WHY, using the tree diagram format from `docs/architecture/overview.md`.

## Plan Review Execution

8. Before execution, ALWAYS run the plan through the **Plan Review Checklist** against all referenced skills. This catches critical issues that would break implementation.

9. Previous bug: the OpenWrt router plan had two critical issues (SSH auth transition, dynamic group persistence) that would have broken implementation — both caught only by cross-referencing skills during review.