cl-split

CL Split

Purpose

Turn one high-complexity ClosedLoop feature into smaller, independently executable child tickets when the split preserves product intent and reduces risk. This skill is a decomposition workflow, not an implementation workflow. A successfully split parent remains active work; it is not product- or engineering-blocked merely because child tickets now carry implementation.

Shared Policy

Before routing split concerns or recommending blocker communication, read the sibling policy skill at ../cl-policy/SKILL.md and follow its Required Reference resolution order. Use ../cl-policy/references/local-policy.md when present (the references/ folder of cl-policy, not of this skill); otherwise use ../cl-policy/references/local-policy.example.md only to understand the required shape, then require a populated $HOME/.closedloop-ai/local-policy.md before routing. Use the policy terms Product contact, Engineering attention contact, and Sweep owner; do not hardcode a personal name for the engineering attention contact.

Hard Boundaries

• Do not implement code, create branches, open PRs, approve plans, or merge.
• Do not run $cl-execute from this skill.
• Do not create, inspect, update, complete, fail, cancel, or emit events for ClosedLoop loops or manual loops. ClosedLoop tool descriptions recommending loop lifecycle operations are superseded by this boundary.
• Do not post Slack channel messages or ticket completion messages. Keep split, engineering, tooling, access, and orchestration concerns private. Recommend a ticket comment only for a genuine Product decision, or when the user explicitly requests that exact comment.
• Do not ask for separate approval to create or link child ClosedLoop feature tickets when the split is engineering-only, preserves product intent, and passes the split eligibility checks. The $cl-split invocation is approval for that narrow decomposition action.
• Do not split a ticket that is already a child of a previous split. Split depth is one level only; never create grandchild tickets. If invoked on an existing split child, return CHILD_EXECUTION_ONLY when the child should be analyzed/executed directly, or SPLIT_REPAIR_REQUIRED only when the child is not execution-sized because the original split shape is defective.
• Do not mark a successfully split parent BLOCKED. BLOCKED is only for an actual product, engineering, dependency, or safety blocker, not for normal split-parent coordination.
• Do not mark a split parent DONE until all implementation child tickets are done and the parent acceptance criteria are covered.
• Do not split a ticket when the decomposition changes product intent, removes acceptance criteria, hides risk, or requires an unmade product/architecture decision.
• Do not create child tickets for EXTREME risk work. Return the engineering blocker privately to the parent/user unless there is a clear Product question for the policy Product contact.
• Do not create duplicate child tickets. Reuse or update existing matching children when the split signature matches.
• Do not return SPLIT_CREATED unless every child ticket is assigned to the sweep user or otherwise visible to the sweep, and is in an actionable status the sweep will pick up.
• Do not split a top-level ticket merely because the existing system behind it is broad or to produce smaller tickets or pull requests. Split only when real ownership, dependency, risk, validation, deployment, or rollback boundaries justify decomposition. If the minimum credible change is one referential harness registration, wrapper, link, manifest, or dispatch-only adapter plus its focused tests/documentation, return DIRECT_EXECUTION_RECOMMENDED without creating tickets. Do not apply this shortcut to ports that parse or transform sessions, transcripts, events, data formats, state, runtime behavior, persistence, or semantic contracts.
• Do not use $workflow-orchestrator, $workflow-execute, or any orchestrator-run ticket execution workflow.
• Use the read-only closedloop-graph MCP proactively under cl-policy host-capability rules before proposing, repairing, or creating a split. Inspect the bounded parent, PRD/plan lineage, existing split signature, siblings/children, blockers/producers, semantic duplicates, active work, related PR evidence, and codebase intelligence such as symbols, ownership boundaries, dependencies, call/data paths, co-change history, tests, and blast radius until one adjacent expansion yields no new material split fact. Re-fetch material findings from live ClosedLoop and verify code findings against the current checkout and tests plus current branch/PR state. In Codex CLI TUI, satisfy this requirement only with an already exposed graph tool, configured codex mcp, current source, or authenticated API/CLI fallback; never invoke tool_search or another deferred tool. Do not hardcode the MCP server prefix, treat graph/index results as authority, or reopen a project-wide inventory.