# Goal Exec > Convert an explicit user request into a Codex goal and pass its chosen coder, Lev, LazyCodex, SDD, or Fable execution flags to $coder. - Skill: `lev-os/goal-exec` (Agent Skill) - Install (CLI): `npx skillmds@latest add lev-os/goal-exec` - Raw SKILL.md: https://api.skillmd.com/api/skills/lev-os/goal-exec/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: lev-os (https://skillmd.com/u/lev-os) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/lev-os/goal-exec --- # Goal Exec Use this only before `create_goal` when the user explicitly asks to set or run a goal. The goal describes the domain outcome. Load `skill://coder`; `$coder` owns execution mechanics. For `--lev`, also load `skill://exec` and resolve the flow as `lev://exec/` rather than treating the skill pointer as a runtime URI. ## Flags ```text $goal-exec [--coder] [--lev] [--sdd[=checkpoint|pair]] [--lazycodex] [--fable] ``` | Flag | Contract | |---|---| | `--coder` | Load `$coder`; use its direct single-worker mode unless another topology flag is present. | | `--lev` | Pass `--lev`; execution must use `lev exec` and project FlowMind/profile policy. | | `--sdd` | Pass `--sdd=checkpoint`. | | `--sdd=checkpoint|pair` | Pass the exact SDD mode. Reject other values. | | `--lazycodex` | Pass through; use the inline LazyCodex protocol in `$coder`. | | `--fable` | Pass through; prefer the configured Fable reviewer profile. | `--coder` selects the execution owner. The remaining flags refine `$coder` and must be copied unchanged into the goal's `Tools:` clause. `--sdd`, `--lazycodex`, or `--fable` imply `--coder`. `--fable` requires SDD because it selects the reviewer, never the coder. Reject contradictions instead of silently dropping or substituting flags. ## Long-Horizon Goal Navigation When the user explicitly creates a long-horizon or multi-session goal, read [recursive wayfinding](../lev/references/recursive.md) and arrange exactly one navigation heartbeat bound to that goal. Ordinary discussion, planning, or a bounded goal does not create one. The default cadence is 30 minutes unless resolved project configuration supplies another interval. Before creating the goal or heartbeat, resolve and freeze the navigation packet: ```yaml goal_ref: outcome_ref: outcome_map_ref: workstream_ref: tracker_binding: policy_provenance: tick_policy: outcome_navigation heartbeat_idempotency_key: rolling_horizon_ref: allowed_effects: [] stop_conditions: - goal_paused - goal_cancelled - outcome_confirmed_complete - budget_exhausted - blocker_requires_human_or_external_change ``` If the tracker is unconfigured, ask once among the mechanically supported Markdown, Beads, and GitHub choices, then persist the selection. Resume reuses that binding. An unavailable backend blocks tracker effects; it never causes a write to another backend. Do not create the goal until this required choice is resolved. Before creating the goal, confirm the host exposes a callable thread-heartbeat automation surface. After goal creation succeeds, finalize `goal_ref`, derive a stable automation idempotency key from `goal_ref + tick_policy`, then inspect existing automations by that key. Update the matching heartbeat when present or create one when absent. Never use a display name alone as identity. If the host cannot create or update a heartbeat, report that capability gap; never invent an automation ID or claim scheduling succeeded. Deduplicate timer and worker-return wakes so only one tick can advance a given navigation revision. Pause, cancellation, and confirmed completion disable the heartbeat through the same host surface. Repeated unchanged blocked or live-worker states stay quiet; surface only a changed failure, a required decision, or a meaningful route update. Use this heartbeat meta-prompt with the resolved packet injected by the host. The heartbeat must consume the packet; it does not look up project config: ```text Reconcile current evidence against the bound outcome. Retrieve relevant prior learning. If the selected step is vague or its assumptions failed, run the recursive wayfinding procedure. Refresh the rolling horizon after material changes, keeping steps 1-3 actionable and steps 4-10 appropriately coarse. Select one eligible tick and resume at most one coherent unit within the supplied authority. Do not duplicate a live worker or infer release, publishing, or marketing permission. If waiting remains correct, stay quiet. Stop when the goal is paused, cancelled, or confirmed complete. ``` The heartbeat is a navigation wake, not a second worker. It reconciles evidence before choosing one deterministic tick: required review, wayfind/research, authorized execution, due hygiene, or separately authorized release/publish. It must not rediscover arbitrary config, rewrite an unchanged plan, or treat no eligible work as completion. ## Pre-create Gate Before calling `create_goal`, display the complete goal prompt and, for a long-horizon goal, its resolved navigation packet. Together they must contain: 1. `Hard refs:` exact absolute paths to governing plans/specs. 2. `Outcome:` the stable observable domain result. 3. `Plan:` the ordered execution sequence; for long-horizon work, the outcome-map reference and at most ten stable-ID rolling-horizon steps with unresolved fog. 4. `Acceptance:` hard-cut observable completion criteria. 5. `Batch gates:` controller checks after each applicable batch. 6. `Stop rules:` blockers, review, timeout, identity/session, and dirty-work protections. Do not create a goal, dispatch a worker, or modify code while one is absent. Create a goal only with explicit user authorization and set a token budget only when the user supplies one. For long-horizon work, the stable objective may reference the displayed durable navigation packet rather than repeat its evolving horizon. Do not invent acceptance criteria or replace exact references with conversation shorthand. For SDD, carry the selected `$coder` topology into the packet: PR-sized batches, controller gates before review, one reviewer covering spec and code quality, timeout/no-result handling, and scoped staging with the authorized commit/push policy. Do not review partial diffs unless diagnosis is explicitly requested. Keep scope, exclusions, source refs and other tasks' ownership explicit. Use first-principles analysis, premortems or expert lenses only for unresolved choices or material risk; architectural patterns come from the task or repo. ## Goal Prompt Keep workflow out of the objective and place the resolved flags in one short tools clause: ```text Outcome: . Tools: $coder as the bounded execution surface. Hard refs: . Plan: . Acceptance: . Batch gates: . Stop rules: stop on a failed gate, material decision, unavailable required identity/profile, unusable explicit session after one focused retry, the same blocker twice, or scope conflict with existing work. ``` Source coding standards from the nearest project instructions, DNA/rules, docs, and `.lev/validation-gates.yaml`. Model selection belongs to the selected project execution profile or FlowMind binding. The goal may name a model only for an explicit current-run user override. Before emitting `--lev`, inspect `lev exec --help`, the selected task `execution.yaml`, FlowMind file, and project `.lev/exec-profiles/`. Prefer a declared `--flow` or `--profile`; never guess current flags or model aliases.