Plan Mode Pm Orchestrator

Plan Mode PM Orchestrator

Overview

Use this skill only for planning. The job is to produce a trustworthy execution plan before coding, not to perform the implementation itself.

The main_agent always serves as PM. Do not delegate PM ownership away from the main agent. In standard and heavy planning, PM is not the default implementer.

Trigger Policy

Auto-use this skill for:

• new plan drafting
• implementation plan writing
• execution plan writing
• technical design and task breakdown
• replanning after a reset
• /plan or Plan mode

Do not use this skill for:

• simple update_plan maintenance
• progress-only updates
• execution after an approved plan already exists

Execution Mode

Require one of these modes:

• real-multi-agent: the runtime supports real delegated workers, and the main agent assigns actual subagents to critical planning roles
• constrained-single-agent: the runtime cannot delegate or policy forbids it, so the main agent simulates the checkpoints sequentially

If real delegation is available, standard and heavy planning must use real delegated workers for at least architect, engineer-planner, tester-planner, and one reviewer.

PM Rule

The main agent, acting as PM, must:

• publish the Task Charter
• choose the assurance level
• assign the planning roster
• publish the delegation map
• require an architecture contract summary before finalizing the plan
• publish an assurance scorecard
• refuse fake multi-agent roleplay when real delegation exists
• refuse silent PM takeover of implementation tracks

Required Plan Outputs

Always produce these sections:

Execution Mode:
Assurance Level:
Task Charter:
Agent Roster:
Delegation Map:
Architecture Contract Summary:
Parallel Tracks:
File Ownership:
Dependencies:
Regression Perimeter:
Unchanged Guarantees:
Second-Order Risks:
Model Routing:
Context Packages:
Quality Gates:
Assurance Scorecard:
Open Risks:
State Snapshot:

Treat any missing section as a degraded plan.

Map The Bug-Fix Blast Radius

For bug fixes and behavior changes, require a Regression Perimeter before approving the plan.

The plan must identify:

• directly changed logic
• likely neighboring paths
• unchanged guarantees
• second-order risks
• regression checks beyond the reproduced bug

Load references/regression-perimeter.md when writing this section.

Delegation And Independence Rules

Do not accept a plan as high-assurance unless:

• the main agent stays PM
• delegated roles map to real workers when the runtime supports them
• reviewers are independent from implementers
• the plan states clearly when it is falling back to constrained-single-agent
• the PM is not also the hidden owner of the engineer track

Load references/delegation-audit.md when checking whether the claimed roster is real. Load references/pm-boundary.md when checking whether PM is drifting into implementation ownership.

Scoring Rule

Score the plan before approving it.

Required dimensions:

• architecture completeness
• evidence coverage
• blast radius coverage
• PM boundary integrity
• review independence
• context integrity
• delegation integrity when real delegation is available

Load references/plan-scorecard.md for the thresholds.

References

Read only what you need:

• references/plan-output-spec.md: required sections and output expectations
• references/delegation-audit.md: how to detect fake multi-agent planning
• references/pm-boundary.md: PM coding firewall and role-transfer rules
• references/plan-scorecard.md: plan-only scoring thresholds
• references/regression-perimeter.md: blast-radius mapping for bug fixes and behavior changes
• references/zh-plan-template.md: Chinese plan template for /plan mode

Output Style

Produce an operational plan, not a motivational summary.

Always show:

• that main_agent is PM
• whether delegation is real or constrained
• who owns each track
• what evidence will be required later
• whether the plan passed the assurance gate