# Megaplan

> Run the canonical Megaplan planning pipeline from its Arnold plugin home.

- Skill: `peteromallet/megaplan` (Agent Skill, multi-file: 790 files)
- Install (CLI): `npx skillmds@latest add peteromallet/megaplan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/peteromallet/megaplan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: peteromallet (https://skillmd.com/u/peteromallet)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/peteromallet/megaplan

---


> **Authority status (M11):** This skill document is retained as zero-authority
> history. All repair, audit, and deployment authority has been migrated to
> canonical delegation. Content must not be used to materialize commands,
> grant authority, or drive automated repair actions.

# Megaplan

Use this pipeline for high-rigor planning workflows that need prep, plan,
critique, gate, revise, finalize, execute, review, and tiebreaker stages.

For epic-sized, migration, public-contract, or otherwise drift-sensitive work,
capture durable end-state intent with a North Star anchor: pass
`--north-star PATH` to `megaplan init` for a standalone plan, or declare
`anchors.north_star` in `chain.yaml` for epics.

---

## North Star Actions (v1)

### Where questions come from

North Star questions are **explicitly authored** — they are not extracted from
code, diffs, or execution traces. In v1 the pipeline reads them from a
`NORTHSTAR.md` file in the plan directory (standalone plans) and/or from
sprint-brief anchors declared in `chain.yaml` (epic chains).  There is no
semantic-parity extraction step: if a question is not written in one of those
sources it does not exist from the pipeline's point of view.

### How actions flow through the pipeline

1. **Gate (structured carry).**  When a gate or reviewer evaluator raises a
   concern tied to a North Star question, it emits a `north_star_actions[]`
   entry — an action with a concrete `action_type` (`change_plan`,
   `add_gate`, `add_scenario`, `add_checker`, `dead_delete`, or
   `add_human_halt`), a `severity` (blocking/advisory), supporting evidence,
   and optional plan references.  Actions in the *dangerous* categories
   (`route_authority`, `baselines`, `row_carrier_exemptions`,
   `target_narrowing`, `generated_conformance_authority`,
   `live_plan_topology_resume_risk`) are **blocking by schema rule** regardless
   of what the evaluator labels them.  All actions are normalized at gate time
   and carried forward through `gate_carry.json` (with `gate.json` as a
   fallback).

2. **Revise (change the plan or halt).**  The revise worker prompt receives
   the carried `north_star_actions[]` with per-action-type instructions:
   - `change_plan` — make a concrete, traceable plan change.
   - `add_gate` — add an explicit gate requirement.
   - `add_scenario` — add a concrete scenario / test case.
   - `add_checker` — add an automated checker.
   - `dead_delete` — remove dead plan steps.
   - `add_human_halt` — halt; the action cannot be mapped to a plan change.

   Before the revise worker runs, a pre-worker guard halts through the
   existing `CliError`/step-failure path when any carried blocking action is
   `add_human_halt`, has an unrecognized `action_type`, or is a
   dangerous-category blocker with no concrete target (`plan_refs` or
   `required_change`).  **Revise must change the plan or halt** — it cannot
   silently ignore a blocking action.

   After the revise worker completes, the pipeline validates that every
   carried blocking action has a corresponding `north_star_actions_addressed[]`
   entry with concrete `plan_refs` and the matching `action_type` marker.
   Prose-only resolutions, mismatched action types, and omitted actions are
   rejected (fail-closed).

3. **Finalize / Review → done (closeout blocking).**  Finalize refuses to
   produce executable tasks if any carried blocking North Star action is
   unresolved in the latest revise metadata.  The review→done transition
   runs a separate pre-check before `TransitionPolicy.evaluate_review_done()`;
   unresolved blocking actions deny the transition through the existing
   denial path.  Absent or malformed `north_star_actions_addressed[]` is
   treated as all-carried-blocking-unresolved (fail-closed).

### `north_star_critical` and robustness

Chain and milestone specs support an optional `north_star_critical: bool`
(default `false`).  When `true`, the milestone (or chain) declares that
North Star enforcement is mandatory for that work unit and cannot be
skipped.

`north_star_critical: true` is **incompatible** with `bare` and `light`
robustness.  The chain-spec validator rejects these combinations with a
`CliError` — it never silently upgrades the robustness level.  Acceptable
robustness levels are `full`, `thorough`, and `extreme`.  Milestone-level
robustness takes precedence over driver-level robustness when both are
present; `north_star_critical` is OR'd across the chain-level and
milestone-level settings.

### Missing packaged skill paths

Some North Star action types conceptually suggest packaged skills (e.g. a
`dead_delete` action could map to a dead-code-removal skill), but no such
skills ship with the pipeline today.  These are **packaging follow-up
items** — the pipeline enforces the structured action contract regardless,
and any future skill packaging would consume the existing
`north_star_actions[]` / `north_star_actions_addressed[]` metadata without a
contract change.