| name | cybernetic-planning-workflow |
| description | Use when an approved non-trivial cybernetic requirements, design, and goal chain must be converted into an executable plan.control.json strategy before review. |
Cybernetic Planning Workflow
Purpose
Turn approved meaning into a candidate execution strategy without changing the
meaning, approving the strategy, or executing target work. The owning
writing-cybernetic-execution-policies skill writes the official JSON artifact.
Inputs
Read the approved requirements.control.json, any required
design.control.json, and goal.control.json. Treat their required outcomes,
non-goals, authority boundaries, and completion predicates as immutable inputs.
Workflow
- Build an outcome-to-producing-action map. Every blocking outcome needs an
action that can change its state and evidence that can observe that change.
- Build the dependency graph and critical path. Separate sequential work from
genuinely independent work.
- Define coherent work packages around state changes, not arbitrary file or
time slices. Do not predeclare source-file write allowlists: implementation
discovers the files needed to produce the approved state change. Keep
semantic scope, non-goals, live/destructive gates, and command capability
explicit.
- Select
Main-only, Serial subagent-driven, or Parallel subagent-driven
using the delegation registry and approved human/live gates.
- Define integration barriers, stale-evidence retirement, failure routing, and
typed stop conditions. Agent-owned repair remains an automatic action.
- Check projection completeness: every required outcome, result path, surface,
and completion claim must survive into the candidate plan.
Test And Evidence Policy
Do not impose TDD, red-green order, test counts, or per-package tests. Include a
test only when it captures a real counterexample, protects a critical invariant,
or materially lowers repeated acceptance cost. Counterexample Gate remains the
semantic quality entry.
Output
Return a complete candidate strategy to the owning execution-policy skill. It
must be representable by the current plan.control.json schema and must not rely
on conversational context that runtime cannot read.
Boundaries
- Do not modify approved requirements, design, or goal semantics.
- Do not execute target work or claim approval.
- Do not hide missing authority, evidence, or semantics in a generic blocker.
- If infrastructure required to produce the plan is missing, classify it as
shared_infrastructure and return to pre-goal diagnosis.
