planning

name	planning
description	Use when accepted Decodex work needs slicing.

Planning

Shape accepted work into Decodex-native issue briefs and Program Intake readiness. Read ../../references/routing.md for project policy and Program-vs-label dispatch rules.

• Use this only after explicit Decodex execution instruction or accepted project-policy authority.
• Own issue shaping here; do not call external delivery issue, split, brief, handoff, or progress skills for Decodex planning.
• Give each issue one outcome, scope, landing zone, acceptance, validation, dependencies, conflict-domain notes, and dispatch-ready briefing.
• Preserve accepted Decision Contract constraints, objections, stop conditions, validation, and conflict-domain notes.
• Each issue must be executable by a cold-start lane without chat replay: outcome, required reading, in-scope work, non-goals, landing zone, owner, acceptance, validation expectations, dependencies, blockers, conflict domains, and dispatch notes.
• Use real paths, commands, specs, runbooks, and policy. Do not invent modules, validation, tracker state, or runtime authority.
• Split work only by real ownership boundary, validation surface, dependency, or conflict domain; each child issue must still be executable on its own.
• For existing issue-batch intake, hold issues that lack a generic dispatch briefing instead of treating machine-only blocks, private pointers, progress checkpoints, or review summaries as executable issue text.
• When an MCP client is available, prefer intake_goal for typed Program Intake readiness/apply boundaries; dry-run stays non-mutating and apply requires explicit authority.
• Do not replace WORKFLOW.md, mutate active state, or queue unaccepted decisions.