ultra-planning

Ultra Planning

Use this skill as a rigid workflow gate before controlled dispatch. This skill must remove planning ambiguity rather than summarize it.

Hard Gate

Do not allow controlled dispatch until the plan includes:

• success criteria
• constraints
• non-goals
• owned paths
• acceptance checks
• dependency order
• risk level
• retry assumptions

If any of those are missing or still depend on chat interpretation, the plan is not complete.

When To Use

Planning is required when:

• the work spans multiple files or directories
• multiple phases or roles are involved
• OpenSpec change assets are being turned into execution packages
• review, QA, or risk gates need explicit targets
• parallel execution is being considered
• the implementer would otherwise need to make design or boundary decisions

Planning may be compressed only when:

• the task is truly tiny
• the write scope is narrow and obvious
• no risky command or external mutation is involved
• review and QA targets remain explicit

If you compress planning, record the reason in the orchestration log.

Planning Workflow

1. Read the intake, brainstormed design, or OpenSpec bridge artifacts.
2. Check whether success criteria, constraints, and scope are already stable.
3. If not stable, route back to ultra-brainstorming or the intake step.
4. Define the top-level TaskManifest.
5. Split the work into one or more WorkPackage items.
6. Mark dependencies, owned paths, parallel groups, and serial boundaries.
7. Attach acceptance checks, risk level, and retry assumptions.
8. Record assumptions, blockers, and re-plan triggers.
9. Run the planning self-review before declaring the plan complete.

Planning Standard

Produce one TaskManifest plus one or more WorkPackage items.

The plan is not complete until it defines:

• goal
• context
• success criteria
• constraints
• non-goals
• dependencies
• owned_paths
• expected outputs
• risk level
• acceptance checks
• retry budget or retry assumptions