harnessloop-looplisted

# Harnessloop Use this skill as a project-local operating protocol. Do not treat it as a generic engineering checklist. ## Input Contract Accept one of these inputs: - A user goal for a long-running task, including target project path when it is not the current working directory. - An explicit skill invocation such as `$harnessloop-loop`, `$harnessloop-goal`, `$harnessloop-status`, `$harnessloop-continue`, `$harnessloop-evidence`, `$harnessloop-channels`, `$harnessloop-connectivity`, `$harnessloop-delegation`, or `$harnessloop-secrets`. - Natural-language aliases such as `harnessloop:goal`, `harnessloop:status`, `harnessloop:continue`, `harnessloop:evidence`, `harnessloop:channels`, `harnessloop:connectivity`, `harnessloop contract control`, or `harnessloop issue evolve`. Skill names cannot contain `:`, so `$harnessloop:...` is not valid. - Existing `.harnessloop/` state files that define the active goal, round, evidence, handoffs, and control state. - A takeover request only after `harnessloop-intake` has produced or accepted the intake packet, gate, and intake-review boundary. The useful input should include goal/non-goal context, acceptance criteria, relevant file paths, available validation commands, external tool requirements, and any required human decisions. If these are missing, create the smallest setup, status, or gap request instead of inventing facts. If the user or contract requires a specific tool call, the input must identify the tool name, intended opera