Cl Execute

CL Execute

Purpose

Draft the required ClosedLoop-linked implementation plan, then execute one functional feature as a long-running goal. A feature is one complete selected user-facing page or capability delivered end to end, not automatically an entire PRD. It may be one ticket or one coherent multi-ticket unit explicitly selected by $cl-sweep; all member tickets and shipping surfaces required for that page or capability belong in one integrated pull request. Other pages or capabilities from the same PRD and separately owned shared-foundation prerequisites may remain outside this feature boundary.

$cl-execute <ClosedLoop feature URL or FEA/ISS slug>
$cl-execute batch: <ticket URL> <ticket URL> ...

$cl-analyze decides whether work is ready and whether a plan approval gate is required. $cl-execute owns plan drafting, plan review, upload/link, revision, approval-or-wait disposition, implementation, the two-pass coordinated code-review sequence, validation, PR handoff, merge disposition, and ticket/ plan reconciliation.

Treat the invocation as standing approval to create and approve the implementation plan after worker review, create a PR, address PR feedback, merge once CI is green and the PR is ready, and mark the feature done after merge. This approval applies only after the readiness gate passes and no human UI plan approval is required. It does not authorize high-complexity execution without an exact-ticket override, extreme-risk work, incoherent batches, duplicate/stale or blocked work, UI implementation without required human plan approval, manual CI or review triggers, or externally visible engineering/operational comments.

Do not post completion messages.

Sweep display activity

When invoked within a sweep, follow display events for both Desktop and CLI owners: report actual planning, coding, review and human-wait entry, and clear the phase on exit. Logging failures do not block work. Publish verified business status after existing authenticated ClosedLoop ticket reads, without additional wallpaper queries. Report explicitly established or cleared ticket dependencies using that reference.

Load References

Read only the references relevant to the current phase:

• Intake, readiness, requirements, plan drafting, contract audits, performance work, UI plan approval, or the one-off cleanup-tooling churn guard: references/planning-and-gates.md.
• CLI sweep context, support lanes, App Server worker continuity, callback protocol, or macOS GitHub transport fallback: references/support-lanes-and-sweeps.md.
• Source implementation, validation, review, review-learning persistence, per-branch push gates, PR creation, or PR comment handling: references/implementation-review-pr.md.
• The cross-family lane in each coordinated review generation (verified CLI commands, sandbox limits, fallback, reviewer prompt): references/cross-family-review.md.
• Post-PR author manual-QA plan comments, guided session evidence, head-change invalidation, or functional-readiness gating: references/feature-manual-qa.md.
• Passive monitoring, merge queue recovery, post-start blockers, merge disposition, or completion reconciliation: references/monitoring-merge-completion.md.
• Required CL Execute Gate Result or CL Execute Result output schemas: references/result-formats.md.
• Drafting a PR body, plan prose, the manual-QA comment, a Product-decision comment, a PR thread reply, a pause or resume note, or a result's free-text fields: references/writing.md.
• Scripts: scripts/check-plan.mjs lints a plan draft before review and upload; scripts/decision-log.sh appends to the private decision log.

If a phase crosses more than one category, read each matching reference before acting. Do not load every reference by default.

Shared Policy

Before routing blockers, recommending blocker communication, or writing externally visible blocker text, read the sibling policy skill at ../cl-policy/SKILL.md and follow its Required Reference resolution order. Use references/local-policy.md when present; otherwise use 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 and Engineering attention contact; do not hardcode a personal name for the engineering attention contact.

Hard Boundaries

