cybernetic-planning-workflow

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

1. 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.
2. Build the dependency graph and critical path. Separate sequential work from genuinely independent work.
3. 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.
4. Select Main-only, Serial subagent-driven, or Parallel subagent-driven using the delegation registry and approved human/live gates.
5. Define integration barriers, stale-evidence retirement, failure routing, and typed stop conditions. Agent-owned repair remains an automatic action.
6. 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.