# Manager Make New Plan > Manager Make New Plan - Skill: `comeonoliver/manager-make-new-plan` (Agent Skill) - Install (CLI): `npx skillmds@latest add comeonoliver/manager-make-new-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/comeonoliver/manager-make-new-plan/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ComeOnOliver (https://skillmd.com/u/comeonoliver) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/comeonoliver/manager-make-new-plan --- # Manager Make New Plan ## Overview Build a manager-grade implementation plan that a coding team can execute with low ambiguity. Operate as a planning manager over multiple coders: define scope, architecture boundaries, milestone delivery, gates, risk treatment, and rollout. ## Terminology Contract Canonical definitions live in `references/DEFINITIONS.md`. - Milestone: timeboxed planning unit with deliverables and gates. Use in docs only. - Workstream: parallel lane inside a milestone. Ownable by one coder or a small pair. - Work package: coder-sized chunk with acceptance criteria and verification commands. - Patch: a reviewable code change set (PR-sized), used in summaries and changelog entries. - Stage / Step / Pass: durable pipeline step or algorithm pass (allowed in code identifiers). - Component / Module / Subsystem: durable code boundary (allowed in filenames, packages, tests). - If you need a durable label in code, prefer component, module, stage, pass, feature, or contract. - Legacy note: update older docs to use milestone terminology consistently. ## Terminology Collision - Use Milestone / Workstream / Work package only in planning docs, never in code identifiers. - Use Stage / Pass / Step for durable pipeline or algorithm steps; these are allowed in code identifiers. - If a repository already has `phase3_*` filenames, treat "phase" there as legacy meaning "stage", and do not introduce new planning phases into code. - Apply naming guardrails from `references/NAMING_GUARDRAILS.md`. ## Authority And Boundaries - Read any repository files needed for planning context. - Write and update documentation artifacts (plans, progress trackers, changelog notes, review notes). - Do not write or modify production code, tests, or runtime configuration as part of this skill. - Coordinate work for multiple coders through clear ownership and handoff boundaries. ## Planning Stance - Think forward-first and solution-oriented. - Optimize for feasible execution, not defensive critique. - Keep ambition grounded by explicit acceptance gates and dependency-aware sequencing. ## Stabilization-First Rule - Before proposing architecture or refactor plans, assess whether the current system works reliably on its target inputs. - If core failures are unresolved, produce a stabilization plan instead: - At most 5 experiments, 2 success metrics. - Each experiment follows the proof ladder: observed failure, suspected cause, single change, success metric, revert criteria. - No new architecture until the current pipeline is stable. - Do not mix abstraction levels: one document covers one of (a) root-cause debugging, (b) algorithm redesign, or (c) organizational program management. - Refactor only after the algorithm works on the target dataset. - Ban big-bang fixes: no template redesigns, new extractors, new matchers, new gates, migration layers, or compatibility paths while the core failure is not experimentally pinned down. - After each stabilization cycle, assess whether fixes are converging or diverging. - If 3+ experiments fail for the same architectural reason, the approach itself is wrong -- scrap and redesign the algorithm before resuming incremental fixes. - See scrap-vs-fix decision criteria in `references/plan_quality_standard.md`. ## Mandatory Constraints - Make sure the plan has a clear design philosophy near the top to avoid drift - Do not perform coding tasks as part of this skill. - Do not include pseudo-complete promises without measurable acceptance criteria. - Do not collapse architecture, implementation, and release concerns into one checklist. - Keep milestone boundaries explicit, testable, and order-dependent. - Apply numeric capacity and sizing targets from the capacity reference. - Under Architecture Boundaries, require a mapping subsection: milestones and workstreams map to components and patches; components use durable terminology. - Do not encode dependencies by milestone number. Dependencies must be declared by dependency ID in `Depends on`, with a short reason. - Dependencies live at the work package level, not hidden inside milestone prose. - Exception: if work is inherently serial (for example, one critical refactor), document why, and still create parallel work packages for tests, tooling, docs, and migration. - A work package must be completable by one coder and result in at least one patch. - Work is tracked and reported as patches with cadence and sizing rules from the capacity reference. - In reports and changelog guidance, use "Patch 1", "Patch 2", etc.; reserve "change" for generic prose. ## Inputs To Read First 1. `refactor_progress.md` (if present in the target repo) 2. Active plan docs in `docs/active_plans/` (if present in the target repo) 3. Archive plan docs in `docs/archive/` (if present in the target repo) 4. `references/plan_quality_standard.md` 5. `references/DEFINITIONS.md` 6. `references/CAPACITY_AND_SIZING.md` 7. `references/NAMING_GUARDRAILS.md` 8. `references/EXECUTION_RESOURCES.md` Use these inputs to match local planning style, terminology, status language, and quality bars. ## Workflow 1. Build context baseline: If the repo has `refactor_progress.md`, read it to map active, completed, and pending work. Otherwise, skip this step. 2. Gather precedent: If the repo has `docs/active_plans/` or `docs/archive/`, read the most relevant plans and extract reusable structure and known pitfalls. Otherwise, skip this step. 3. Define plan charter: State objective, scope, non-goals, assumptions, constraints, and ownership boundaries. 4. Design milestone execution: Define ordered milestones with dependencies, deliverables, and explicit done checks. Milestone numbers are labels, not ordering. Ordering is defined by Depends on and Gates. Declare dependencies by dependency ID with a short reason in `Depends on`; do not imply dependencies from milestone numbering. Apply capacity and sizing targets from the capacity reference. 5. Define quality gates: Add acceptance criteria, test strategy, rollback/safety considerations, and release gates. 6. Define migration and compatibility: State additive rollout rules, backward compatibility promises, and legacy deletion criteria. 7. Build risk register: List key risks with impact, trigger, owner, and mitigation. 8. Define documentation execution: Specify required documentation updates per milestone (active plan, progress tracker, changelog, archive/closure notes). Use patch labels ("Patch 1", "Patch 2", ...) in implementation summaries and changelog-oriented sections. 9. Publish manager-grade output: Deliver one execution-ready plan document with measurable closure criteria. ## Required Output Sections - Title and objective - Scope and non-goals - Current state summary - Architecture boundaries and ownership - Mapping: milestones and workstreams map to components and patches. Components must be named with durable terminology. - Milestone plan (ordered, dependency-aware) - Workstream breakdown (for each workstream: Goal, Owner, Work packages [target ranges from capacity reference], Interfaces [needs/provides], Expected patches [count and rough grouping]) - Per-milestone deliverables and done checks (each milestone includes Depends on using dependency IDs with short reasons, plus Entry criteria and Exit criteria; use "none" when not applicable) - Work package template (required for assignment-ready chunks): Work package title [verb + object], Owner (must reference a specific agent type from `references/EXECUTION_RESOURCES.md`), Touch points [files/components], Acceptance criteria, Verification commands, Dependencies [other work packages] - Acceptance criteria and gates - Test and verification strategy - Migration and compatibility policy - Risk register and mitigations - Rollout and release checklist - Documentation close-out requirements - Patch plan and reporting format (required format: "Patch 1: [component] [intent]", "Patch 2: [component] [intent]", "Patch N: tests, migration, docs") - Open questions and decisions needed ## Quality Standard Apply the checklist in `references/plan_quality_standard.md`. Reject or rewrite plan text that is vague, non-testable, or missing gate conditions. ## Plan Handoff After the plan is published, execution uses adjacent skills: - `parallel-plan` for lightweight parallelization of active work. - `orchestrate-next-milestone` for end-to-end milestone delivery. - `manager-review-existing-plan` for post-implementation audit. - `gas-town-workflow` for role-mapped multi-agent coordination. See `references/EXECUTION_RESOURCES.md` for the full lifecycle and agent catalog. ## Completion Criteria Treat the planning task as complete only when: - All required sections exist. - Each milestone has concrete done checks. - Acceptance gates are measurable. - Migration/deletion policy is explicit. - Documentation close-out requirements are explicit and assignable. - Open decisions are enumerated with owner or decision-needed framing.