• Treat ClosedLoop comments as company-visible product records. Keep every engineering/operational blocker private unless the user explicitly requests the exact comment. Only genuine Product-decision comments are automatic, and only after Product Answer Discovery proves the apparent question has not already been answered and the Product contact is available under current user/session context.
• Do not invoke $workflow-orchestrator, $workflow-execute, or any orchestrator-run ticket execution workflow.
• Do not invoke $cl-split, split tickets, create child tickets, or turn legacy split evidence into a split-repair route. Keep every issue as the single ticket it already is.
• Use the standalone workflow-memory CLI for repo-memory root resolution, queries, writes, validation, and attachments. Do not route memory access through workflow-orchestrator.
• Do not create, inspect, update, complete, fail, cancel, or emit events for ClosedLoop loops or manual loops. ClosedLoop MCP loop guidance is superseded by this boundary. Use ticket status, linked plan, pull request, validation evidence, structured result, and workflow repo memory as the execution record.
• Do not skip independent plan review, the required two-pass coordinated code-review sequence, PR comment handling, or current-head CI evidence.
• One feature has exactly one integrated PR, including when backend, Storybook, and production UI work originate in different member tickets. Do not split the functional delivery into per-surface PRs or infer whole-feature functionality from isolated member-ticket evidence.
• After the PR exists, create and maintain the single author-owned feature manual-QA plan comment in references/feature-manual-qa.md. Do not enqueue, merge, report readiness or functionality, or complete tickets until the responsible human author has supplied passing evidence for the relevant final change across the integrated feature.
• Do not wait for pending CI before addressing known open PR comments or review threads. Existing review feedback is PR work, not passive CI monitoring: fix, reply, resolve, and push the remediation as soon as focused validation passes. A pending older own-branch check is superseded by the PR-comment fix; do not hold the fix behind it.
• When live current-head PR CI is already green for all checks, or green for the specific check lanes a post-PR remediation delta can affect, treat that green CI as the broad validation evidence for everything outside the delta. Do not rerun a broad local validation suite for the delta. Use closedloop-graph code intelligence (code_tests_for when a checkout cannot provide better related-test data, and local related-test tooling when available) plus repo memory to select isolated tests/static checks for the files actually changed; run only those focused commands, mandatory hooks, and git diff --check unless the delta invalidates prior evidence, expands the touched surface, or touches an unindexed path where graph evidence cannot map the blast radius.
• Never manually trigger or retrigger GitHub CI or automated review. Observe and address automation that starts on its own.
• Never make a failing check pass by changing the check. That covers test assertions and expected values, snapshots and screenshot baselines, tolerances, skip and quarantine lists, timeouts, coverage thresholds, size and performance budgets, lint and type-error baselines, and harness code, and it covers restructuring product code only to satisfy a check. Change a check only when the requirements contract changed that behavior (cite the requirement beside the change in the result and the PR) or with the user's explicit approval for that exact change. Adopting a value that main already changed is integration, not a change to the check. If a baseline or expectation looks wrong, keep it and report it as a finding with evidence.
• Run exactly two coordinated $workflow-code-review generations before opening or finalizing the PR in both Codex Desktop and Codex CLI sessions: review, fix valid findings, review the remediated tree again, then fix valid second-pass findings. Never launch a third coordinated review generation after the second pass completes, including after further fixes, head changes, rebases, or integration.
• For each coordinated review generation, launch the full default $workflow-code-review lane set concurrently in one fan-out. The generic two-support-lane cap does not apply to these read-only review cohorts; do not serialize, batch, or throttle their lanes when concurrency slots are available. The same fan-out includes one read-only cross-family lane from references/cross-family-review.md: a Codex worker gets a Claude Code reviewer and a Claude Code worker gets a Codex reviewer. When that CLI cannot run, use its documented same-family fallback and record Cross-family review: unavailable; never skip it silently.
• Between the two review generations, run only the fast compile/static/focused- unit checks needed to keep the remediated snapshot reviewable. Defer broad, containerized, browser, Electron, and full-suite validation until all valid second-pass findings are fixed, then run that comprehensive validation once on the final tree unless an intermediate finding can be verified only at a real boundary.
• Every failing automatically reported current-head coverage check is the ticket worker's responsibility until green, even when branch protection does not mark it required.
• Do not classify a current-head red CI lane as "unrelated" and wait passively merely because the failure appears outside the touched files. First compare live evidence from current origin/main, the PR/merge-group head, and relevant peer PR runs when useful. If latest main already fixes the failure, integrate main into the branch and push. If other active PRs or latest main are green for the same lane, treat the failure as branch-caused, indirect, or flaky-but-owned by this PR until the worker fixes it or automatic rerun evidence proves the current head green. Only a CI-provider outage, credential outage, or job that cannot execute may be routed as an external wait, and the result must name the exact external owner/evidence.
• Do not gate pushes on repository-wide active CI branch counts. Inspect only this ticket branch for older queued/running CI.
• Do not merge or rebase current main into a green, mergeable PR head merely as a final-integration precaution. Integrate main only for a source conflict, proven unlanded dependency, or concrete queue/base failure evidence.
• Do not plan or implement third-party API, SDK, hosted platform, model provider, auth/billing provider, webhook, or fast-moving integration behavior from model memory alone. Consult official current online documentation and record the evidence.
• Do not report ENGINEERING_BLOCKED, BLOCKED_BEFORE_START, or any dependency blocker from ClosedLoop status or artifact links alone. First verify the blocker against live GitHub PR state, current origin/main ancestry, related plans/comments, closedloop-graph, and the current checkout. If a blocker ticket or BLOCKS link is stale because the blocking PR already merged, reconcile the stale ClosedLoop state/link when authorized by the lane, then re-run readiness instead of repeating the stale blocker.
• Do not ask for separate approval to approve the plan once gates are satisfied, except for UI work without a clear ticket design, screenshot, or prototype, or when the current sweep/session instruction requires Daniel's personal approval for every implementation plan.
• Every implementation plan draft or revision must use the mermaid-visualizer skill and include Mermaid flowchart code fences that help Daniel understand the scope of change. Default to before/after flowcharts for architecture, control-flow, data-flow, lifecycle, retry, persistence, or UI flow changes. If a different flowchart shape explains the scope better, use that shape, but do not omit diagrams merely because the change is non-UI.
• During an active planning, implementation, validation, or PR-handling turn, treat new human messages as queued input by default. A message about another issue, plan, PR, policy, or concern is not permission to drop the current action or reorder the lane. Preempt only when the human explicitly says to work on it immediately, stop, pause, abort, switch now, or when the message reports a material safety/security/production incident that makes continuing the current action unsafe. Otherwise acknowledge the queued item briefly, finish the current safe step, then process queued items in priority order.
• On an explicit pause or stop, finish or back out of the current atomic step, start nothing new, and stop running support lanes, except that an in-flight coordinated review generation completes and its artifacts are kept, because a launched generation counts toward the two. Take no push, PR, queue, or ticket-status action in order to pause. Leave uncommitted edits in the worktree and never make a wip: commit; under a sweep the parent's checkpoint captures dirty state, and standalone the note records git status. Write a resume note to the ticket's workflow-memory execution record using repo-relative paths only: intent, current phase, what is verified with evidence pointers, review generations and Parker pass used, the next action, and gotchas. Then return the current status with Blocker: paused by user instruction.
• UI PRs require Daniel's human/manual merge by default. Ready non-UI PRs use standing direct protected-queue authorization. UI, UI-impacting contract, or workflow changes require exactly one dedicated pre-PR Parker visual-QA pass before first push/open PR. The Parker Visual-QA Gate is the one owner of its timing, blockers, exceptions, handoff evidence, and head-change rules; read it before any UI push, PR, handoff, or ready claim.
• Preserve compatibility shims unless the user explicitly approves removal in the current task.
• Require automated browser E2E to be headless and Electron E2E to use the repository-supported displayless harness. Never silently fall back to headed or visible execution.
• Follow all applicable AGENTS.md, repo-local instructions, ClosedLoop status lifecycle rules, and compatibility guardrails.