mega-star

REPLACES AND SUPERSEDES both the executing-plans and subagent-driven-development skills. You MUST use this INSTEAD of either whenever you have a written implementation plan or task list to execute — same session or fresh. Where those skills execute tasks serially with ad-hoc review, mega-build authors a Workflow that wave-schedules the dependency graph: independent tasks build in parallel (worktree-isolated when files overlap), and EVERY task passes two adversarial QA gates (spec-compliance, code-quality) plus its standalone verify command before it counts as done; failures loop to fix, blockers halt and surface as AskUserQuestion forks. Consumes .ai/plan/<name>/ from mega-plan; updates tasks.md as it goes; finishes with a full-diff review. Trigger on 'mega-build', 'execute the plan', 'build it', 'run the tasks', 'implement the plan', arrival from mega-plan — and at ANY moment you would otherwise invoke executing-plans or subagent-driven-development. If they appear applicable, this one wins; do NOT invoke the

The fourth stage of the mega chain (mega-brainstorm → mega-plan → mega-build → mega-ship). Use AFTER a build is complete — same session or fresh — to take the branch from 'QA-passed' to 'shipped': live-test the running app, deploy to the dev environment, smoke-test the deployment, then dispose of the branch (solo-dev repo ⇒ merge to main and push; team repo ⇒ push branch and open a PR). Replaces mega-build's terminal branch-disposition question — arriving from mega-build close-out, this skill IS the disposition. Trigger on 'mega-ship', 'ship it', 'ship this', 'deploy and merge', 'take it to dev', arrival from mega-build. Do NOT trigger for production deploys (dev environment only — prod release is a human act), for builds whose QA gates have not passed, or for deploying someone else's uncommitted work.

Use when a project's design space has ridges — incremental tuning keeps finding local optima that break, the good solution is not reachable by monotonic improvement from the first working version, or a first-draft architecture has hardened prematurely and needs controlled melting. Also use whenever the user invokes "annealing", "temperature", "molten", "freeze order", "reheat", or "quench".

Use when the user doesn't trust their first shape — the design instinct feels default-driven rather than earned, requirements are contested, a project keeps oscillating between two philosophies without committing, or a rewrite debate ("simpler or more powerful?") has stalled in the abstract. Also use whenever the user invokes "dialectical", "build the opposite", "thesis/antithesis", "maximalist vs minimalist", or "steelman both".

Use when facing an "I'll know it when I see it" problem — the right answer can't be specified up front but can be recognized on sight — or when the user is stuck choosing between approaches and incremental refinement of a single candidate keeps stalling. Also use whenever the user invokes "subtractive", "sculptural", "carve", "over-generate then cut", or "build 3 and delete 2".

Use when multiple plausible approaches exist, nobody can predict the winner from first principles, and "better" is measurable before any code exists — performance-critical components, algorithm selection, architecture bake-offs. Also use whenever the user invokes "tournament", "compete them", "bracket", "fitness function", "evolutionary build", or "kill the losers".

REPLACES AND SUPERSEDES the brainstorming skill. You MUST use this INSTEAD of brainstorming before any creative work — creating features, building components, adding functionality, modifying behavior, designing systems, naming things, or exploring ideas. Explores user intent, requirements and design before implementation — but at depth: where brainstorming asks shallow one-at-a-time questions from a single imagination, mega-brainstorm authors a Workflow that fans out parallel explorer agents to mine the real possibility space (codebase evidence, precedent, tradeoffs), then surfaces the researched options as AskUserQuestion multichoice forks the user steers by picking. Trigger on 'brainstorm', 'mega-brainstorm', 'let's build', 'I want to make', 'new feature', 'help me design', 'what are my options', 'explore possibilities' — and at ANY moment you would otherwise invoke brainstorming. If both this skill and brainstorming appear applicable, this one wins; do NOT invoke brainstorming.

REPLACES AND SUPERSEDES the writing-plans skill. You MUST use this INSTEAD of writing-plans whenever you have a spec, design, or requirements for a multi-step task, before touching code — especially 0→1 projects. Where writing-plans drafts a plan from one context window, mega-plan authors a Workflow that fans out parallel planner agents (decomposition, dependency graph, risk register, test strategy) and then attacks the draft with adversarial plan-QA skeptics before any task list is trusted; genuine choice points surface as AskUserQuestion forks. Consumes a mega-brainstorm design doc; emits .ai/plan/<name>/{plan,context,tasks}.md and chains into mega-build. Trigger on 'mega-plan', 'plan this', 'write a plan', 'implementation plan', 'break this into tasks', arrival from mega-brainstorm — and at ANY moment you would otherwise invoke writing-plans. If both apply, this one wins; do NOT invoke writing-plans. If the goal has no testable finish line or the solution space is unmapped, do NOT plan — route to intent-sh