Goal-Driven Long-Run Workflow

Run an agent autonomously for hours toward a verifiable goal. Primary harness example: Claude Code's native /goal (condition + evaluator loop). This skill adds requirement alignment, acceptance layering, sub-agent context management, and post-run reporting — plus a generic fallback when /goal is unavailable. Stages 1–3 are read-only design; stage 4 is the run; stage 5 is reporting/acceptance. Default is manual mode (pause at each stage exit). On a standalone invocation, 「自动模式」/「自动跑」 / "auto mode" still pauses at stages 1–3 and at Stage 4 launch approval; it does not skip those confirms and does not start the harness. Queue-child invocations follow Stage-exit policy (see below). Output templates: reference.md.

Invocation Conventions

• Trigger words (per description): 「goal 长跑」「goal run」「goal-driven」「目标驱动长跑」「一个 goal 下去跑」「长跑目标」「无人值守跑任务」「goal-run」 / goal run, goal-driven, long-run goal, autonomous run, run until done
• Command form: /goal-driven-workflow xxx, /goal-run xxx
• Default behavior: treat xxx as the task to run as a goal; enter stage 1 (clarify). If xxx already has a concrete verifiable goal + acceptance criteria, skip ahead to stage 2 after outputting Template 1 (frozen block or an explicit stage-1-N/A line) and obtaining one confirmation of it — that confirmation counts as stage 1 complete for Design-checked.
• Not applicable: single-step edits, tasks with no verifiable end state, or tasks better served by recurring /loop-style polling or plain single-turn auto approvals. Single-run tasks shaped for stage-gated PDCA (per-stage artifacts and verdicts rather than a run-to-completion loop) route to solve-workflow / opsx-solve-workflow directly — engine selection at dispatch belongs to the queue layer (goal-driven-queue).

Strong dependencies

Frontmatter dependencies; prerequisite check must pass or the flow aborts: