LoopX Project Workflow

Use this skill when the requested operation changes or diagnoses the project lifecycle, Goal configuration, registry routing, or status projection, or a direct user request materially refines the bound Goal’s supporting outcomes. A LoopX mention, registry path, or routine refresh-state command in an admitted task does not by itself select the project lifecycle workflow.

For ordinary task execution, follow the current interaction_contract, its required reads and ordered settlement commands. Do not repeat onboarding, registry synchronization, or lifecycle discovery merely to execute that packet. This routing rule does not replace fresh admission, lease checks, required reads, or repair instructions. A missing or contradictory contract still needs the relevant diagnosis; an explicit request to use this skill still applies.

If the task is mainly about reading, remembering, recording, indexing, or registering a durable project material, load loopx-doc-registry and use that narrower workflow first.

LoopX has two layers:

• Project-local state: each repo owns .loopx/registry.json; new Goal state defaults to .loopx/goals/<goal-id>/ACTIVE_GOAL_STATE.md.
• Shared local control plane: the default ~/.loopx stores run history and registry.global.json for multi-project status.

Use the registry-declared state_file and the resolved runtime/global-registry route for existing installations. .codex/goals and ~/.codex/loopx are legacy compatibility paths, not defaults to recreate or migrate implicitly. If routes conflict, diagnose the existing state before selecting or migrating one.

Do not manually copy one project's registry entry into another project. Local connect and refresh-state should sync into the shared global registry automatically.

Read The Relevant Procedure Before Acting