superplan-shape

Shape Work

Overview

Create the minimum durable artifact structure and execution trajectory that preserves visibility, verification quality, and bounded execution.

This skill is not a task generator. It is a trajectory shaper.

Its job is to shape work so the agent can move with bounded autonomy while staying aligned to the user's real expectations. It must not collapse graph-shaped work into a single task merely because one agent could carry it alone.

Phase Ownership Rule

This skill owns artifact creation and execution trajectory, not open-ended analysis.

• shape the minimum durable structure that makes the next execution move safe
• choose the proof path before broad implementation starts
• once the executable frontier is clear, stop shaping and hand to execution

Trigger

Use when:

• superplan-route has decided Superplan should engage
• the work needs durable structure created now
• the next step is to author plan, spec, or task artifacts proportional to the work
• the system must decide how much of the work is shapeable now versus discovery-driven
• the system must choose a verification loop before execution begins

Stay Out

Do not shape work when:

• superplan-route decided to stay out
• execution is already fully shaped
• the request was already answered directly
• creating artifacts would add no value

Inputs And Assumptions

Inputs:

• routing decision and chosen depth
• user request and raw narrative when available
• repo state
• current .superplan/ artifacts if any
• workspace context when available
• existing verification loops
• existing user-owned harnesses, scripts, custom skills, and workflows
• recent decision log entries when relevant
• known gotchas when relevant

Assumptions:

• depth determines how much structure to create
• not all work is fully deterministic at shaping time
• some work should be represented as investigation, prototype, or decision-gate work before deeper decomposition
• the right shaping output is often a trajectory, not a frozen perfect plan
• shaping should stop once the minimum useful artifact set and next executable frontier are clear
• multi-step work means work with 3 or more distinct steps, or work where sequencing across files or components matters; do not rationalize 3-step work as "only two steps" to skip graph shaping
• dense PRDs, JTBD dumps, implementation checklists, or multi-surface requests should default to multiple tracked tasks unless they truly collapse to one bounded executable unit
• if different parts of the work need different acceptance checks, they should usually not share one task contract
• when useful workspace or global skills already exist for planning, brainstorming, review, debugging, or verification, shaping should route execution toward them instead of inventing an ad hoc loop